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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination (RCE) under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on December 22, 2025 has been entered.
Response to Amendments
This office action is responsive to application 17/420,343 and the RCE filed on December 22, 2025. Claims 1 and 11 are amended, and claims 1-20 remain pending in the application.
Response to Arguments
The Examiner has fully considered the Applicant’s arguments filed with the RCE, and the Examiner responds as provided below.
Regarding the Applicant’s response at page 11 of the Remarks that concerns the § 112 rejection, the arguments in conjunction with the amendments are persuasive, and the § 112 rejection is withdrawn.
Regarding the Applicant’s response at pages 11-13 of the Remarks that concerns the § 103 rejection, the Applicant’s arguments in conjunction with the claim amendments are persuasive, and consequently the Examiner conducted a new prior art search. The Applicant’s arguments are now moot with respect to the pending claims because the arguments do not apply to one of the references currently used in the rejection of the aforementioned claims as detailed below.
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 conventions apply to the mapping of the prior art to the claims:
Italicized text – claim language.
Parenthetical plain text – Examiner’s citation and explanation.
Citation without an explanation – an explanation has been previously provided for the respective limitation(s).
Quotation marks – language quoted from a prior art reference.
Underlining – language quoted from a claim.
Brackets – material altered from either a prior art reference or a claim, which includes the Examiner’s explanation that relates a claim limitation to the quoted material of a reference.
Braces – a limitation taught by another reference, but the limitation is presented with the mapping of the instant reference for context.
Numbered superscript – a first phrase to be moved upwards to the primary reference analysis.
Lettered superscript – a second phrase to be moved after the movement of the first phrase from which it was lifted, or more succinctly, move numbered material first, lettered material last.
A. Claims 1-2, 5-6, 9-10, 11-12, 15-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Beard (US Provisional Application 62/784,416, “Beard,” see previously attached document) in view of Hamdi (US 2018/0124094, “Hamdi”), and further in view of and Sellers et al. (US 2020/0092165, “Sellers”). (See also Beard US 2020/0201620 that claims priority to provisional application 62/784,416, and thus the provisional application is “deemed published” pursuant to § 102(a)(2) via the publishing of the non-provisional application.)
Regarding Claim 1
A method (at least Fig. 6, ¶ [0017]) for facilitating cybersecurity risk management (¶¶ [0003]-[0004], “However, many manufactures may not be able to identify cyber threats, vulnerable software versions, and/or vulnerable hardware in every environment;” and ¶ [0016], “Embodiments of the present disclosure generate a SBOM blockchain. The SBOM blockchain may be employed to validate updates [to facilitate cybersecurity risk management] to a device specific SBOM for each of a plurality of medical devices.”), the method comprising:
receiving, by one or more hardware processors, asset information from a computing asset configured to generate the asset information (Fig. 3, ¶ [0027], “Each of the plurality of medical devices 310 [computing asset] may be configured to communicate a device specific SBOM [asset information] 311 to at least one of the plurality of validator systems 340 [possessing a hardware processor that communicates by receiving the SBOM/asset information].”; Fig. 1, ¶ [0025], “The SBOM validation system 100 may comprise a plurality of medical devices [computing assets] (110, 111 ... 119).”; and ¶ [0022], “The new block may comprise at least one update [as asset information] to the device specific SBOM from a previous device specific SBOM.”),
1 …;
2 …;
3 …;
4 …;
generating, by the one or more hardware processors, a risk notification associated with the computing asset based on the risk profile (Fig. 3, ¶ [0027], “Each of the plurality of validator systems 340 [hardware processor] may be configured to [generate and] communicate alert data 341 [as a risk notification when the determining involving hashes fails that leads to an unacceptable SBOM score or risk profile] to the at least one coordinator system 360.”);
transmitting, by the one or more hardware processors, the risk notification to a user device (Fig. 3, ¶ [0027], “Each of the plurality of validator systems [hardware processors] 340 may be configured to communicate [transmit] alert data 341 [risk notification] to the at least one coordinator system 360,” “The at least one coordinator system [hardware processors] 360 may be configured to communicate [transmit] status data 361 to at least one client system 370,” and ¶ [0024], “The status data may comprise alerts,...” i.e., the risk profile is a “status” that is communicated to the “client system” comprising a user device);
5 …;
6 …;
7 …; and
transmitting, by the one or more hardware processors, a second risk notification generated based on the updated risk weight value risk profile (Fig. 3, ¶ [0027], “Each of the plurality of validator systems 340 [hardware processor] may be configured to [generate and] communicate [generate] alert data 341 [as a second risk notification when the determining involving hashes fails that leads to an unacceptable SBOM score to the at least one coordinator system 360.”, i.e., it would be obvious to one skilled in the art to send a second risk notification upon a change in the state variables/predetermined criteria and/or risk weight values that signify a threat to the system).
Beard doesn’t disclose
1 the computing asset associated with a plurality of risk weight values;
2 retrieving, by the one or more hardware processors, secondary asset information associated with the computing asset from a third-party database;
3 analyzing, by the one or more hardware processors, the asset information and the secondary asset information based on a plurality of predetermined criteria and the plurality of risk weight values respectively corresponding to the plurality of predetermined criteria;
4 determining, by the one or more hardware processors, a risk profile corresponding to the computing asset based on a weighted sum of the plurality of risk weight values applied to the asset information and the secondary asset information;
5 receiving, by the one or more hardware processors, a risk weight value corresponding to a predetermined criterion of the plurality of predetermined criteria;
6 modifying, by the one or more hardware processors, the predetermined criterion based on the risk weight value to generate a modified criterion;
7 updating, by the one or more hardware processors, the risk profile based on the modified criterion;
Hamdi, however, discloses
1 the computing asset associated with a plurality of risk weight values (¶ [0165], “The ranking engine 316 can compute the ranking value as a weighted sum [based on a plurality of risk weight values] of multiple parameter [risk weight] values associated with the specification profiles [containing the state variables as predetermined criteria], the received vulnerability data, and the received profiling data.”);
3 analyzing, by the one or more hardware processors, the {asset information (Beard, ¶¶ [0022], [0025] & [0027], i.e., at least “updates”)} and the {secondary asset information (Sellers ¶ [0066])} based on a plurality of predetermined criteria (¶ [0135], “The criteria can include requirements or specifications defined in the specification profiles [comprising asset information and secondary asset information] associated with the target [computing] asset [and secondary asset of Sellers ¶ [0062]] or the computing and network environment 210.”; ¶¶ [0138]-[0139], “Determining the state(s) of operation can include the asset profiling engine 312 or the controller engine 310 updating one or more state variables [predetermined criteria] corresponding to the one or more determined states of operation [i.e., “predetermined” is relative with respect to time, and here state variables change, with the initial state variable considered predetermined].”, and “In some implementations, the ranking engine 316 can update a ranking value [as a risk weight value] associated with the target asset based on the updated state variables [predetermined criteria].”; and ¶¶ [0106]-[0107], “The ranking engine 316 can also use collected data (e.g., asset profiling data [asset information and secondary asset information], vulnerability scanning data, and/or data from other sources such as databases 240, 250 or 260) to quantify or estimate [via analyzing] how critical the state(s) of operation [based on “state variables”/predetermined criteria] of the asset is/are.”) and
the plurality of risk weight values respectively corresponding to the plurality of predetermined criteria (¶ [0138], “Setting the HA [high availability] state variable [predetermined criterion] to False makes the asset no longer HA available. The asset profiling engine 312 or the controller engine 310 can set the HA True or False (or 1 or 0) states based on, for example, what is an acceptable deviation from a desired synchronization speed. In some implementations, a number [plurality] of state variables [predetermined conditions] can be associated with each asset, such as a HA state variable, one or more stress level state variables, one or more security state variables. The back-end system 222 (e.g., the controller engine 310) can define such state variables based on the specification variables in the respective specification profiles. The asset profiling engine 312 can update the state variables associated with the target asset based on the parameter [risk weight] values received at step 950 or the comparison performed at step 960.”);
4 determining, by the one or more hardware processors, a risk profile corresponding to the computing asset based on a weighted sum of the plurality of risk weight values applied to the asset information and the secondary asset information (¶ [0165], “Taking into account all these aspects of the asset in computing the ranking value(s) allows for comprehensive and reliable prioritizing approach in handling detected vulnerabilities. The ranking engine 316 can compute [determine] the ranking [risk weight] value as a weighted sum of multiple [plurality] parameter [risk weight] values associated with [applied to] the specification [risk] profiles [that also include asset information and secondary asset information], the received vulnerability data, and the received profiling data.”);
5 receiving, by the one or more hardware processors, a risk weight value corresponding to a predetermined criterion of the plurality of predetermined criteria (¶ [0138], “The asset profiling engine 312 can update the state variables associated with the target asset based on the parameter [risk weight] values [that correspond to the predetermined criteria/”state variables”] received at step 950 or the comparison performed at step 960.”);
6 modifying, by the one or more hardware processors, the predetermined criterion based on the risk weight value to generate a modified criterion (¶ [0138], “The asset profiling engine 312 can update [modify] the state variables [to generate a modified criterion] associated with the target asset based on the parameter [risk weight] values received at step 950 or the comparison performed at step 960.”);
7 updating, by the one or more hardware processors, the risk profile based on the modified criterion (¶ [0165], “The ranking engine 316 can compute [update] the ranking value as a weighted sum of multiple [plurality] parameter [risk weight] values associated with the specification [risk] profiles, the received vulnerability data, and the received profiling data.”; and ¶¶ [0138]-[0139], “In some implementations, the ranking engine 316 can update a ranking value associated with the target asset [and associated risk profile] based on the updated [modified] state variables [criterion].”);
Regarding the combination of Beard and Hamdi, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the validation system of Beard to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C).
To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C):
1) the prior art contained a base system, namely the validation system of Beard, upon which the claimed invention can be seen as an “improvement” through the use of a criteria-weighting feature;
2) the prior art contained a “comparable” system, namely the vulnerability system of Hamdi, that has been improved in the same way as the claimed invention through the criteria-weighting feature; and
3) one of ordinary skill in the art could have applied the known improvement technique of applying the criteria-weighting feature to the base validation system of Beard, and the results would have been predictable to one of ordinary skill in the art.
Sellers, however, discloses
2 retrieving, by the one or more hardware processors, secondary asset information associated with the computing asset from a third-party database (Fig. 2, ¶ [0062], “A production system can include one or more security appliances 208. As described, a security appliance [secondary asset] can accept connections from third party entities [with the security appliance also being a third-party asset with respect to the computing asset as disclosed by Beard ¶ [0027]] (e.g., a hardware and/or software entity), such as third-party entity 209.”; Fig. 1, ¶¶ [0049]-[0050], “These types can include, for example, application servers operable to process instructions provided by a user or database servers operable to process data stored in one or more data stores [database] 116 in response to a user request.”; and “In various embodiments, resource provider environment 106 may include various types of resources [secondary assets] that can be utilized for analyzing and reporting anomalous network activity.”; and ¶ [0066], “The information in data store 220 can include data imported [received] from various repositories of data from one or more production systems such as production systems 204 and 210. In this example, import component 212 can obtain [secondary] information associated with computing devices [secondary assets as honeypots that mimic the primary computing asset] from these production systems. The information can include attribute information for the computing devices that identifies an electronic device, service, or other resource of a provider and corresponding functionality.”);
Regarding the combination of Beard-Hamdi and Sellers, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the validation system of Beard-Hamdi to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C).
To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C):
1) the prior art contained a base system, namely the validation system of Beard-Hamdi, upon which the claimed invention can be seen as an “improvement” through the use of a secondary asset feature;
2) the prior art contained a “comparable” system, namely the vulnerability system of Sellers, that has been improved in the same way as the claimed invention through the secondary asset feature; and
3) one of ordinary skill in the art could have applied the known improvement technique of applying the secondary asset feature to the base validation system of Beard-Hamdi, and the results would have been predictable to one of ordinary skill in the art.
Regarding Claim 2
Beard in view of Hamdi, and further in view of Sellers (“Beard-Hamdi-Sellers”) discloses the method of claim 1, and Beard further discloses:
further comprising:
receiving, by the one or more hardware processors, additional asset information associated with the computing asset from an external device (¶ [0016], “In this disclosure, updates to device [computing asset] specific SBOM are to include installation [from an external device, i.e., a medical device receives updates from a manufacturer server as it cannot generate an update itself] of additional software [as additional asset information] and/or hardware;” ¶ [0029], “The update data 534 may comprise at least one update [as additional asset information] to the known device specific SBOM in SBOM data 513;” and Fig. 6, ¶ [0034], “The device specific SBOM may be communicated [received] to at least one of a plurality of validator systems [hardware processors] at 620. A SBOM hash tree [that includes “updates” comprising additional asset information received by the hardware processors] may be built based on data in a SBOM blockchain at 630.”); and
1 ….
Hamdi further discloses
1 analyzing, by the one or more hardware processors, the {additional asset information (Beard ¶ [0016])} based on at least one predetermined criterion of the plurality of predetermined criteria (¶ [0164], “For example, an asset with a high level of functional dependencies (e.g., a larger number of other assets depend on it for one or more of their functions or operations), can be perceived as an important asset that needs to be prioritized in terms of vulnerability patching [that relate back to each predetermined criterion for the asset information, secondary asset information, and additional asset information]. High severity vulnerabilities [involving the predetermined criteria/state variables] can be assigned higher weights in order for them to be prioritized.”),
wherein determining the risk profile is based on the analysis of the additional asset information (¶ [0165], “Taking into account all these aspects of the asset in computing the ranking value(s) allows for comprehensive and reliable prioritizing approach in handling detected vulnerabilities. The ranking engine 316 can compute [determine] the ranking value [risk profile] as a weighted sum of multiple parameter values [as an analysis] associated with the specification profiles [comprising additional asset information], the received vulnerability data, and the received profiling data.”).
Regarding the combination of Beard-Sharifi and Hamdi, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 2.
Regarding Claim 5
Beard-Hamdi-Sellers discloses the method of claim 1, and Beard further discloses
wherein the asset information comprises software bill of materials (SBOM) data (Fig. 3, ¶ [0027], “Each of the plurality of medical devices 310 may be configured to communicate a device specific SBOM [as asset information] 311 to at least one of the plurality of validator systems 340.”),
wherein the method further comprises analyzing, by the one or more hardware processors (¶ [0034], “The at least one update in the device specific SBOM may be validated [via analyzing using the validator system/hardware processors] based on a vulnerability database at 660.”),
the software bill of materials data based on at least one predetermined criterion of the plurality of predetermined criteria, wherein determining the risk profile is based on the analysis of the software bill of materials data (¶ [0022], “The validator instructions may be configured to cause the validator processor [device] to generate [determine] a SBOM score [as a risk profile]. The SBOM score may be based on the device specific SBOM [that is mapped to at least one predetermined criterion involving hashing] and the vulnerability [related to risks] database,” and ¶ [0030], “A SBOM hash tree may be built based on data in a SBOM blockchain. The SBOM hash tree may comprise a root hash with a known device specific SBOM. The SBOM hash tree may comprise at least one leaf node. Each of the at least one leaf node may comprise a distinct device specific SBOM,” i.e., each hash within the hash tree has a corresponding predetermined criterion of a plurality of predetermined criteria that is based on the analyzing and is involved in the validation that contributes to the SBOM score or risk profile).
Regarding Claim 6
Beard-Hamdi-Sellers discloses the method of claim 1, and Beard further discloses
further comprising:
receiving, by the one or more hardware processors, network information from at least one network device (Fig. 8, ¶ [0045], “By way of example, and not limitation, FIG. 8 illustrates remote application programs 885 [with such programs from a medical device manufacturer containing network information for establishing network connections via a LAN or WAN] as residing on remote [network] device 880. It will be appreciated that the network connections shown are presented as examples only and other means of establishing a communications link between the devices may be used;” and ¶ [0019], “According to an embodiment, a device specific SBOM may be distinct for a specific medical device type [with the SBOM possessing network information to map the SBOM to each medical device] when first powered up in an operational environment. Over time, the device specific SBOM may be updated for each distinct medical device in operation,” i.e., updates regarding a specific SBOM are communicated and thus received for analyzing via the communication device via the illustrated LAN or WAN network),
wherein the at least one network device is communicatively coupled with the computing asset over at least one communication network (Fig. 8, ¶ [0038], “FIG. 8 is a block diagram of a medical device in which aspects of the disclosure may be practiced. The medical device may comprise computing device 810;” ¶ [0027], “When used in a LAN networking environment, the computing device 810 [computing asset] is connected [communicatively coupled] to the LAN 871 [communication network] through a network interface or adapter 870 [as a network device]. When used in a WAN networking environment, the computing device 810 may comprise a modem 872 [as a network device] or other means for establishing communications over the WAN 873, such as the Internet.”),
wherein the network information is associated with the at least one communication network (Fig. 8, ¶ [0045], “When used in a LAN [communication] networking environment, the computing device 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computing device 810 may comprise a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which may be internal or external, may be connected to the system bus 881 via interface 860, or other appropriate mechanism. The modem 872 may be wired or wireless. Examples of wireless devices may comprise, but are not limited to: Wi-Fi and Bluetooth,” i.e., the use of LAN or WAN as a communication network is associated with the network information that correlates the each of the medical devices/computer assets with the SBOMs);
modifying, by the one or more hardware processors, the asset information based on the network information (¶ [0016], “The SBOM blockchain may be employed to validate updates to a device specific SBOM for each of a plurality of medical devices. In this disclosure, updates to device specific SBOM [that relies upon network information to correlate SBOMs with each medical device/computer asset that possesses asset information] are to include installation of additional software and/or hardware,” i.e., updates can include security patches that are based on the network information and consequently modify the asset information comprising at least the device specific SBOM);
generating, by the one or more hardware processors, modified asset information based on the modified asset information (¶ [0034], “The SBOM hash tree may comprise at least one leaf node each comprising a distinct device specific SBOM. The distinct device specific SBOM may be a combination of the known device specific SBOM and the updates in all of the parent nodes [that yields the hash tree as a generated modified asset information based on the update or modifying of the asset information].”); and
1 …,
wherein determining the risk profile is based on the analysis of the modified asset information and the secondary asset information (Beard ¶¶ [0016], [0022], [0030], Hamdi ¶¶ [0097], [0106]-[0107], [0135], i.e., the SBOM score/risk profile using the asset information and secondary asset information is recalculated/determined and based on modified asset information and secondary asset information using the predetermined criterion).
Hamdi further discloses
1 analyzing, by the one or more hardware processors, the modified asset information and the secondary asset information based on at least one predetermined criterion of the plurality of predetermined criteria (¶ [0135], “The criteria can include requirements or specifications defined in the specification profiles [asset information] associated with the target [computing] asset or the computing and network environment 210;” “Threshold values [predetermined criterion of the plurality of predetermined criteria] can include, for example, benchmark parameter values to determine whether an asset is under stress;” “For instance, for each asset of the computing and network environment 210, the CEMM system 220 (e.g., the controller engine 310) can define a respective set of criteria or threshold values for use in assessing the state(s) of operation of that asset. For example, the CEMM system 220 can define the [predetermined] criteria or threshold values for a given asset based on the specification profiles [asset information] associated with that asset;” and ¶¶ [0106]-[0107], “The ranking engine 316 can also use collected data (e.g., asset profiling data [asset information and the open source software as secondary asset information], vulnerability scanning data, and/or data from other sources such as databases 240, 250 or 260) to quantify or estimate [via analyzing] how critical the state(s) of operation of the asset is/are,” i.e., the asset information and secondary asset information are analyzed based on a threshold for “stress,” as a predetermined criterion, to assess the stress of the computing asset),
Regarding the combination of Beard and Hamdi, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 6.
Regarding Claim 9
Beard-Hamdi-Sellers discloses the method of claim 1, and Hamdi further discloses
further comprising:
receiving, by the one or more hardware processors, at least one risk weight value of the plurality of risk weight values corresponding to at least one predetermined criterion of the plurality of predetermined criteria from the user device (¶ [0164], “For example, an [computing] asset [with each computing asset with an associated risk weight value to create a plurality of risk weight values] with a high level of functional dependencies (e.g., a larger number of other assets depend on it for one or more of their functions or operations), can be perceived as an important asset that needs to be prioritized in terms of vulnerability patching [that relate back to each predetermined criterion for the asset information and secondary asset information]. High severity vulnerabilities [correlating back to the thresholds/predetermined criteria] can be assigned [via one user device] higher [risk] weights in order for them to be prioritized.”; and ¶ [0097], “For example, if an asset is experiencing stress or abnormal behavior, the [hardware processor of the] controller engine 310 [after receiving the risk weight of high stress] can increase the profiling frequency [as one of the predetermined criteria] of the asset to allow collecting profiling data every one or more milliseconds.”);
modifying, by the one or more hardware processors, the at least one predetermined criterion based on the at least one risk weight value (¶ [0164], “For example, an [computer] asset with a high level of functional dependencies [that are modified based on software updates within the computer assets] (e.g., a larger number of other assets depend on it for one or more of their functions or operations), can be perceived as an important asset that needs to be prioritized in terms of vulnerability patching [that relate back to each predetermined criterion for the asset information and secondary asset information]. High severity vulnerabilities [involving the predetermined criteria] can be assigned higher [risk] weights in order for them to be prioritized.”); and
analyzing, by the one or more hardware processors, the asset information and the secondary asset information based on the at least one modified criterion (¶ [0135], “The criteria can include requirements or specifications defined in the specification profiles [asset information] associated with the target [computing] asset or the computing and network environment 210;” “Threshold values [as one predetermined criterion] can include, for example, benchmark parameter values to determine whether an asset is under stress;” “For instance, for each asset of the computing and network environment 210, the CEMM system 220 (e.g., the controller engine 310) can define a respective set of criteria or threshold values for use in assessing the state(s) of operation of that asset. For example, the CEMM system 220 can define the [predetermined] criteria or threshold values for a given asset based on the specification profiles [asset information] associated with that asset;” and ¶¶ [0106]-[0107], “The ranking engine 316 can also use collected data (e.g., asset profiling data [asset information and secondary asset information], vulnerability scanning data, and/or data from other sources such as databases 240, 250 or 260) to quantify or estimate [via analyzing] how critical the state(s) of operation of the asset is/are,” i.e., the asset information and secondary asset information are analyzed based on a threshold for “stress,” as a predetermined criterion, to assess the stress of the computing asset, and the analysis is conducted based upon the “profiling frequency” as a modified criterion),
wherein determining the risk profile is based on the analysis of the asset information and the secondary asset information (Beard ¶¶ [0022], [0030], Hamdi ¶¶ [0097], [0106]-[0107], [0135], i.e., the SBOM score/risk profile using the asset information and secondary asset information is recalculated/determined at a higher frequency/modified criterion).
Regarding the combination of Beard and Hamdi, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 9.
Regarding Claim 10
Beard-Hamdi-Sellers discloses the method of claim 1, and Hamdi further discloses
further comprising:
analyzing, by the one or more hardware processors, the risk profile associated with the computing asset (¶¶ [0106]-[0107], [0135]) based on(¶ [0068], “The authority database(s) 260 can include databases and/or websites related to cyber security and associated with government institutions [that promulgate regulations] or organizations such as the Federal Bureau of Investigation (FBI), the Department of Homeland Security (DHS), European Network and Information Security Agency (ENISA), North Atlantic Treaty Organization (NATO), or the like,” i.e., the “authority databases” provide regulations that can be “indicative of the importance of that asset to the mission and operation” to produce rankings/risk profiles of the computing asset);
generating, by the one or more hardware processors, a risk management report associated with the computing asset (¶¶ [0111]-[0115], “Therefore, the Visual modes can provide [generate for] users [managers] with flexibility with regard to what data portion to display [of a report] and how. Such flexibility of visualizing data from different perspectives and at various granularities can help users navigate through and analyze large sets of data;” and “The color of each cell in grid 806 can represent the severity of the respective vulnerability [risk].”) based on the analysis of the risk profile based on the regulation data (¶ [0120], “The criteria can vary depending on the functional mode associated with a user (e.g., networking, vulnerability management, cyber security, compliance [of regulation data], etc.).”); and
transmitting, by the one or more hardware processors, the risk management report to the user device (¶ [0111], “The front-end system 224 can include a visualization engine 320 configured to handle display [via a user device] of asset data received [and thereby transmitted by] from the back-end system 222.”).
Regarding the combination of Beard and Hamdi, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 10.
Regarding Independent Claim 11 and Dependent Claims 12, 15-16, and 19-20
With respect to claims 11-12, 15-16, and 19-20 a corresponding reasoning as given earlier for claims 1-2, 5-6, and 9-10 applies, mutatis mutandis, to the subject matter of claims 11-12, 15-16, and 19-20. Therefore, claims 11-12, 15-16, and 19-20 are rejected, for similar reasons, under the grounds set forth for claims 1-2, 5-6, and 19-20.
B. Claims 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Beard in view of Hamdi and Sellers, and further in view of Mayer et al. (US 8,132,260, “Mayer”).
Regarding Claim 3
Beard-Hamdi-Sellers discloses the method of claim 1, and Beard further discloses:
wherein the method further comprising:
receiving, by the one or more hardware processors,…1 from each computing asset of a plurality of computing assets (Fig. 3, ¶ [0027], “Each of the plurality of medical devices 310 [plurality of computing assets] may be configured to communicate a device specific SBOM 311 to at least one of the plurality of validator systems 340 [possessing a hardware processor that communicates by receiving the SBOM/asset attributes.”);
2 …;
3 …; and
4 ….
Beard-Hamdi-Sellers doesn’t disclose
1 …, an asset attribute…
2 analyzing, by the one or more hardware processors, the asset attribute;
3 determining, by the one or more hardware processors, a priority rank associated with each computing asset based on the analysis of the asset attribute; and
4 identifying, by the one or more hardware processors, one or more actions associated with each computing asset based on the priority rank, wherein generating the risk notification associated with each computing asset is based on the one or more actions.
Mayer, however, discloses
1 …, an asset attribute… (Col. 3:21-48, “A device may also include a processor coupled to the memory, wherein the processor is configured to determine a security risk value associated with the first host location with respect to the vulnerability in response to the plurality of vulnerability [asset] attributes,…;” Col. 8:63-9:11, “In various embodiments, harm probability may be determined based upon the harm probability specified for these threats (e.g. parameters or attributes of the threats). These attributes can typically be determined from the library of vulnerabilities;” and Col. 6:15-23, “Next, configuration data from network infrastructure devices 210-230 is received by analysis server 290, step 310. In various embodiments, a library of threats (e.g. a threat reference library) is also referenced [to receive the attributes],” i.e., the vulnerability assessment of Mayer that is applied to servers is a known technique for assessing vulnerabilities that can be applied to medical devices)
2 analyzing, {by one or more hardware processors (Beard Fig. 3, ¶ [0027])}, the asset attribute (Col. 8:63-9:33, “In various embodiments, the vulnerability certainty value is also determined [via an analysis] in response to how vulnerable the host server is to a given vulnerability, given vulnerability [asset] attributes versus known configuration data of the host server.”);
3 determining, {by one or more hardware processors (Beard Fig. 3, ¶ [0027])}, a priority rank associated with each computing asset based on the analysis of the asset attribute (Col. 3:21-48, “wherein the processor is configured to determine a plurality of remediation actions in response to the vulnerability, wherein the plurality of remediation actions comprise a first remediation action and a second remediation action, wherein the processor is configured to determine an updated security risk value associated with the first host location [that can be repeated for other host locations] with respect to the vulnerability for each remediation action from the plurality of remediation actions, wherein the first remediation action is associated with a first updated security risk value, and wherein the second remediation action is associated with a second updated security risk value, and wherein the processor is configured to display a [determined] prioritized list of remediation actions from the plurality of remediation actions on a display, wherein the first remediation action is prioritized [within a priority rank] over the second remediation action when the first updated security risk value with respect to the security risk value shows a greater improvement in risk than the second updated security risk value with respect to the security risk value,” i.e., the priority rank discloses for hosts can be applied as a known technique for a plurality of computer assets);
4 identifying, {by one or more hardware processors (Beard Fig. 3, ¶ [0027])}, one or more actions associated with each computing asset based on the priority rank, wherein generating the risk notification associated with each computing asset is based on the more actions (Col. 3:21-48, “…wherein the plurality of remediation actions comprise a first remediation action and a second remediation action,… [that can be applied to associated computing assets in the same manner as applied to other computing assets, such as hosts]”).
Regarding the combination of Beard-Hamdi-Sellers and Mayer, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the risk management system of Beard-Sharifi-Hamdi to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C).
To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C):
1) the prior art contained a base system, namely the risk management system of Beard-Hamdi-Sellers, upon which the claimed invention can be seen as an “improvement” through the use of priority remediation feature of Mayer;
2) the prior art contained a “comparable” feature, namely the priority remediation feature of Mayer, that has been improved in the same way as the claimed invention through the priority remediation feature; and
3) one of ordinary skill in the art could have applied the known improvement technique of applying the priority remediation feature to the base risk management system of Beard-Hamdi-Sellers, and the results would have been predictable to one of ordinary skill in the art.
Regarding Claim 4
Beard-Hamdi-Sellers discloses the method of claim 1, and Beard further discloses
further comprising:
1 …;
2 …; and
3 ….
Beard-Hamdi-Sellers doesn’t disclose
1 determining, by the one or more hardware processors, an impact of at least one of a vulnerability and a remediation action associated with the computing asset based on the analysis;
2 generating, by the one or more hardware processors, an impact log based on the determining of the impact of at least one of the vulnerability and the remediation action, wherein the impact log comprises the impact associated with at least one of the vulnerability and the remediation action for each event of a plurality of events; and
3 transmitting, by the one or more hardware processors, the impact log to the user device.
Mayer, however, discloses
1 determining, {by the one or more hardware processors (Beard Fig. 3, ¶ [0027])}, an impact of at least one of a vulnerability and a remediation action associated with the computing asset based on the analyzing (Col. 3:21-48, “wherein the processor is configured to display a prioritized list of remediation actions [for the associated computing asset] from the plurality of remediation actions on a display, wherein the first remediation action is prioritized over the second remediation action when the first updated security risk value with respect to the security risk value shows a greater improvement [and therefore a determined impact] in risk [or vulnerability] than the second updated security risk value with respect to the security risk value.”);
2 generating, {by the one or more hardware processors (Beard Fig. 3, ¶ [0027])}, an impact log based on the determining of the impact of at least one of the vulnerability and the remediation action, wherein the impact log comprises the impact associated with at least one of the vulnerability and the remediation action for each event of a plurality of events (Col. 3:21-48, “wherein the plurality of remediation actions [for each associated event] comprise a first remediation action and a second remediation action, wherein the processor is configured to determine an updated security risk value associated with the first host location with respect to the vulnerability [associated with an impact] for each remediation action from the plurality of remediation actions, wherein the first remediation action is associated with a first updated security risk value [for an impact associated with the risk of an event], and wherein the second remediation action is associated with a second updated security risk value [for an impact associated with the risk of another event], and wherein the processor is configured to display a prioritized list [as an impact log] of remediation actions from the plurality of remediation actions on a display, wherein the first remediation action is prioritized over the second remediation action when the first updated security risk value with respect to the security risk value shows a greater improvement in risk than the second updated security risk value with respect to the security risk value.”); and
3 transmitting, {by the one or more hardware processors (Beard Fig. 3, ¶ [0027])}, the impact log to the user device (Col. 3:21-48, “…wherein the processor is configured to display [after its transmission to the display] a prioritized list of remediation actions [comprising the impact log] from the plurality of remediation actions on a display [of a user device],…”).
Regarding the combination of Beard-Hamdi-Sellers and Mayer, the rationale to combine is the same as provided for claim 3 due to the overlapping subject matter of claims 3 and 4.
Regarding Dependent Claims 13 and 14
With respect to claims 13 and 14, a corresponding reasoning as given earlier for claims 3 and 4 applies, mutatis mutandis, to the subject matter of claims 13 and 14. Therefore, claims 13 and 14 are rejected, for similar reasons, under the grounds set forth for claims 3 and 4.
C. Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Beard in view of Hamdi and Sellers, and further in view of Bunker et al. (US 2006/0075503, “Bunker”).
Regarding Claim 7
Beard-Hamdi-Sellers discloses the method of claim 1, and Beard further discloses
further comprising:
1 …; and
2 analyzing, by the one or more hardware processors, the asset information and the secondary asset information based on the at least one user-determined criterion,
wherein determining the risk profile is based on the analysis of the asset information and the secondary asset information (Beard ¶¶ [0022], [0030], Bunker ¶ [0078], and Hamdi ¶¶ [0106]-[0107], [0135], i.e., the SBOM score/risk profile using the asset information and secondary asset information is calculated/determined based upon the user defined time range/user-determined criterion).
Hamdi further discloses
2 analyzing, by the one or more hardware processors, the asset information and the secondary asset information based on the at least one user-determined criterion (¶ [0135], “The criteria can include requirements or specifications defined in the specification profiles [asset information] associated with the target [computing] asset or the computing and network environment 210;” “Threshold values [predetermined criterion] can include, for example, benchmark parameter values to determine whether an asset is under stress;” “For instance, for each asset of the computing and network environment 210, the CEMM system 220 (e.g., the controller engine 310) can define a respective set of criteria or threshold values for use in assessing the state(s) of operation of that asset. For example, the CEMM system 220 can define the [predetermined] criteria or threshold values for a given asset based on the specification profiles [asset information] associated with that asset;” and ¶¶ [0106]-[0107], “The ranking engine 316 can also use collected data (e.g., asset profiling data [asset information and secondary asset information], vulnerability scanning data, and/or data from other sources such as databases 240, 250 or 260) to quantify or estimate [via analyzing] how critical the state(s) of operation of the asset is/are,” i.e., the asset information and secondary asset information are analyzed based on a threshold for “stress,” as a predetermined criterion , to assess the stress of the computing asset),
Regarding the combination of Beard and Hamdi, the rationale to combine is the same as provided for claim 1 due to the overlapping subject matter of claims 1 and 7.
Beard-Hamdi-Sellers doesn’t disclose
1 receiving, by the one or more hardware processors, at least one user-determined criterion from the user device;
Bunker, however, discloses
1 receiving, by the one or more hardware processors, at least one user-determined criterion from the user device (¶ [0078], “The charts report 728 may additionally provide trending information related to vulnerabilities by risk, the system scan, user defined time range [as a user-defined criterion that was implemented in the report after receiving the criterion via the input of a user device] and user defined testing periods.”);
Regarding the combination of Beard-Hamdi-Sellers and Bunker, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the risk management system of Beard-Hamdi-Sellers to arrive at the claimed invention. KSR establishes that a rationale for obviousness is proven by showing a “use of [a] known technique to improve similar devices in the same way.” See MPEP § 2143(I)(C).
To substantiate the conclusion of obviousness under this KSR rationale, the Examiner finds pursuant to MPEP § 2143(I)(C):
1) the prior art contained a base system, namely the risk management system of Beard-Hamdi-Sellers, upon which the claimed invention can be seen as an “improvement” through the use of a user-defined criterion feature;
2) the prior art contained a similar system, namely the vulnerability management system of Bunker, that has been improved in the same way as the claimed invention through the user-defined criterion feature; and
3) one of ordinary skill in the art could have applied the known improvement technique of applying the user-defined criterion feature to the base risk management system of
Beard-Hamdi-Sellers, and the results would have been predictable to one of ordinary skill in the art.
Regarding Dependent Claim 17
With respect to claim 17, a corresponding reasoning as given earlier for claim 7 applies, mutatis mutandis, to the subject matter of claim 17. Therefore, claim 17 is rejected, for similar reasons, under the grounds set forth for claim 7.
D. Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Beard in view of Hamdi and Sellers, and further in view of Warner et al. (US 2019/0095587, “Warner”).
Regarding Claim 8
Beard-Hamdi-Sellers discloses the method of claim 1, and Beard further discloses
further comprising:
1 …;
modifying, by the one or more hardware processors, the asset information associated with the computing asset based on the at least one user data (¶ [0016], “The SBOM blockchain may be employed to validate updates to a device specific SBOM for each of a plurality of medical devices. In this disclosure, updates to device specific SBOM are to include installation of additional software and/or hardware,” i.e., updates can include open source programs selected by an administrator that are based on user data and consequently modify the asset information comprising at least the device specific SBOM); and
2 …,
wherein determining the risk profile is based on the analysis of the modified asset information and the secondary asset information (Beard ¶¶ [0016], [0022], [0030], Hamdi ¶¶ [0097], [0106]-[0107], [0135], i.e., the SBOM score/risk profile using the asset information and secondary asset information is recalculated/determined and based on modified asset information and secondary asset information using the predetermined criterion).
Hamdi further discloses
2 analyzing, by the one or more hardware processors, the modified asset information and the secondary asset information based on at least one predetermined criterion of the plurality of predetermined criteria (¶ [0135], “The criteria can include requirements or specifications defined in the specification profiles [asset information] associated with the target [computing] asset or the computing and network environment 210;” “Threshold values [predetermined criterion] can include, for example, benchmark parameter values to determine whether an asset is under stress;” “For instance, for each asset of the computing and network environment 210, the CEMM system 220 (e.g., the controller engine 310) can define a respective set of criteria or threshold values for use in assessing the state(s) of operation of that asset. For example, the CEMM system 220 can define the [predetermined] criteria or threshold values for a given asset based on the specification profiles [asset information] associated with that asset;” and ¶¶ [0106]-[0107], “The ranking engine 316 can also use collected data (e.g., asset profiling data [asset information and secondary asset information], vulnerability scanning data, and/or data from other sources such as databases 240, 250 or 260) to quantify or estimate [via analyzing] how critical the state(s) of operation of the asset is/are,” i.e., the asset information and secondary asset information are analyzed based on a threshold for “stress,” as a predetermined criterion of the plurality of predetermined criteria, to assess the stress of the computing asset),
Beard-Hamdi-Sellers doesn’t disclose
1 receiving, by the one or more hardware processors, at least one user data associated with the computing asset from the user device;
Warner, however, discloses
1 receiving, by the one or more hardware processors, at least one user data associated with the computing asset from the user device (¶ [0027], “The original medical device 14 is developed with a permitted “software catalog” in database 28 that stores and/or records all permitted safe third party software packages, e.g., not operating system software patches, installed and/or approved by the device manufacturer for use on the device 14. The certification system 30 enables the consumer/customer of the medical device 14 to perform on site testing that can modify the [user] approved software catalog for the device 14 to self-certify new software packages [as user data] and/or upgrades for use with the device [computing asset] 14.”);
Regarding the combination of Beard-Hamdi-Sellers and Warner, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the risk management system of Beard-Hamdi-Sellers to have included the software installation feature of Warner. One of ordinary skill in the art would have been motivated to incorporate the software installation feature of Warner because Warner teaches, “develop a system and method for streamlining the certification of third party software products for safe and effective use on a medical device or product without intervention by the device manufacturer,” which beneficially increases the versatility of medical devices.
Regarding Dependent Claim 18
With respect to claim 18, a corresponding reasoning as given earlier for claim 8 applies, mutatis mutandis, to the subject matter of claim 18. Therefore, claim 18 is rejected, for similar reasons, under the grounds set forth for claim 8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to D'ARCY WINSTON STRAUB whose telephone number is (303)297-4405. The examiner can normally be reached Monday-Friday 9:00-5:00 Mountain Time. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, WILLIAM KORZUCH can be reached at (571)272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/D'Arcy Winston Straub/Primary Examiner, Art Unit 2491