DETAILED ACTION
The applicant’s amendment filed on November 25, 2025 has been acknowledged. Claims 2 and 12 have been canceled. Claims 1, 3-11, and 13-19, as previously presented, are currently pending and have been considered below.
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 .
Double Patenting
The nonstatutory 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 nonstatutory 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 nonstatutory 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 nonstatutory 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 eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 3-11 and 13-19 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-19 of copending Application No. 18/923,095 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because see table below.
Application 18/048,630
Claim 1
Application 18/923,095
Claim 1
A method for remediating contextually enriched alerts in infrastructure as code (laC) deployments, comprising:
A method for remediation (claim 1)
determining, based on a unique identifier of a computing infrastructure resource indicated in an alert, a source identifier of a resource component including the computing infrastructure resource, wherein the resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component reside;
determining a source identifier of a second resource component including a computing infrastructure resource by querying the enrichment database using the unique identifier of the computing infrastructure resource, wherein the second resource component is indicated in an alert; (claim 1)
wherein the second resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component reside. (claim 2)
wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component;
wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component. (claim 6)
extracting source code of the resource component based on the source identifier;
recursively crawling through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling. (Claim 7)
determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert;
determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author. (Claim 5)
contextually enriching the alert by adding the source identifier of the resource component including the computing infrastructure resource and the determined author of the revision of the extracted source code to the alert; and
contextually enriching the alert indicating the second resource component by adding the source identifier of the second resource component to the alert in order to create a contextually enriched alert. (Claim 3)
wherein the alert is contextually enriched based further on the determined author. (Claim 5)
performing at least one remediation action with respect to the contextually enriching alert.
and performing at least one remediation action with respect to the alert based on the source identifier of the second resource component. (Claim 1)
wherein the at least one remediation action is performed based on the contextually enriched alert. (Claim 4)
Claim 3
Claim 1
wherein the resource component is a first resource component, wherein the resource is a first resource of a plurality of resources included in the first resource component, wherein determining the source identifier of the resource component further comprises: querying an enrichment database using the unique identifier of the computing infrastructure resource indicated in the alert, wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components.
determining a source identifier of a second resource component including a computing infrastructure resource by querying the enrichment database using the unique identifier of the computing infrastructure resource, wherein the second resource component is indicated in an alert;
wherein the enrichment database includes associations between source identifiers of the plurality of first resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of first resource components;
Claim 4
Claim 1
creating the enrichment database, wherein creating the enrichment database further comprises analyzing source code of a root resource component in order to identify a plurality of dependencies of the root resource component.
creating an enrichment database by analyzing the source code of each root resource component in order to identify a plurality of dependencies of each root resource component,
Claim 5
Claim 7
wherein creating the enrichment database further comprises: recursively crawling through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components is determined based on the recursive crawling.
wherein creating the enrichment database further comprises: recursively crawling through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling.
Claim 6
Claim 8
wherein the recursive crawling is performed up to at least one leaf resource component, wherein each leaf resource component is a resource component from which another resource component depends, wherein each leaf resource component does not depend from another resource component.
wherein the recursive crawling is performed up to at least one leaf resource component among the plurality of first resource components, wherein each leaf resource component is a resource component from which another resource component depends, wherein each leaf resource component does not depend from another resource component.
Claim 7
Claim 9
wherein the root resource component is a first root resource component of at least one root resource component, wherein the enrichment database is created based on a configuration mapping file of at least one root resource component and based on source code of the at least one root resource component.
wherein the enrichment database is created based on a configuration mapping file of at least one root resource component and based on source code of the at least one root resource component.
Claim 8
Claim 1
analyzing a software development pipeline log including a step in which the first resource component is deployed in order to determine a location and a time of deployment for the first resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the first resource component.
analyzing the at least one software development pipeline log with respect to the identified plurality of steps in order to determine a location and a time of deployment for each first resource component of the plurality of first resource components;
retrieving source code of a root resource component for each first resource component of the plurality of first resource components based on the determined location and time of deployment for the first resource component;
Claim 9
Claim 5
determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
Claim 10
Claim 10
A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising:
A non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process, the process comprising:
determining, based on a unique identifier of a computing infrastructure resource indicated in an alert, a source identifier of a resource component including the computing infrastructure resource, wherein the resource component includes source code and at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component reside;
determining a source identifier of a second resource component including a computing infrastructure resource by querying the enrichment database using the unique identifier of the computing infrastructure resource, wherein the second resource component is indicated in an alert; (claim 10)
wherein the second resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component reside. (claim 2)
wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component;
wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component. (Claim 16)
extracting source code of the resource component based on the source identifier;
recursively crawling through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling. (Claim 7)
determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert;
determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author. (Claim 5)
contextually enriching the alert by adding the source identifier of the resource component including the computing infrastructure resource and the determined author of the revision of the extracted source code to the alert; and
contextually enriching the alert indicating the second resource component by adding the source identifier of the second resource component to the alert in order to create a contextually enriched alert. (Claim 3)
wherein the alert is contextually enriched based further on the determined author. (Claim 5)
performing at least one remediation action with respect to the contextually enriching alert.
performing at least one remediation action with respect to the alert based on the source identifier of the second resource component. (Claim 10)
wherein the at least one remediation action is performed based on the contextually enriched alert. (Claim 4)
Claim 11
Claim 11
A system for securing deployment of computing infrastructure resources, comprising:
A system for remediation, comprising: (Claim 11)
a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to:
a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to: (Claim 11)
determine, based on a unique identifier of a computing infrastructure resource indicated in an alert, a source identifier of a resource component including the computing infrastructure resource, wherein the resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component reside;
determine a source identifier of a second resource component including a computing infrastructure resource by querying the enrichment database using the unique identifier of the computing infrastructure resource, wherein the second resource component is indicated in an alert; and (Claim 11)
wherein the second resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component reside. (Claim 12)
wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component;
wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component. (Claim 16)
extract source code of the resource component based on the source identifier;
recursively crawling through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling. (Claim 15)
determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert;
determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author. (Claim 19)
contextually enrich the alert by adding the source identifier of the resource component including the computing infrastructure resource and the determined author of the revision of the extracted source code to the alert; and
wherein the system is further configured to: contextually enrich the alert indicating the second resource component by adding the source identifier of the second resource component to the alert in order to create a contextually enriched alert. (Claim 13)
wherein the alert is contextually enriched based further on the determined author. (Claim 19)
perform at least one remediation action with respect to the contextually enriching alert.
perform at least one remediation action with respect to the alert based on the source identifier of the second resource component. (Claim 11)
wherein the at least one remediation action is performed based on the contextually enriched alert. (Claim 14)
Claim 13
wherein the resource component is a first resource component, wherein the resource is a first resource of a plurality of resources included in the first resource component, wherein the system is further configured to: query an enrichment database using the unique identifier of the computing infrastructure resource indicated in the alert, wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components.
wherein each of the identified plurality of steps is a step in which a first resource component among a plurality of first resource components is deployed; (Claim 11)
determine a source identifier of a second resource component including a computing infrastructure resource by querying the enrichment database using the unique identifier of the computing infrastructure resource, wherein the second resource component is indicated in an alert; and (Claim 11)
wherein the enrichment database includes associations between source identifiers of the plurality of first resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of first resource components; (Claim 11)
Claim 14
Claim 11
wherein the system is further configured to: create the enrichment database, wherein creating the enrichment database further comprises analyzing source code of a root resource component in order to identify a plurality of dependencies of the root resource component.
create an enrichment database by analyzing the source code of each root resource component in order to identify a plurality of dependencies of each root resource component, (Claim 11)
Claim 15
Claim 17
wherein the system is further configured to: recursively crawl through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components is determined based on the recursive crawling.
wherein the system is further configured to: recursively crawl through source code of the root resource component and at least one dependency of the root resource component, wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling.
Claim 16
Claim 18
wherein the recursive crawling is performed up to at least one leaf resource component, wherein each leaf resource component is a resource component from which another resource component depends, wherein each leaf resource component does not depend from another resource component.
wherein the recursive crawling is performed up to at least one leaf resource component among the plurality of first resource components, wherein each leaf resource component is a resource component from which another resource component depends, wherein each leaf resource component does not depend from another resource component.
Claim 17
Claim 19
wherein the root resource component is a first root resource component of at least one root resource component, wherein the enrichment database is created based on a configuration mapping file of at least one root resource component and based on source code of the at least one root resource component.
wherein the enrichment database is created based on a configuration mapping file of at least one root resource component and based on source code of the at least one root resource component. (Claim 19)
Claim 18
Claim 11
wherein the system is further configured to: analyze a software development pipeline log including a step in which the first resource component is deployed in order to determine a location and a time of deployment for the first resource component; and retrieve the source code of the root resource component based on the determined location and time of deployment for the first resource component.
analyze the at least one software development pipeline log with respect to the identified plurality of steps in order to determine a location and a time of deployment for each first resource component of the plurality of first resource components; retrieve source code of a root resource component for each first resource component of the plurality of first resource components based on the determined location and time of deployment for the first resource component; (Claim 11)
Claim 19
Claim 15
wherein the system is further configured to: determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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(s) 1 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Rizo et al. (US 2020/0012480 A1) hereafter Rizo, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut.
As per claim 1, Shen discloses a method for remediating contextually enriched alerts in […] deployments (Page 12, paragraph [0120]; discloses contextually enriching alerts with additional data specifically an identifier of system components which the alert is related to. Page 7, paragraph [0075]; discloses that the faults are identified and remediated as quickly as possible to minimize costs and computational resources. Page 11, paragraphs [0111]-[0112]; discloses that the remediations can take the form of rollbacks or reconfigurations), comprising:
determining, based on a unique identifier of a computing infrastructure resource indicated in an alert, a source identifier of a resource component including the computing infrastructure resource (Page 8, paragraph [0081]; discloses that the monitoring system is configured to receive a plurality of alerts. The alerts are associated with faults in the network. The alerts can identify system components which are experiencing a fault. This acts as a unique identifier of the components and can be used to identify the common or root cause of the faulty component which is considered the source identifier),
contextually enriching the alert by adding the source identifier of the resource component including the computing infrastructure resource and additional information to the alert (Page 12, paragraph [0120]; discloses that alert can be enriched by adding the identifier of the system component to the alert. Shen additionally states in paragraph [0120] that the alert can include additional information); and
performing at least one remediation action with respect to the contextually enriching alert (Page 13, paragraph [0124]; discloses that the remediation actions are performed in respect for the alert, which include automatic rollback).
While Shen discusses infrastructure components it is not explicit that the environment of use is infrastructure as code (IaC). Additionally, Shen is not explicit wherein the resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides. Shen fails to state extracting source code of the resource component based on the source identifier; determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. Shen further fails to explicitly disclose wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
McCann, which like Shen discusses monitoring components, teaches wherein the resource component includes at least one source file (Col. 13, lines 42-54; teaches that it is known to define components and for those components to include source files. Col. 15, line 47 through Col. 16, line 25; teaches that the components are defined by make files which outline the dependencies of the of the system for the component. Col. 16, lines 33-57; teach that the make files specify the dependencies between different source files. This is used to track rebuilding of necessary files and tracks objects that depend on the source files. The software tools process one or more inputs such as user source code),
McCann additionally teaches wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides (Col. 21, lines 24-55; teaches that the make files include derived information derived by the build component and included in the file. The items can redefine the directory location, in doing so the make file includes information that identifies the target and target variants, it identifies the version of the build, the directory location of the source, object, default directory location. This information is used to communicate with the tools of the system. Col. 25, lines 16-57; teaches that the system contains a directory structure of files including a root directory and has subdirectories, the directory includes the make file which is user supplied code and the user source code. Since Shen discusses identifying the component having the fault it would have been obvious to identify the at component using other techniques such as the one shown in McCann which is a combination of characteristics of the component or machine).
McCann additionally teaches extracting source code of the resource component based on the source identifier (Col. 21, lines 24-55; teaches identifying the version of the build, the directory location of the source, object, default directory location. This information is used to communicate with the tools of the system and identify the source. Col. 14, line 39-65; teaches that the system can extract information including source code from the components based on the identifiers);
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts.
The sole difference between the Shen reference and the claimed subject matter is that the Shen reference does not disclose wherein the resource component includes at least one source file and wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides.
The McCann reference teaches analyzing resource components teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. McCann establishes that this type of identifying a source was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the unique identifier shown in Shen with the combination of characteristic used together to identify the source as shown in McCann.
Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Therefore, from this teaching of McCann, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, with the unique identifier being a combination of characteristics as taught by McCann, for the purposes of using known techniques to uniquely identify a resource. Since Shen discusses identifying the component having the fault it would have been obvious to identify the at component using other techniques such as the one shown in McCann which is a combination of characteristics of the component or machine.
The combination fails to explicitly disclose determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. The combination further fails to explicitly disclose wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Bostick, which like the combination talks about identifying information from source code, teaches it is known to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code (Page 2, paragraph [0021]; teaches that the system can compare source code to determine revisions and determines the author of the changes in the revision of the source code by analyzing the software development log. The system can issue an alert or message indicating the author’s name and version indicator. Since the combination already establishes that the alert can include any additional information, it would have been obvious to include the version indicator and the author’s name to determine who is responsible for the changes as shown in Bostick. As discussed in Bostick this is done to identify the individual who introduced, modified, or deleted specific portions of code and caused the error or errors).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. However, the combination fails to determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code.
Bostick teaches determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. Bostick establishes that identifying revisions and those who authored those revisions was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen and McCann the ability to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code as taught by Bostick since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Bostick, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen and McCann, with the ability to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code as taught by Bostick, for the purposes of identifying revisions and the author of those revisions. Since the combination already establishes that the alert can include any additional information, it would have been obvious to include the version indicator and the author’s name to determine who is responsible for the changes as shown in Bostick. As discussed in Bostick this is done to identify the individual who introduced, modified, or deleted specific portions of code and caused the error or errors.
While Shen discusses infrastructure components and McCann teaches the use of infrastructure code it is not explicit that the environment of use is infrastructure as code (IaC). The Examiner notes that this is solely used in the claim preamble and the preamble does not limit the body of the claim as it does not “give life, meaning and vitality” to the claim, See MPEP 2111.02. Specifically claims 10 and 11 recite similar limitations but do not reference or recite “infrastructure as code (IaC)”. However, for the purposes of expedited prosecution the Examiner has provided the following to establish the implementation of Infrastructure as Code was known. The combination further fails to explicitly disclose wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Rizo, which like the combination talks about monitoring infrastructure, teaches it is known to implement components in an Infrastructure as Code (IaC) environment and to utilize the monitored information to remediate unauthorized changes to the system (Page 2, paragraphs [0019]-[0020]; teaches it known to implement infrastructure in a cloud platform using Infrastructure as Code environment. Rizo establishes that system can compare the infrastructure to code base to check for unauthorized changes and/or differences between different environments. This is similar to what is shown in Shen paragraph [0086] where the system determines unauthorized changes. As such it would have been obvious to utilize the techniques shown in Shen in the IaC environment discussed in Rizo to remediate the unauthorized changes as discussed in Shen. As stated in Shen this would minimize costs and resources).
Rizo additionally teaches that the infrastructure code can be versioned controlled in a source code repository for others to reuse and/or compare. Rizo provides a commit log as part of the history of the version controlled source code repository (Page 2, paragraph [0026]).
One of ordinary skill in the art of infrastructure management would have found it obvious to perform source identification and alert enrichment in the Infrastructure as Code (IaC) environment based on what was known in the related environment as shown in Shen. Specifically, that it is known to monitoring for unauthorized changes or modifications and to enrich alerts to include source identifiers. This allows the system automatically remediate the problems which are found. Additionally, Shen establishes that this reduces the costs and necessary resources when managing the system. All this would be accomplished with no unpredictable results.
Therefore, from this teaching of Rizo, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen and McCann, with the managing infrastructure in the Infrastructure as Code (IaC) environment as taught by Rizo, for the purposes of using known techniques in related environments to achieve known results. It would have been obvious to utilize the techniques shown in Shen in the IaC environment discussed in Rizo to remediate the unauthorized changes as discussed in Shen. As stated in Shen this would minimize costs and resources.
The combination further fails to explicitly disclose wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Malamut, which like the combination talks about uniquely identifying resources, teaches it is known wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component (Page 6, paragraph [0057]; teaches that the file can be uniquely identified using the repository or directory in which the file is stored, the revision or version and the path to the directory. This is used to uniquely identify the resource or file. Since the combination establishes that the unique identifier can be a combination of elements it would have been obvious to substitute that combination with any other known combination as the end result would continue to be a unique identifier to identify the location of the resource).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Rizo teaches it is known to implement components in an Infrastructure as Code (IaC) environment and to utilize the monitored information to remediate unauthorized changes to the system.
The sole difference between the combination and the claimed subject matter is that the combination does not explicitly disclose the source identifier combination comprises a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component.
Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. Malamut establishes that the use of this combination of information to uniquely identify a resource was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of combination of identifiers to identify resource taught by Shen, McCann, Bostick and Rizo with the combination being a repository, a revision and a path to the directory as shown in Malamut.
Therefore, from this teaching of Malamut, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick and Rizo, with the combination of characteristics including a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component as taught by Malamut, for the purposes of uniquely identifying the resource using known techniques. Since the combination establishes that the unique identifier can be a combination of elements it would have been obvious to substitute that combination with any other known combination as the end result would continue to be a unique identifier to identify the location of the resource.
Claim(s) 3-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Rizo et al. (US 2020/0012480 A1) hereafter Rizo, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut, further in view of Shekhar (US 8,615,015 B1) hereafter Shekhar.
As per claim 3, the combination of Shen, McCann, Bostick, Rizo and Malamut teaches the method of claim 1; Shen further discloses wherein the resource component is a first resource component (Page 10, paragraph [0096]; discloses that the resource component is a first resource component),
wherein the resource is a first resource of a plurality of resources included in the first resource component (Page 10, paragraph [0096]; discloses that the component can comprise a plurality of nodes or resources. Page 10, paragraph [0097]; discloses that each alert is associated with at least one node of a plurality of nodes. Each set of nodes is associated with software applications as well as other nodes),
wherein determining the source identifier of the resource component further comprises: querying an enrichment database using the unique identifier of the computing infrastructure resource indicated in the alert (Page 10, paragraph [0098]; discloses that monitoring system determines common nodes by determine which nodes are connected to each other and which nodes share edges. This is done to determine the root cause of the one or more affected system components. Page 11, paragraph [0109]; discloses that the records are used to identify the effected node or resource and the state of the resource. Page 12, paragraphs [0117]-[0118]; discloses that the monitoring system determines which nodes are affected and used this information to determine the root cause of the fault indicated in the alert. Page 13, paragraph [0127]; discloses that the infrastructure and application configurations as well as topology are stored and received from a database).
While the combination discloses utilizing a database to identify the resources affected by the fault indicated in the alert, the combination is not explicit wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components.
Shekhar, which like the combination discusses mapping the infrastructure of the system, teaches wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. Col. 10, line 27 through Col. 11, line 3; teaches that the unique identifiers of each of the plurality of resources are indicated and stored as associations between the each of the identifiers. Col. 13, lines 45-49; teaches that the route and connections are stored in a database for future reference. From this the system stores in a database the relationships between each identifier for each resource and the resources it depends from or which depends from it. Since Shen already identifies the related nodes and their relationships to other nodes it would have been obvious to store along with the affected nodes their associations to other nodes as shown in Shekhar as this is a known technique in mapping the network and determine which nodes depend on other nodes).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Rizo teaches it is known to implement components in an Infrastructure as Code (IaC) environment and to utilize the monitored information to remediate unauthorized changes to the system. Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. However, the combination fails to explicitly disclose wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components.
Shekhar teaches wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components. Specifically, that the database stores the associations between the source identifier and the plurality of resource components and the unique identifiers of a plurality of resources indicated in the resource files or definitions. Shekhar establishes that this type of topology mapping was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen, McCann, Bostick, Rizo and Malamut the ability for the enrichment database to include associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components as taught by Shekhar since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Shekhar, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick, Rizo and Malamut, with the ability for the enrichment database to include associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components as taught by Shekhar, for the purposes of using known techniques to map the resources. Since Shen already identifies the related nodes and their relationships to other nodes it would have been obvious to store along with the affected nodes their associations to other nodes as shown in Shekhar as this is a known technique in mapping the network and determine which nodes depend on other nodes.
As per claim 4, the combination of Shen, McCann, Bostick, Rizo, Malamut and Shekhar teaches the method of claim 3; McCann further teaches wherein the dependencies of the component are referenced in the source code (Col. 25, lines 16-57; teaches that the system contains a directory structure of files including a root directory and has subdirectories, the directory includes the make file which is user supplied code and the user source code).
Shekhar further teaches creating the enrichment database, wherein creating the enrichment database further comprises analyzing dependency of a root resource component in order to identify a plurality of dependencies of the root resource component (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. The resources are recursively accessed and considered to determine the structure of the tree. Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not. In doing so the system analyzes each node through its definitions and identifies dependencies and establish which nodes are root nodes or resources).
As per claim 5, the combination of Shen, McCann, Bostick, Rizo, Malamut and Shekhar the method of claim 4; McCann further teaches wherein the dependencies of the component are referenced in the source code (Col. 25, lines 16-57; teaches that the system contains a directory structure of files including a root directory and has subdirectories, the directory includes the make file which is user supplied code and the user source code).
Shekhar further teaches wherein creating the enrichment database further comprises: recursively crawling through source code of the root resource component and at least one dependency of the root resource component (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. The resources are recursively accessed and considered to determine the structure of the tree. Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not),
wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling (Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not. As the system recursively processes the data the system identifies each of the resources uniquely and establishes their dependency).
As per claim 6, the combination of Shen, McCann, Bostick, Rizo, Malamut and Shekhar the method of claim 5; Shekhar further teaches wherein the recursive crawling is performed up to at least one leaf resource component (Col. 10, line 27 through Col. 11, line 3; teaches that the recursive crawling goes through each leaf resource or node),
wherein each leaf resource component is a resource component from which another resource component depends (Col. 10, line 27 through Col. 11, line 3; teaches that the leaf resources can have dependent resources),
wherein each leaf resource component does not depend from another resource component (Col. 10, line 27 through Col. 11, line 3; teaches that the leaf resource or node cannot be connected to another resource).
As per claim 7, the combination of Shen, McCann, Bostick, Rizo, Malamut and Shekhar the method of claim 4; McCann further teaches wherein the dependencies of the component are referenced in the source code (Col. 25, lines 16-57; teaches that the system contains a directory structure of files including a root directory and has subdirectories, the directory includes the make file which is user supplied code and the user source code).
Shekhar further teaches wherein the root resource component is a first root resource component of at least one root resource component, wherein the enrichment database is created based on a configuration mapping file of at least one root resource component and based on dependency of the at least one root resource component (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. The resources are recursively accessed and considered to determine the structure of the tree. Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Rizo et al. (US 2020/0012480 A1) hereafter Rizo, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut, further in view of Shekhar (US 8,615,015 B1) hereafter Shekhar, further in view of Gersht et al. (US 11,327,723 B1) hereafter Gersht.
As per claim 8, the combination of Shen, McCann, Bostick, Rizo, Malamut and Shekhar the method of claim 4; the combination fails to explicitly discloses analyzing a software development pipeline log including a step in which the first resource component is deployed in order to determine a location and a time of deployment for the first resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the first resource component.
Gersht, which like the combination checks for faults, teaches analyzing a software development pipeline log including a step in which the first resource component is deployed in order to determine a location and a time of deployment for the first resource component (Col. 6, lines 20-64; teach tracking the execution of jobs including real-time progress data to indicate when the faults occur in real-time and the location of each failure including which stage or line of code. Col. 7, lines 34-45; teaches that logs are generated by the build tools to generate pipeline logs describing the progress of the operations performed. Col. 8, line 7 through Col. 9, line 16; teach that pipeline logs are analyzed to determine the location when a fault occurs to determine the reason and ultimate the resolution to the fault); and
retrieving the source code of the root resource component based on the determined location and time of deployment for the first resource component (Col. 7, lines 22-33; teaches that the source code is retrieved of the failing component based on the determine location when the failure is detected. Since the purpose of the combination is to identify faults or failures in the system, it would have been obvious to also analyze the code being implemented to identify faults and correct them as necessary as shown in Gersht. This would allow the corrective action to be performed as soon as the fault or failure is detected).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Rizo teaches it is known to implement components in an Infrastructure as Code (IaC) environment and to utilize the monitored information to remediate unauthorized changes to the system. Shekhar teaches wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components. Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. However, the combination fails to disclose analyzing a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component.
Gersht teaches analyzing a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component. Gersht establishes that this type of failure analysis was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen, McCann, Bostick, Rizo, Malamut and Shekhar the ability to analyze a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component as taught by Gersht since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Shekhar, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick, Rizo, Malamut and Shekhar, with the ability to analyze a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component as taught by Gersht, for the purposes of identifying faults as they occur. Since the purpose of the combination is to identify faults or failures in the system, it would have been obvious to also analyze the code being implemented to identify faults and correct them as necessary as shown in Gersht. This would allow the corrective action to be performed as soon as the fault or failure is detected.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Rizo et al. (US 2020/0012480 A1) hereafter Rizo, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut, further in view of Dixon et al. (WO 2007/041242 A2) hereafter Dixon.
As per claim 9, the combination of Shen, McCann, Bostick, Rizo and Malamut the method of claim 1; the combination fails to explicitly disclose determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
Dixon, which like the combination monitors for alerts, teaches it is known to determine a software development pipeline run which triggered the alert (Page 1, lines 16-24; teaches that the invention is directed toward software development. Page 2, lines 21-25; teaches that the invention allows for the development manager to identify skills deficits and monitor developer performance over time. Page 2, line 26 through Page 3, line 2; teaches that the system monitors and analyzes the software as it is developed and deployed. Page 14, lines 17-21; teaches that alerts are developed for software which exceeds threshold metrics); and
determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author (Page 14, lines 17-21 and Page 19, lines 3-7; teaches that alerts are developed for software which exceeds threshold metrics. The author or developer is determined and included in the alert to track the progress of specific developers over time. As stated in Dixon this allows the manager to identify deficits and monitor performance over time. Since the combination is already monitoring performance and identifying faults or issues it would have been obvious to include the author or person responsible for the faults so they can be tracked over time as shown in Dixon. This allows for greater insight into how the system is managed over time as shown in Dixon).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Rizo teaches it is known to implement components in an Infrastructure as Code (IaC) environment and to utilize the monitored information to remediate unauthorized changes to the system. Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. However, the combination fails to disclose determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
Dixon teaches determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author. Dixon establishes that this type of failure analysis and alert was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen, McCann, Bostick, Rizo and Malamut the ability to determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author as taught by Dixon since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Dixon, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick, Rizo and Malamut, with the ability to determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author as taught by Dixon, for the purposes of managing developers over time. Since the combination is already monitoring performance and identifying faults or issues it would have been obvious to include the author or person responsible for the faults so they can be tracked over time as shown in Dixon. This allows for greater insight into how the system is managed over time as shown in Dixon.
Claim(s) 10 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut.
As per claim 10, Shen discloses a non-transitory computer readable medium having stored thereon instructions for causing a processing circuitry to execute a process (Page 2, paragraph [0017]; discloses that the instructions are stored on a non-transitory computer readable medium and are executed by a processor), the process comprising:
determining, based on a unique identifier of a computing infrastructure resource indicated in an alert, a source identifier of a resource component including the computing infrastructure resource (Page 8, paragraph [0081]; discloses that the monitoring system is configured to receive a plurality of alerts. The alerts are associated with faults in the network. The alerts can identify system components which are experiencing a fault. This acts as a unique identifier of the components and can be used to identify the common or root cause of the faulty component which is considered the source identifier),
contextually enriching the alert by adding the source identifier of the resource component including the computing infrastructure resource and additional information to the alert (Page 12, paragraph [0120]; discloses that alert can be enriched by adding the identifier of the system component to the alert. Shen additionally states in paragraph [0120] that the alert can include additional information); and
performing at least one remediation action with respect to the contextually enriching alert (Page 13, paragraph [0124]; discloses that the remediation actions are performed in respect for the alert, which include automatic rollback).
Shen fails to explicitly disclose wherein the resource component includes source code and at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides. Shen fails to state extracting source code of the resource component based on the source identifier; determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. Shen further fails wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
McCann, which like Shen discusses monitoring components, teaches wherein the resource component includes at least one source file (Col. 13, lines 42-54; teaches that it is known to define components and for those components to include source files. Col. 15, line 47 through Col. 16, line 25; teaches that the components are defined by make files which outline the dependencies of the of the system for the component. Col. 16, lines 33-57; teach that the make files specify the dependencies between different source files. This is used to track rebuilding of necessary files and tracks objects that depend on the source files. The software tools process one or more inputs such as user source code),
McCann additionally teaches wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides (Col. 21, lines 24-55; teaches that the make files include derived information derived by the build component and included in the file. The items can redefine the directory location, in doing so the make file includes information that identifies the target and target variants, it identifies the version of the build, the directory location of the source, object, default directory location. This information is used to communicate with the tools of the system. Col. 25, lines 16-57; teaches that the system contains a directory structure of files including a root directory and has subdirectories, the directory includes the make file which is user supplied code and the user source code. Since Shen discusses identifying the component having the fault it would have been obvious to identify the at component using other techniques such as the one shown in McCann which is a combination of characteristics of the component or machine).
McCann additionally teaches extracting source code of the resource component based on the source identifier (Col. 21, lines 24-55; teaches identifying the version of the build, the directory location of the source, object, default directory location. This information is used to communicate with the tools of the system and identify the source. Col. 14, line 39-65; teaches that the system can extract information including source code from the components based on the identifiers);
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts.
The sole difference between the Shen reference and the claimed subject matter is that the Shen reference does not disclose wherein the resource component includes at least one source file and wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides.
The McCann reference teaches analyzing resource components teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. McCann establishes that this type of identifying a source was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the unique identifier shown in Shen with the combination of characteristic used together to identify the source as shown in McCann.
Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Therefore, from this teaching of McCann, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, with the unique identifier being a combination of characteristics as taught by McCann, for the purposes of using known techniques to uniquely identify a resource. Since Shen discusses identifying the component having the fault it would have been obvious to identify the at component using other techniques such as the one shown in McCann which is a combination of characteristics of the component or machine.
The combination fails to explicitly disclose determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. The combination further fails wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Bostick, which like the combination talks about identifying information from source code, teaches it is known to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code (Page 2, paragraph [0021]; teaches that the system can compare source code to determine revisions and determines the author of the changes in the revision of the source code by analyzing the software development log. The system can issue an alert or message indicating the author’s name and version indicator. Since the combination already establishes that the alert can include any additional information, it would have been obvious to include the version indicator and the author’s name to determine who is responsible for the changes as shown in Bostick. As discussed in Bostick this is done to identify the individual who introduced, modified, or deleted specific portions of code and caused the error or errors).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. However, the combination fails to determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code.
Bostick teaches determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. Bostick establishes that identifying revisions and those who authored those revisions was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen and McCann the ability to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code as taught by Bostick since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Bostick, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen and McCann, with the ability to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code as taught by Bostick, for the purposes of identifying revisions and the author of those revisions. Since the combination already establishes that the alert can include any additional information, it would have been obvious to include the version indicator and the author’s name to determine who is responsible for the changes as shown in Bostick. As discussed in Bostick this is done to identify the individual who introduced, modified, or deleted specific portions of code and caused the error or errors.
The combination further fails wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Malamut, which like the combination talks about uniquely identifying resources, teaches it is known wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component (Page 6, paragraph [0057]; teaches that the file can be uniquely identified using the repository or directory in which the file is stored, the revision or version and the path to the directory. This is used to uniquely identify the resource or file. Since the combination establishes that the unique identifier can be a combination of elements it would have been obvious to substitute that combination with any other known combination as the end result would continue to be a unique identifier to identify the location of the resource).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions.
The sole difference between the combination and the claimed subject matter is that the combination does not explicitly disclose the source identifier combination comprises a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component.
Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. Malamut establishes that the use of this combination of information to uniquely identify a resource was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of combination of identifiers to identify resource taught by Shen, McCann and Bostick with the combination being a repository, a revision and a path to the directory as shown in Malamut.
Therefore, from this teaching of Malamut, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann and Bostick, with the combination of characteristics including a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component as taught by Malamut, for the purposes of uniquely identifying the resource using known techniques. Since the combination establishes that the unique identifier can be a combination of elements it would have been obvious to substitute that combination with any other known combination as the end result would continue to be a unique identifier to identify the location of the resource.
As per claim 11, Shen discloses a system for securing deployment of computing infrastructure resources (Page 12, paragraph [0120]; discloses contextually enriching alerts with additional data specifically an identifier of system components which the alert is related to. Page 7, paragraph [0075]; discloses that the faults are identified and remediated as quickly as possible to minimize costs and computational resources. Page 11, paragraphs [0111]-[0112]; discloses that the remediations can take the form of rollbacks or reconfigurations. Page 6, paragraph [0064]; discloses that the system includes a processor and memory) comprising:
a processing circuitry (Page 6, paragraph [0064]; discloses that the system includes a processor and memory); and
a memory (Page 6, paragraph [0064]; discloses that the system includes a processor and memory), the memory containing instructions that, when executed by the processing circuitry (Page 2, paragraph [0017]; discloses that the instructions are stored on a non-transitory computer readable medium and are executed by a processor), configure the system to:
determine, based on a unique identifier of a computing infrastructure resource indicated in an alert, a source identifier of a resource component including the computing infrastructure resource (Page 8, paragraph [0081]; discloses that the monitoring system is configured to receive a plurality of alerts. The alerts are associated with faults in the network. The alerts can identify system components which are experiencing a fault. This acts as a unique identifier of the components and can be used to identify the common or root cause of the faulty component which is considered the source identifier),
contextually enrich the alert by adding the source identifier of the resource component including the computing infrastructure resource and additional information to the alert (Page 12, paragraph [0120]; discloses that alert can be enriched by adding the identifier of the system component to the alert. Shen additionally states in paragraph [0120] that the alert can include additional information); and
perform at least one remediation action with respect to the contextually enriching alert (Page 13, paragraph [0124]; discloses that the remediation actions are performed in respect for the alert, which include automatic rollback).
Shen fails to disclose wherein the resource component includes at least one source file, wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides. Shen fails to state extracting source code of the resource component based on the source identifier; determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. Shen further fails wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
McCann, which like Shen discusses monitoring components, teaches wherein the resource component includes at least one source file (Col. 13, lines 42-54; teaches that it is known to define components and for those components to include source files. Col. 15, line 47 through Col. 16, line 25; teaches that the components are defined by make files which outline the dependencies of the of the system for the component. Col. 16, lines 33-57; teach that the make files specify the dependencies between different source files. This is used to track rebuilding of necessary files and tracks objects that depend on the source files. The software tools process one or more inputs such as user source code),
McCann additionally teaches wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides (Col. 21, lines 24-55; teaches that the make files include derived information derived by the build component and included in the file. The items can redefine the directory location, in doing so the make file includes information that identifies the target and target variants, it identifies the version of the build, the directory location of the source, object, default directory location. This information is used to communicate with the tools of the system. Col. 25, lines 16-57; teaches that the system contains a directory structure of files including a root directory and has subdirectories, the directory includes the make file which is user supplied code and the user source code. Since Shen discusses identifying the component having the fault it would have been obvious to identify the at component using other techniques such as the one shown in McCann which is a combination of characteristics of the component or machine).
McCann additionally teaches extracting source code of the resource component based on the source identifier (Col. 21, lines 24-55; teaches identifying the version of the build, the directory location of the source, object, default directory location. This information is used to communicate with the tools of the system and identify the source. Col. 14, line 39-65; teaches that the system can extract information including source code from the components based on the identifiers);
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts.
The sole difference between the Shen reference and the claimed subject matter is that the Shen reference does not disclose wherein the resource component includes at least one source file and wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides.
The McCann reference teaches analyzing resource components teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. McCann establishes that this type of identifying a source was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the unique identifier shown in Shen with the combination of characteristic used together to identify the source as shown in McCann.
Thus, the simple substitution of one known element for another producing a predictable result renders the claim obvious.
Therefore, from this teaching of McCann, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, with the unique identifier being a combination of characteristics as taught by McCann, for the purposes of using known techniques to uniquely identify a resource. Since Shen discusses identifying the component having the fault it would have been obvious to identify the at component using other techniques such as the one shown in McCann which is a combination of characteristics of the component or machine.
The combination fails to explicitly disclose determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. The combination further fails wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Bostick, which like the combination talks about identifying information from source code, teaches it is known to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code (Page 2, paragraph [0021]; teaches that the system can compare source code to determine revisions and determines the author of the changes in the revision of the source code by analyzing the software development log. The system can issue an alert or message indicating the author’s name and version indicator. Since the combination already establishes that the alert can include any additional information, it would have been obvious to include the version indicator and the author’s name to determine who is responsible for the changes as shown in Bostick. As discussed in Bostick this is done to identify the individual who introduced, modified, or deleted specific portions of code and caused the error or errors).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. However, the combination fails to determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code.
Bostick teaches determining an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code. Bostick establishes that identifying revisions and those who authored those revisions was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen and McCann the ability to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code as taught by Bostick since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Bostick, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen and McCann, with the ability to determine an author of a revision of the extracted source code by analyzing a software development pipeline log of a run which triggered the alert; and that the alert includes the determined author of the revision of the extracted source code as taught by Bostick, for the purposes of identifying revisions and the author of those revisions. Since the combination already establishes that the alert can include any additional information, it would have been obvious to include the version indicator and the author’s name to determine who is responsible for the changes as shown in Bostick. As discussed in Bostick this is done to identify the individual who introduced, modified, or deleted specific portions of code and caused the error or errors.
The combination further fails wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component.
Malamut, which like the combination talks about uniquely identifying resources, teaches it is known wherein the combination of characteristics of the source identifier of the resource component includes a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component (Page 6, paragraph [0057]; teaches that the file can be uniquely identified using the repository or directory in which the file is stored, the revision or version and the path to the directory. This is used to uniquely identify the resource or file. Since the combination establishes that the unique identifier can be a combination of elements it would have been obvious to substitute that combination with any other known combination as the end result would continue to be a unique identifier to identify the location of the resource).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions.
The sole difference between the combination and the claimed subject matter is that the combination does not explicitly disclose the source identifier combination comprises a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component.
Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. Malamut establishes that the use of this combination of information to uniquely identify a resource was known in the prior art at the time of the invention.
Since each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of combination of identifiers to identify resource taught by Shen, McCann and Bostick with the combination being a repository, a revision and a path to the directory as shown in Malamut.
Therefore, from this teaching of Malamut, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann and Bostick, with the combination of characteristics including a repository in which the at least one source file of the resource component reside, a revision of the repository, and a path to the directory of the resource component as taught by Malamut, for the purposes of uniquely identifying the resource using known techniques. Since the combination establishes that the unique identifier can be a combination of elements it would have been obvious to substitute that combination with any other known combination as the end result would continue to be a unique identifier to identify the location of the resource.
Claim(s) 13-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut, further in view of Shekhar (US 8,615,015 B1) hereafter Shekhar.
As per claim 13, the combination of Shen, McCann, Bostick and Malamut teaches the system of claim 11; Shen further discloses wherein the resource component is a first resource component (Page 10, paragraph [0096]; discloses that the resource component is a first resource component),
wherein the resource is a first resource of a plurality of resources included in the first resource component (Page 10, paragraph [0096]; discloses that the component can comprise a plurality of nodes or resources. Page 10, paragraph [0097]; discloses that each alert is associated with at least one node of a plurality of nodes. Each set of nodes is associated with software applications as well as other nodes),
wherein determining the source identifier of the resource component further comprises: querying an enrichment database using the unique identifier of the computing infrastructure resource indicated in the alert (Page 10, paragraph [0098]; discloses that monitoring system determines common nodes by determine which nodes are connected to each other and which nodes share edges. This is done to determine the root cause of the one or more affected system components. Page 11, paragraph [0109]; discloses that the records are used to identify the effected node or resource and the state of the resource. Page 12, paragraphs [0117]-[0118]; discloses that the monitoring system determines which nodes are affected and used this information to determine the root cause of the fault indicated in the alert. Page 13, paragraph [0127]; discloses that the infrastructure and application configurations as well as topology are stored and received from a database).
While the combination discloses utilizing a database to identify the resources affected by the fault indicated in the alert, the combination is not explicit wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components.
Shekhar, which like the combination discusses mapping the infrastructure of the system, teaches wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. Col. 10, line 27 through Col. 11, line 3; teaches that the unique identifiers of each of the plurality of resources are indicated and stored as associations between the each of the identifiers. Col. 13, lines 45-49; teaches that the route and connections are stored in a database for future reference. From this the system stores in a database the relationships between each identifier for each resource and the resources it depends from or which depends from it. Since Shen already identifies the related nodes and their relationships to other nodes it would have been obvious to store along with the affected nodes their associations to other nodes as shown in Shekhar as this is a known technique in mapping the network and determine which nodes depend on other nodes).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. However, the combination fails to explicitly disclose wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components.
Shekhar teaches wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components. Specifically, that the database stores the associations between the source identifier and the plurality of resource components and the unique identifiers of a plurality of resources indicated in the resource files or definitions. Shekhar establishes that this type of topology mapping was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen, McCann, Bostick and Malamut the ability for the enrichment database to include associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components as taught by Shekhar since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Shekhar, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick and Malamut, with the ability for the enrichment database to include associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components as taught by Shekhar, for the purposes of using known techniques to map the resources. Since Shen already identifies the related nodes and their relationships to other nodes it would have been obvious to store along with the affected nodes their associations to other nodes as shown in Shekhar as this is a known technique in mapping the network and determine which nodes depend on other nodes.
As per claim 14, the combination of Shen, McCann, Bostick, Malamut and Shekhar teaches the system of claim 13; Shekhar further teaches wherein the system is further configured to: create the enrichment database, wherein creating the enrichment database further comprises analyzing source code of a root resource component in order to identify a plurality of dependencies of the root resource component (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. The resources are recursively accessed and considered to determine the structure of the tree. Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not. In doing so the system analyzes each node through its definitions and identifies dependencies and establish which nodes are root nodes or resources).
As per claim 15, the combination of Shen, McCann, Bostick, Malamut and Shekhar teaches the system of claim 14; Shekhar further teaches wherein the system is further configured to: recursively crawl through source code of the root resource component and at least one dependency of the root resource component (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. The resources are recursively accessed and considered to determine the structure of the tree. Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not),
wherein the source identifiers of the plurality of resource components are determined based on the recursive crawling (Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not. As the system recursively processes the data the system identifies each of the resources uniquely and establishes their dependency).
As per claim 16, the combination of Shen, McCann, Bostick, Malamut and Shekhar teaches the system of claim 15; Shekhar further teaches wherein the recursive crawling is performed up to at least one leaf resource component (Col. 10, line 27 through Col. 11, line 3; teaches that the recursive crawling goes through each leaf resource or node),
wherein each leaf resource component is a resource component from which another resource component depends (Col. 10, line 27 through Col. 11, line 3; teaches that the leaf resources can have dependent resources),
wherein each leaf resource component does not depend from another resource component (Col. 10, line 27 through Col. 11, line 3; teaches that the leaf resource or node cannot be connected to another resource).
As per claim 17, the combination of Shen, McCann, Bostick, Malamut and Shekhar teaches the system of claim 14; Shekhar further teaches wherein the root resource component is a first root resource component of at least one root resource component, wherein the enrichment database is created based on a configuration mapping file of the at least one root resource component and based on source code of the at least one root resource component (Col. 2, lines 25-49; teaches that it is known to map the resources to unique identifiers specifically IP addresses. The system can store the topology or tree structure of the resources to indicate the leaf nodes as well as the root nodes as indicated in Col. 8, lines 51-58. The resources are recursively accessed and considered to determine the structure of the tree. Col. 10, line 27 through Col. 11, line 3; teaches that the resources are defined in that they indicate the routes and which resources are connected and they are dependent or not).
Claim(s) 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut, further in view of Shekhar (US 8,615,015 B1) hereafter Shekhar, further in view of Gersht et al. (US 11,327,723 B1) hereafter Gersht.
As per claim 18, the combination of Shen, McCann, Bostick, Malamut and Shekhar teaches the system of claim 14; the combination fails to explicitly discloses wherein the system is further configured to: analyze a software development pipeline log including a step in which the first resource component is deployed in order to determine a location and a time of deployment for the first resource component; and retrieve the source code of the root resource component based on the determined location and time of deployment for the first resource component.
Gersht, which like the combination checks for faults, teaches wherein the system is further configured to: analyze a software development pipeline log including a step in which the first resource component is deployed in order to determine a location and a time of deployment for the first resource component (Col. 6, lines 20-64; teach tracking the execution of jobs including real-time progress data to indicate when the faults occur in real-time and the location of each failure including which stage or line of code. Col. 7, lines 34-45; teaches that logs are generated by the build tools to generate pipeline logs describing the progress of the operations performed. Col. 8, line 7 through Col. 9, line 16; teach that pipeline logs are analyzed to determine the location when a fault occurs to determine the reason and ultimate the resolution to the fault); and
retrieve the source code of the root resource component based on the determined location and time of deployment for the first resource component (Col. 7, lines 22-33; teaches that the source code is retrieved of the failing component based on the determine location when the failure is detected. Since the purpose of the combination is to identify faults or failures in the system, it would have been obvious to also analyze the code being implemented to identify faults and correct them as necessary as shown in Gersht. This would allow the corrective action to be performed as soon as the fault or failure is detected).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Shekhar teaches wherein the enrichment database includes associations between source identifiers of the plurality of resource components and unique identifiers of a plurality of resources indicated in a plurality of respective resource definitions in the plurality of resource components. Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. However, the combination fails to disclose analyzing a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component.
Gersht teaches analyzing a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component. Gersht establishes that this type of failure analysis was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen, McCann, Bostick, Malamut and Shekhar the ability to analyze a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component as taught by Gersht since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Gersht, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick, Malamut and Shekhar, with the ability to analyze a software development pipeline log including a step in which the resource component is deployed in order to determine a location and a time of deployment for the resource component; and retrieving the source code of the root resource component based on the determined location and time of deployment for the resource component as taught by Gersht, for the purposes of identifying faults as they occur. Since the purpose of the combination is to identify faults or failures in the system, it would have been obvious to also analyze the code being implemented to identify faults and correct them as necessary as shown in Gersht. This would allow the corrective action to be performed as soon as the fault or failure is detected.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shen et al. (US 2023/0246902 A1) hereafter Shen, in view of McCann et al. (US 9,703,550 B1) hereafter McCann, further in view of Bostick et al. (US 2008/0086718 A1) hereafter Bostick, further in view of Malamut et al. (US 2022/0083520 A1) hereafter Malamut, further in view of Dixon et al. (WO 2007/041242 A2) hereafter Dixon.
As per claim 19, the combination of Shen, McCann, Bostick and Malamut teaches the system of claim 11; the combination fails to explicitly disclose wherein the system is further configured to: determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
Dixon, which like the combination monitors for alerts, teaches wherein the system is further configured to: determine a software development pipeline run which triggered the alert (Page 1, lines 16-24; teaches that the invention is directed toward software development. Page 2, lines 21-25; teaches that the invention allows for the development manager to identify skills deficits and monitor developer performance over time. Page 2, line 26 through Page 3, line 2; teaches that the system monitors and analyzes the software as it is developed and deployed. Page 14, lines 17-21; teaches that alerts are developed for software which exceeds threshold metrics); and
determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author (Page 14, lines 17-21 and Page 19, lines 3-7; teaches that alerts are developed for software which exceeds threshold metrics. The author or developer is determined and included in the alert to track the progress of specific developers over time. As stated in Dixon this allows the manager to identify deficits and monitor performance over time. Since the combination is already monitoring performance and identifying faults or issues it would have been obvious to include the author or person responsible for the faults so they can be tracked over time as shown in Dixon. This allows for greater insight into how the system is managed over time as shown in Dixon).
The primary reference Shen discloses enhancing alerts with additional information specifically the identifier of the source of the problem. Shen utilizes this information to perform automatic remediation of the errors or problems identified in the alerts. McCann teaches it is known for the resource component to include a source file and for the source identifier of the resource component to be a combination of characteristics of the resource component which collectively uniquely identifies the resource component with respect to the directory in which the source file is located. Bostick determines the author of software revisions. Malamut teaches it is known to uniquely identify files using a combination of characteristics including a repository in which the at least one source file of the resource component resides, a revision of the repository, and a path to the directory of the resource component. However, the combination fails to disclose determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author.
Dixon teaches determining a software development pipeline run which triggered the alert; and determining an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author. Dixon establishes that this type of failure analysis and alert was known in the prior art at the time of the invention.
It would have been obvious to one of ordinary skill in the art to include in the alert system of Shen, McCann, Bostick and Malamut the ability to determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author as taught by Dixon since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Therefore, from this teaching of Dixon, it would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the method of enhancing alerts provided by Shen, McCann, Bostick and Malamut, with the ability to determine a software development pipeline run which triggered the alert; and determine an author of the software development pipeline run which triggered the alert, wherein the alert is contextually enriched based further on the determined author as taught by Dixon, for the purposes of managing developers over time. Since the combination is already monitoring performance and identifying faults or issues it would have been obvious to include the author or person responsible for the faults so they can be tracked over time as shown in Dixon. This allows for greater insight into how the system is managed over time as shown in Dixon.
Response to Arguments
Applicant's arguments filed November 25. 2025 have been fully considered but they are not persuasive.
In response to the applicant’s arguments on pages 8-16 regarding the art rejections specifically that, “Respectfully, the Office Action repeatedly treats unrelated software artifacts, such as the runtime nodes in Shen, build-time configuration metadata in Mccann, and repository file identifiers in Malamut, as interchangeable "components." This approach contravenes MPEP § 2141.02, which prohibits "distilling an invention down to the gist or thrust" and requires considering the claimed subject matter as a whole. See MPEP 2141.02 II (citing W.L. Gore & Assocs. v. Garlock, 721 F.2d 1540, 1553 (Fed. Cir. 1983)). The Office Action does the opposite: it isolates each claim term, assigns it an abstract label ("component," "identifier"), and then asserts that each such label is shown in the art regardless of the actual context or function disclosed in each reference. As this response shall demonstrate, the collapsing of these terms in to "components" ignores the lifecycle stage, function and cannot be simply substituted.”
“First, the Office Action, in support that the combination of references is a simple substitution, maps the claimed "source identifier"to elements in both Shen and Mccann. The Office Action states that in Shen "[t]he alerts can identify system components which are experiencing a fault. This acts as a unique identifier of the components and can be used to identify the common or root cause of the faulty component which is considered the source identifier." (Non-Final Rejection at pg. 23 citing Shen 0081.) Then, in Mccann the Office Actions states, "Mccann additionally teaches wherein the source identifier of the resource component is a combination of characteristics of the resource component which collectively uniquely identify the resource component with respect to the directory in which the at least one source file of the resource component resides (Col. 21, lines 24- 55; teaches that the make files include derived information derived by the build component and included in the file. The items can redefine the directory location. in doing so the make file includes information that identifies the target and target variants, it identifies the version of the build, the directory location of the source, object, default directory location.)" (Non-Final Rejection at pg. 24-5 citing Mccann Col. 21, 25) 1 Therefore, the Office Actions asserts that both the runtime root-cause node in Shen and the build-time configuration metadata (i.e., the target, target variants, directory location) are both "source identifiers." As such, the Office Actions concludes that "[s]ince each individual element and its function are shown in the prior art, albeit shown in separate references, the difference between the claimed subject matter and the prior art rests not on any individual element or function but in the very combination itself- that is in the substitution of the unique identifier shown in Shen with the combination of characteristic used together to identify the source as shown in Mccann."”
“As a threshold point, the Office Action concedes that the alleged "source identifier" in Shen is "not included in a resource." This admission undermines the rejection based on simple substitution. The claims expressly require a source identifier that identifies a resource component using repository, revision, and path-based metadata. Shen's "root cause" is merely an inferred runtime node in an alert graph; it does not identify any resource, has no repository or revision context, and bears no relationship to source code or laC. If Shen does not provide a source identifier of a resource component, then there is nothing for Mccann to "substitute" into and no basis to treat McCann's build-time metadata as interchangeable with Shen's runtime fault node. In order to properly claim that these are components that can be substituted, the original component must be whole. Because, if it not whole, then what is being performed is an expansion and not a substitution. Therefore, the simple-substitution rationale collapses at the outset.”
“Moreover, if Shen's "identifier" does not identify a resource component, then Shen and Mccann are identifying different types of objects entirely, i.e., runtime operational nodes vs. build-time code artifacts. Substituting one for the other is not a simple substitution of known equivalents but a change in the type of thing being identified, which fundamentally alters Shen's operation.”
“Shen states that its method is applied to "live systems," which "undergo changes at runtime" and generate alerts reflecting faults in the "networked computer system." (0003). Shen repeatedly teaches receiving "alerts associated with a fault in a networked computer system," generating "a graph of a network topology," and associating those alerts with "nodes" representing the active components of that topology (0005-6, 0108). Shen identifies a "faulty component by correlating alerts to a "common node" in the runtime topology graph (0081, 0097-0102).”
“Shen determines a "source identifier" only in the sense of identifying a root-cause infrastructure node within a runtime alert topology. Shen's identifiers therefore refer exclusively to operational components, not to any resource component including a source file, as addressed in Mccann. Mccann, by contrast, operates in an entirely different domain: its "components" are software build modules defined by static makefile metadata and unrelated to Shen's infrastructure resources. Substituting McCann's build-time identifiers, which exist only during software compilation, for Shen's runtime components changes Shen's principle of operation from dynamic, alert-based fault analysis to static, pre-deployment code configuration, which is contrary to Shen's explicit disclosure of diagnosing faults in "live systems."”
“Similarly, the proposed combination of Shen and Mccann would also render Shen inoperable for its intended purpose. Shen's system depends on receiving live alerts, mapping them to nodes in an active network graph, and identifying a faulty component to enable corrective actions such as rollback or reconfiguration ( Shen, ¶¶ [0005]-[0007]). Mccann, by contrast, operates entirely at build time, where targets and target variants define how source code is compiled and linked for particular platforms (Mccann, ¶¶[0012]-[0014], [0060]-[0062]). Because McCann's identifiers are defined before execution and have no runtime correspondence to the network components or alerts that Shen analyzes, incorporating them would not "augment" Shen's analysis, instead it would substitute non-operational, pre-deployment metadata for the live system identifiers on which Shen's topology-based fault diagnosis depends. In doing so, the modification would disconnect Shen's alert-driven graph from the very runtime data it requires, thereby preventing it from performing its stated fault-analysis function. Such a modification would render Shen inoperable for its intended purpose, identifying faulty infrastructure components based on alert relationships, and is therefore improper under MPEP 2143.0t(V).”
“The Office Action further suggests that Malamut's "identifier" is also a source identifier. "It would have been obvious to substitute the unique identifier in Shen with the combination of characteristics (repository, revision, path) in Malamut. .. the end result would continue to be a unique identifier to identify the location of the resource." However, again, Shen's "identifier" is a runtime fault/component identifier used to associate live alerts with deployed system resources and trigger immediate remediations. In contrast, Malamut's "identifier" is a static repository-path construct used solely for file version control. Substituting Malamut's identifier for Shen's would decouple the alerting system from the runtime infrastructure, thereby disabling Shen's ability to locate and remediate faulty components, i.e., Shen's intended purpose. Accordingly, the proposed modification changes Shen's principle of operation and would render the system inoperable for its stated purpose, contrary to MPEP §2143.01 (V) and the reasoning of In re Ratti, 270 F.2d 810, and In re Gordon, 733 F.2d 900.”
“A single limitation cannot simultaneously be (1) a runtime root-cause node in Shen, (2) a build-time configuration parameter in Mccann, and (3) a static repository file identifier in Malamut.”
“The Office Action takes a similar approach to "source file." First mapping "source
file" to McCann and then also mapping "source file" to Malamut.”
“However, as a threshold issue, Mccann does not teach a source file. The passages cited by the Office Action (e.g., Col. 13:42-54; Col. 15:47-16:25; Col. 16:33- 57) describe build-system metadata, such as components defined by makefiles, dependency rules, and objects rebuilt when dependencies change. Although Mccann does use the term "source files," McCann's "source files" are solely compile-time inputs to a make/dependency process and are not identifiable, selectable, or operational components within the system. Mccann does not teach identifying, selecting, attributing, or otherwise analyzing a "source file" as a discrete resource. Shen cannot cure this deficiency because nothing in Shen transforms, or suggests transforming, compiler input files into runtime components capable of emitting alerts or participating in Shen's network topology. Shen's monitored entities are active, running system components, while McCann's "source files" are static text files used only during compilation. Accordingly, McCann's incidental mention of source files in the context of makefile dependency graphs does not teach, suggest, or imply the claimed "source file."”
“This is notable because the Office Action relies on the Mccann to connect Malamut's source file. Malamut does reference "source files," but only in the narrow sense of repository-based code or configuration files identified by (repository, revision, path) tuples that are static version-controlled artifacts used during deployment. Malamut does not teach a "source file" in the sense relevant to fault attribution, operational-change analysis, laC execution, or runtime alert correlation. Malamut's source files are not tied to live system behavior, do not cause or correspond to runtime faults, and are not associated with operational changes or topology-based diagnostics. Malamut's identifiers describe which file in a version-controlled repository is being referenced; McCann's identifiers describe how a compiled output should be configured for execution. They arise at entirely different points in the software lifecycle (source management vs. build configuration) and operate on different objects (file revisions vs. build targets). Because these identification mechanisms serve different purposes, appear in different operational stages, and apply to different entities, they cannot reasonably be treated as interchangeable or subject to simple substitution.”
“Similarly, the Office Action relies on McMann teaching a source file to conclude Mccann in view of Bostick teaches "determining an author of a revision." The Office Action characterizes McCann's build system and Bostick's source-control author analysis as interchangeable. Mccann cannot track authorship, even if one attempted to retrofit it. McCann's build system receives only build targets, target variants, dependency lists, and configuration files (Mccann ,¶¶ [0012]-[0014], [0060]-[0062]); it has no interface with any version-control system, no access to revision metadata, and no structures for storing or processing author information. Mccann operates solely on the content selected for compilation, not on the provenance or authorship of that content. Adding authorship tracking would require new subsystems that Mccann does not disclose or suggest. Therefore, this is not a simple substitution.”
“None of the references, either individually or in combination, teach or suggest determining, based on a unique identifier for a resource component, a source identifier, as recited in claim 1. The Office Action appears to rely on Mccann for this limitation (e.g., Cols. 14:39-65, 21 :24-55, 25:16-57). However, Mccann, at best, describes that a makefile (which the Office Action seems to map as the alleged "source file") may include static configuration data such as directory paths, build versions, and target variants (which the Office Action seems to map as the alleged "source identifier.") Those fields are predefined user inputs within the makefile itself; they are not identifiers determined from another identifier or from any external "unique identifier." The "target variant" and directory information in Mccann are simply metadata that the makefile already contains and that the build tool reads directly. Accordingly, McCann's build system performs no operation in which one identifier is derived from another to locate or identify corresponding source code, and the remaining references are silent on any such determination.”
“The reliance on a "simple substitution" rationale is unsupported because the proposed modification is not simple under MPEP § 2143. A simple substitution requires that the substituted element perform the same function, be interchangeable in the system being modified, and yield a predictable result. See MPEP 2143. As identified above, the substituted elements do not perform the same function, are not interchangeable and do not yield a predictable result. For example, Shen's identifier is a runtime fault node derived from live alerts in an operational topology, whereas McCann's and Malamut's identifiers are non-runtime artifacts (such as compile-time build metadata or static repository identifiers). These artifacts operate in different lifecycle stages, serve different purposes, and identify different types of entities. A runtime component identifier does not perform the same function nor is interchangeable with build-time or repository metadata and is neither interchangeable nor predictable. Accordingly, the combination exceeds what the MPEP permits as a "simple substitution." Indeed, treating runtime alert nodes, compile-time build metadata, and version-control file identifiers as substitutable solely because they can each be labeled a "component" would effectively render any software architecture obvious, contrary to the MPEP and established precedent.”
“Lastly, simple-substitution rationale requires that the equivalency between elements be taught or recognized in the prior art itself. See MPEP § 2144.06 ("In order to rely on equivalence as a rationale supporting an obviousness rejection, the equivalency must be recognized in the prior art, and cannot be based on applicant's disclosure or the mere fact that the components at issue are functional or mechanical equivalents," quoting In re Ruff, 256 F.2d 590, 118 USPQ 340 (CCPA 1958)). Equivalence must be rooted in the prior art, not created by labeling disparate elements as "components." Here, none of the applied references teach or recognize any equivalence between the items the Office Action substitutes for one another. Instead, the Office Action concludes that Shen's runtime root-cause node, McCann's build-time configuration metadata, and Malamut's repository-based identifiers are "components" and therefore interchangeable, without citing any disclosure in any reference that treats these items as equivalents in function, purpose, or lifecycle stage. For example, the Office Action substitutes McCann's compile-time target/target-variant metadata for Shen's runtime fault-component identifier even though neither reference suggests that build-time metadata may identify, represent, or substitute for live system components. In another example, the Office Action treats Malamut's repository-revision-path tuple as a drop-in replacement for Shen's alert-graph node, despite no teaching in Malamut that repository identifiers correspond to or can substitute for runtime operational components. Because the record contains no prior-art recognition of equivalency between these fundamentally different artifacts, the simple-substitution rationale cannot apply under MPEP § 2144.06.”
“The Office Action's invocation of Rizo does not establish any equivalence between the disparate artifacts that the rejection substitutes for one another. Rizo merely teaches that an Infrastructure-as-Code (laC) system may compare deployed infrastructure to its code representation to detect configuration drift (Rizo ,¶¶ 19-20). Rizo does not teach that laC source files, repository metadata, or code-defined resources are interchangeable with the runtime alert-graph nodes analyzed in Shen. Rizo does not teach that Shen's remediation logic, designed for live operational faults in a runtime topology, can be substituted directly into an laC code-comparison workflow. The Office Action relies on Rizo only to state that laC "implements infrastructure," and concludes this makes Shen's runtime components, McCann's build-time metadata, Malamut's repository identifiers, and Bostick's revision authorship functionally interchangeable. However, the prior art, including Rizo, never recognizes these artifacts as equivalents, and no reference suggests that runtime nodes, laC code, repository paths, or build-system metadata identify the same type of "resource component." Accordingly, Rizo cannot supply the missing equivalence necessary for any simple-substitution rationale and the cure deficiencies of the 35 USC 103 rejection.”
“Claim 1 is therefore allowable over the cited art. Claims [10] and [11] are rejected under similar rationale 7, and accordingly Applicant applies the same arguments, mutatis mutandis, with respect to these claims. To the extent that claims 3-9 and 13-19 were not directly addressed, claims 3-9 and 13-19 are allowable, at minimum, based on their dependency to allowable subject matter.”
The Examiner respectfully disagrees.
While the applicant has argued that the Examiner has distilled the invention down to the gist or thrust, the Examiner respectfully disagrees. The terms component and identifier are generic and not described in the claims or specification as specific elements. Rather the claims do not establish what the component is doing or performing but rather merely that there is an identifier of some kind to identify that component. As shown in the Shen reference the method determines a component hardware or software which are experience a fault. Again the limitation is determining a source identifier or the identifier for the component. The fault of the component can be a hardware or software fault which is identified in the alert. McCann is used to establish that an identifier can be a combination of characteristics which include the directory. This does not substitute the component as alleged by the applicant but establish that when identifying components it is known for the identifier to be a combination of characteristics. Malamut is used to establish additional data which can be used to identify a resource component. Again it is not about what the component is but rather how to identify the component itself.
The applicant appears to be arguing that the components being identified are different software elements running at different times, that is runtime, build-time and a repository, but as stated above the combination is not about the type of component as this is shown in the Shen reference but rather how to identify components using different pieces of information. This isn’t ignoring subject matter but rather considering the subject matter as a whole to establish that in the art it is known to use different combinations of information to identify components which can include software components.
While the applicant has argued that the combination is improper as it is not simple substitution the Examiner respectfully disagrees. As stated above the identifier is being substituted with other known formatting techniques for identifying files or software components. Again it is not about the specific component but how to identify components uniquely.
The applicant has alleged that the fact the identifier is not included in the resource undermines the simple substitution, the Examiner respectfully disagrees. The substitution is the collection of data used to identify the source not where the identifier is located. The Examiner has provided the McCann reference to establish this is known and the combination establish it would have been obvious to include it. The Examiner notes that Shen does disclose a identifying the system component in the alert. The component includes a software component. The combination of references establishes the type of information which is included to identify the system components. Again the basis for substitution is not if the code is runtime or build-time but what data is used to identify the component itself. As such the combination is proper and the reasons for combination are proper as it is not an expansion as alleged but substituting one type of identification information for another. While the Examiner has provided the Rizo reference to establish the type of components include IaC the specifics of IaC are not claimed or established. Rather the claims merely determine and identifier based on a combination of data, extract source code based on the identifier, determine the author and add the identifier and the author to an alert. As such the Examiner asserts that when combined the references read over the claims as written.
While the applicant has alleged that Shen does not identify a resource component, the Examiner respectfully disagrees. As stated above the substitution is the collection of data used to identify the source not where the identifier is located. The Examiner has provided the McCann reference to establish this is known and the combination establish it would have been obvious to include it. The Examiner notes that Shen does disclose a identifying the system component in the alert. The component includes a software component. The combination of references establishes the type of information which is included to identify the system components. Again the basis for substitution is not if the code is runtime or build-time but what data is used to identify the component itself. This does not alert the operation of Shen as alleged as it merely establishes additional or substitution of data which can be used to identify the source identifier.
While the applicant alleges that Shen does not include any resource component including a source file, the Examiner respectfully disagrees as it does include software elements which include source files as shown and established by the McCann reference. Again the applicant is arguing environment of use and when the files are compiled rather than the combination merely identifies a software source which includes an error or fault based on a combination of data which is known in the art. This is not contrary to the system of Shen as alleged as Shen does identify software faults.
While the applicant alleges that the combination of Shen and McCann would render Shen inoperable for its intended purpose, the Examiner respectfully disagrees. The applicant again is arguing the difference between runtime and build time however this is not what McCann is relied upon. Rather McCann is relied upon to establish the type of data used to identify the source component, as explained above. This would not render Shen inoperable as it would perform the same the features of McCann establish what data can be used to uniquely identify a source component, and the Shen reference would continue to operate as intended.
The applicant has argued that the Malamut reference stating that substituting the Malamut identifier would decouple the alerting system of Shen, the Examiner respectfully disagrees. As stated above Malamut was not used to change or alert when the component was compiled or even when the determinations were made but rather merely to establish that this type of data was known to be used to uniquely identify a source component. This would therefore not disable Shen’s ability as it would not change when Shen performed the analysis but rather what data is used to make the determination or identifications. As such the Examiner asserts that when combined the references read over the claims as written.
While the applicant has alleged that the Office establishes a single limitation to be “(1) a runtime root-cause node in Shen, (2) a build-time configuration parameter in Mccann, and (3) a static repository file identifier” the Examiner respectfully disagrees. As stated above the combination is not about when the files were compiled but what data is used to uniquely identify the file. As such the Examiner has not stated that it is all 3 elements but rather that the unique identifier is known to include a combination of information as shown.
The applicant has argued that McCann does not teach a source file the cited paragraph Col. 13, lines 42-54, explicitly states that it includes source code files. These files are analyzed for their dependencies and the source code can be extracted. This again is based on the identifier which is uniquely identified by the system. As such the combination would establish it is known for components to be represented by source code files which can be analyzed. Thus the combination would in fact read over the claims as written.
The applicant has alleged that “Malamut does not teach a "source file" in the sense relevant to fault attribution, operational-change analysis, laC execution, or runtime alert correlation. Malamut's source files are not tied to live system behavior, do not cause or correspond to runtime faults, and are not associated with operational changes or topology-based diagnostics” the Examiner notes that these elements are not required by the claims. Specifically the claims merely determine the source identifier based on a combination of elements, extract source code, determine an author, and add the source identifier and author to an alert. As explained above these elements are shown in the combination.
The applicant has alleged that McCann cannot track authorship, the Examiner asserts that the Bostick reference establishes it is known to determine the author of a revision by analyzing a software development pipeline log of a run which triggered the alert. From this combination would establish it is known to establish authorship and this is done to determine which individual caused the error. From this there is explicit rationale and motivation to include this feature in the combination. This would not change how McCann performed its functions but rather to use the log to determine which individual is responsible as stated above. As such the Examiner asserts that when combined the references read over the claims as written.
While the applicant alleges that none of the references, “ teach or suggest determining, based on a unique identifier for a resource component, a source identifier” the Examiner respectfully disagrees. As stated above when combined the references do in fact establish determining a unique identifier for a source component, a source identifier and the combination establishes that the combination of data to uniquely identify the source component was known in the prior art. As such the Examiner asserts that when combined the references read over the claims as written.
While the applicant has alleged that the Examiner rationale is unsupported the Examiner respectfully disagrees. As stated above the combination is about how to uniquely identify the components not exchanging components or when the components were compiled as alleged by the applicant. The references do in fact perform the same functions of identifying source information uniquely and different known ways this can be accomplished. As such when combined they do in fact yield a predictable result. As such the Examiner asserts that when combined the references read over the claims as written.
The applicant has argued that equivalence as not been established, the Examiner respectfully disagrees. As stated above each of the references establishes a manner of identifying the source information. That is a unique way each source component can be identified. The references establish these combination of elements were known and used to uniquely identify files. As such the Office Action has established equivalence. The applicant has again merely argued time of compile and the environment of use and not the identification of those elements. As such the applicant has failed to establish why the combination is in fact improper. As such the Examiner asserts that when combined the references read over the claims as written.
The applicant has argued the Rizo reference and has again argued the equivalence, the Examiner respectfully disagrees. The Shen reference establishes the network components which can include software, and Rizo establishes that it is known for these components to be implemented in Infrastructure as Code (IaC) environment. Rizo merely establishes the environment of use was known. Further the IaC environment is solely in the preamble and does not establish what role if any it plays in the claims. As stated in the rejection Rizo merely establishes that this environment of use is known and would have been obvious when combined with Shen. The equivalence between Shen and Rizo is established in the rejection. The applicant has again merely argued time of compile and not implementing a network resource in IaC as done in the combination. As such the applicant has failed to establish why the combination is in fact improper. As such the Examiner asserts that when combined the references read over the claims as written.
Lacking any additional arguments the Examiner has not been persuaded and the rejections have therefore been maintained.
All rejections made towards the dependent claims are maintained due to the lack of a reply by the applicant in regards to distinctly and specifically point out the supposed errors in the Examiner’s action in the prior Office Action (37 CFR 1.111). The Examiner asserts that the applicant only argues that the dependent claims should be allowable because the independent claims are unobvious and patentable over Shen in view of McCann, further in view of Bostick, further in view of Rizo, further in view of Malamut, and, where appropriate, in further view of Dress, Shekhar, Gersht and Dixon.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL R FISHER whose telephone number is (571)270-5097. The examiner can normally be reached Monday - Friday 9 am to 5:30 pm.
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, Yin-Chen Shaw can be reached at (571)272-8878. 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.
PAUL R. FISHER
Primary Examiner
Art Unit 2498
/PAUL R FISHER/Primary Examiner, Art Unit 2498 1/4/2026