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 § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a method and system for analyzing and storing test results.
The limitation in Independent Claims 1 and 11 of correlating test cases and requirements with test results, as drafted, are processes that, under their broadest reasonable interpretation, covers steps that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. That is, the limitations of “determining at least one test case associated with the at least one test result,” “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,” “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” and “determining, based on the information of the one or more users, a presentation format” in Claims 1 and 11, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of mental processes. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. Claims 1 and 11 recite the following additional elements “collecting at least one test result of the testing,” “obtaining information associated with one or more users” and “presenting, based on the mapping and the presentation format, the synchronized test information to the one or more users.” these limitations do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering and outputting the results of the abstract idea, see MPEP 2106.05(g).
Further, with regard to the “a memory storage storing instructions” and “at least one processor configured to execute the instructions” elements of Claims 1 and 11, these elements are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, see MPEP 2106.05(f). Accordingly, the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
With regard to the individual dependent claims:
Claims 3 and 13 recite, “updating a mapping of the at least one test result and the determined at least one test requirement.”
Claims 4 and 14 recite, “extracting, from the one or more test data, information associated with the test result.”
Claims 5 and 15 recite, “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.”
Claims 6 and 16 recite, “processing the at least one test result to obtain at least one test parameter associated with the at least one test requirement; 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.”
These limitations of Claims 3-6 and 13-16, as drafted, are processes that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out this function through observation, evaluation judgment and/or opinion, or even with the aid of pen and paper. Thus, these limitations recite and fall within the “Mental Processes” grouping of abstract ideas. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Claims 4 and 14 further recite, “gathering, from the a least one test execution environment, one or more test data.”
Claims 8 and 18 recite, “presenting the first GUI to a first user, wherein the presentation format is a generic format.”
Claims 9 and 19 recite, “presenting the second GUI to a second user, wherein the presentation format is a specific format.”
These limitations of Claims 4, 8-9, 14 and 18-19 do nothing more than add insignificant extra solution activity to the judicial exception, such as data gathering, transmitting and outputting the results of the abstract idea, see MPEP 2106.05(g). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Further, these limitations of Claims 4, 8-9, 14 and 18-19 amount to no more than mere instructions to apply the exception using well-understood, routine and conventional computer components and functions, recited at a high level of generality, i.e. receiving/transmitting data over a network and storing/retrieving information in memory. As such, these additional elements do not amount to an inventive concept and are not by themselves sufficient to transform the judicial exception into a patent eligible invention, see MPEP 2106.05(d).
Claims 4 and 14 further recite, “establishing a communication with at least one test execution environment.”
Claims 8 and 18 further recite, “generating, based on the mapping and the presentation format, a first graphical user interface (GUI).”
Claims 9 and 19 further recite, “generating, based on the mapping and the presentation format, a second GUI.”
These limitations of Claims 4, 8-9, 14 and 18-19 are recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception using generic computer components, see MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Further, these limitations of Claims 4, 8-9, 14 and 18-19 amount to no more than mere instructions to apply the exception using well-understood, routine and conventional computer components and functions, recited at a high level of generality, i.e. receiving/transmitting data over a network and storing/retrieving information in memory. As such, these additional elements do not amount to an inventive concept and are not by themselves sufficient to transform the judicial exception into a patent eligible invention, see MPEP 2106.05(d).
Claims 5 and 15 further recite, “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.”
Claims 6 and 16 further recite, “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.”
Claims 10 and 20 recite, “wherein the testing comprises testing of a software of a vehicle system, and wherein the software comprises a virtual electronic control unit (ECU).”
These limitations of Claims 5-6, 10, 15-16 and 20 do nothing more than generally link the judicial exception to a particular technological environment, see MPEP 2106.05(h). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
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 Walters (US PGPUB 2013/0339933; hereinafter “Walters”) and Kolawa et al. (US PGPUB 2006/0123389; hereinafter “Kolawa”).
Claim 1:
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, 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 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 Walters 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 Walters 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: (Currently Amended)
Yadav in view of Walters 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 Walters 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: (Currently Amended)
Yadav in view of Walters and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Walters 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 Walters 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 Walters and Kolawa teaches all the limitations of claim 8 as described above. Yadav in view of Walters 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 Walters 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 Walters 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 Walters and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Walters 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 Walters 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 Walters 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 Walters and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Walters 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 Walters 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 Walters 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 Walters and Kolawa teaches all the limitations of claim 1 as described above. Yadav in view of Walters 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 Walters 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
With respect to the Applicant’s arguments, see Pages 9-11 of the Remarks filed March 5, 2026, with respect to the rejections under 35 U.S.C. 101 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 first argument regarding the 35 U.S.C. 101 rejections, Page 10 Paragraphs 2-3, that “the additional elements evidence improvements to the functioning of a computer. Specifically, the mapping of the present invention as a data structure that links test requirements and test results allows the present invention to process and synchronize test results as soon as they are available, without requiring waiting for the completion of testing,” the Office respectfully disagrees.
In response to this argument, it is noted that the features upon which applicant relies (i.e., the mapping… allows the present invention to process and synchronize test results as soon as they are available) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
With respect to the Applicant’s second argument regarding the 35 U.S.C. 101 rejections, Page 10 Paragraph 3, that “In Enfish, the court concluded that the table improve how the computer stores and retrieves data utilizing the specific data structure. Id. Similarly, the mapping of the instant claims, allows the computer improved storage and processing, as noted in Applicant's specification. As such, the mapping renders any alleged exception as a practical application,” the Office respectfully disagrees.
The Office would like to first note that the courts concluded in Enfish that there was a clear improvement to computer-related technology since the claims in Enfish were directed to a self-referential table for a computer database, i.e. a highly specific type of data structure. The Office contends that the instant claims do not recite such a clear improvement to computer-related technology, as the claims only broadly recite steps of collecting information, determining other information associated with the collected information, creating a mapping (i.e. a diagram or table) of the determined associations, obtaining further information, determining a presentation format based on the further information, and presenting the previously determined information based on the mapping and presentation format. The Office maintains that the claimed steps recite an abstract idea without being directed to clear improvements to computer-related technology, see MPEP 2106.06(b).
With respect to the Applicant’s third argument regarding the 35 U.S.C. 101 rejections, Page 10 Paragraph 4, that “the additional elements … evidence an improved user interface with the ability to present information to users based on information associated with the user. This user interface is analogous to the improved user interface found to be a practical application in Core Wireless,” the Office respectfully disagrees.
The Office would like to first note that the courts concluded in Core Wireless that there was an improvement in computer-functionality since the claims in Core Wireless were directed to “An improved user interface for electronic devices that displays an application summary of unlaunched applications, where the particular data in the summary is selectable by a user to launch the respective application,” see MPEP 2106.05(a) Section I Improvement Examples - (x) “An improved user interface…”. The Office contends that the user interface in Core Wireless recited a specific improved functionality (i.e. the particular data in the summary is selectable to launch the respective application), whereas the instant claims do not recite such a clear improvement to computer-functionality. The instant claims only broadly recite steps of presenting test information based on a determined presentation format, wherein the determined presentation format is based on obtained information from users. The Office contends that such broadly defined limitations merely recite a user-customizable interface for presenting information, wherein such an interface is not sufficient to show an improvement in computer-functionality, see MPEP 2106.05(a) Section I Insufficient Improvement Examples - (vi) “Instructions to display two sets of information” and (viii) “ Arranging transactional information on a graphical user interface”. As such, the Office maintains that the claimed steps recite an abstract idea without being directed to clear improvements to computer-related technology, see MPEP 2106.05(a).
With respect to the Applicant’s argument regarding the 35 U.S.C. 103 rejection of amended Claim 1, Page 13 Paragraph 1, that “Walters only references types of test cases and makes no determination, much less the determination claimed in the present invention. Additionally, this portion of Walters is wholly silent on any synchronization, much less the synchronization claimed in the present invention,” the Office respectfully disagrees.
The Office first contends that Walters does teach and make obvious the limitations regarding “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” 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.” In support of this assertion the Office would like to direct the Applicant’s attention to the following citations in Walters:
[0021] “The tests performed include positive and negative test cases.”
[0034] “In some instances, requirements traceability matrix coverage reports can be produced to drive plans for manual test coverage as well as future automation test development.”
[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.”
The disclosure of Walters discloses that test report data is correlated, i.e. mapped, to a matrix of requirements associated with testing. As such, the Office maintains that Walters does teach and make obvious the limitations which recite “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” 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,” wherein it is noted that the content of the “test requirements” is not recited in Claim 1.
With respect to the Applicant’s further arguments, Pages 14 Paragraphs 5-6 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:
Catt et al. (US PGPUB 2020/0242015) discloses computing systems, database systems, and related methods are provided for managing test cases, including generating test case definitions and updating a database maintaining associates between test case definitions and test results.
Davidov et al. (US Patent 7,836,346) discloses a method for analyzing software test results, including identifying a test result of a failed test case in a test log, determining whether the failed test case has a related defect report, and storing a selectable link to the related defect report in the test result.
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