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 .
DETAILED ACTION
This office action is in response to communication filed 1/25/2024. Claims 1-20 are currently pending and claims 1, 4, and 14 are the independent claims.
Claim Rejections - 35 USC § 112
Claims 3, 6, 8-11, 16, and 18-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 3, 6, and 16, they recite “…determining that the second output of the one or more evaluation tests does not match the one or more target values associated with the replacement/new version of the software…”, however the claims do not previously recite “target values associated with the replacement/new version of the software”, and as such there in insufficient antecedent basis for these limitations in the claims. For the purpose of examination, the examiner will consider these limitations to be “…determining that the second output of the one or more evaluation tests does not match one or more target values associated with the replacement/new version of the software…”.
As per claims 8 and 18, they recite “…identifying the one or more evaluation tests based on the attributes of the second/current version of the software” however the claims do not previously recite “attributes of the second/current version of the software”, and as such there in insufficient antecedent basis for these limitations in the claims. For the purpose of examination, the examiner will consider these limitations to be “…identifying the one or more evaluation tests based on attributes of the second/current version of the software” however the claims do not previously recite “attributes of the second/current version of the software”.
As per claims 9-11 and 19-20, they incorporate the deficiencies of claims 8 and 18, respectively, upon which they depend, and fail to correct the deficiencies of claims 8 and 18. Therefore, claims 9-11 and 19-20 are rejected for similar reasoning as claims 8 and 18, above
As per claims 9 and 19, they further recite “…the one or more evaluation tests comprise API calls…”, and as such recite the acronym “API” without first defining what “API” is intended to mean, and as such the examiner is unclear as to what “API” means. For the purpose of examination, the examiner will consider “API” to mean “application programming interface” and these limitations to be “…“…the one or more evaluation tests comprise application programming interface (API) calls…”.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5-9, and 12-19 are rejected under 35 U.S.C. 103 as being unpatentable over Walker et al. (herein called Walker) (US PG Pub. 2024/0289261 A1) and Petrescu et al. (herein called Petrescu) (US Patent 11,500,763 B1).
As per claim 1, Walker teaches: a system for real-time error mitigation in a software pipeline, the system comprising: one or more processors; and one or more non-transitory computer-readable media having instructions recorded thereon that, when executed by the one or more processors, cause operations comprising:
receiving, from a server, a request for evaluating a software pipeline, wherein the request comprises a previous version of software, a current version of software, (pars. [0029], [0036], [0038]-[0039], [0046]-[0047], software change request/SCR is received by development pipeline from developer using client computing device/servers/etc. and SCR includes the code/application (previous version) and specifications of software change/etc. (current version), and validation/testing/etc. is performed on code/executables/changes/etc. built/developed/resulting/etc. from SCR by pipeline (SCR causes evaluation/validation/testing/etc. of software pipeline and as such the SCR is a request for evaluating a software pipeline);
based on the request, determining one or more evaluation tests to execute on the current version of the software at the recurrent interval of time (pars. [0046]-[0047], [0061]-[0065], when changes are made to software in pipeline (current version of software) in response to software change request (based on the request) test suite/regression tests/test applications/etc. (evaluation testes) are invoked/determined/etc. and run/executed on the software change/current version, and as Petrescu teaches that software testing in a pipeline occurs at recurrent intervals of time/scheduled time intervals/etc., as seen below, it is obvious that the tests to execute are determined at the recurrent interval of time.);
in response to determining an instance of the recurrent interval of time has elapsed, executing the one or more evaluation tests on the current version of the software (pars. [0046]-[0047], [0061]-[0065], test suite/regression tests/test applications/etc. (evaluation testes) are run/executed on the software change/current version, and as Petrescu teaches that software testing in a pipeline occurs at recurrent intervals of time/scheduled time intervals/etc., as seen below, it is obvious that the tests are executed in response to determining the current interval of time has elapsed.);
receiving an output of the one or more evaluation tests on the current version of the software (pars. [0047], [0055]-[0056], [0064], test/regression test/etc. are executed on changed/updated software/current version of software/etc. and are monitored, and test results (output of evaluation tests on current version of software) are received and stored and identify errors, conflicts, failures to satisfy performance metrics thresholds, etc.);
determining whether the output of the one or more evaluation tests does not match one or more target values (pars. [0047], [0055]-[0056], [0064], test results (output of evaluation tests) identify errors, conflicts, failures to satisfy performance metrics thresholds, etc. (output of evaluation tests does not match target values).);
in response to determining that the output of the one or more evaluation tests does not match one or more target values (pars. [0047], [0055]-[0056], [0064], test results (output of evaluation tests) identify errors, conflicts, failures to satisfy performance metrics thresholds, etc. (output of evaluation tests does not match target values).):
terminating deployment of the current version of the software (pars. [0047], [0055], [0061], [0068], when software changes/current version of software fail tests the changes are blocked/not permitted to be merged into deployed software/etc. and rollback operations are performed (terminate/block/rollback/etc. deployment of current version/software changes/etc.).);
generating instructions to replace the current version of the software with the previous version of the software (pars. [0047], [0061], [0068], when software changes/executables/current version fails testing the software changes/executables/current version/etc. is rolled back to prior version (replace current version/software changes with previous version/rollback to previous version/etc.) and developers are notified of unsuccessful testing/validation.); and
transmitting a notification to a remote device indicating a real-time error mitigation action has occurred (pars. [0047], [0061], [0068], notification is provided to developer using client device via push notification/pop-up notification/email notification/etc. (transmit notification to remote/client device) that software changes/current version failed testing and has been rolled back (indicating a real-time error mitigation action has occurred) prompting the user to take action.).
While Walker teaches automatically testing software changes/current version/etc. in a software pipeline in response to a request, it does not explicitly state that the testing may be recurring testing that occurs at recurrent time intervals, and as such does not explicitly state, however Petrescu teaches:
receiving, from a server, a request for evaluating a software pipeline at a recurrent interval of time, wherein the request comprises the recurrent interval of time (col. 6 lines 5-60, col. 8 lines 5-55, code in pipeline/code changes in pipeline/etc. is tested in accordance with developer/user input (request for evaluating software pipeline from Walker) in test environment of pipeline, and user input may specify tests to be performed and schedule to execute testing so that test executing is repeated according to a schedule so that the testing is repeated over time/initiated in minute/sub-minute intervals/every 10 seconds/etc. (request/user input/etc. is received for evaluating software pipeline and includes a recurrent interval of time/scheduled test execution times/minute interval/every 10 seconds/etc. that the tests are to be initiated at.).);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Walker such that the testing is recurring and occurs at recurrent interval of time, as conceptually taught by Petrescu, to create receiving, from a server, a request for evaluating a software pipeline at a recurrent interval of time, wherein the request comprises the recurrent interval of time, because these modifications allow for an effective and efficient method of ensuring that testing occurs as desired/at desired times/according to testing schedule/etc. so that users do not have to remember to initiate testing every time testing is desired, thereby increasing desirability to users and helping to ensure that testing occurs so that errors in code may be determined and corrected so that the code operates/executes as correctly.
As per claim 2, Walker further teaches: wherein the system replaces the current version of the software with the previous version of the software based on the instructions, by:
removing code associated with the current version of the software from the software pipeline (pars. [0047], [0061], [0068], when testing fails software changes/executables/current version of software/etc. in pipeline are rolled back to prior version (remove code associated with current version/software changes and replace current version with prior/previous version).);
generating a replacement version of the software based on the previous version of the software (pars. [0047], [0061], [0068], when testing fails software changes/executables/current version of software/etc. in pipeline are rolled back to prior version (generate replacement version of software based on previous version of software/generate prior version/etc. and replace current version with prior/previous version/rollback software to previous version/etc.).); and
adding the replacement version of the software to the software pipeline (pars. [0047], [0061], [0068], when testing fails software changes/executables/current version of software/etc. in pipeline are rolled back to prior version (add replacement version/prior version/previous version/etc. to the software pipeline/rollback to prior version/replace current version with previous version/etc.).).
As per claims 4-5, they recite methods having similar limitations as the systems of claims 1-2, respectively, and are therefore rejected for similar reasoning as claims 1-2, respectively, above.
As per claim 6, Walker further teaches: performing a check after adding code associated with the first version of the software to the pipeline, by:
receiving a second output of the one or more evaluation tests on the new version of the software (pars. [0047], [0055]-[0056], [0064], test/regression test/etc. are executed on changed/updated software/etc. and are monitored, and test results (output of evaluation tests on version of software) are received and stored and identify errors, conflicts, failures to satisfy performance metrics thresholds, etc.. As changed/updated/etc. software is tested and output/results of the testing is received, and as the version of software is changed from the current version to the prior version when the rollback occurs, it is obvious to repeat the testing on the prior version/new version when the software is changed/rolled back/etc. to the new/prior version, and as such it is obvious that a second output of the one or more evaluation tests on the new version of the software would be received.);
determining the second output of the one or more evaluation tests does not match the one or more target values associated with the new version of the software (pars. [0047], [0055]-[0056], [0064], test results (output of evaluation tests) identify errors, conflicts, failures to satisfy performance metrics thresholds, etc. (output of evaluation tests does not match target values). As changed/updated/etc. software is tested and output/results of the testing is received and determined not to match/fails to satisfy/etc. target values/performance thresholds/etc., and as the version of software is changed from the current version to the new/prior version when the rollback occurs, it is obvious to repeat the testing on the prior version/new version when the software is changed/rolled back/etc. to the new/prior version, and that the results of the test may fail to satisfy/does not match/etc. target values of the software, and as such it is obvious that second output of the one or more evaluation tests is determined not to match the one or more target values associated with the new version of the software.);
and transmitting a second notification to the remote device (pars. [0047], [0061], [0068], notification is provided to developer using client device via push notification/pop-up notification/email notification/etc. (transmit notification to remote/client device) that software changes/software version failed testing. As a notification is sent that software version failed testing, it would be obvious to repeat/send a second notice/etc. when testing on the second version/prior version/new version/etc. fails.).
As per claim 7, Walker does not explicitly state, however Petrescu teaches:
determining the one or more evaluation tests to execute on the second version of the software at the intermittent intervals, comprising: receiving a user input including attributes of the one or more evaluation tests, wherein the attributes describe components of a software to evaluate (col. 6 lines 4-17, col. 8 lines 4-65, col. 10 lines 1-30, user/developer/etc. supplies/indicates/etc. tests to be performed on software and tests include software artifacts needed to perform testing such as software parameter values, configuration files, libraries, schedules, software API’s to be tested, etc. (user input including attributes describing components of software to be tested/software parameters/API’s to be tested, configuration files, libraries, etc. is received that indicates/supplies/etc. tests to be performed/determines evaluation tests to execute/etc.).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add determining the one or more evaluation tests to execute on the second version of the software at the intermittent intervals, comprising: receiving a user input including attributes of the one or more evaluation tests, wherein the attributes describe components of a software to evaluate, as conceptually taught by Petrescu, into that of Walker because these modifications increase user control over tests executed on software, thereby helping to ensure that testing meets user desires which makes it more desirable to users.
As per claim 8, Petrescu does not explicitly state, however teaches:
determining the one or more evaluation tests to execute on the second version of the software at intermittent intervals, comprising: accessing, from a remote server, a plurality of evaluation tests based on attributes of the one or more evaluation tests, wherein the attributes describe components of a software to evaluate (col 4 lines 5-35, col. 6 lines 4-20, col. 8 lines 34-col. 9 line 30, col. 10 lines 1-30, user input supplies/indicates tests to be performed on software in pipeline at scheduled times/intermittent intervals/etc. and includes APIs to be tested, parameters, code, etc., and tests/test artifacts/code packages/configuration files/parameters/software components/etc. are retrieved from artifact source/repository/distributed storage/etc. (access remote server and obtain evaluation tests/tests/artifacts/code based on attributes describing components of software to be tested/parameters/API’s/etc. to be tested/etc.).); and
identifying the one or more evaluation tests based on the attributes of the second version of the software (col. 4 lines 4-45, col. 6 lines 5-20, col. 8 line 54-col. 9 line 25, col. 10 lines 1-30, input specifies/supplies tests to be performed and included parameters/specifications/artifacts/API’s to be tested/etc. and test artifacts used to perform tests/evaluation tests are retrieved/downloaded/etc. from artifact source (identify tests/artifacts used to perform testing/evaluation tests/etc. based on attributes of version of software/second version of software/etc.).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add determining the one or more evaluation tests to execute on the second version of the software at intermittent intervals, comprising: accessing, from a remote server, a plurality of evaluation tests based on attributes of the one or more evaluation tests, wherein the attributes describe components of a software to evaluate; and identifying the one or more evaluation tests based on the attributes of the second version of the software, as conceptually taught by Petrescu, into that of Walker because these modifications allow for a method of identifying and obtaining desired tests to be executed on software while saving the resources/storage/memory that may be spent storing/obtaining/etc. tests that are not desired to be run/executed/etc., thereby making the testing more desirable to users while helping to ensure that desired testing occurs.
As per claim 9, Walker does not explicitly state, however Petrescu teaches:
wherein the attributes of the one or more evaluation tests comprise API calls, wherein the API calls are the attributes of specific functions in the software (col. 3 lines 35-40, col. 9 lines 24-30, col. 10 lines 1-30, testing may include testing software API’s by simulating/sending/etc. requests to API’s (test comprise API calls) in software being tested, and API’s in software to be tested may be selected/specified/etc. and tests/test artifacts/etc. for those API’s are retrieved and run/executed/etc. (attributes of evaluation tests comprise API calls which are attributes of functions in the software).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add wherein the attributes of the one or more evaluation tests comprise API calls, wherein the API calls are the attributes of specific functions in the software, as conceptually taught by Petrescu, into that of Walker because these modifications allow for API’s of software to be tested, thereby increasing user control over the testing and helping to ensure that errors/issues/etc. with API’s are found and corrected, thereby helping to ensure that software operates correctly.
As per claim 12, Walker further teaches: wherein executing the one or more evaluation tests further comprises:
inputting, to the one or more evaluation tests, the second version of the software (pars. [0046]-[0047], [0061]-[0065], test suite/regression tests/test applications/etc. (evaluation testes) are run/executed on the software change/second version/current version/etc. (second/current version of software is input to the evaluation tests).);
generating a second output based on the one or more evaluation tests (pars. [0047], [0055]-[0056], [0064], test/regression test/etc. are executed on changed/updated software/second version/current version of software/etc. and are monitored, and test results (output of evaluation tests on second/current version of software) are received and stored (generate output/second output based on evaluation tests) and identify errors, conflicts, failures to satisfy performance metrics thresholds, etc.); and
generating a second notification to the remote device based on the second output (pars. [0047], [0061], [0068], notification is provided to developer using client device via push notification/pop-up notification/email notification/etc. (transmit notification/second notification to remote/client device) that software changes/second version/current version failed testing and has been rolled back (second notification to remote device based on second output.).
As per claim 13, Walker further teaches: wherein generating the second output based on the one or more evaluation tests further comprises:
inputting, to the one or more evaluation tests, the second version of the software(pars. [0046]-[0047], [0061]-[0065], test suite/regression tests/test applications/etc. (evaluation testes) are run/executed on the software change/second version/current version/etc. (second/current version of software is input to the evaluation tests).);
receiving the second output based on the one or more evaluation tests (pars. [0047], [0055]-[0056], [0064], test/regression test/etc. are executed on changed/updated software/second version/current version of software/etc. and are monitored, and test results (output of evaluation tests on second/current version of software) are received and stored (receive output/second output based on evaluation tests) and identify errors, conflicts, failures to satisfy performance metrics thresholds, etc.); and
generating the second notification to the remote device based on the second output (pars. [0047], [0061], [0068], notification is provided to developer using client device via push notification/pop-up notification/email notification/etc. (transmit notification/second notification to remote/client device) that software changes/second version/current version failed testing and has been rolled back (second notification to remote device based on second output.).
As per claims 14-15 and 16-19, they recite non-transitory computer readable media having similar limitations as the systems of claims 1-2 and methods of claims 6-9, respectively, and are therefore rejected for similar reasoning as claims 4-5 and 6-10, respectively, above.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Walker et al. (herein called Walker) (US PG Pub. 2024/0289261 A1) and Petrescu et al. (herein called Petrescu) (US Patent 11,500,763 B1) in further view of Stijohann (US PG Pub 2020/0278921 A1).
As per claim 10, Walker and Petrescu do not explicitly state, however Stijohann teaches:
wherein the attributes of the one or more evaluation tests comprise sensor data, wherein the sensor data is included in the attributes of specific functions in the software (pars. [0079]-[0080], test program/test executed on program/etc. performs a function on input data which is an evaluation of sensor data (attributes of evaluation tests/test program/etc. comprise sensor data that is included in attributes of specific functions in software/used to perform functions in software/etc.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add wherein the attributes of the one or more evaluation tests comprise sensor data, wherein the sensor data is included in the attributes of specific functions in the software, as conceptually taught by Stijohann, into that of Walker and Petrescu because these modifications allow for sensor data to be used in performing the testing, which is desirable as it expands the usability of the testing so that software that performs functions using sensor data may be tested thereby making the testing more desirable to users.
As per claim 20, it recites a non-transitory computer readable media having similar limitations as the system of claim 10, and is therefore rejected for similar reasoning as claim 10, above.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Walker et al. (herein called Walker) (US PG Pub. 2024/0289261 A1) and Petrescu et al. (herein called Petrescu) (US Patent 11,500,763 B1) in further view of Lee et al. (herein called Lee) (US PG Pub. 2015/0339213 A1).
As per claim 11, Walker and Petrescu do not explicitly state, however Lee teaches:
wherein the attributes of the one or more evaluation tests comprise user input, wherein the user input is included in the attributes of specific functions in the software (pars. [0005], [0011]-[0013], [0018], test parameter values/data (attributes of evaluation test) correspond to/are associated with/etc. user input (tests comprise user input), and application being tested is provided test parameter values/data for user input objects of application to perform functions (user input is included in attributes of specific functions in software/user input objects of application performing functions/etc.).).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to add wherein the attributes of the one or more evaluation tests comprise user input, wherein the user input is included in the attributes of specific functions in the software, as conceptually taught by Lee, into that of Walker and Petrescu because these modifications allow for an effective method of testing software/applications that use/require user input, which is desirable as it allow for testing to be performed on software/applications/etc. that use/require/etc. user input, thereby expanding usability of the tests so that software/applications that use user input may be tested, making the tests more desirable to users.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS M SLACHTA whose telephone number is (571)270-0653. The examiner can normally be reached Monday-Friday 6:30am-4pm.
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, Chat Do can be reached at 571-272-3721. 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.
/DOUGLAS M SLACHTA/ Examiner, Art Unit 2193