DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The amendment filed 18 December 2025 has been entered. Applicant amended claims 1, 4, and 7. Applicant added new claims 10-12. Accordingly, claims 1-12 remain pending.
Applicant’s amendment to the abstract partially overcomes the abstract objection of 30 July 2025. Therefore, abstract objection of 30 July 2025 is withdrawn for elements a and b in the abstract objection of 30 July 2025..
Applicant’s amendment to the specification overcomes the specification and drawing objections of 30 July 2025. Therefore, specification and drawing objections of 30 July 2025 are withdrawn.
Applicant’s amendment to the claims overcomes the claim objections of 30 July 2025. Therefore, the claim objections of 30 July 2025 are withdrawn.
Response to Arguments
Applicant’s arguments, filed 18 December 2025, with respect to specification and drawing objections have been fully considered and are persuasive. The specification and drawing objections of 30 July 2025 have been withdrawn.
Applicant’s arguments, filed 18 December 2025, with respect to the claim objections have been fully considered and are persuasive. The claim objections of 30 July 2025 have been withdrawn
Applicant’s arguments, filed 18 December 2025, with respect to the abstract objection has been fully considered and are partially persuasive. The abstract objection of 30 July 2025 has been withdrawn for elements a and b in the abstract objection of 30 July 2025..
Regarding the 35 USC 101 Rejection:
Applicant’s remarks :
This type of invention is directly aligned with that in Desjardins, where the specification described an improvement to how the system operates, supporting a finding that a particular operative limitation in the claim reflected that improvement leading to a Prong Two finding that the claim integrated any abstract idea into a practical application.
The same analytic approach favors allowance here: the asserted improvement is implemented through the claimed R-graph structure (objects per resource with compliance/criticality attributes), the specific logical rule application (including hierarchical inheritance), and the domain-specific rendering, which collectively define a particular, computer-implemented technique for resilience/compliance computation in a resource graph.
The "R-graph" generation with attribute-bearing objects plus hierarchical rule inheritance is not a conventional, purely functional "apply it" generic data structure or generic instruction; it is a specific data-structure-driven computation pipeline tailored to the asserted technical problem of programmatically assessing data resilience across interrelated resources and operational scopes.
Applicant’s support:
Claim 1 is not merely "organizing" compliance/criticality information; it recites a specific computer-implemented technique for representing and computing resilience status in a complex data-processing environment by (i) generating a model of the data processing resources, (ii) generating an R-graph based on the model, having an object per resource with at least compliance, criticality and recovery-objective attributes, (iii) applying compliance and criticality rules to the objects, and (iv) displaying a domain-specific view of the resulting graph.
Dependent claim 2 further constrains the solution by requiring a hierarchy of objects and generating the domain-specific view by applying inheritance attributes of the compliance/criticality rules to that hierarchy.
Those limitations collectively amount to a concrete, technical mechanism-i.e., a particular graph-based data structure with attribute-bearing nodes and hierarchical rule inheritance and propagation logic that is used to compute and identify data protection and compliance issues for different operational scopes across an enterprise. See at least paragraphs [0028]- [0035] of the application as filed, which describes the R-graph data structure, the propagation logic, and the resulting advantages.
In Enfish terms, software improvements may be defined by "logical structures and processes," and eligibility depends on whether the claims are directed to an improvement to computer functionality rather than an abstract idea. Here, the R-graph and its rule-and- inheritance logic are not an incidental "field-of-use" context; they are the claimed technological mechanism that provides the operational solution-enabling computer systems'
Examiner’s remarks:
It has been determined that the steps of (i) generating a model of the data processing resources, (ii) generating an R-graph based on the model, having an object per resource with at least compliance, and criticality and recovery-objective attributes, (iii) applying compliance and criticality rules to the objects are steps that can be performed in the human mind using pencil and paper.
Applicant’s specification (Applicant cited paragraphs 28-35) does not appear to explain how the invention improves the functioning of the overall computing system in which it operates as is Enfish. Moreover, the limitations are directed to the abstract idea/judicial exception. The judicial exception alone cannot provide the improvement. The improvement is provided by the one or more additional elements. See the discussion of Diamond v. Diehr, 450 U.S. 175, 187 and 191-92, 209 USPQ 1, 10 (1981)). In addition, the improvement can be provided by the additional element(s) in combination with the recited judicial exception. See MPEP § 2106.04(d) (discussing Finjan, Inc. v. Blue Coat Sys., Inc., 879 F.3d 1299, 1303-04, 125 USPQ2d 1282, 1285-87 (Fed. Cir. 2018)).
The additional elements of the generic computer components and displaying the R-graph do not amount to more than the abstract idea.
The claims appear to provide the addition of general purpose computer components added post-hoc to an abstract idea.
Regarding the 102 Rejection:
Applicant’s arguments with respect to the claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because:
Should the recitation of “….compliance attributed and a criticality attribute…” instead be “compliance attribute [[attributed]] and a criticality attribute…”?
A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 10-11 are rejected under 35 U.S.C. 112(a) as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor at the time the application was filed, had possession of the claimed invention.
Claim 10 recites propagation logic iteratively traverses the dependency relationships in the R-graph to update compliance attributes until convergence or completion of a policy evaluation cycle. It has been determine that the limitation recited in the claim is new matter because there is no support for this limitation in the original disclosure. It is requested for Applicant to pinpoint in the specification support for the limitations provided in claim 10.
Claim 11 recites the conditional policy rules inhibit propagation of a compliant value of the compliance attribute from a first object to a dependent second object when an associated data protection policy or recovery objective parameter is not satisfied at the first object. It has been determine that the limitation recited in the claim is new matter because there is no support for this limitation in the original disclosure. It is requested for Applicant to pinpoint in the specification support for the limitations provided in claim 11.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (mental process) without significantly more. The independent claim(s) recite(s) “generating a model of a data processing resources…”, “generating a data resilience graph (R-graph), the R-graph including an object for each resource, and an object for each resource group comprising a plurality of resources, each object further including at least a compliance attribute and a criticality attribute; and applying compliance and criticality rules, including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group, wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources”.
The limitations above pertain to the method for assessing data resilience status of a data processing environment which is a process that under its broadest reasonable interpretation covers performance of the limitations being an abstract idea of a mental process. The method can be performed mentally by a human using pencil and paper, but for the recitation of generic computer components such as “data processing environment” (claims 1, 4, and 7), a data processor and computer readable media (claim 4), and non-transient medium and data processing system (claim 7). Therefore, nothing in the claimed elements preclude the steps from being practically performed manually by a human via a mental process or by a human using pencil or paper. If a claim under its broadest reasonable interpretation covers performance in the human mind or by a human using pencil and paper, but for the recitation of generic computer components, then if falls within the mental processing grouping of abstract ideas. Thus, claims 1, 4, and 7 recite an abstract idea.
This judicial exception is not integrated into a practical application. The independent claims recite additional elements of within the data processing environment, additional generic computer components, and displaying a domain specific view of the R-graph.
The generic computer components (including the data processing environment) are recited at a high level of generality such that it amounts to no more than mere instructions to apply the judicial exception using generic computing components. Accordingly, such additional elements do not integrate the abstract idea into a practical application because it does not impose meaningful limits on practicing the abstract idea. In addition, the processing environment is merely linking the judicial exception to a particular environment or field of use and does not qualify as significantly more than the judicial exception.
The additional element of displaying a domain specific view of the R-graph including propagated compliance attributes and propagated criticality attributes is determined to be post solution activity/insignificant extra solution activity that involves selecting a particular data source or type of data to be manipulated and displayed (see MPEP 2106.05(g)) and activity that is well-understood, routine, and conventional activity (MPEP 2106.05(d)). Therefore the additional element does not integrate the abstract idea into a practical application and do not add an inventive concept to the claims.
For the reasons above, the independent claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Thus, claims 1, 4, 7 are ineligible under 35 U.S.C 101.
Claims 2, 5, and 8 provide limitations that under the broadest reasonable interpretation further narrow the R-graph, which is activity that can be perform by a human using pencil and paper. The generation of the domain specific view by applying inheritance attributes of the compliance and criticality rules to the hierarchy of object appear to be an additional element that is not enough to qualify as significantly more than the abstract idea because the limitations is adding the words apply it with the judicial exception (MPEP 2106.05(d)). In addition, applying attributes/settings/rules to a display objects is determined to be well-understood, routine, conventional activity. Thus, claims 2, 5, and 8 are not eligible under 35 USC 101.
Claims 3, 6, and 9 provide limitations that under the broadest reasonable interpretation further narrow the domain specific view to a particular environment or field of use and does not qualify as significantly more than the judicial exception. Thus, claims 3, 6, and 9 are not eligible under 35 USC 101.
Claims 10-11 provide limitations that under the broadest reasonable interpretation can be achieve by the human mind using pencil and paper. The claims do not recite additional elements that amounts to more than the abstract idea. Thus, claims 10-11 are not eligible under 35 USC 101.
Claim 12 provides limitations that under the broadest reasonable interpretation further narrow the domain specific view and does not qualify as significantly more than the judicial exception. Thus, claim 12 is not eligible under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Morgan US 20220191230 (hereinafter Morgan) in view of Rieke US 20160072831 (hereinafter Rieke).
Regarding claim 1, Morgan teaches a method for assessing data resilience status of a data processing environment (abstract discloses method for identifying instances of vulnerabilities on a computing network and generating a graph representing pathways that an attacking entity may take with respect to accessing one or more sensitive assets. Paragraph 11 discloses assessing and evaluating vulnerabilities within in a computer network to determine security risk postures. Therefore, assessing the network resilience status by Morgan involves evaluating its capabilities to anticipate, withstand, and adapt to potential threats and vulnerabilities by determining/scoring security risks in different areas of the computer network) comprising:
generating a model of data processing resources within the data processing environment (paragraph 77 discloses the system generates a model that is based on a particular network environment including physical and logical network architecture. The model includes (a) the customer's security architecture and (b) vulnerability data, which is mapped to the model using (c) a set of rules. Paragraph 78 discloses generating a modeling of a security architecture that is characterized by the collections of nodes/entities in the network that interact with one another. The model uses data logs, user data logs, user behavior data, user account data, relationships between the user accounts, application configurations, etc., which may be gathered from customer systems and databases, as well as from public sources. Additionally, knowledge of the systems, devices and applications used in the network may be included. This data is incorporated into a customer's security architecture model. Paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph, wherein paragraph 19 discloses the network refers to a hierarchical structure including groups of devices, virtual networks, fault domains, or other groupings of devices. The computing network may include a variety of computing devices including client devices (e.g., mobile or non-mobile user devices), server devices, routers, switches, etc.,) and the domain-specific view is further generated by applying inheritance attributes of the compliance and criticality rules to the hierarchy of objects. See also paragraphs 59-61);
generating a data resilience-graph (R-graph) based the model (paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph), the R-graph including an object for each resource (paragraph 79 further discloses that in the graph, nodes[objects] depicts user accounts, assets, domains, host, etc., and are related by one another using edges to depict communications/can be accessed); and
applying … rules to the objects in the R-graph (paragraph 34 discloses the system collects different types of network information(rules/policies) such as sensitive asset information (e.g., customer indications of sensitive assets), knowledge of network architecture (e.g., device data, topology data, inter-device connection data), knowledge of system access rights (e.g., node data, permissions), and knowledge of application configurations (e.g., policies, application configurations, node configurations, device configurations). Paragraph 84 discloses the system uses one or more rules for a vulnerability to add or map vulnerabilities to the graphed security architecture. The rules includes compliance rules such as access rights. The rules are used to add a vulnerability to the customer security architecture and weight the edges in the graph from a security perspective, e.g., based on difficulty of exploiting a vulnerability. Paragraph 79 also discloses the system provides rules that transform the vulnerability data, e.g., description of an exploit, into a data set that maps to the graph model, e.g., updates the weights of an edge connecting nodes relevant to the vulnerability data update. See also paragraphs 34, 44, and 51); and
[AltContent: textbox (Selected Host by User to provided Domain-specific View/Data, see paragraph 100)][AltContent: arrow]
PNG
media_image1.png
561
795
media_image1.png
Greyscale
Figure 4B of Morgan
displaying a domain-specific view of the R-graph (Figure 4B and paragraph 100 reveal the system providing one or more reports/reviews, wherein the user select a host which contains an indication (critical) of risk associated with the host. The selected host is also indicated as having sensitive assets contained therein, with the actual file location of the sensitive assets being displayed in the lower right hand panel. This data may be discovered and stored during an initial scanning process and later retrieved in association with identifying the host as storing an important asset in terms of business risk. The selected host is displayed in the center in a graph view where it can be viewed in context. The system may display the graph view with more or less granularity in the network based on the underlying graph data, which is user selectable (e.g., via a slider), but is initially set to a default granularity centered on the host in question).
Morgan does not teach an object for each resource group comprises a plurality of resources; each object further including at least a compliance attribute and a criticality attribute for the corresponding resource; applying compliance and criticality rules including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group, wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources; and displaying a domain specific view of the R-graph, including propagated compliance attributes and propagated criticality attributes.
Rieke teaches a graph (Figure 10; paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph) including an object for each resource (Figure 10 reveals each object includes one or more assets/resources. Object denoted as Physician terminal has three assets. Health record has 1 asset), and an object for each resource comprising a plurality of resources (Figure 10 reveals each object includes one or more assets/resources. Object denoted as Physician terminal has three assets. Datacenter admin has nine assets); each object further including at least a compliance attribute and a criticality attribute for the corresponding resource (paragraph 132 reveals reports are generated and presented to users of the system and/or third parties. The report may be included in an electronic document, and may provide a summary of state, status, and/or history of some aspect of a network, TrustZones, and/or individual assets. The report may be created that details the compliance state/compliance attribute of all the assets in a TrustZone at the time the report is run. The report may be created to detail the detected vulnerabilities/criticality attribute of all assets in a TrustZone or a particular asset); applying compliance and criticality rules including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group (paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph. The data collected is analyzed via comparing the data to security policy (criticality rules), standards compliance policy (compliance rules) and performance standards. Paragraph 112 reveal that the collected data may include network flow attributes (flow can indicates group relationship, flow can also indicate propagation logic), information on a user of an asset, information regarding an asset (child resources) as well as hardware and/or virtual components associated with an asset (objects representing a resource group), information on software applications, attributes of different network nodes, security vulnerabilities, attributes of a network of assets, information on the content of data packets, as well as any other desired information. Network flow data (e.g., information pertaining to message exchanges and attempted message exchanges) is collected between virtual and physical assets in a network from hardware components (such as routers and switches or their virtual analogues) collecting “NetFlow” data. The NetFlow is the propagation logic. Paragraph 110 reveals the graph data analyzes asset and network data from multiple sources, and use such data to present a more complete and accurate representation of security posture and security relevant phenomena, supporting and performing complex combinatoric analyses for the correlation of events, network connections, asset operational states, and the states of security technical controls. See also paragraphs 110 and 114), wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources (paragraph 110 reveals the graph data analyzes asset and network data from multiple sources, and use such data to present a more complete and accurate representation of security posture and security relevant phenomena compared to conventional systems by, for example, supporting and performing complex combinatoric analyses for the correlation of events, network connections, asset operational states. Paragraph 132 discloses the report may be created that details the compliance state of all the assets (child resources) and provide detected vulnerability of all assets. Paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph. The data collected is analyzed via comparing the data to security policy (criticality rules), standards compliance policy (compliance rules) and performance standards. Paragraph 112 reveal that the collected data may include network flow attributes (flow can indicates group relationship, flow can also indicate propagation logic), information on a user of an asset, information regarding an asset (child resources) as well as hardware and/or virtual components associated with an asset (objects representing a resource group), information on software applications, attributes of different network nodes, security vulnerabilities, attributes of a network of assets, information on the content of data packets, as well as any other desired information. Network flow data (e.g., information pertaining to message exchanges and attempted message exchanges) is collected between virtual and physical assets in a network from hardware components (such as routers and switches or their virtual analogues) collecting “NetFlow” data. The NetFlow is the propagation logic, and the states of security technical controls. See also paragraphs 101, 131-132); and displaying a domain specific view of the R-graph, including propagated compliance attributes and propagated criticality attributes (paragraph 111 discloses receiving a selection of a component in the flow information graph, displaying additional information in response to the selection. Paragraph 20 and Figures 12-24 reveal screenshots of examples of interactions with a flow information graph and data table. Figure 23 shows a screenshot of PCI APP1 DB and the security control applied, with the selection to view propagated criticality attributes and flow data (compliance attributes). Paragraph 132 discloses a report may be included in an electronic document, and may provide a summary of state, status, and/or history of some aspect of a network, TrustZones, and/or individual assets. In one exemplary embodiment, a report may be created that details the compliance state of all the assets in a TrustZone at the time the report is run. In another example, a report may be created to detail the detected vulnerabilities of all assets in a TrustZone or a particular asset. Reports may also be generated to provide a summary of information at a particular point in time (e.g., a “snapshot”) or a summary of information over a period of time (e.g., showing trends in data) for TrustZones and/or assets. Exemplary embodiments may also generate a report that details the Zone Access Control List (ZACL), and all assets with their asset IP address(es) and TrustZone membership. Claims 10-11 disclose the teachings of displaying the characteristics of the selected connection).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Morgan’s information graph with Rieke’s teachings of generating an information flow graph, applying rules, and displaying views of the graph to present a more complete and accurate representation of the network connections between various systems and software applications and the policies dictating the operation of security controls on a network compared to conventional systems (paragraph 6 of Rieke).
Regarding claim 2, the combination of Morgan in view of Rieke teaches wherein the R-graph consists of a hierarchy of objects (Morgan: paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph, wherein paragraph 19 discloses the network refers to a hierarchical structure including groups of devices, virtual networks, fault domains, or other groupings of devices. The computing network may include a variety of computing devices including client devices (e.g., mobile or non-mobile user devices), server devices, routers, switches, etc.,) and the domain-specific view is further generated by applying inheritance attributes of the compliance and criticality rules to the hierarchy of objects (Morgan: paragraph 73 discloses the view shown in Figure 4B is presented based on an action/applying an inheritance attributes of the compliance and criticality rules for reducing risk on the network. Paragraphs 48-54 and 63 describe details on how the action is determined such as applying a scenario analysis to the graph, utilizing security information feeds (attributes of compliance and criticality) about the graph to determine actionable intelligence to lower risk on the graph).
Regarding claim 3, the combination of Morgan in view of Rieke teaches wherein the domain-specific view is for an entire enterprise, a department within the enterprise, an application, or a service (Morgan : Figure 4B and paragraph 100 disclose the user selected view is of a host, the selected host is also indicated as having sensitive assets that contained therein, with the actual file location of the sensitive assets being displayed in the lower right hand panel).
Regarding claim 4, Morgan teaches an apparatus for assessing compliance status of a data processing environment (abstract discloses system and method for identifying instances of vulnerabilities on a computing network and generating a graph representing pathways that an attacking entity may take with respect to accessing one or more sensitive assets. Paragraph 11 discloses assessing and evaluating vulnerabilities within in a computer network to determine security risk postures. Therefore, assessing the network resilience status involves evaluating its capabilities to anticipate, withstand, and adapt to potential threats and vulnerabilities by determining/scoring security risks in different areas of the computer network) comprising:
one or more data processors (paragraph 33 reveals the components of the system include one or more processors); and
one or more computer readable media including instructions that, when executed by the one or more data processors (paragraph 33 discloses system includes instructions stored on a computer-readable storage medium and executable by processors of one or more computing device. When executed by the one or more processors, the computer-executable instructions of one or more computing devices (e.g., client device, network devices) can perform one or more methods described), cause the one or more data processors to perform a process (see paragraph 33) for:
generating a model of data processing resources within the environment (paragraph 77 discloses the system generates a model that is based on a particular network environment including physical and logical network architecture. The model includes (a) the customer's security architecture and (b) vulnerability data, which is mapped to the model using (c) a set of rules. Paragraph 78 discloses generating a modeling of a security architecture that is characterized by the collections of nodes/entities in the network that interact with one another. The model uses data logs, user data logs, user behavior data, user account data, relationships between the user accounts, application configurations, etc., which may be gathered from customer systems and databases, as well as from public sources. Additionally, knowledge of the systems, devices and applications used in the network may be included. This data is incorporated into a customer's security architecture model. Paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph, wherein paragraph 19 discloses the network refers to a hierarchical structure including groups of devices, virtual networks, fault domains, or other groupings of devices. The computing network may include a variety of computing devices including client devices (e.g., mobile or non-mobile user devices), server devices, routers, switches, etc.,) and the domain-specific view is further generated by applying inheritance attributes of the compliance and criticality rules to the hierarchy of objects. See also paragraphs 59-61);
generating a data resilience-graph (R-graph) based on the model (paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph), the R-graph including an object for each resource (paragraph 79 further discloses that in the graph, nodes[objects] depicts user accounts, assets, domains, host, etc., and are related by one another using edges to depict communications/can be accessed);
applying … rules to the R-graph (paragraph 34 discloses the system collects different types of network information(rules/policies) such as sensitive asset information (e.g., customer indications of sensitive assets), knowledge of network architecture (e.g., device data, topology data, inter-device connection data), knowledge of system access rights (e.g., node data, permissions), and knowledge of application configurations (e.g., policies, application configurations, node configurations, device configurations). Paragraph 84 discloses the system uses one or more rules for a vulnerability to add or map vulnerabilities to the graphed security architecture. The rules includes compliance rules such as access rights. The rules are used to add a vulnerability to the customer security architecture and weight the edges in the graph from a security perspective, e.g., based on difficulty of exploiting a vulnerability. Paragraph 79 also discloses the system provides rules that transform the vulnerability data, e.g., description of an exploit, into a data set that maps to the graph model, e.g., updates the weights of an edge connecting nodes relevant to the vulnerability data update. See also paragraphs 34, 44, and 51); and
displaying a domain-specific view from the R-graph (Figure 4B and paragraph 100 reveal the system providing one or more reports/reviews, wherein the user select a host which contains an indication (critical) of risk associated with the host. The selected host is also indicated as having sensitive assets contained therein, with the actual file location of the sensitive assets being displayed in the lower right hand panel. This data may be discovered and stored during an initial scanning process and later retrieved in association with identifying the host as storing an important asset in terms of business risk. The selected host is displayed in the center in a graph view where it can be viewed in context. The system may display the graph view with more or less granularity in the network based on the underlying graph data, which is user selectable (e.g., via a slider), but is initially set to a default granularity centered on the host in question).
Morgan does not teach an object for each resource group comprises a plurality of resources; each object further including at least a compliance attribute and a criticality attribute for the corresponding resource; applying compliance and criticality rules including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group, wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources; and displaying a domain specific view of the R-graph, including propagated compliance attributes and propagated criticality attributes.
Rieke teaches a graph (Figure 10; paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph) including an object for each resource (Figure 10 reveals each object includes one or more assets/resources. Object denoted as Physician terminal has three assets. Health record has 1 asset), and an object for each resource comprising a plurality of resources (Figure 10 reveals each object includes one or more assets/resources. Object denoted as Physician terminal has three assets. Datacenter admin has nine assets); each object further including at least a compliance attribute and a criticality attribute for the corresponding resource (paragraph 132 reveals reports are generated and presented to users of the system and/or third parties. The report may be included in an electronic document, and may provide a summary of state, status, and/or history of some aspect of a network, TrustZones, and/or individual assets. The report may be created that details the compliance state/compliance attribute of all the assets in a TrustZone at the time the report is run. The report may be created to detail the detected vulnerabilities/criticality attribute of all assets in a TrustZone or a particular asset); applying compliance and criticality rules including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group (paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph. The data collected is analyzed via comparing the data to security policy (criticality rules), standards compliance policy (compliance rules) and performance standards. Paragraph 112 reveal that the collected data may include network flow attributes (flow can indicates group relationship, flow can also indicate propagation logic), information on a user of an asset, information regarding an asset (child resources) as well as hardware and/or virtual components associated with an asset (objects representing a resource group), information on software applications, attributes of different network nodes, security vulnerabilities, attributes of a network of assets, information on the content of data packets, as well as any other desired information. Network flow data (e.g., information pertaining to message exchanges and attempted message exchanges) is collected between virtual and physical assets in a network from hardware components (such as routers and switches or their virtual analogues) collecting “NetFlow” data. The NetFlow is the propagation logic. Paragraph 110 reveals the graph data analyzes asset and network data from multiple sources, and use such data to present a more complete and accurate representation of security posture and security relevant phenomena, supporting and performing complex combinatoric analyses for the correlation of events, network connections, asset operational states, and the states of security technical controls. See also paragraphs 110 and 114), wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources (paragraph 110 reveals the graph data analyzes asset and network data from multiple sources, and use such data to present a more complete and accurate representation of security posture and security relevant phenomena compared to conventional systems by, for example, supporting and performing complex combinatoric analyses for the correlation of events, network connections, asset operational states. Paragraph 132 discloses the report may be created that details the compliance state of all the assets (child resources) and provide detected vulnerability of all assets. Paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph. The data collected is analyzed via comparing the data to security policy (criticality rules), standards compliance policy (compliance rules) and performance standards. Paragraph 112 reveal that the collected data may include network flow attributes (flow can indicates group relationship, flow can also indicate propagation logic), information on a user of an asset, information regarding an asset (child resources) as well as hardware and/or virtual components associated with an asset (objects representing a resource group), information on software applications, attributes of different network nodes, security vulnerabilities, attributes of a network of assets, information on the content of data packets, as well as any other desired information. Network flow data (e.g., information pertaining to message exchanges and attempted message exchanges) is collected between virtual and physical assets in a network from hardware components (such as routers and switches or their virtual analogues) collecting “NetFlow” data. The NetFlow is the propagation logic, and the states of security technical controls. See also paragraphs 101, 131-132); and displaying a domain specific view of the R-graph, including propagated compliance attributes and propagated criticality attributes (paragraph 111 discloses receiving a selection of a component in the flow information graph, displaying additional information in response to the selection. Paragraph 20 and Figures 12-24 reveal screenshots of examples of interactions with a flow information graph and data table. Figure 23 shows a screenshot of PCI APP1 DB and the security control applied, with the selection to view propagated criticality attributes and flow data (compliance attributes). Paragraph 132 discloses a report may be included in an electronic document, and may provide a summary of state, status, and/or history of some aspect of a network, TrustZones, and/or individual assets. In one exemplary embodiment, a report may be created that details the compliance state of all the assets in a TrustZone at the time the report is run. In another example, a report may be created to detail the detected vulnerabilities of all assets in a TrustZone or a particular asset. Reports may also be generated to provide a summary of information at a particular point in time (e.g., a “snapshot”) or a summary of information over a period of time (e.g., showing trends in data) for TrustZones and/or assets. Exemplary embodiments may also generate a report that details the Zone Access Control List (ZACL), and all assets with their asset IP address(es) and TrustZone membership. Claims 10-11 disclose the teachings of displaying the characteristics of the selected connection).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Morgan’s information graph with Rieke’s teachings of generating an information flow graph, applying rules, and displaying views of the graph to present a more complete and accurate representation of the network connections between various systems and software applications and the policies dictating the operation of security controls on a network compared to conventional systems (paragraph 6 of Rieke).
Regarding claim 5, the combination Morgan in view of Rieke teaches wherein the R-graph consists of a hierarchy of objects (Morgan: paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph, wherein paragraph 19 discloses the network refers to a hierarchical structure including groups of devices, virtual networks, fault domains, or other groupings of devices. The computing network may include a variety of computing devices including client devices (e.g., mobile or non-mobile user devices), server devices, routers, switches, etc.,) and the domain-specific view is further generated by applying inheritance attributes of the compliance and criticality rules to the hierarchy of objects (Morgan: paragraph 73 discloses the view shown in Figure 4B is presented based on an action/applying an inheritance attributes of the compliance and criticality rules for reducing risk on the network. Paragraphs 48-54 and 63 describe details on how the action is determined such as applying a scenario analysis to the graph, utilizing security information feeds (attributes of compliance and criticality) about the graph to determine actionable intelligence to lower risk on the graph).
Regarding claim 6, the combination of Morgan in view of Rieke teaches wherein the domain-specific view is for an entire enterprise, a department within the enterprise, an application, or a service (Morgan: Figure 4B and paragraph 100 disclose the user selected view is of a host, the selected host is also indicated as having sensitive assets that contained therein, with the actual file location of the sensitive assets being displayed in the lower right hand panel).
Regarding claim 7, Morgan teaches a computer program product embodied in a non-transient medium (paragraph 33 discloses the system includes instructions stored on a computer-readable storage medium and executable by processors of one or more computing device. When executed by the one or more processors, the computer-executable instructions of one or more computing devices (e.g., client device, network devices) can perform one or more methods described) for assessing compliance status of a data processing environment, the computer program product holding computer program instructions that, when executed by a data processing system, is configured for (abstract discloses system and method for identifying instances of vulnerabilities on a computing network and generating a graph representing pathways that an attacking entity may take with respect to accessing one or more sensitive assets. Paragraph 11 discloses assessing and evaluating vulnerabilities within in a computer network to determine security risk postures. Therefore, assessing the network resilience status involves evaluating its capabilities to anticipate, withstand, and adapt to potential threats and vulnerabilities by determining/scoring security risks in different areas of the computer network) comprising:
generating a model of data processing resources within the data processing environment (paragraph 77 discloses the system generates a model that is based on a particular network environment including physical and logical network architecture. The model includes (a) the customer's security architecture and (b) vulnerability data, which is mapped to the model using (c) a set of rules. Paragraph 78 discloses generating a modeling of a security architecture that is characterized by the collections of nodes/entities in the network that interact with one another. The model uses data logs, user data logs, user behavior data, user account data, relationships between the user accounts, application configurations, etc., which may be gathered from customer systems and databases, as well as from public sources. Additionally, knowledge of the systems, devices and applications used in the network may be included. This data is incorporated into a customer's security architecture model. Paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph, wherein paragraph 19 discloses the network refers to a hierarchical structure including groups of devices, virtual networks, fault domains, or other groupings of devices. The computing network may include a variety of computing devices including client devices (e.g., mobile or non-mobile user devices), server devices, routers, switches, etc.,) and the domain-specific view is further generated by applying inheritance attributes of the compliance and criticality rules to the hierarchy of objects. See also paragraphs 59-61);
generating a data resilience-graph (R-graph) based on the model (paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph), the R-graph including an object for each resource (paragraph 79 further discloses that in the graph, nodes[objects] depicts user accounts, assets, domains, host, etc., and are related by one another using edges to depict communications/can be accessed);
applying … rules to the R-graph (paragraph 34 discloses the system collects different types of network information(rules/policies) such as sensitive asset information (e.g., customer indications of sensitive assets), knowledge of network architecture (e.g., device data, topology data, inter-device connection data), knowledge of system access rights (e.g., node data, permissions), and knowledge of application configurations (e.g., policies, application configurations, node configurations, device configurations). Paragraph 84 discloses the system uses one or more rules for a vulnerability to add or map vulnerabilities to the graphed security architecture. The rules includes compliance rules such as access rights. The rules are used to add a vulnerability to the customer security architecture and weight the edges in the graph from a security perspective, e.g., based on difficulty of exploiting a vulnerability. Paragraph 79 also discloses the system provides rules that transform the vulnerability data, e.g., description of an exploit, into a data set that maps to the graph model, e.g., updates the weights of an edge connecting nodes relevant to the vulnerability data update. See also paragraphs 34, 44, and 51); and
displaying a domain-specific view from the R-graph (Figure 4B and paragraph 100 reveal the system providing one or more reports/reviews, wherein the user select a host which contains an indication (critical) of risk associated with the host. The selected host is also indicated as having sensitive assets contained therein, with the actual file location of the sensitive assets being displayed in the lower right hand panel. This data may be discovered and stored during an initial scanning process and later retrieved in association with identifying the host as storing an important asset in terms of business risk. The selected host is displayed in the center in a graph view where it can be viewed in context. The system may display the graph view with more or less granularity in the network based on the underlying graph data, which is user selectable (e.g., via a slider), but is initially set to a default granularity centered on the host in question).
Morgan does not teach an object for each resource group comprises a plurality of resources; each object further including at least a compliance attribute and a criticality attribute for the corresponding resource; applying compliance and criticality rules including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group, wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources; and displaying a domain specific view of the R-graph, including propagated compliance attributes and propagated criticality attributes.
Rieke teaches a graph (Figure 10; paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph) including an object for each resource (Figure 10 reveals each object includes one or more assets/resources. Object denoted as Physician terminal has three assets. Health record has 1 asset), and an object for each resource comprising a plurality of resources (Figure 10 reveals each object includes one or more assets/resources. Object denoted as Physician terminal has three assets. Datacenter admin has nine assets); each object further including at least a compliance attribute and a criticality attribute for the corresponding resource (paragraph 132 reveals reports are generated and presented to users of the system and/or third parties. The report may be included in an electronic document, and may provide a summary of state, status, and/or history of some aspect of a network, TrustZones, and/or individual assets. The report may be created that details the compliance state/compliance attribute of all the assets in a TrustZone at the time the report is run. The report may be created to detail the detected vulnerabilities/criticality attribute of all assets in a TrustZone or a particular asset); applying compliance and criticality rules including propagation logic, to the objects in the R-graph based on relationships between the objects, including nested group relationships, such that compliance values and criticality values are propagated from objects representing child resources to an object representing a resource group (paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph. The data collected is analyzed via comparing the data to security policy (criticality rules), standards compliance policy (compliance rules) and performance standards. Paragraph 112 reveal that the collected data may include network flow attributes (flow can indicates group relationship, flow can also indicate propagation logic), information on a user of an asset, information regarding an asset (child resources) as well as hardware and/or virtual components associated with an asset (objects representing a resource group), information on software applications, attributes of different network nodes, security vulnerabilities, attributes of a network of assets, information on the content of data packets, as well as any other desired information. Network flow data (e.g., information pertaining to message exchanges and attempted message exchanges) is collected between virtual and physical assets in a network from hardware components (such as routers and switches or their virtual analogues) collecting “NetFlow” data. The NetFlow is the propagation logic. Paragraph 110 reveals the graph data analyzes asset and network data from multiple sources, and use such data to present a more complete and accurate representation of security posture and security relevant phenomena, supporting and performing complex combinatoric analyses for the correlation of events, network connections, asset operational states, and the states of security technical controls. See also paragraphs 110 and 114), wherein the propagation logic determines a compliance status for the object representing the resource group based at least in part on (i) compliance attributes of the child resources and (ii) criticality attributes of the child resources (paragraph 110 reveals the graph data analyzes asset and network data from multiple sources, and use such data to present a more complete and accurate representation of security posture and security relevant phenomena compared to conventional systems by, for example, supporting and performing complex combinatoric analyses for the correlation of events, network connections, asset operational states. Paragraph 132 discloses the report may be created that details the compliance state of all the assets (child resources) and provide detected vulnerability of all assets. Paragraph 131 reveals that the collected data is data related to the generation and or presentation of the flow information graph. The data collected is analyzed via comparing the data to security policy (criticality rules), standards compliance policy (compliance rules) and performance standards. Paragraph 112 reveal that the collected data may include network flow attributes (flow can indicates group relationship, flow can also indicate propagation logic), information on a user of an asset, information regarding an asset (child resources) as well as hardware and/or virtual components associated with an asset (objects representing a resource group), information on software applications, attributes of different network nodes, security vulnerabilities, attributes of a network of assets, information on the content of data packets, as well as any other desired information. Network flow data (e.g., information pertaining to message exchanges and attempted message exchanges) is collected between virtual and physical assets in a network from hardware components (such as routers and switches or their virtual analogues) collecting “NetFlow” data. The NetFlow is the propagation logic, and the states of security technical controls. See also paragraphs 101, 131-132); and displaying a domain specific view of the R-graph, including propagated compliance attributes and propagated criticality attributes (paragraph 111 discloses receiving a selection of a component in the flow information graph, displaying additional information in response to the selection. Paragraph 20 and Figures 12-24 reveal screenshots of examples of interactions with a flow information graph and data table. Figure 23 shows a screenshot of PCI APP1 DB and the security control applied, with the selection to view propagated criticality attributes and flow data (compliance attributes). Paragraph 132 discloses a report may be included in an electronic document, and may provide a summary of state, status, and/or history of some aspect of a network, TrustZones, and/or individual assets. In one exemplary embodiment, a report may be created that details the compliance state of all the assets in a TrustZone at the time the report is run. In another example, a report may be created to detail the detected vulnerabilities of all assets in a TrustZone or a particular asset. Reports may also be generated to provide a summary of information at a particular point in time (e.g., a “snapshot”) or a summary of information over a period of time (e.g., showing trends in data) for TrustZones and/or assets. Exemplary embodiments may also generate a report that details the Zone Access Control List (ZACL), and all assets with their asset IP address(es) and TrustZone membership. Claims 10-11 disclose the teachings of displaying the characteristics of the selected connection).
It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to modify Morgan’s information graph with Rieke’s teachings of generating an information flow graph, applying rules, and displaying views of the graph to present a more complete and accurate representation of the network connections between various systems and software applications and the policies dictating the operation of security controls on a network compared to conventional systems (paragraph 6 of Rieke).
Regarding claim 8, the combination of Morgan in view of Rieke teaches wherein the R-graph consists of a hierarchy of objects (Morgan: paragraph 79 discloses the data from the security architecture model of a network environment may be formed into a graph, wherein paragraph 19 discloses the network refers to a hierarchical structure including groups of devices, virtual networks, fault domains, or other groupings of devices. The computing network may include a variety of computing devices including client devices (e.g., mobile or non-mobile user devices), server devices, routers, switches, etc.,) and the domain-specific view is further generated by applying inheritance attributes of the compliance and criticality rules to the hierarchy of objects (Morgan: paragraph 73 discloses the view shown in Figure 4B is presented based on an action/applying an inheritance attributes of the compliance and criticality rules for reducing risk on the network. Paragraphs 48-54 and 63 describe details on how the action is determined such as applying a scenario analysis to the graph, utilizing security information feeds (attributes of compliance and criticality) about the graph to determine actionable intelligence to lower risk on the graph).
Regarding claim 9, the combination of Morgan in view of Rieke teaches wherein the domain-specific view is for an entire enterprise, a department within the enterprise, an application, or a service (Morgan: Figure 4B and paragraph 100 disclose the user selected view is of a host, the selected host is also indicated as having sensitive assets that contained therein, with the actual file location of the sensitive assets being displayed in the lower right hand panel).
Regarding claim 10, the combination of Morgan in view of Rieke teaches wherein the propagation logic iteratively traverses the dependency relationships in the R-graph to update the compliance attributes until convergence or completion of a policy evaluation cycle (Rieke: paragraph 111 discloses receiving edits to network traffic rules and applying such rules to the network; collecting updated data and updating the flow information graph with the updated data. Paragraph 53 discloses a Control Management and Directives component performs the construction of directives and initiates the delivery of directives to the computing environment elements to affect the appropriate action or actions from the elements including: the generation of events, transfer of configuration and process data in either direction, the starting and stopping of a security technical control, the reconfiguration of the security technical control with an updated policy, the reconfiguration of an element of any type, the starting and stopping of a program or process, the change of a configuration or attribute affecting a configuration, and the validation that the control is applied to any information asset as qualified by configuration data supplied through the events or directives). Motivation similar to the motivation presented in claim 1.
Regarding claim 11, the combination of Morgan in view of Rieke teaches wherein the conditional policy rules inhibit propagation of a compliant value of the compliance attribute from a first object to a dependent second object when an associated data-protection policy or recovery-objective parameter is not satisfied at the first object (Rieke: paragraph 118 discloses a selection of a component (e.g., a network asset or connection between assets) may be received In a case where the flow information graph is presented on a display screen of client device controlled by a user, the user can select (e.g., using a mouse) a flow line to perform various actions. For example, selection of the flow line may display additional information associated with the connection, such as by presenting the user with characteristics of the connection associated with the flow line. Selection of the flow line may also allow the user to view and edit rules for allowing and blocking traffic over the connection. Rules edited in this manner can then be applied to the connection. Paragraph 121 and Figure 13 disclose a screenshot showing ZACL rules being triggered. In this example, events where traffic is allowed by a ZACL rule cause the rule to be highlighted in green, while events where traffic is blocked cause the ZACL rule to be highlighted in red. Thus, the blocked traffic over the connection inhibit propagation of a compliant value from a first object to a second object based on ZACL/data protection rules ). Motivation similar to the motivation presented in claim 1.
Regarding claim 12, the combination of Morgan in view of Rieke teaches wherein the domain-specific view presents the propagated compliance attributes and criticality attributes color-coded according to protection tiers and policy thresholds (Rieke: paragraph 121 and Figure 13 disclose a screenshot showing ZACL rules being triggered. In this example, events where traffic is allowed (compliance) by a ZACL rule cause the rule to be highlighted in green, while events where traffic is blocked (criticality) cause the ZACL rule to be highlighted in red Paragraph 112 further discloses data that is collected may also include security technical control configuration attributes or policies defining allowed and blocked traffic between specific assets, groups of assets, and/or logical zones ). Motivation similar to the motivation presented in claim 1.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FELICIA FARROW whose telephone number is (571)272-1856. The examiner can normally be reached M - F 7:30am-4:00pm (EST).
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, Alexander Lagor can be reached at (571)270-5143. 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.
/F.F/ Examiner, Art Unit 2437
/ALI S ABYANEH/ Primary Examiner, Art Unit 2437