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 10/3/2024. Claims 1-19 are currently pending and claim 1 is the independent claims.
Claim Objections
Claim 13 is objected to because of the following informalities:
As per claim 13, it recites “…wherein the static code analysis can be used in the customer build environment” which does not make clear whether the static code analysis is actually being used in the customer build environment or merely could potentially be used/has an potential intended use/etc. in the customer build environment, and as such, for clarity, claim 13 should recite “…wherein the static code analysis is used in the customer build environment” to make clear that the static code analysis is actually being used.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7, 13, 14, 16, and 18 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 claim 7, it recites the limitations “The method of claim 1 wherein detecting the dynamic/runtime behavioral changes comprises: exercising the existing codebase and capturing results; exercising the updated codebase and capturing results; and comparing the captured results.” The examiner would like to point out that claim 1 does not previously recite an “existing codebase” or “updated codebase”, as those elements are previously recited in claim 3, and as such there is insufficient antecedent basis for these limitations in the claim. For the purpose of examination, the examiner will consider these limitations to be “The method of claim 3, wherein detecting the dynamic/runtime behavioral changes comprises: exercising the existing codebase and capturing results; exercising the updated codebase and capturing results; and comparing the captured results.”
As per claim 13, it recites “The method of claim 12 wherein the static code analysis can be used in the customer build environment.” The examiner would like to point out that claim 13 is dependent on claim 12, which is dependent on claim 1, however neither claim 12 or claim 1 previously recites a “customer build environment”, rather a customer build environment is recited in claim 8, and as such there is insufficient antecedent basis for these limitations in the claim. For the purpose of examination, the examiner will consider these limitations to be “The method of claim 8, wherein the static code analysis is used in the customer build environment.”
As per claim 14, it recites “…including a signature and/or marker in relevant code based on any code changes.” The examiner is unclear as to what is meant by “relevant” as different persons of ordinary skill in the art may have different opinions as to what criteria would need to be satisfied for code to be considered “relevant”. For the purpose of examination, the examiner will consider these limitations to be “…including a signature and/or marker in code that has been changed.”
As per claim 16, it recites “The method of claim 1 wherein the static code analysis leverages the generally available build tool framework of the platform.” Examiner would like to point out that claim 1 does not previously recite a “generally available build tool framework”, as this element is previously recited in claim 6, and as such there is insufficient antecedent basis for these limitations in the claim. For the purpose of examination, the examiner will consider these limitations to be recites “The method of claim 6, wherein the static code analysis leverages the generally available build tool framework of the platform.”
As per claim 18, it recites “The method of claim 17 further comprising: upon the successful test of the version of the code with the variable type automatically corrected to match, changing the updated codebase to include the matching variable type.” The examine would like to point out that while claim 17 previously recites “…a version of the code is tested with a variable type automatically corrected to match”, it does not previously recite/clarify that the test is a “successful” test, or explicitly recite that the variable type automatically corrected to match is a “matching variable type”, and as such there is insufficient antecedent basis for these limitations in the claim. Similarly, claim 18 depends on claim 1, and neither claim 17 or claim 1 previously recite an “updated codebase”, rather “updated codebase” is previously recited in claim 3, and as such there is insufficient antecedent basis for these limitations in the claim. For the purpose of examination, the examiner will consider these limitations to be “…upon a successful test of the version of the code with the variable type automatically corrected to match, changing an updated codebase to include the variable type automatically corrected to match.”
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.
As per independent claim 1, it recites “A method for mitigating risk of platform software changes, the method comprising: detecting a change using static code analysis; and detecting dynamic/runtime behavioral changes.”
The limitations “detecting a change using static code analysis” and “detecting dynamic/runtime behavioral changes”, as drafted, recites a function that, under its broadest reasonable interpretation, covers a function that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components, and as such, as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. The limitations encompass a human mind carrying out the function through observation, evaluation, judgment, and/or opinion, or even with the aid of pen and paper. For example, a human may mentally/with pen and paper/etc. evaluate/analyze/judge/etc. a code and judge/observe/determine/identify/etc. changes, and may mentally/with pen and paper/etc. observe/judge/determine/decide/etc. changes in behavior/operation/etc. during runtime/execution/etc.. Therefore, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas.
This judicial exception is not integrated into a practical application. The claim recites the additional elements/limitations “A method for mitigating risk of platform software changes, the method comprising”. These additional elements recite that high level/generic computer/computer components/platform software/etc. are used to implement/perform/apply/etc. the exception/abstract idea/mental process, and as such amounts to no more than mere instructions to apply the exception using generic computer, and/or mere computer components. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore directed to the judicial exception. See MPEP 2106.05(f), 2106.05(g), etc..
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions, or generic computer/computer components to carry out/implement/perform/apply the exception, which does not provide an inventive concept and does not amount to significantly more than the judicial exception/abstract idea/mental process. Accordingly, the claims are not patent eligible under 35 USC 101.
As per claim 2, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein detecting the dynamic/runtime behavioral changes comprises: testing the dynamic/runtime behavioral changes based on the detected change using static code analysis” which, conceptually, with broadest reasonable interpretation, provides further clarification as to judgement/observation/analysis/evaluation/etc. performed, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 2 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 3, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein detecting the change using static code analysis comprises: analyzing an existing codebase and capturing results; analyzing an updated codebase and capturing results; and comparing the captured results” which, conceptually, with broadest reasonable interpretation, provides further clarification as to analysis/observation/judgement/evaluation/comparison/etc. performed using high level/generic computer/computer components/codebases/etc., which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 3 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 4, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the existing codebase and updated codebase comprise source code files and libraries of interest” which, conceptually, with broadest reasonable interpretation, provides further clarification as to high level/generic computer/computer components/codebase/source code files/libraries/etc., which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 4 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 5, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein comparing the captured results comprises a focus on one or more of: structure; data types; function signatures; and class definitions” which, conceptually, with broadest reasonable interpretation, provides further clarification as to the abstract idea/mental process/judgement/analysis/comparing/etc., which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 5 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 6, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the static code analysis leverages a generally available build tool framework of the platform” which, conceptually, with broadest reasonable interpretation, provides further clarification as to high level/generic computer/computer components/build tool framework/etc. used to implement/apply/perform the abstract idea/mental process/analysis/judgement/etc., which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 6 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 7, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein detecting the dynamic/runtime behavioral changes comprises: exercising the existing codebase and capturing results; exercising the updated codebase and capturing results; and comparing the captured results”, which conceptually, with broadest reasonable interpretation, recites further clarification as to the abstract idea/mental process/analysis/judgement/evaluation/comparing, and further recites insignificant extra solution activities to the judicial exception/abstract idea/mental process of gathering/obtaining/capturing/etc. data/information/results/etc. used in performing the abstract idea/mental process, which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 7 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
As per claim 8, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the method is performed in a customer build environment where platform code is integrated” which, conceptually, with broadest reasonable interpretation, provides further clarification as to high level/generic computer/computer components/customer build environment/platform code/etc. used to implement/apply/perform the abstract idea/mental process, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 8 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 9, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…preparing a report including information about the dynamic/runtime behavioral changes” which, conceptually, with broadest reasonable interpretations, recites insignificant extra solution activities to the judicial exception/abstract idea/mental process of updating/preparing/etc. and displaying/outputting/reporting/etc. information/data/etc., which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 9 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
As per claim 10, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the report including the information about the dynamic/runtime behavioral changes is encrypted” which, with broadest reasonable interpretation, provided further clarification as to the data/information displayed/output/reported/etc. by performing the insignificant extra solution activities of updating/preparing/etc. data/information and displaying/reporting/outputting/etc. data/information, which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 10 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
As per claim 11, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the report highlights the differences between the existing codebase and the updated codebase” which, with broadest reasonable interpretation, provided further clarification as to the data/information displayed/output/reported/etc. by performing the insignificant extra solution activities of displaying/reporting/outputting/etc. data/information, which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 11 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
As per claim 12, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the static code analysis is captured in the form of a binary/executable” which, with broadest reasonable interpretation, provides further clarification as to the abstract idea/mental process/evaluation/analysis/judging/etc. performed, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 12 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 13, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the static code analysis can be used in the customer build environment” which, conceptually, with broadest reasonable interpretation, provides further clarification as to high level/generic computer/computer components/customer build environment/etc. used to implement/apply/perform the abstract idea/mental process/analysis/judgement/etc., which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 13 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 14, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…including a signature and/or marker in relevant code based on any code changes” which, conceptually, with broadest reasonable interpretation, recites insignificant extra solution activities to the judicial exception/abstract idea/mental process of updating/modifying information/data/updating code to include a signature or marker/etc. which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 14 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
As per claim 15, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the static code analysis does not require purchase and/or license of any other off the shelf products or tools” which conceptually, with broadest reasonable interpretation, provides further clarification as to the abstract idea/mental process/analysis/judgement/etc. performed, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 15 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 16, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the static code analysis leverages the generally available build tool framework of the platform” which, conceptually, with broadest reasonable interpretation, provides further clarification as to high level/generic computer/computer components/build tool framework/etc. used to implement/apply/perform the abstract idea/mental process/analysis/judgement/etc., which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 16 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 17, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…upon the static code analysis indicating a type mismatch, a version of the code is tested with a variable type automatically corrected to match” which, with broadest reasonable interpretation provides further clarification as to the abstract idea/mental process/evaluation/analysis/testing/judgment/etc. performed, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. Therefore, claim 17 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above.
As per claim 18, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…upon the successful test of the version of the code with the variable type automatically corrected to match, changing the updated codebase to include the matching variable type” which, conceptually, with broadest reasonable interpretation, recites insignificant extra solution activities to the judicial exception/abstract idea/mental process of updating/changing/modifying information/data/changing codebase to include variable type/etc. which does not integrate the abstract idea into a practical application and the courts have identified functions such as gathering, displaying, updating, transmitting, and storing data as well-understood, routine, conventional activity, thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). As such, claim 18 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
As per claim 19, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the software changes relate to Radio Frequency (RF) Front End (RFFE) components” which, with broadest reasonable interpretation, provides further clarification as to the abstract idea/mental process, which does not integrate the abstract idea/mental process into a practical application and is not significantly more than the abstract idea/mental process. As such, claim 19 fails to correct the deficiencies of claim 1, and is therefore rejected for similar reasoning as claim 1, above.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-9, 11-13, and 15-16 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Pohlack et al. (herein called Pohlack) (US Patent 12,399,693 B1).
As per claim 1, Pohlack anticipates: a method for mitigating risk of platform software changes, the method comprising:
detecting a change using static code analysis (col. 10 lines 53-58, col 13 lines 23-30, static code analyzer compares previous and updated versions of code/program/etc. and determines/identifies (detects) differences/changes/updates to code/program (detect a change using static code analysis).); and
detecting dynamic/runtime behavioral changes (col. 3 lines 25-33, col. 9 lines 1-14, 28-55, col. 10 line 63-col. 11 line 50, col. 12 lines 13-50, targeted fuzzing service performs dynamic analysis of code by executing portions of code/code paths/etc. static analyzer determined to have been changed/updated/etc. (dynamic/runtime) and determining (detecting) effects of the changes/defects that occur/new or different execution paths through code/etc. (dynamic/runtime/execution behavioral changes).).
As per claim 2, Pohlack further anticipates: wherein detecting the dynamic/runtime behavioral changes comprises:
testing the dynamic/runtime behavioral changes based on the detected change using static code analysis (col. 3 lines 25-33, col. 9 lines 1-14, 28-55, col. 10 line 63-col. 11 line 50, col. 12 lines 13-50, targeted fuzzing service performs dynamic analysis (testing) of code by executing portions of code/code paths/etc. static analyzer determined to have been changed/updated/etc. and determining/detecting effects of the changes/defects that occur/new or different execution paths through code/etc. (testing dynamic/runtime/execution behavior changes/defects/different or new code paths/etc. based on detected change using static analysis/executing portions of code static analyzer determined to be changed/etc.).).
As per claim 3, Pohlack further anticipates: wherein detecting the change using static code analysis comprises:
analyzing an existing codebase and capturing results; analyzing an updated codebase and capturing results; and comparing the captured results (col. 10 lines 53-58, col 13 lines 23-30, static code analyzer receives binary executable code/test build/etc. corresponding to two versions of code/previous and updated versions of code/current source code under review and prior version of source code/etc. (analyze existing/previous/prior and updated/current codebases/versions of code and capture results) and compares previous and updated versions of code/program/etc. (compare captured results/previous and current codes/etc.) and determines/identifies/detects differences/changes/updates to code/program.).
As per claim 4, Pohlack further anticipates: wherein the existing codebase and updated codebase comprise source code files and libraries of interest (col. 8 lines 31-33, 35-40, code (codebase) being analyzed/tested/etc. via static and dynamic analysis (existing and updated codebase) may comprise python, javascript libraries (libraries of interest), source code (source code files), etc.).).
As per claim 5, Pohlack further anticipates: wherein comparing the captured results comprises a focus on one or more of: structure; data types; function signatures; and class definitions (col. 10 lines 55-55, two versions of the source code are compared and new or changed execution paths (structure) are determined (comparing captured results comprises a focus on structure).).
As per claim 6, Pohlack further anticipates: wherein the static code analysis leverages a generally available build tool framework of the platform (col. 6 lines 40-55, col. 10 lines 43-60, computing environment includes build service connected to static code analyzer (generally available build tool framework of the platform/computing environment) which performs static code analysis on code (static code analysis leverages generally available build tool framework of the platform/static analyzer/etc.).).
As per claim 7, Pohlack further anticipates: wherein detecting the dynamic/runtime behavioral changes comprises: exercising the existing codebase and capturing results; exercising the updated codebase and capturing results; and comparing the captured results (col. 8 line 63-col. 9 line 21, col. 13 lines 50-67, col. 14 lines 13-55, targeted fuzzing service performs initial dynamic analysis by executing initial version of code/existing codebase, generating map of execution paths and inputs, determining defects and storing map to use a guidance for later future analysis (exercise existing codebase and capture results), and when code changes create changes in execution paths/differences in code/etc. targeted fuzzing system uses stored map when executing changed code/updated codebase to determine changed/new code paths to be executed and determine defects caused by the changed code paths (exercise/execute updated codebase and capture results and compare captured results to determine defects/changed code paths/etc.).).
As per claim 8, Pohlack further anticipates: wherein the method is performed in a customer build environment where platform code is integrated (col. 4 lines 20-67, col. 6 lines 21-45, col. 8 lines 40-45, col. 16 lines 4-55, computer environment may be provided CI/CD pipeline in which software developer (customer) uses provided build services, static analyzer, targeted fuzzing service performing dynamic analysis/etc. to develop code (customer/developer build/development environment), and CI/CD pipeline/build services/static analyzer/targeted fuzzing service/etc. are implemented as web services/software tools/software modules/programs/instructions stored in memory of computing system/environment/etc. (platform code/software modules/instructions/web services/software tools/etc. integrated in/stored in/available in/etc. environment/system).).
As per claim 9, Pohlack further anticipates: preparing a report including information about the dynamic/runtime behavioral changes (col. 9 lines 50-col. 10 line 7, col. 11 lines 35-50, targeted fuzzing service that performs dynamic/runtime analysis/testing/etc. reports back identified defects/code execution paths/etc. (behavioral changes) identified during execution/dynamic analysis (prepare report including information about dynamic/runtime behavioral changes/defects/code paths/etc.).
As per claim 11, Pohlack further anticipates: wherein the report highlights the differences between the existing codebase and the updated codebase (col. 9 lines 50-col. 10 lines 5, col. 11 lines 35-50, col. 12 lines 13-50, col. 13 lines report comprises/includes/etc. (highlights) defects/new code paths/code paths associated with defects/etc. (differences between existing codebase and updated codebase/changes in updated version of code causing defects/etc.).).
As per claim 12, Pohlack further anticipates: wherein the static code analysis is captured in the form of a binary/executable (col. 8 lines 40-45, col. 10 lines 41-46, static code analyzer comprises analysis programs or modules which is triggered/executed/etc. and performs static analysis on code (static code analysis is captured in the form of executable/program/software module that is executed to perform static analysis).).
As per claim 13, Pohlack further anticipates: wherein the static code analysis can be used in the customer build environment (col. 4 lines 17-22 and 35-62, static code analyzer is included in computing environment/CI/CD pipeline used by software developer (customer/software developer build environment) and is executed on devices in environment to perform static analysis (static code analysis is used in customer/developer build environment/computing environment).).
As per claim 15, Pohlack further anticipates: wherein the static code analysis does not require purchase and/or license of any other off the shelf products or tools (col. 6 lines 43-48, static code analyzer may user open source analysis tools to perform static analysis. As the static analyzer may use open source analysis tools to perform the analysis and no other off the shelf products or tools are disclosed as being purchased and/or licensed to use the static code analyzer/perform static code analysis, the static code analysis does not require purchase and/or license of any other off the shelf products or tools.).
As per claim 16, Pohlack further anticipates: wherein the static code analysis leverages the generally available build tool framework of the platform (col. 6 lines 40-55, col. 10 lines 43-60, computing environment includes build service connected to static code analyzer (generally available build tool framework of the platform/computing environment) which performs static code analysis on code (static code analysis leverages generally available build tool framework of the platform/static analyzer/etc.).).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Pohlack et al. (herein called Pohlack) (US Patent 12,399,693 B1) and Sirota et al. herein called Sirota) (US Patent 8,819,106 B1).
As per claim 10, while Pohlack teaches performing dynamic analysis of code which includes executing the code and reporting back results of the execution/defects that occur during execution/etc., and storing the report/execution results/identified defects and code paths/etc. (ex: col. 9 lines 28-col. 10 line 7), it does not explicitly disclose that the report is encrypted and as such does not explicitly state, however Sirota teaches:
wherein the report including the information about the dynamic/runtime behavioral changes is encrypted (col. 10 lines 8-13, output data generated by program execution (report from Pohlack) is encrypted before storage. As Pohlack teaches generating a report that includes output/results of executing the code/program and storing the report/output, and Sirota teaches encrypting output data generated by program execution/executing a program before storing the output data, it is obvious that the report including the execution results/data generated by executing the program of Pohlack may be encrypted before being stored.).
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 report including the information about the dynamic/runtime behavioral changes is encrypted, as conceptually taught by Sirota, into that of Pohlack because these modifications allow for increased security of the report and help to prevent access to the report by undesired entities and ensure that the report is only available/readable/accessible/etc. to desired entities, thereby helping to ensure that the report is only used by entities that are desired to have access to the report.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Pohlack et al. (herein called Pohlack) (US Patent 12,399,693 B1) and Richardson et al. (herein called Richardson) (US PG Pub. 2016/0321452 A1).
As per claim 14, Pohlack does not explicitly state, however Richardson teaches:
including a signature and/or marker in relevant code based on any code changes (par. [0033], as developers release updates to application (code changes) developers sign updates (include signature in code changes/relevant code based on any code changes).).
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 including a signature and/or marker in relevant code based on any code changes, as conceptually taught by Richardson, into that of Pohlack because these modifications allow for the developer/user/etc. that makes code changes to be known and tracked, which is desirable as it helps ensure that changes are made by desired/authorized developers thereby increasing security of the code, and allows for the developer responsible for the code changes to be notified when defects/issues/etc. found in the code changes they are responsible for to be reported for the developer who made the change so the issue/defect may be corrected, thereby helping to ensure that errors/defects/etc. in the code are corrected so the code operates/executes as desired.
Claims 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Pohlack et al. (herein called Pohlack) (US Patent 12,399,693 B1) and Cook et al. (herein called Cook) (US Patent 11,200,144 B1).
As per claim 17, while Pohlack teaches performing static and dynamic analysis/testing, it does not explicitly state, however Cook teaches:
upon the static code analysis indicating a type mismatch, a version of the code is tested with a variable type automatically corrected to match (col. 9 lines 47, col. 10 lines 2-10, col. 11 lines 20-33, static analysis includes determining format string argument type mismatch, type mismatch integer to character, type mismatch negative to unsigned, etc. (static code analysis indicating a type mismatch), and static analysis system automatically generates source code/patches that corrects the problem/type mismatch/etc. (variable type is automatically corrected to match) which is presented to user for review and acceptance or rejection (version of code with variable type corrected to match is tested/reviewed and accepted or rejected by user/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 upon the static code analysis indicating a type mismatch, a version of the code is tested with a variable type automatically corrected to match, as conceptually taught by Cook, into that of Pohlack because these modifications allow for type mismatches/errors/etc. in the code/software/etc. to be identified and corrected, thereby helping to ensure that the code operates correctly/as desired.
As per claim 18, Pohlack does not explicitly state, however Cook teaches:
upon the successful test of the version of the code with the variable type automatically corrected to match, changing the updated codebase to include the matching variable type match (col. 9 lines 47, col. 10 lines 2-10, col. 11 lines 20-33, static analysis includes determining format string argument type mismatch, type mismatch integer to character, type mismatch negative to unsigned, etc. type mismatch), and static analysis system automatically generates source code/patches that corrects the problem/type mismatch/etc. (variable type automatically corrected to match) which is presented to user for review and acceptance or rejection and upon user accepting the changes/recommendations/etc. (successful test of version of code with variable type automatically corrected to match) the source code/program (updated codebase) is modified/changed/fixed/etc. by entering the code changes/replacing problematic code with patches/etc. (changing updated codebase to include matching variable type match).).
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 upon the successful test of the version of the code with the variable type automatically corrected to match, changing the updated codebase to include the matching variable type, as conceptually taught by Cook, into that of Pohlack because these modifications allow for type mismatches/errors/etc. in the code/software/codebase/etc. to be corrected, thereby helping to ensure that the code operates correctly/as desired.
Claims 19 is rejected under 35 U.S.C. 103 as being unpatentable over Pohlack et al. (herein called Pohlack) (US Patent 12,399,693 B1) and Mishra et al. (herein called Mishra) (US PG Pub. 2018/0074985 A1).
As per claim 19, Pohlack does not explicitly state, however Mishra teaches:
wherein the software changes relate to Radio Frequency (RF) Front End (RFFE) components (pars. [0006], [0009], [0020], [0029], code/software may be radio frequency front end/RFFE command code which may receive extensions allowing insertions of additional commands/field/etc. (software changes relate to radio frequency front end components).).
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 software changes relate to Radio Frequency (RF) Front End (RFFE) components, as conceptually taught by Mishra, into that of Pohlack because these modifications allow for the code/software/etc. being changed/updated/etc. to be known code type of code of RFFE/radio frequency front end code, thereby increasing usability of the code by allowing for additional known types of code to be the code being updated/modified/changed/etc., and helping to ensure that RFFE code may be changed/modified/etc. as desired thereby helping to ensure it operates as desired by users.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kuehlmann et al. US PG Pub. 2014/0096113 A1 teaches performing static and dynamic analysis/testing on source code, observe dynamic/runtime testing behavior, and provide/report observations about runtime behavior of the code during dynamic testing.
Fortier US PG Pub. 2012/0317645 A1 teaches performing static analysis and dynamic analysis on code, determining code/application behavior, and reporting behavior, issues, threat assessment of code/application.
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
