DETAILED ACTION
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 Rejections - 35 USC § 103
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-5, 7-10, 12-16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Sathianarayanan et al. (US PGPUB 2020/0401506; hereinafter “Sath”) in view of Gonzales (US PGPUB 2009/0271764; hereinafter “Gonzales”), Gu et al. (US PGPUB 2023/0127800; hereinafter “Gu”), Groenewegen et al. (US PGPUB 2024/0004623; hereinafter “Groenewegen”), Daunais et al. (US PGPUB 2023/0418727; hereinafter “Daunais”) and Deodhar et al. (US PGPUB 2017/0116552; hereinafter “Deodhar”).
Claim 1: (Currently Amended)
Sath teaches a system to facilitate automated testing for an enterprise data application layer, comprising:
an Automated Testing Framework (‘ATF’) platform ([0044] “The framework 100 shown in FIG. 1 is merely illustrative. In accordance with various embodiments, the automated testing framework…”), including:
a computer processor for executing program instructions; and a memory, coupled to the computer processor, for storing program instructions that, when executed by the computer processor, cause the ATF platform to ([0082] “the framework 100 includes an electronic device having one or more processors and memory storing one or more programs configured for execution by the one or more processors.”):
during a test design phase, receive, from a user, data test planning information that defines a test case and store information via a third-party enterprise team planning system ([0046] “data required for API testing (i.e., data either input by the user or generated by the framework 100 according to user data) is categorized into a plurality of groups (e.g., six groups)… Subsequently, this data is stored in the database 126 that acts as the data store for the data model. In some embodiments, the select groups are: test scenarios, test cases, an inventory of APIs, test data, and response validation data (sometimes called validation data).” [0039] “test lifecycle (or test case) management tools 108 to support, interface or integrate with test case management infrastructure, such as HP ALM (Application Lifecycle Management), CA Rally (an agile project management solution), or QA Symphony's qTest (a test case management tool)… the test lifecycle management tools 108 is implemented as a database store that includes information to manage lifecycle of tests.”),
automatically verify the test case via an ATF Application Programming Interface ("API") ([0041] “The core engine 112 further includes a validation component 122 to retrieve validation data from the database 126, and to validate response data for the APIs invoked by the API invocation module 116. In some instances, the validation component 122 executes database calls and/or generate database queries to retrieve reference data for validation against the responses for the APIs invoked by the API invocation module 116 (described below). In some embodiments, the validation component 122 validates response data at various testing levels (e.g., testing with increasing complexity, or testing according to test levels as specified by a user).”),
during a test execution phase, detect a trigger event, from a user or a system, that initiates a test execution associated with the test case ([0047] “the execution control column allows the user to specify to the test engine whether to execute a particular test scenario (sometimes called a scenario) listed in the input files.”),
receive test execution information to be referred from the third-party enterprise team planning system ([0081] “The test scripts 220… interfaces with application lifecycle management tools and databases… and/or TFS module or job 116… to start (224) regression tests (sometimes called a test case)… The request builder 222 is in a continuous loop as indicated by LOOP (that terminates only if there are no more tests to execute).”), and
determine test results for the executed test case scenarios and store them within the third-party enterprise team planning system ([0039] “The reporting layer 106 includes test lifecycle (or test case) management tools 108 to support, interface or integrate with test case management infrastructure, such as HP ALM (Application Lifecycle Management), CA Rally (an agile project management solution), or QA Symphony's qTest (a test case management tool), to track API testing status… The reporting layer 106 also includes test reports 136 in various formats.”).
With further regard to Claim 1, Sath does not teach the following, however, Gonzales teaches:
wherein the verification is associated with missing inputs, and automatically transmit a warning in a case inputs are missing ([0042] “the request management module 34 also checks to ensure that all of the required fields are populated. In the embodiment shown, the module 34 ensures that all of the fields with an asterisk are populated. If not, an error message is generated and the user is prompted to input the missing required field.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Sath with the verification and warning regarding missing inputs as taught by Gonzales since “Such error checking ensures that the initial submission of a request for environment setup is sufficient for an administrator to set up the test environment without going back to the user for more information” (Gonzales [0042]).
With further regard to Claim 1, Sath in view of Gonzales does not teach the following, however, Gu teaches:
refer a Data Test Automation-as-a-Service ("DTAaaS") capability from a DTAaaS capability store to execute data test scenarios ([0023] “A centralized TaaS Orchestrator (TO) is used to define/manage the Network Topology under test for TaaS execution. In one example embodiments, the TaaS Orchestrator works with IBM Orchestrator, for example, to manage network slicing and CI/CD process in general.” [0029] “As shown in FIG. 3, the TaaS Orchestrator… activates the CDT to produce the testing personality (emulator or nodal) and executes Test Cases and record test data into the Data Lake 304.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Sath in view of Gonzales with the testing service as taught by Gu as this “improves flexibility as well as reduces the overall testing costs” (Gu [0025]).
With further regard to Claim 1, Sath in view of Gonzales and Gu does not teach the following, however, Groenewegen teaches:
generate predictive modeling-based help suggestions to resolve exceptions encountered during test execution ([0063] “the software 302 receives 612 a set 324 of several suggestions 312, and chooses 616 an optimal one or an optimal subset to present 618 to the user. The set 324 of fix candidates 312 can collectively come from one or more weakness fixers 212, e.g., the set may include several candidates from a single model 322, or one respective candidate from each of several different models 322.”),
perform defect management within the third-party enterprise team planning system ([0089] “If a testing tool runs ten unit tests and one fails (due to inaccurate behavior, sub-optimal performance, insecurity, etc.), the failure message may indicate a block that is likely broken. Then the enhanced system may invoke an AI fixer on that block to generate a possible fix 312 for the code. The fix can be checked by running the unit tests before it is suggested.”), and
generate a user notification via a third-party enterprise communication platform ([0096] “Some embodiments change user interface focus to the file to be fixed, with a suggested fix 312 displayed in the UI, e.g., as a diff or as gray text.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Sath in view of Gonzales and Gu with the modelling-based help as taught by Groenewegen in order to “support source code editing and promote improved code quality” (Groenewegen [0014]).
With further regard to Claim 1, Sath in view of Gonzales, Gu and Groenewegen does not teach the following, however, Daunais teaches:
provide at least one dashboard display to the user including all of ([0023] “FIG. 1 is a block diagram that depicts an example design flow 100 pertaining to a user interface tool, in an embodiment. The user interface tool that generates report data pertaining to software tests and defects and provides a user interface for navigating the corresponding reports resulting from those software tests… Hereafter, ‘user interface tool’ and ‘Quality Dashboard’ are used interchangeably.”):
(i) a test execution report ([0049] “FIG. 3B is a screenshot of user interface 350 that lists details about multiple test cases”),
(ii) a test execution summary (See Fig. 3B: Status Column, [0049] “user interface 350 comprises a table 360, where each row corresponds to a different test case and columns include … a status of the test case (e.g., pass, fail, work-in-progress (WIP), or blocked).”),
(iii) a detailed report ([0052] “FIG. 3D is a screenshot of an example user interface 390 that includes details about a selected test case.”),
(iv) historical trends ([0085] “The user interface tool enables the comparison of current build health with previous ones. Thus, a software development team can retrospect on what went well, what did not go well, and can plan on areas of improvement.”),
(v) sprint information (See Fig. 3B: Status Column, [0049] “user interface 350 comprises a table 360, where each row corresponds to a different test case and columns include a sprint identifier, a drop identifier, a test case identifier, a description of the test case, a status of the test case (e.g., pass, fail, work-in-progress (WIP), or blocked).”),
(vii) server usage ([0065] “FIG. 4E. User interface 490 includes information about different API calls that a software build makes when executed. In this example, table 492 lists nine API calls and, for each API call, a request type (i.e., POST, GET, PATCH), an endpoint, and a name of an API call, where the name includes a link to a description of the API call,” wherein the API calls show in Fig. 4E include server target/endpoint information.), and
(viii) team usage ([0038] “. Main page 200 includes a navigation panel 210 that includes selectable options that allow the user (interacting with the QD [Quality Dashboard]) to navigate through all the information available through the QD. The selectable options include:” [0039] “a. a team option 211 that, when selected, causes the user interface to be updated to include information about a software development team responsible for a software project.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Sath in view of Gonzales, Gu and Groenewegen with the dashboard display as taught by Daunais in order to “allow information and changes to that information to be updated, communicated, and distributed more quickly in a rich project-specific context” (Daunais [0022]).
With further regard to Claim 1, Sath in view of Gonzales, Gu, Groenewegen and Daunais does not teach the following, however, Deodhar teaches:
(vi) adoption consistency including an adoption consistency status summary for all users and an adoption consistency status-per-user ([0013] “The term ‘organization sub-units’ in this specification relates to the entire organization or any part thereof, including business units, projects, teams.” [1054] “The systems and methods of present disclosure support extensive analytics. The organization effort aggregation and analytics engine 414 derives a per-employee daily average of Work Pattern. This is a powerful metric that facilitates meaningful and direct comparisons between any two or more organization sub-units of any type, including individual employees. Various trends and reports are available to compare the average daily productive time across various Purposes, Activities, applications, artifacts, online and offline time distribution, work focus, breaks taken, capacity utilization and so on. The reports and trends are available on daily, weekly, monthly or cumulative basis over a specified time range, or during the project or organization lifecycle phases,” wherein the metrics regarding the “Work Pattern” and “Average Daily Productive Time” are equivalent to the claimed “adoption consistency”, as evidenced by Fig. 28 of the Applicant’s disclosure which shows an example of the “Adoption Consistency” dashboard information. [1058] “a web user interface 430 that is accessed using any standard internet browser or standalone web applications. It enables users to view trends, reports, set goals, alerts, goal compliance, and performs administrative functions,” see also ‘Table 8’ below Paragraph [0615] which shows an example of the type of information that may be aggregated and displayed, both for “all users” and “per-user”.), and
(ix) an enterprise leaderboard ([1048] “The present disclosure provides for exact effort and time productivity measurement at enterprise level.” [1058] “[1058] “a web user interface 430… to view trends, reports…” [0822] “Table 10 summarizes an example of how to compute the work time for the organization sub-units for one week period” See also ‘Table 10’ below Paragraph [0822] which includes metrics such as “Delivered Capacity as % of Available Capacity: shows how busy the user is, and if they can achieve more,” wherein the metrics shown in ‘Table 10’ serve as a type of “Enterprise Leaderboard” since they enable a comparison between different enterprise teams and business units (BUs).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Sath in view of Gonzales, Gu, Groenewegen and Daunais with the dashboard display metrics as taught by Deodhar as this provides “exact effort and time productivity measurement at organization level without any manual definition or configuration of employee groups or attributes” (Deodhar [0045]) for purposes of “improving productivity and workload allocation, and optimizing workforce and operational efficiency” (Deodhar [0034]).
Claim 2:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1. However, Sath in view of Gonzales, Groenewegen, Daunais and Deodhar does not teach the following, but Gu teaches,
wherein the DTAaaS capability store holds test automation capability for various test scenarios ([0022] “FIG. 1B is a diagram showing example NSs of a CNN under test, each for different testing environments and each including a plurality of NCs, according to various embodiments of the present disclosure. Four example NSs are shown in FIG. 1B. However, fewer or additional NSs may be generated in various different embodiments for various different testing environment by cloning the CNN (i.e. the production environment). In the example shown in FIG. 1B, a different NS is generated for the development environment 116, the integration environment 114, the pre-production environment 112 and the production environment 110. Each NS has its own set of respective NCs cloned from the production environment 110.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system as disclosed by Sath in view of Gonzales, Groenewegen, Daunais and Deodhar with the testing service capabilities as taught by Gu as this “improves flexibility as well as reduces the overall testing costs” (Gu [0025]).
Claim 3:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1, and Sath further teaches wherein the data test planning information received from the user includes information about at least one of (i) test script design, (ii) test plan creation, (iii) a bulk upload template, (iv) a spreadsheet application record, (v) a test locator, (vi) a test case name, (vii) a test case description, and (viii) test case inputs ([0046] “data required for API testing (i.e., data either input by the user…) is categorized into a plurality of groups (e.g., six groups)… the select groups are: test scenarios, test cases, an inventory of APIs, test data, and response validation data (sometimes called validation data).”).
Claim 4:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1, and Sath further teaches wherein each test result comprises one of: (i) pass,
(ii) fail, and (iii) inconclusive ([0059] “For example, if the test category is basic, then the framework 100 verifies a status code in the response and/or marks the test as a pass or a fail depending on the test code.”).
Claim 5:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1, and Sath further teaches wherein information about the test case is stored via a third-party hosting service for software development and version control ([0046] “data required for API testing (i.e., data either input by the user or generated by the framework 100 according to user data) is categorized into a plurality of groups (e.g., six groups)… Subsequently, this data is stored in the database 126 that acts as the data store for the data model. In some embodiments, the select groups are: test scenarios, test cases, an inventory of APIs, test data, and response validation data (sometimes called validation data).” [0039] “test lifecycle (or test case) management tools 108 to support, interface or integrate with test case management infrastructure, such as HP ALM (Application Lifecycle Management), CA Rally (an agile project management solution), or QA Symphony's qTest (a test case management tool)… the test lifecycle management tools 108 is implemented as a database store that includes information to manage lifecycle of tests,” wherein the disclosed “HP ALM”, “CA Rally” and “qTEST” are examples of a “third-party hosting service for software development and version control”.),
Claim 7: (Currently Amended)
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1, and Sath further teaches wherein the verification is further associated with at least one of: (i) a test environment, (ii) test parameters ([0041] “the validation component 122 executes database calls and/or generate database queries to retrieve reference data for validation against the responses for the APIs invoked by the API invocation module 116 (described below). In some embodiments, the validation component 122 validates response data at various testing levels (e.g., testing with increasing complexity, or testing according to test levels as specified by a user),” wherein testing “response data” is associated with at least “a test environment” since the “response data” was generated using “a test environment”.).
Claim 8:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1. However, Sath in view of Gonzales, Gu, Daunais and Deodhar does not teach the following, but Groenewegen teaches,
wherein user notification is automatically transmitted to the user ([0277] “During software 132 development 318, embodiments find 606 various kinds of weak spots 208 in source code 130 and automatically suggest 618 fixes 214 to strengthen 620 the code 130, without requiring developers 104 to expressly select weakness finder mechanisms 210 or fixer mechanisms 212 by navigating a development tool 320 menu 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 have modified the system as disclosed by Sath in view of Gonzales, Gu, Daunais and Deodhar with the automatic notification as taught by Groenewegen in order to “support source code editing and promote improved code quality” (Groenewegen [0014]).
Claim 9:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1, and Sath further teaches wherein the trigger event comprises at least one of:
(i) a standalone testing trigger, (ii) a command line interface trigger, (iii) a workload scheduler trigger, (iv) a third-party enterprise communication platform chat trigger, (v) a third-party enterprise team planning system trigger, (vi) a continuous testing trigger, (vii) an ATF API trigger, and (viii) natural language processing ([0081] “. The request builder 222 is in a continuous loop as indicated by LOOP (that terminates only if there are no more tests to execute),” wherein the “continuous loop” is “(vi) a continuous testing trigger.”).
Claim 10:
Sath in view of Gonzales, Gu, Groenewegen, Daunais and Deodhar teaches the system of claim 1, and Sath further teaches wherein data test scenarios are executed via the DTAaaS include at least one of:
(i) database conversion, (ii) file format conversion, (iii) data ingestion validation, (iv) file feed validation, (v) table-to-table count validation, (vi) trend drift detection, (vii) JavaScript Object Notation ("JSON") structure validation, (viii) data quality checks, (ix) data reconciliation across heterogeneous data platforms including data stores and file systems, and (x) data profiling ([0046] “data for the remaining one or more groups are imported into the database 126 in a specific format (e.g., as a JSON file; for raw test data, test scenarios, and test cases). In some embodiments, the specifically formatted file (e.g., the JSON file) is exported to a second format (e.g., a POSTMAN format, such as Postman Export V2.1). In some embodiments, a RESTClient (an application for talking to RESTful web services) uses the second format (sometimes called a request format) to communicate with an API endpoint or server, and the server responds to the request after performing the operations with results,” wherein the “the specifically formatted file (e.g., the JSON file) is exported to a second format” language discloses a type of “(ii) file format conversion.”).
Claims 12-16 and 18:
With regard to Claims 12-16 and 18, these claims are equivalent in scope to Claims 1-5 and 7 rejected above, merely having a different independent claim type, and as such Claims 12-16 and 18 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1-5 and 7.
Claims 19 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Sath in view of Gonzales, Epperlein et al. (US PGPUB 2019/0235994; hereinafter “Epperlein”), Atyam et al. (US PGPUB 2018/0329807; hereinafter “Atyam”), Daunais and Deodhar.
Claim 19: (Currently Amended)
Sath teaches a non-transitory computer-readable medium storing instructions adapted to be executed by a computer processor to perform a method to facilitate automated testing for an enterprise data application layer, the method comprising ([0022] “In accordance with some implementations, a non-transitory computer-readable storage medium has one or more processors and memory storing one or more programs executable by the one or more processors. The one or more programs include instructions for performing any of the methods described herein.”):
receiving, from a user at a computer processor of an Automated Testing Framework ("ATF") platform, data test planning information that defines a test case ([0044] “The framework 100 shown in FIG. 1 is merely illustrative. In accordance with various embodiments, the automated testing framework…” [0046] “data required for API testing (i.e., data either input by the user or generated by the framework 100 according to user data) is categorized into a plurality of groups (e.g., six groups)… Subsequently, this data is stored in the database 126 that acts as the data store for the data model. In some embodiments, the select groups are: test scenarios, test cases, an inventory of APIs, test data, and response validation data (sometimes called validation data).”);
automatically verifying the test case via an ATF Application Programming Interface ("API") ([0041] “The core engine 112 further includes a validation component 122 to retrieve validation data from the database 126, and to validate response data for the APIs invoked by the API invocation module 116. In some instances, the validation component 122 executes database calls and/or generate database queries to retrieve reference data for validation against the responses for the APIs invoked by the API invocation module 116 (described below). In some embodiments, the validation component 122 validates response data at various testing levels (e.g., testing with increasing complexity, or testing according to test levels as specified by a user).”),
detecting a trigger event that initiates a test execution associated with the test case ([0047] “the execution control column allows the user to specify to the test engine whether to execute a particular test scenario (sometimes called a scenario) listed in the input files.”);
outputting a test result of the executed test case ([0039] “The reporting layer 106 includes test lifecycle (or test case) management tools 108 to support, interface or integrate with test case management infrastructure, such as HP ALM (Application Lifecycle Management), CA Rally (an agile project management solution), or QA Symphony's qTest (a test case management tool), to track API testing status… The reporting layer 106 also includes test reports 136 in various formats.”).
With further regard to Claim 19, Sath does not teach the following, however, Gonzales teaches:
wherein the verification is associated with missing inputs, and automatically transmitting a warning in a case inputs are missing ([0042] “the request management module 34 also checks to ensure that all of the required fields are populated. In the embodiment shown, the module 34 ensures that all of the fields with an asterisk are populated. If not, an error message is generated and the user is prompted to input the missing required field.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the medium as disclosed by Sath with the verification and warning regarding missing inputs as taught by Gonzales since “Such error checking ensures that the initial submission of a request for environment setup is sufficient for an administrator to set up the test environment without going back to the user for more information” (Gonzales [0042]).
With further regard to Claim 19, Sath in view of Gonzales does not teach the following, however, Epperlein teaches:
interpreting API information to implement a Data Test Automation-as-a-Service ("DTAaaS") ([0085] “The user may be provided access to a Rest-based API (or other type) to use the HiLaaS interface. The user may create a simulation and may define one or more simulation parameters such as, for example, defining a specific scenario via configuration files”); and
responsive to the detected trigger, automatically arranging to execute the test case via the DTAaaS ([0078] “The HiLaaS 404 may be application-independent. To test a specific application or service, a set of test cases and scenarios may be executed and evaluated, which may be the role of the test system 408. The test system 408 may be a system that runs specific scenarios (using the HiLaaS 404) related to an application and measures the success of the application in those scenarios.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the medium as disclosed by Sath in view of Gonzales with the testing service as taught by Epperlein since “it may not be economical to purchase the high-performance hardware for the purposes of the test, HiLaaS testing provides access to the high-performance hardware ‘as a service’ (e.g., as a service on demand), whereby the high-performance computing facilities are shared in a cloud computing environment” (Epperlein [0023]).
With further regard to Claim 19, Sath in view of Gonzales and Epperlein does not teach the following, but Atyam teaches,
wherein a test case creation notification is automatically transmitted to the user ([0016] “identifying areas of code that are not covered by any currently existing automated test cases allows the testing tool to generate notifications for a development team to create test cases for that code… the developer can review notifications generated by the testing tool and accordingly create a test case.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the medium as disclosed by Sath in view of Gonzales and Epperlein with the test case creation notification as taught by Atyam since “Doing so eliminates manual guesswork for a developer in determining whether to create a test case for a new functionality provided by a patch” (Atyam [0016]).
With further regard to Claim 19, Sath in view of Gonzales, Epperlein and Atyam does not teach the following, however, Daunais teaches:
providing at least one dashboard display to the user including all of ([0023] “FIG. 1 is a block diagram that depicts an example design flow 100 pertaining to a user interface tool, in an embodiment. The user interface tool that generates report data pertaining to software tests and defects and provides a user interface for navigating the corresponding reports resulting from those software tests… Hereafter, ‘user interface tool’ and ‘Quality Dashboard’ are used interchangeably.”):
(i) a test execution report ([0049] “FIG. 3B is a screenshot of user interface 350 that lists details about multiple test cases”),
(ii) a test execution summary (See Fig. 3B: Status Column, [0049] “user interface 350 comprises a table 360, where each row corresponds to a different test case and columns include … a status of the test case (e.g., pass, fail, work-in-progress (WIP), or blocked).”),
(iii) a detailed report ([0052] “FIG. 3D is a screenshot of an example user interface 390 that includes details about a selected test case.”),
(iv) historical trends ([0085] “The user interface tool enables the comparison of current build health with previous ones. Thus, a software development team can retrospect on what went well, what did not go well, and can plan on areas of improvement.”),
(v) sprint information (See Fig. 3B: Status Column, [0049] “user interface 350 comprises a table 360, where each row corresponds to a different test case and columns include a sprint identifier, a drop identifier, a test case identifier, a description of the test case, a status of the test case (e.g., pass, fail, work-in-progress (WIP), or blocked).”),
(vii) server usage ([0065] “FIG. 4E. User interface 490 includes information about different API calls that a software build makes when executed. In this example, table 492 lists nine API calls and, for each API call, a request type (i.e., POST, GET, PATCH), an endpoint, and a name of an API call, where the name includes a link to a description of the API call,” wherein the API calls show in Fig. 4E include server target/endpoint information.), and
(viii) team usage ([0038] “. Main page 200 includes a navigation panel 210 that includes selectable options that allow the user (interacting with the QD [Quality Dashboard]) to navigate through all the information available through the QD. The selectable options include:” [0039] “a. a team option 211 that, when selected, causes the user interface to be updated to include information about a software development team responsible for a software project.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the medium as disclosed by Sath in view of Gonzales, Epperlein and Atyam with the dashboard display as taught by Daunais in order to “allow information and changes to that information to be updated, communicated, and distributed more quickly in a rich project-specific context” (Daunais [0022]).
With further regard to Claim 19, Sath in view of Gonzales, Epperlein, Atyam and Daunais does not teach the following, however, Deodhar teaches:
(vi) adoption consistency including an adoption consistency status summary for all users and an adoption consistency status-per-user ([0013] “The term ‘organization sub-units’ in this specification relates to the entire organization or any part thereof, including business units, projects, teams.” [1054] “The systems and methods of present disclosure support extensive analytics. The organization effort aggregation and analytics engine 414 derives a per-employee daily average of Work Pattern. This is a powerful metric that facilitates meaningful and direct comparisons between any two or more organization sub-units of any type, including individual employees. Various trends and reports are available to compare the average daily productive time across various Purposes, Activities, applications, artifacts, online and offline time distribution, work focus, breaks taken, capacity utilization and so on. The reports and trends are available on daily, weekly, monthly or cumulative basis over a specified time range, or during the project or organization lifecycle phases,” wherein the metrics regarding the “Work Pattern” and “Average Daily Productive Time” are equivalent to the claimed “adoption consistency”, as evidenced by Fig. 28 of the Applicant’s disclosure which shows an example of the “Adoption Consistency” dashboard information. [1058] “a web user interface 430 that is accessed using any standard internet browser or standalone web applications. It enables users to view trends, reports, set goals, alerts, goal compliance, and performs administrative functions,” see also ‘Table 8’ below Paragraph [0615] which shows an example of the type of information that may be aggregated and displayed, both for “all users” and “per-user”.), and
(ix) an enterprise leaderboard ([1048] “The present disclosure provides for exact effort and time productivity measurement at enterprise level.” [1058] “[1058] “a web user interface 430… to view trends, reports…” [0822] “Table 10 summarizes an example of how to compute the work time for the organization sub-units for one week period” See also ‘Table 10’ below Paragraph [0822] which includes metrics such as “Delivered Capacity as % of Available Capacity: shows how busy the user is, and if they can achieve more,” wherein the metrics shown in ‘Table 10’ serve as a type of “Enterprise Leaderboard” since they enable a comparison between different enterprise teams and business units (BUs).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the medium as disclosed by Sath in view of Gonzales, Epperlein, Atyam and Daunais with the dashboard display metrics as taught by Deodhar as this provides “exact effort and time productivity measurement at organization level without any manual definition or configuration of employee groups or attributes” (Deodhar [0045]) for purposes of “improving productivity and workload allocation, and optimizing workforce and operational efficiency” (Deodhar [0034]).
Claim 21:
Sath in view of Gonzales, Epperlein, Atyam, Daunais and Deodhar teaches the medium of claim 19, and Sath further teaches wherein the trigger event comprises at least one of:
(i) a standalone testing trigger, (ii) a command line interface trigger, (iii) a workload scheduler trigger, (iv) a third-party enterprise communication platform chat trigger, (v) a third-party enterprise team planning system trigger, (vi) a continuous testing trigger, (vii) an ATF API trigger, and (viii) natural language processing ([0081] “. The request builder 222 is in a continuous loop as indicated by LOOP (that terminates only if there are no more tests to execute),” wherein the “continuous loop” is “(vi) a continuous testing trigger.”).
Claim 22:
Sath in view of Gonzales, Epperlein, Atyam, Daunais and Deodhar teaches the medium of claim 19, and Sath further teaches wherein said arranging to execute the test case via the DTAaaS includes at least one of:
(i) database conversion, (ii) file format conversion, (iii) data ingestion validation, (iv) file feed validation, (v) table-to-table count validation, (vi) trend drift detection, (vii) JavaScript Object Notation ("JSON") structure validation, (viii) data quality checks, (ix) data reconciliation across heterogeneous data platforms including data stores and file systems, and (x) data profiling ([0046] “data for the remaining one or more groups are imported into the database 126 in a specific format (e.g., as a JSON file; for raw test data, test scenarios, and test cases). In some embodiments, the specifically formatted file (e.g., the JSON file) is exported to a second format (e.g., a POSTMAN format, such as Postman Export V2.1). In some embodiments, a RESTClient (an application for talking to RESTful web services) uses the second format (sometimes called a request format) to communicate with an API endpoint or server, and the server responds to the request after performing the operations with results,” wherein the “the specifically formatted file (e.g., the JSON file) is exported to a second format” language discloses a type of “(ii) file format conversion.”).
Response to Arguments
Applicant's arguments, see Pages 9-11 of the Remarks filed March 3, 2026, with respect to the rejections under 35 U.S.C. 103 of Claims 1-5, 7-10, 12-16, 18-19 and 21-22 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument, Page 10 Paragraph 2 of the Remarks, that the cited prior art does not teach the first part of the newly amended limitation which recites, “automatically verify the test case via an ATF Application Programming Interface ("API"),” the Office respectfully disagrees. The Office contends that the previously cited Sathianarayanan et al. (US PGPUB 2020/0401506) reference does teach the newly amended language recited in independent claims 1 and 12. The Office respectfully directs the Applicant’s attention to the newly modified rejections of claims 1 and 12 above for further explanation regarding how the Sathianarayanan reference has been interpreted as teaching the newly amended language of independent claims 1 and 12.
With respect to the Applicant’s argument that the cited prior art does not teach the second part of the newly amended limitation which recites, “wherein the verification is associated with missing inputs, automatically transmit a warning in a case inputs are missing,” this argument has been fully considered but is moot in view of the newly cited Gonzales (US PGPUB 2009/0271764) reference as discussed above in the respective rejections.
With respect to the Applicant’s further arguments, Page 10 of the Remarks, that the features of the remaining claims are not taught by the cited prior art, the Office respectfully disagrees. These arguments rely upon the arguments as presented in relation to claims discussed above, and as such the Office directs the Applicant to the responses above regarding these arguments.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Kumar et al. (US Patent 9,983,982) discloses techniques for redirecting data streams from a production environment to validate non-production software code, including testing code related to a request payload module, wherein such testing verifies issues with a malformed request payload which has missing request payload fields.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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.
/JOANNE G MACASIANO/ Examiner, Art Unit 2197
Prosecution Insights