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 .
Claims 1-24 are pending in this office action.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a non-statutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based e-Terminal Disclaimer may be filled out completely online using web-screens. An e-Terminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about e-Terminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-24 are provisionally rejected on the ground of non-statutory double patenting as being unpatentable over claim 1-40 of co-pending Application No. 18196950 in view of Hoenzsch et al US20220283801A1.
Mapping of independent claims is as follow where respective claimed limitations are aligned with each other , while bald limitations constitute the difference.
This is a provisional non-statutory double patenting rejection.
Application:18/771,749
Copending:18/196,950
1. A method for analyzing at least one computing system to determine attributes of software within the computing system,
the attributes including vulnerabilities, weaknesses, robustness, expected/unexpected behaviors, functional attributes, non-functional attributes, and/or configuration/misconfigurations, the method comprising:
loading, via a processor, from a data storage, a memory, or via a communication, or via a user entry through a user interface, at least one input data representing or pertaining to the at least one software of the computing system, the at least one input data comprising at least one data format of the at least one software, the at least one data format including code, configurations, and/or behavioral data;
loading, from the data storage, the memory, or via the communication, or via the user entry through the user interface, and executing, via the processor, at least two individual analyses on the at least one data format of the at least one software of the at least one input data;
generating, via the processor, an individual analysis result for each of the at least two individual analyses, each individual analysis result pertaining to a layer and/or data format of the software, and indicating an attribute pertaining to the at least one input data;
loading, from the data storage, the memory, or via the communication, or via the user entry through the user interface, and executing, via the processor, at least one multi-layer and/or multi-data format analysis on the individual analysis results of the at least two individual analyses by identifying at least one logical relationship between an attribute of a first one of the individual analysis results pertaining to one layer and/or data format, an attribute of a second one of the individual analysis results pertaining to a different layer and/or data format that is logically related to the attribute of the first one of the individual analysis results;
generating, via the processor, at least one multi-layer and/or multi-data format analysis result indicating an additional attribute being different from the attributes indicated by the first and second ones of the individual analysis results;
generating, via the processor, an output data describing the individual analysis results and/or the at least one multi-layer and/or multi-data format analysis result;
storing, via the processor, the at least one output data in the memory; and determining, via the processor, if the at least one output data satisfies a predetermined condition, and if so, executing at least one action corresponding to the at least one output data on the computing system.
1.A method for analyzing at least one computing system for properties of at least one machine learning model comprised in the at least one computing system, the method comprising:
loading, via a processor, from a data storage, a memory, or via a communication, or via a user entry through a user interface, at least one input data for at least one machine learning model;
generating, via the processor, at least one surrogate model that simulates the behavior or characteristics, or an approximation of the behavior or the characteristics of the machine learning model, by using segments or an entirety of the loaded input data;
loading, from the data storage, the memory, or via the communication, or via the user entry through the user interface, and executing, via the processor, at least one analysis of a correlation between inputs and outputs of the at least one surrogate model, to identify at least one result pertaining to the at least one input data or the at least one machine learning model;
generating, via the processor, an output data describing the at least one result;
storing, via the processor, the output data pertaining to the at least one result in a memory; and determining, via the processor, if the at least one result satisfies a predetermined condition, and if so, executing at least one action corresponding to the at least one result on the computing system.
Independent claim 13
Independent claim 21
The co-pending application does not explicitly disclose:
the attributes including vulnerabilities, weaknesses, robustness, expected/unexpected behaviors, functional attributes, non-functional attributes, and/or configuration/misconfigurations;
loading, via a processor, from a data storage, a memory, or via a communication, or via a user entry through a user interface, at least one input data representing or pertaining to the at least one software of the computing system, the at least one input data comprising at least one data format of the at least one software, the at least one data format including code, configurations, and/or behavioral data;
generating, via the processor, at least one multi-layer and/or multi-data format analysis result indicating an additional attribute being different from the attributes indicated by the first and second ones of the individual analysis results;
Hoenzsch discloses
the attributes including vulnerabilities, weaknesses, robustness, expected/unexpected behaviors, functional attributes, non-functional attributes, and/or configuration/misconfigurations;
[0070] The scanning stage 225 may support utilities for vulnerability analysis associated with various stages (e.g., any of build stage 205, testing stage 210, scanning stage 215, or packaging stage 220) of an application lifecycle. In some examples, the scanning stage 240 may support identifying, resolving, and prevention of security vulnerabilities associated with the various stages. In some examples, the scanning stage 240 may support utilities for cloud-based detection of vulnerabilities on networked assets (e.g., servers, network devices, workstations.”;
loading, via a processor, from a data storage, a memory, or via a communication, or via a user entry through a user interface, at least one input data representing or pertaining to the at least one software of the computing system, the at least one input data comprising at least one data format of the at least one software, the at least one data format including code, configurations, and/or behavioral data;
[0059] In some examples, at any moment in time, the user device 105 (e.g., user device 105-e) may retrieve a version of a codebase by immutable identifier (e.g., commit, git commit)”;
[0099] The pipeline validation manager 320 may support managing metadata in accordance with examples as disclosed herein. The pipeline manager 325 may be configured as or otherwise support a means for executing a pipeline on a version of a codebase, the pipeline comprising one or more utilities corresponding to respective stages within the pipeline, wherein the version of the codebase is associated with an immutable identifier of a version control management system.
[0066]“In some cases, the build stage 205 may support utilities for building, testing, storing, and managing code and build configurations, for example, using any language (e.g., Java, JavaScript, PHP, Ruby, Python) or platform. For example, the build stage 205 may utilize utilities for repository management, which may, for example, be associated with a Git-based source code repository hosting service”;
generating, via the processor, at least one multi-layer and/or multi-data format analysis result indicating an additional attribute being different from the attributes indicated by the first and second ones of the individual analysis results;
[0085]”The application security testing stage may include an SAST stage. In some aspects, the application security testing stage may include a DAST stage. In some other aspects, the application security testing stage may include an interactive application security testing (IAST) stage. In some examples, the application security testing stage may include runtime application security protection (RASP). In some other examples, the application security testing stage may include software composition analysis (SCA). In an example, a user device 105 (e.g., user device 105-e described with reference to FIG. 1) may indicate, via a dashboard, “SAST Scanning Vulnerabilities. Critical: 1. High: 2. Low: 27.” In another example, the user device 105 may indicate, via the dashboard, “DAST Scanning Vulnerabilities. Critical: 0. High: 2. Low: 27.”
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Hoenzsch into teachings of Co-pending application for for improving accuracy in representing the safety and reliability of a version of a codebase. For example, in some development processes, developers may have the ability to bypass gates. The techniques described herein with respect to an immutable identifier may provide an external source of truth in the development process. [Hoenzsch 0091]
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-24 are rejected under 35 U.S.C. 103 as being unpatentable over Hoenzsch et al US20220283801A1, and further in view of Naik et al US10817283B1.
As per claim 1, Hoenzsch discloses a method for analyzing at least one computing system to determine attributes of software within the computing system, the attributes including vulnerabilities, weaknesses, robustness, expected/unexpected behaviors, functional attributes, non-functional attributes, and/or configuration/misconfigurations:
[0070] The scanning stage 225 may support utilities for vulnerability analysis associated with various stages (e.g., any of build stage 205, testing stage 210, scanning stage 215, or packaging stage 220) of an application lifecycle. In some examples, the scanning stage 240 may support identifying, resolving, and prevention of security vulnerabilities associated with the various stages. In some examples, the scanning stage 240 may support utilities for cloud-based detection of vulnerabilities on networked assets (e.g., servers, network devices, workstations.”;
the method comprising: the at least one input data comprising at least one data format of the at least one software, the at least one data format including code, configurations, and/or behavioral data:
[0059] In some examples, at any moment in time, the user device 105 (e.g., user device 105-e) may retrieve a version of a codebase by immutable identifier (e.g., commit, git commit)”;
[0099] The pipeline validation manager 320 may support managing metadata in accordance with examples as disclosed herein. The pipeline manager 325 may be configured as or otherwise support a means for executing a pipeline on a version of a codebase, the pipeline comprising one or more utilities corresponding to respective stages within the pipeline, wherein the version of the codebase is associated with an immutable identifier of a version control management system.
[0066]“In some cases, the build stage 205 may support utilities for building, testing, storing, and managing code and build configurations, for example, using any language (e.g., Java, JavaScript, PHP, Ruby, Python) or platform. For example, the build stage 205 may utilize utilities for repository management, which may, for example, be associated with a Git-based source code repository hosting service”;
loading, from the data storage, the memory, or via the communication, or via the user entry through the user interface, and executing, via the processor, at least two individual analyses on the at least one data format of the at least one software of the at least one input data
[0101] “The pipeline manager 425 may be configured as or otherwise support a means for executing a pipeline on a version of a codebase, the pipeline comprising one or more utilities corresponding to respective stages within the pipeline, wherein the version of the codebase is associated with an immutable identifier of a version control management system. The metadata manager 430 may be configured as or otherwise support a means for generating metadata for at least one utility of the one or more utilities of the pipeline based at least in part on executing the pipeline on the version of the codebase. In some examples, the metadata manager 430 may be configured as or otherwise support a means for storing the metadata at a database, “
.
generating, via the processor, an individual analysis result for each of the at least two individual analyses, each individual analysis result pertaining to a layer and/or data format of the software, and indicating an attribute pertaining to the at least one input data:
[0052]”In an example, using the immutable identifier, the user device 105 (e.g., user device 105-a, user device 105-b) may generate or publish metadata for one or more stages (e.g., a build stage, an application testing stage, an application security testing stage, a code quality stage, a policy adherence stage, a scanning stage, a packaging stage, a deployment stage, a monitoring stage) of the pipeline. In some examples, for a stage of a pipeline, the user device 105 may generate or publish metadata for one or more utilities (e.g., application testing tools, application security testing tools) associated with the stage. The metadata may include, for example, compliance results associated with any of the stages of the pipeline. In some aspects, the metadata may include compliance results for one or more utilities for any of the stages of the pipeline. An example pipeline and example stages thereof are described with reference to FIG. 2.”;
loading, from the data storage, the memory, or via the communication, or via the user entry through the user interface, and executing, via the processor, at least one multi-layer and/or multi-data format analysis on the individual analysis results of the at least two individual analyses:
[0054] “For example, the user device 105 (e.g., user device 105-e) may retrieve metadata at a gate (or gates) of the pipeline and compare the retrieved metadata to policy information 125 associated with the gate (or gates). In an example, for metadata retrieved by the user device 105 at a gate of the pipeline, the user device 105 may verify the retrieved metadata based on the comparison of the metadata to policy information 125 associated with the same gate (or gates). In some aspects, the metadata may include compliance results for stages (and utilities associated with the stages) in the pipeline which precede the gate”;
by identifying at least one logical relationship between an attribute of a first one of the individual analysis results pertaining to one layer and/or data format, an attribute of a second one of the individual analysis results pertaining to a different layer and/or data format that is logically related to the attribute of the first one of the individual analysis results;:
[0057]” That is, the user device 105 may query an immutable identifier (e.g., commit hash) being deployed, and the user device 105 may receive metadata corresponding to the query, where the metadata includes security, testing, and other information. In some examples, if the user device 105 detects a failed policy based on the comparison of retrieved metadata to the policy information 125, the user device 105 may terminate or pause deployment of the codebase until all policies or standards included in the policy information 125 have been met. The techniques described herein for terminating or pausing deployment of the codebase may thereby reduce risk and provide development teams a relatively safe and quick pathway to production”;
generating, via the processor, at least one multi-layer and/or multi-data format analysis result indicating an additional attribute being different from the attributes indicated by the first and second ones of the individual analysis results;
[0085]”The application security testing stage may include an SAST stage. In some aspects, the application security testing stage may include a DAST stage. In some other aspects, the application security testing stage may include an interactive application security testing (IAST) stage. In some examples, the application security testing stage may include runtime application security protection (RASP). In some other examples, the application security testing stage may include software composition analysis (SCA). In an example, a user device 105 (e.g., user device 105-e described with reference to FIG. 1) may indicate, via a dashboard, “SAST Scanning Vulnerabilities. Critical: 1. High: 2. Low: 27.” In another example, the user device 105 may indicate, via the dashboard, “DAST Scanning Vulnerabilities. Critical: 0. High: 2. Low: 27.”
generating, via the processor, an output data describing the individual analysis results and/or the at least one multi-layer and/or multi-data format analysis result;
[0086]”In another example, for an application security testing stage (e.g., the testing stage 210, the testing stage 235), the metadata parameters may include code coverage information associated with the application security testing stage. The code coverage information may include, for example, a quantity of tests performed, a quantity of tests passed, a quantity of tests skipped, or a quantity of tests failed. In an example, a user device 105 (e.g., user device 105-e) may indicate, via a dashboard, “Code Quality: A. Code Coverage: 87%.” In another example, the user device 105 may indicate, via the dashboard, “Unit Tests Ran: 1204. Unit Tests Passed: 1204. Unit Tests Skipped: 1. Unit Tests Failed: 0.”
storing, via the processor, the at least one output data in the memory:
[0050] In an example, any of the user devices 105 (e.g., user devices 105-a through 105-f) may store metadata (e.g., compliance results) at the database 115 using an immutable identifier (e.g., a commit hash, git commit hash, or the like).”;
and determining, via the processor, if the at least one output data satisfies a predetermined condition, and if so, executing at least one action corresponding to the at least one output data on the computing system:
[0059]“In some examples, at any moment in time, the user device 105 (e.g., user device 105-e) may retrieve a version of a codebase by immutable identifier (e.g., commit, git commit). The user device 105 may determine or verify whether the version of the codebase was scanned, whether any vulnerabilities were found, whether all tests were passed by each team (e.g., development team, quality assurance team), and so on. In some aspects, such data may be indicated as a release dashboard (e.g., via a graphical user interface) displayed at the user device 105 and may be implemented as a manual gate before a team goes to production.”;
[0053]“In some examples, a user device 105 (e.g., user device 105-e) may verify metadata at one or more gates (also referred to herein as release gates) of the pipeline. In some aspects, the gates may be enabled at the start of a stage (e.g., pre-deployment conditions) or at the end of a stage (e.g., post-deployment conditions), or both. Pre-deployment gates, for example, may be enabled to ensure that no active issues are present prior to deploying a build to an environment.”;
But not explicitly:
loading, via a processor, from a data storage, a memory, or via a communication, or via a user entry through a user interface, at least one input data representing or pertaining to the at least one software of the computing system:
Naik discloses:
loading, via a processor, from a data storage, a memory, or via a communication, or via a user entry through a user interface, at least one input data representing or pertaining to the at least one software of the computing system:
Col 4 lines 60-67 “In one embodiment, responsive to detecting a new version of source code 112, the CI pipeline 115 can then send a notification of the new source code version 125 to risk assessment manager 140. Risk assessment manager 140 may then, upon detecting the new version of source code 112, retrieve source code 112 and perform automated risk assessment for the new source code version. As discussed in further detail herein, risk assessment manager 140 can analyze the new version of the source code, determine the differences between the new version of the source code and a previous version of the source code, determine a risk weight value associated with the differences, and execute an appropriate deployment protocol based on the determined risk.”;
It would have obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to combine the teachings of cited references. One of ordinary skill in the art before the effective filling date of the claimed invention would have been motivated to incorporate the teachings of Naik into teachings of Hoenzsch for performing automated risk assessment of source code. The automated risk assessment is provided within a pipeline in a more cost effective and resource efficient manner. The risk assessment manager is provided automatically which determines risk associated with a change to source code thus enhance the performance of various change management stages of a continuous integration (CI) pipeline.(Naik col 2lines 10-20).
As per claim 2, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one computing system comprises at least one of a No/Low-Code (NLC) application platform, information technology (IT) system, cloud system, artificial intelligence system, machine learning model, simulation, control system, edge device, embedded device, information technology device, operational technology (OT) device, industrial control system, cyber-physical system, headset, mobile device, tablet device, or robotics system:
[0037] FIG. 1 illustrates an example of a system 100 for that supports pipeline release validation in accordance with aspects of the present disclosure. The system 100 may include one or more user devices 105 (e.g., including user device 105-a through user device 105-f). The system 100 may be, for example, a version control management system. Each user device 105 may be an example of a laptop, a desktop computer, a mobile device, a smart device, or the like.
As per claim 3, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the attributes comprise at least one of vulnerabilities, weaknesses, correctness, compliance, adherence to best practices, robustness, fairness, non-bias, transparency, interpretability, safety, security, reliability, accuracy, trust, explainability, privacy, or accountability.
[0032] In an example, for an application security testing stage (e.g., a static application security testing (SAST) tool, a dynamic application security testing (DAST) tool) the metadata parameters may include vulnerability information for the application security testing stage. The vulnerability information may include, for example, a quantity of vulnerabilities and respective seventies thereof. In another example, for a testing stage, the metadata parameters may include code coverage information associated with the testing stage. The code coverage information may include, for example, a quantity of tests performed, a quantity of tests passed, a quantity of tests skipped, or a quantity of tests failed. Additional examples of pipeline stages and configured metadata parameters are described further herein.
[0035]“In some aspects, the features described herein may provide increased accuracy in representing the safety and reliability of a version of a codebase.”;
As per claim 4, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
performing, by the processor, at least one of continuous integration and continuous deployment (CI/CD) DevOps/DevSecOps, testing, development, security analysis, evaluation, certification:
[0028] A DevOps pipeline includes a set of practices implemented by development and operations teams to build, test, and deploy software. Similarly, a DevSecOps pipeline may include additional security (e.g., active and/or automated security audits) for DevOps-based software development. In a software development process, utilizing a DevOps or DevSecOps pipeline may serve to maintain organization during the process. For example, a DevOps or DevSecOps pipeline may utilize strategies such as continuous integration (also referred to herein as CI) for integrating portions or chunks of code from multiple developers into a shared code repository or database as often as possible. Continuous integration may support automatic testing of code for errors, independent of code contributed by other members. Continuous delivery and continuous deployment are extensions of continuous integration. Continuous delivery involves the manual release or deployment of software, features, and code updates (by developers) to production in incremental chunks, whereas continuous deployment involves automation of the release cycle”;
and determining a suspicious fault, violation of requirements, or vulnerability in the computing system during the performance of the at least one of CI/CD DevOps/DevSecOps, testing, development, security analysis, evaluation, certification:
[0013] “the one or more utilities comprises a set of utilities corresponding to a set of application security testing stages of the pipeline and the vulnerability information comprises a security report associated with a report identifier, the set of utilities, the set of application security testing stages, or any combination thereof”;
wherein the at least one input data is loaded when the suspicious fault, violation of requirements, or vulnerability is determined.
[0068]”The scanning stage 215 may support continuous inspection of code quality, policy adherence for infrastructure or configuration, or a combination thereof. In some cases, the scanning stage 215 may utilize platforms to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities. In some examples, the scanning stage 215 may utilize platforms supportive of continuous inspection of code quality and security of codebases. Some other platforms may include software composition analysis solutions for detecting and identifying open-source components.”;
As per claim 5, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one input data comprises at least one of binary software, machine code software, Intermediate Representation (IR) software, Intermediate Language (IL) software, bytecode software, source code, No/Low-Code (NLC) configurations, and application configurations:
[0029] A DevOps or DevSecOps pipeline may include various stages, as software may evolve from source code to being deployed in a particular environment
[0066] The build stage 205 may support building or compiling of an application. In some cases, the build stage 205 may support utilities for building, testing, storing, and managing code and build configurations, for example, using any language (e.g., Java, JavaScript, PHP, Ruby, Python) or platform”;.
As per claim 6, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least two individual analyses include security policies and configurations analysis, binary analysis, artificial intelligence and machine learning (AI/ML) based analysis, software composition analysis, and system behavior analysis.:
[0072] The testing stage 235 may support code testing of the application, for example for test applications, measuring system behavior and performance under load. In some examples, the testing stage 235 may support post-deployment testing.
[0085] “ In some other aspects, the application security testing stage may include an interactive application security testing (IAST) stage. In some examples, the application security testing stage may include runtime application security protection (RASP). In some other examples, the application security testing stage may include software composition analysis (SCA). “;
As per claim 7, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one individual analysis result comprises at least one of vulnerability, weakness, absence of vulnerability, absence of weakness, mitigation recommendation, attacks, severity, and potential impact:
[0060] “In some cases, the release dashboard may provide an interface via which the change owner may open or provide security exceptions with respect to the vulnerabilities (e.g., to proceed to production). Accordingly, the techniques may provide advantages for change owners. For example, gates may occur in a development environment, and the techniques described herein may provide change owners an awareness of those gates at the time of pre-production or production deployments.”;
[0068] “ In some cases, the scanning stage 215 may utilize platforms supportive of identifying and reporting of patterns found in code, improving code consistency, and bug identification or mitigation. In some other cases, the platforms may support the defining of rules, actions, and policies for satisfying parameters defined by an organization or development teams.”;
As per claim 8, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one multi-layer analysis comprises identifying correlations across individual analysis results indicating additional results and detecting anomalies across individual analysis results indicating additional results:
[0070]” In some examples, the scanning stage 240 may support identifying, resolving, and prevention of security vulnerabilities associated with the various stages. In some examples, the scanning stage 240 may support utilities for cloud-based detection of vulnerabilities on networked assets (e.g., servers, network devices, workstations.”;
[0068] “ In some cases, the scanning stage 215 may utilize platforms supportive of identifying and reporting of patterns found in code, improving code consistency, and bug identification or mitigation. In some other cases, the platforms may support the defining of rules, actions, and policies for satisfying parameters defined by an organization or development teams.”;
As per claim 9, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one input data is loaded once, multiple times, or on a continuous basis.
[0047] “According to examples of aspects described herein, techniques are described for pipeline release validation and release lifecycle management, for example, of a continuous integration pipeline (e.g., where code changes may be merged with a central repository), continuous delivery pipeline (e.g., where code changes may be deployed within some environment prior to deployment), and/or a continuous deployment pipeline (e.g., where code changes may be deployed to a production environment). “;
As per claim 10, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
analyzing the input data for unexpected data, inconsistencies, anomalies, or out-of-distribution data:
[0068] “In some examples, the scanning stage 215 may utilize platforms supportive of continuous inspection of code quality and security of codebases. Some other platforms may include software composition analysis solutions for detecting and identifying open-source components. In some cases, the scanning stage 215 may utilize platforms supportive of identifying and reporting of patterns found in code, improving code consistency, and bug identification or mitigation.”;
As per claim 11, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one output data comprises at least one of an analysis report, user-readable analysis report, visualizations, suggestions, recommendations, scorecard, machine-readable analysis report, or application programming interface (API) call.
[0074] “ In some cases, the monitoring stage 245 may support capturing, indexing, and correlation of real-time data in a searchable repository, from which graphs, reports, alerts, dashboards and visualizations may be generated by a user device 105. “:
As per claim 12, the rejection of claim 1 is incorporated and furthermore Hoenzsch discloses:
wherein the at least one action comprises at least one of presenting output data to a user, communicating output data to another machine, storing output data, triggering one or more notifications or alarms, blocking functioning of a computing system, or triggering automated hardening of the computing system.
[0074]”The monitoring stage 245 may support visualization of near real-time status of the pipeline 200. In some cases, the monitoring stage 245 may support capturing, indexing, and correlation of real-time data in a searchable repository, from which graphs, reports, alerts, dashboards and visualizations may be generated by a user device 105.
Claims 13, 14, 15, 16,17, 18, 19, 20, 21, 22, 23, 24 are the system claims corresponding to method claims 1, 2, 2, 4, 5, 6, 7, 8, 9,1 0, 11, 12 and rejected under the same rational set forth in connection with the rejection of claims 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 above.
Pertinent arts:
US 11809575 B1:
analyzing the software asset for supply chain information to verify if the software asset meets the minimum policy requirements for compliance based on provenance, licensing, vulnerability and security criteria set by the company, determining if a third-party software component is approved for use in the company's applications based on policy and compliance rules and identifying current vulnerabilities and potential remediation for software in use by the company.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRAHIM BOURZIK whose telephone number is (571)270-7155. The examiner can normally be reached Monday-Friday (8-4:30).
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, Wei Y Mui can be reached at 571-270-2738. 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.
/BRAHIM BOURZIK/ Examiner, Art Unit 2191
/WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191
Prosecution Insights