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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on July 21, 2026 has been entered.
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, 4-5, 8-9, 11, 14-15 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav et al. (US PGPUB 2017/0344467; hereinafter “Yadav”) in view of Yamamoto et al. (US PGPUB 2008/0010542; hereinafter “Yamamoto”), Walters (US PGPUB 2013/0339933; hereinafter “Walters”), Chavan et al. (US PGPUB 2024/0354225; hereinafter “Chavan”) and Kolawa et al. (US PGPUB 2006/0123389; hereinafter “Kolawa”).
Claim 1: (Currently Amended)
Yadav teaches a method, implemented by at least one processor, for automatically synchronizing test information of a testing, the method comprises ([0043] “The computer system 300 may execute, by a processor (e.g., a single or multiple processors) or other hardware processing circuit, the methods, functions and other processes described herein.”):
collecting at least one test result of the testing ([0018] “The testing integration tool may automatically determine when the testing batch job is completed, and extract the test results from the execution of the test suites for uploading to a selected test management tool.”); and
determining at least one test case associated with the at least one test result ([0034] “The testing integration tool 110 accesses the test results 201 from the one or more files and maps the test results 201 to test cases in the test management tool 102.”).
With further regard to Claim 1, Yadav does not teach the following, however, Yamamoto teaches:
wherein the collecting the at least one test result comprises establishing communications with a plurality of test execution environments and continuously collecting test results from the plurality of test execution environments ([0055] “the test monitoring unit 21… monitors execution performance (test performance) of each PC 200 in terms of testing of test cases (step S110). In fact, the test case selection apparatus 100 is continuously operated, and the test monitoring unit 21 continuously receives information concerning test performance for each PC 200, including whether tests have been performed by the PC 200 and the test results… it is assumed that test performance information about all tests is received in this process. The test monitoring unit 21 writes the received test performance information to the test case table 32 saved in the database 30, in association with, for example, the names of the tests,” wherein the plurality of “PC 200” systems, see Fig. 1 of Yamamoto, are the “test execution environments”.).
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 method as disclosed by Yadav with the continuously collecting test results as taught by Yamamoto in order “to more efficiently track down any malfunction present in the software system targeted for the testing” (Yamamoto [0017]).
With further regard to Claim 1, Yadav in view of Yamamoto does not teach the following, however, Walters teaches:
determining, from among a plurality of test requirements of the at least one test case, at least one test requirement associated with the at least one test result ([0021] “The tests performed include positive and negative test cases.” [0048] “The reporting service 112 supports a web application 510 and web services 512. The web application 510 correlates actual recorded test report data to requirements traceability matrix reports that measure and illustrate the adherence to requirements within a project and the health of those implementations within the system and/or software.”); and
synchronizing the at least one test result with the at least one test requirement to form a synchronized test information by generating a mapping of the at least one test result and the determined at least one test requirement ([0021] “The tests performed include positive and negative test cases.” [0048] “The reporting service 112 supports a web application 510 and web services 512. The web application 510 correlates actual recorded test report data to requirements traceability matrix reports that measure and illustrate the adherence to requirements within a project and the health of those implementations within the system and/or software,” wherein the “correlating” is “mapping”.).
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 method as disclosed by Yadav in view of Yamamoto with the test requirement synchronizing and mapping as taught by Walters in order “to ensure the software… is working correctly and meeting the appropriate requirements” (Walters [0024]).
With further regard to Claim 1, Yadav in view of Yamamoto and Walters does not teach the following, however, Chavan teaches:
wherein the mapping enables processing and synchronizing the at least one test result as soon as the at least one test result is available without requiring waiting for completion of testing on all test requirements ([0027] “As the test cases of the test batch are executed by the testing tool, a testing dashboard of the testing system monitors the execution of the test cases in near real-time such as, for example, within fifteen seconds. For example, the testing dashboard may monitor the test results of each individual test case of a test batch at the conclusion of the execution of the given test case. Thus, unlike conventional testing systems which rely on analysis performed manually by a tester only following the execution of every one of the test cases of a given test batch, at least some of the analysis performed by the testing dashboard of the test logs is performed concurrently with the execution of the plurality of test cases defining the test batch. To state in other words, the testing dashboard need not wait until the conclusion of the execution of the test batch, and instead may automatically begin the process of analyzing the results of the test batch prior to the conclusion of the execution of each test case of the test batch.”).
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 method as disclosed by Yadav in view of Yamamoto and Walters with the synchronizing of test results without waiting for completion of testing as taught by Chavan in order to “save processing or resources of the computer system which would otherwise have been used to execute unnecessary test cases of the test batch” (Chavan [0028]).
With further regard to Claim 1, Yadav in view of Yamamoto, Walters and Chavan does not teach the following, however, Kolawa teaches:
obtaining information associated with one or more users ([0052] “In one embodiment, access to GRS reports requires authorization with a login and password. Each GRS user account has a set of roles assigned to it,” wherein the “login and password” is the obtained “information”.);
determining, based on the information of the one or more users, a presentation format ([0052] “Once inside the system, the users are presented with a configurable dashboard that lets them visualize the status of their software development lifecycle. For example, a user with an appropriate access right can choose to view the behavior of the entire project, a development group, individual testers or programmers.” [0050] “The reporting engine 33 is capable of generating predefined views and reports for each roles, customizable views, and configurable graphical user interfaces (GUI) for each role.”); and
presenting, based on the mapping and the presentation format, the synchronized test information to the one or more users ([0049] “the present invention is a system and method for automating reports, including software test reports.” [0053] “GRS tool provides flexibility by customizing prepackaged reports to a given role, which allows the user to view different aspects of their development process.” [0063] “In one embodiment of the present invention, GRS is pre-configured with sets of reports for the various roles (for example, reports for the developers, architect, and/or project manager).”).
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 method as disclosed by Yadav in view of Yamamoto, Walters and Chavan with the different presentation formats as taught by Kolawa so that “users are presented with a dashboard (GUI) that shows them relevant information based on their role within the system” (Kolawa [0064]), thereby improving the GUI by only displaying information relevant to the specific user.
Claim 4:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 1 as described above. Yadav further teaches wherein the collecting the at least one test result comprises:
establishing a communication with at least one test execution environment ([0022] “Some examples of automated software testing tools that may be used for the software testing tools 101 include the following: … Unified Functional Testing (UFT) software, which provides functional and regression test automation for software applications and environments.” [0018] “The testing integration tool may execute test results generated from testing batch jobs. For example, multiple test suites of test cases may be executed in a testing batch job overnight.”);
gathering, from the a least one test execution environment, one or more test data ([0029] “the batch manager 112 determines whether test results for the batch job are stored in a predetermined location or the batch manager 112 may get a notification from the software testing tool indicating the batch job is completed or the software testing tool may set a flag indicating completion of the batch job. A flag may be an indicator stored in a file or sent in a message specifying whether the batch job is completed. In response to determining the batch job has completed, the test results for the batch job are retrieved from the predetermined storage location and may be sent via an API to the test management tool 102,” wherein the “test results for the batch job” are the “one or more test data”.); and
extracting, from the one or more test data, information associated with the at least one test result ([0038] “The driver determines the file format for the test result file and parses the file according to the file format to identify the test case results for extraction. In an example, if a file is XML, a Document Object Model (DOM) or tree structure for the XML is determined, and the DOM is traversed node by node to find the test results to extract. In another example, a regex operation may be executed on the file to extract test results for a particular test case or to extract test results for multiple test cases. The extracted test results for each test case, which may include pass, fail, whether a test case was executed and/or other information, may be stored with its associated source and target test case names in the mappings 208.”).
Claim 5:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 1 as described above. Yadav further teaches wherein the determining the at least one test case comprises:
processing the at least one test result to obtain at least one identity parameter associated with the at least one test case; and identifying, based on the at least one identity parameter, the at least one test case, wherein the at least one identity parameter comprises at least one of: a keyword associated with the at least one test case, a unique identifier (ID) associated with the at least one test case, and a tag associated with the at least one test case ([0050] “the mapper 108 may determine the mapping based on analysis of the test results 201. For example, a keyword may associate a test result with a test case. The mapper 108 may identify the keyword from a test result and associate it with the corresponding test case. The keyword may be an identifier or may be a description of the test case or a test case name.”).
Claim 8:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Yamamoto, Walters and Chavan does not teach the following, however, Kolawa teaches wherein the presenting the synchronized test information comprises:
generating, based on the mapping and the presentation format, a first graphical user interface (GUI); and presenting the first GUI to a first user ([0008] “The method and system include … displaying respective portions of the collected data in a graphical user interface (GUI) customized for a respective role.”),
wherein the presentation format is a generic format ([0055] “When a standard report is accessed, it may be shown in graphic form. The user can click on this graphic to retrieve the data in an easy to read text format. Standard reports also include multiple data sets collected from different runs of tools,” wherein the “standard report” is a type of “presentation format” which is a “generic format”. [0064] “In one embodiment, a variety of standard reports are included with the enterprise reporting server, accessible using a standard web browser.” [0057] “In one embodiment, GRS includes two levels of reporting that can be configured by the user. In the first level, the system can be configured to create reports from any activity at the developer desktop. For example, the architect and the developer can be automatically notified that there is a violation that needs to be addressed. This provides an instant report of errors and violations, but no analysis of improvement, relation to other developers, or relation to other projects. This level can provide a snapshot of the activity just completed by the developer,” wherein the “first level report” is also a type of “presentation format” which is a “generic format”.).
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 method as disclosed by Yadav in view of Yamamoto, Walters and Chavan with the different presentation formats as taught by Kolawa so that “users are presented with a dashboard (GUI) that shows them relevant information based on their role within the system” (Kolawa [0064]), thereby improving the GUI by only displaying information relevant to the specific user.
Claim 9:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 8 as described above. Yadav in view of Yamamoto, Walters and Chavan does not teach the following, however, Kolawa teaches wherein the wherein the presenting the synchronized test information further comprises:
generating, based on the mapping and the presentation format, a second GUI; and presenting the second GUI to a second user ([0008] “The method and system include … displaying respective portions of the collected data in a graphical user interface (GUI) customized for a respective role.”),
wherein the presentation format is a specific format ([0050] “The reporting engine 33 is capable of generating predefined views and reports for each roles, customizable views, and configurable graphical user interfaces (GUI) for each role.” [0063] “GRS is pre-configured with sets of reports for the various roles (for example, reports for the developers, architect, and/or project manager).” [0064] “Developers are able to view different types of graphs which that show how well they performed on achieving coverage of the rules, which rules where used during statistical analysis, which passed and failed, and where they failed. They can also view which pieces of code are failing the most,” wherein the reports viewed by developers are a type of “presentation format” which is a “specific format”.).
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 method as disclosed by Yadav in view of Yamamoto, Walters and Chavan with the different presentation formats as taught by Kolawa so that “users are presented with a dashboard (GUI) that shows them relevant information based on their role within the system” (Kolawa [0064]), thereby improving the GUI by only displaying information relevant to the specific user.
Claims 11, 14-15 and 18-19:
With regard to Claims 11, 14-15 and 18-19, these claims are equivalent in scope to Claims 1, 4-5 and 8-9 rejected above, merely having a different independent claim type, and as such Claims 11, 14-15 and 18-19 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1, 4-5 and 8-9.
With further regard to Claim 11, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Yadav reference also anticipates these additional elements of Claim 11, for example, Yadav teaches a system for automatically synchronizing test information of a testing, the system comprises:
a memory storage storing instructions ([0043] “These methods, functions and other processes may be embodied as machine readable instructions stored on a computer readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory).”); and
at least one processor configured to execute the instructions ([0043] “The computer system 300 may execute, by a processor (e.g., a single or multiple processors) or other hardware processing circuit, the methods, functions and other processes described herein.”).
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Yamamoto, Walters, Chavan, and Kolawa as applied to Claims 1 and 11 above, and further in view of Muthusamy (US PGPUB 2016/0062740; hereinafter “Muthusamy”).
Claim 3:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Yamamoto, Walters, Chavan, and Kolawa does not teach the following, however, Muthusamy teaches wherein the synchronizing the at least one test result with the at least one test requirement comprises:
updating a mapping of the at least one test result and the determined at least one test requirement ([0024] “the operations can comprise generating, creating, etc. a trace matrix that associates the individual requirement specifications with respective test steps of the individual test steps or respective documents of the set of requirement specification documents,” wherein the “trace matrix” is equivalent to the “requirements traceability matrix” taught above by Walters. [0080] “At 1010, validation system 110 executes an Ajax method to store a received test result, e.g., pass, fail, NA, etc. in a data store, database, etc. At 1020, validation system 110 dynamically updates a traceability, trace, etc. matrix (402) with the received test result. At 1030, validation system 110 highlights the relevant trace test case in green if the received test result is pass. At 1040, if the received test result is fail, validation system 110 highlights the relevant tract test case in red. At 1050, if the received test result is NA, validation system 110 highlights the relevant test cast in yellow or amber. At 1060, validation system 110 executes an Ajax method to display, within the traceability, trace, etc. matrix (402), the current, latest, etc. status, test status, etc. of respective requirement specifications.”).
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 method as disclosed by Yadav in view of Yamamoto, Walters, Chavan, and Kolawa with the updating of a mapping as taught by Muthusamy in order to “improve validation efficiency by dynamically creating relationships between requirements specifications, e.g., URS, FRS, etc. and functional test steps, cases, etc.” (Muthusamy [0020]).
Claim 13:
With regard to Claim 13, this claim is equivalent in scope to Claim 11 rejected above, merely having a different independent claim type, and as such Claim 13 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 11.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Yamamoto, Walters, Chavan, and Kolawa as applied to Claims 1 and 11 above, and further in view of Boden et al. (US PGPUB 2014/0201703; hereinafter “Boden”).
Claim 6:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Yamamoto, Walters, Chavan, and Kolawa does not teach the following, however, Boden teaches wherein the determining the at least one test requirement comprises:
processing the at least one test result to obtain at least one test parameter associated with the at least one test requirement ([0035] “At block 404, the code coverage and/or test results are linked to the requirements. In an embodiment, the code coverage and/or test results are linked to the requirements using the task ID found in 402. The task ID is associated with one or more pieces of code identified by file name and the lines in the file that have changed. Any piece of code that is executed in a test run is identified during that test run via code coverage results, and these tested code sections may be mapped to the task ID via code associated with the task ID,” wherein the “task ID” is the “test parameter”.); and
determining, based on the at least one test parameter, the at least one test requirement from among a plurality of test requirements of the at least one test case ([0035] “The task IDs are then mapped to the IDs of the user stories (by for example via intermediate task IDs), which are further associated in the project management database with the user stories, and from the user stories with the requirements. Therefore, for a given requirement all the committed code may be identified using user story IDs and Task IDs.”),
wherein the at least one test parameter comprises at least one of: a keyword associated with the at least one test requirement, descriptions defining at least a portion of the at least one test requirement, and a tag associated with the at least one test requirement ([0035] “the IDs of the user stories (by for example via intermediate task IDs), which are further associated in the project management database with the user stories, and from the user stories with the requirements,” wherein the “user story IDs” comprise the “tag associated with the at least one test requirement”.).
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 method as disclosed by Yadav in view of Yamamoto, Walters, Chavan, and Kolawa with the test requirement determination steps as taught by Boden as this “improves the business value and test efficiency by automating the ability to relate code coverage to original product or release requirements” (Boden [0013]).
Claim 16:
With regard to Claim 16, this claim is equivalent in scope to Claim 6 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 6.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav in view of Yamamoto, Walters, Chavan, and Kolawa as applied to Claims 1 and 10 above, and further in view of Mine et al. (US PGPUB 2018/0095745; hereinafter “Mine”).
Claim 10:
Yadav in view of Yamamoto, Walters, Chavan, and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Yamamoto, Walters, Chavan, and Kolawa does not teach the following, however, Mine teaches wherein
the testing comprises testing of a software of a vehicle system, and wherein the software comprises a virtual electronic control unit (ECU) ([0047] “The term ‘advance verification’ refers to the process of transmitting the updating software to an ECU (specific terminal) of a test vehicle prior to transmitting such updating software to the ECUs… of general vehicles, and actually operating the update file in the test vehicle to test whether the updating software will operate normally in the test vehicle, The test vehicle transmits operational information of the update file; that is, verification information as the result of the operation test, and the computer system 10 receives the foregoing information and determines whether the update file passed the operation test.”).
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 method as disclosed by Yadav in view of Yamamoto, Walters, Chavan, and Kolawa with the vehicle system testing as taught by Mine in order to avoid errors in the vehicle software since “in cases where the distribution-target of software is an automobile or the like which must be compliant with the functional safety standard, there will be a profound effect if a bug is discovered in the software after the software is broadly distributed” (Mine [0036]).
Claim 20:
With regard to Claim 20, this claim is equivalent in scope to Claim 10 rejected above, merely having a different independent claim type, and as such Claim 20 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 10.
Response to Arguments
Applicant’s arguments, see Pages 9-10 of the Remarks filed July 21, 2026, with respect to 35 U.S.C. 101 have been fully considered and are persuasive. The 35 U.S.C. 101 rejections of Claims 1, 3-6, 8-11, 13-16 and 18-20 have been withdrawn.
Applicant's arguments, see Pages 11-13 of the Remarks, with respect to the rejections under 35 U.S.C. 103 of Claims 1, 3-6, 8-11, 13-16 and 18-20 have been fully considered but they are not persuasive. With respect to the Applicant’s argument that the newly amended language of Claims 1, 3-6, 8-11, 13-16 and 18-20 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the newly cited Yamamoto et al. (US PGPUB 2008/0010542) and Chavan et al. (US PGPUB 2024/0354225) references as discussed above in the respective rejections.
With respect to the Applicant’s further related arguments, Page 13 Paragraph 3 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 Claim 1 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:
Pugh et al. (US PGPUB 2005/0010678) discloses systems for debugging and editing of software code, including allowing a developer to monitor, inspect, and control the execution of software running on a remote server.
Koong et al. (“The Architecture of Parallelized Cloud-based Automatic Testing System,” 2013) discusses a paralleled cloud based automatic testing system (PCATS) which enables real-time software testing and automatically computation scaling, as well as execution of testing scenarios on a plurality of virtual environments in parallel.
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