Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
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 factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beard (US 11,150,888) in view of Karve (US 11,200,048), further in view of Allen (US 2023/0195901 A1) and Jadhav (US 2023/0244791).
Regarding Claim 1, Beard (US 11,150,888) teaches
A method for operating a telemetry interception and analysis platform (TIAP) system, comprising:
generating, on a server comprising a database and a processor, a software build of materials (SBOM) used by an application being executed on a customer computer system, the SBOM comprising a plurality of SBOM components (Col 4: ln 17-57, The SBOM hash tree may be based on data in the SBOM blockchain. The SBOM hash tree may comprise a root node with an original SBOM. The original SBOM may be based on a specific medical device type. The original SBOM may be provided with the medical device by a medical device manufacturer. The original SBOM may be the first SBOM generated once a specific medical device is put into operation… The SBOM hash tree may comprise at least one leaf node. Each of the at least one leaf node may comprise a distinct SBOM update. The distinct SBOM update may comprise at least one update in a device specific SBOM) Examiner Comments: This maps to generating an SBOM on a server, as Beard’s system generates SBOMs for devices (analogous to applications on customer systems) listing software components, with the server handling validation and storage in a database and blockchain;
executing, on the server, a TIAP portal comprising a common vulnerabilities and exposures (CVE) service operative to receive CVEs from at least one CVE source (Col 5: ln 1-31, The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM based on a vulnerability database. The new block may comprise device specific SBOM changes communicated from at least one medical device. The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM in response to the device specific SBOM not being completely contained in the SBOM hash tree) Examiner Comments: This maps to executing a portal or service on the server to receive vulnerability data, as Beard’s validator systems access a vulnerability database (analogous to a CVE source) for validation;
receiving, at the TIAP portal, a plurality of vulnerabilities from the at least one CVE source (Col 6: ln 34-67, Each of the plurality of validator systems 340 may be configured to communicate validation messages 351 to the at least one vulnerability database 350… The at least one vulnerability database 350 may be configured to communicate validation messages 351 to at least one of the plurality of validator systems 340) Examiner Comments: This maps to receiving a plurality of vulnerabilities, as the system receives multiple validation messages relating to vulnerabilities from the vulnerability database;
determining, at the TIAP portal, that the SBOM comprises a SBOM component of the plurality of SBOM components that is associated with a vulnerability of the plurality of vulnerabilities (Col 4: ln 17-57, The validator instructions may be configured to cause the validator processor to create a local copy of a SBOM blockchain. The local copy may be based on blocks communicated from other validator systems) Examiner Comments: This maps to determining that the SBOM contains a component associated with a vulnerability, as Beard searches and validates SBOM components against the vulnerability database to identify components associated with vulnerabilities.
Beard did not specifically teach
after determining that the SBOM comprises the SBOM component that is associated with the vulnerability, determining, by the TIAP portal, a version of the SBOM component;
determining, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability;
preventing, at the TIAP portal, the SBOM component from being used in an application build for the application when the vulnerability associated with that SBOM component exceeds a threshold and the fixed version does not exist; and
a common vulnerabilities and exposures (CVE).
However, Karve (US 11,200,048) teaches
preventing, at the TIAP portal, the SBOM component from being used in an application build for the application when the vulnerability associated with that SBOM component exceeds a threshold (Col 2: ln 15-38, The program code combines a selection of the identified non-native program instructions and subjects the combined selection to a risk evaluation by the one or more non-native tools. A result from the risk evaluation is received and the program code maps the received result to one or more corresponding lines the source code. The program code assigns a risk identifier to the corresponding one or more lines of the source code. The program code further selectively applies one or more modifications to the codified infrastructure in correspondence with the assigned risk identifier. The applied modification mitigates any defects in the source code) Examiner Comments: This maps to preventing use of the component in the build when the vulnerability exceeds a threshold, as Karve evaluates risk of code components, assigns a risk identifier corresponding to severity, and selectively applies modifications that block the defective code from proceeding through the pipeline.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Karve’s in order to integrate risk evaluation into the SBOM-driven build workflow so that defects are mitigated and deployment of vulnerable code is prevented, thereby enabling the risk evaluation and modification of program instructions in the computer system in an effective manner (Karve, Col 2: ln 15-38).
Beard and Karve did not specifically teach
after determining that the SBOM comprises the SBOM component that is associated with the vulnerability, determining, by the TIAP portal, a version of the SBOM component;
determining, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability;
and the fixed version does not exist; and
a common vulnerabilities and exposures (CVE).
However, Allen (US 2023/0195901 A1) teaches
after determining that the SBOM comprises the SBOM component that is associated with the vulnerability, determining, by the TIAP portal, a version of the SBOM component ( [0033] In Step 204, vulnerable components are identified using the application dependency specifications and a list of known vulnerable components… [0035] 2) identifying components corresponding to nodes of the dependency graph whose <component ID, version ID> labels are included in the list of known vulnerable components… [0042] In Step 206, candidate dependency specifications are selected for a vulnerable component. The candidate dependency specifications are upgrade targets and may be processed separately. The candidate dependency specifications may each specify a version ID for a component. The upgrade manager may select a candidate dependency specification that sets the version ID of the vulnerable component) Examiner Comments: This maps to determining the version of the SBOM component only after the component has been determined to be associated with the vulnerability, because Allen expressly orders the operations into Step 204, in which a component is first identified as vulnerable, followed by Step 206, in which the version ID of that already identified vulnerable component is then determined from the candidate dependency specification that sets it;
determining, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability ( [0045] In Step 208, an upgraded version ID for a component is selected for a candidate dependency specification. The upgrade manager may select an upgraded version ID for the candidate dependency specification that removes the dependency of the application on the vulnerable component… [0047] If the candidate dependency specification directly sets the version ID of the vulnerable component, then the upgrade manager may select the first subsequent version ID that is clean (i.e., the first subsequent version ID that is not included in the known vulnerable components list)… [0050] The upgrade manager may generate and process candidate version dependency graphs until an upgraded version ID is found that removes the dependency on the vulnerable component. If no such version ID is found, then the earliest version ID with the fewest number of dependencies on vulnerable components may be selected) Examiner Comments: This maps to determining whether a fixed version of the component exists to remediate the vulnerability, because Allen searches the series of subsequent version IDs of the already identified vulnerable component for a clean version that removes the vulnerability, and expressly resolves the two outcomes of that determination through the branch beginning if no such version ID is found;
and the fixed version does not exist ( [0050] … If no such version ID is found, then the earliest version ID with the fewest number of dependencies on vulnerable components may be selected… [0055] If the upgrade manager is unable to remove one or more dependencies on vulnerable components, the upgrade manager may: [0056] 1) issue an alert indicating that the application includes one or more dependencies on vulnerable components. The alert may include the candidate dependency specification and the component ID and version ID of each vulnerable component) Examiner Comments: This maps to the conditional requirement that the fixed version does not exist, because Allen expressly conditions its blocking and alerting output on the absence of any clean version ID capable of removing the vulnerable component, which is the same condition recited in the claim.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s and Karve’s teachings with Allen’s in order to resolve the version of a component only after that component has been confirmed to be vulnerable, and to then determine whether a clean subsequent version exists that removes the vulnerability, because performing the version lookup on the reduced set of already identified vulnerable components avoids the wasted processing of resolving versions for components that are not implicated, and because determining whether a remediating version exists before blocking the build ensures that a build is stopped only when no remediation path is available (Allen, [0047], [0050], [0055]).
Beard, Karve, and Allen did not specifically teach
a common vulnerabilities and exposures (CVE).
However, Jadhav (US 2023/0244791) teaches
a common vulnerabilities and exposures (CVE) ([0062], In a further embodiment, once the CBOM has been updated and/or modified to conform to the desired CPE, the system may map the CPE(s) to Common Vulnerabilities and Exposures (CVEs)) Examiner Comments: This maps to the recited CVE, as Jadhav expressly maps bill of materials component identifiers to Common Vulnerabilities and Exposures (CVEs).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s, Karve’s, and Allen’s teachings with Jadhav’s in order to streamline and automate the process of generating a proper cybersecurity bill of materials for a device and to assist regulators, users, and manufacturers with verifying and effectively managing critical components of the devices by using the standardized CVE identifier (Jadhav, [0062]).
Regarding Claim 2, Beard, Karve, Allen, and Jadhav teach
The method of Claim 1.
Beard did not specifically teach
displaying, at the TIAP portal, a message indicating that the application build contains a vulnerable component.
However, Karve teaches
displaying, at the TIAP portal, a message indicating that the application build contains a vulnerable component (Col 7: ln 24-55, The risk manager (154) combines the identified non-native program instructions into snippets, subjects the snippets to a risk evaluation by the identified one or more non-native instruction tool(s), and assigns a risk identifier to the evaluated non-native program instructions) Examiner Comments: This maps to displaying a message indicating a vulnerable component, as Karve assigns and surfaces risk identifiers for the evaluated code so that the vulnerable condition of the build is reported to the user.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Karve’s in order to integrate risk evaluation into the SBOM-driven build workflow so that defects are mitigated and deployment of vulnerable code is prevented, thereby enabling the risk evaluation and modification of program instructions in the computer system in an effective manner (Karve, Col 2: ln 15-38).
Regarding Claim 3, Beard, Karve, Allen, and Jadhav teach
The method of Claim 1.
Beard did not specifically teach
wherein the threshold is set by an alert policy.
However, Karve teaches
wherein the threshold is set by an alert policy (Col 8: ln 1-23, The modifier (156) further functions to integrate the assigned severity and confidence as feedback (168 A)-(168 N) within the CI/CD pipeline for further learning by the ML models (164 A)-(164 N), respectively. The confidence identifier is an indication of the accuracy of the severity level assigned by the ML model) Examiner Comments: This maps to a threshold set by an alert policy, as Karve’s assigned severity and confidence levels constitute the configured policy that governs when the pipeline alerts and acts on a risk.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Karve’s in order to integrate risk evaluation into the SBOM-driven build workflow so that defects are mitigated and deployment of vulnerable code is prevented, thereby enabling the risk evaluation and modification of program instructions in the computer system in an effective manner (Karve, Col 2: ln 15-38).
Regarding Claim 4, Beard, Karve, Allen, and Jadhav teach
The method of Claim 1.
Beard further teaches
wherein the SBOM is generated, on the server, by analyzing content of a container or environment wherein the application is being executed (Col 4: ln 17-57, The SBOM hash tree may be based on data in the SBOM blockchain… The SBOM hash tree may comprise at least one leaf node. Each of the at least one leaf node may comprise a distinct SBOM update. The distinct SBOM update may comprise at least one update in a device specific SBOM) Examiner Comments: This maps to generating the SBOM by analyzing the container or environment in which the application executes, as Beard derives the device specific SBOM from the software actually installed in the device execution environment.
Claim(s) 5, 7-8, 10-13, 15-16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beard (US 11,150,888) in view of Araya (US 2016/0224461), further in view of Allen (US 2023/0195901 A1) and Jadhav (US 2023/0244791).
Regarding Claim 5, Beard teaches
A method for operating a telemetry interception and analysis platform (TIAP) system, comprising:
generating, on a server comprising a database and a processor, a software build of materials (SBOM) used by an application being executed on a customer computer system, the SBOM comprising a plurality of SBOM components (Col 4: ln 17-57, The SBOM hash tree may be based on data in the SBOM blockchain… Each of the at least one leaf node may comprise a distinct SBOM update. The distinct SBOM update may comprise at least one update in a device specific SBOM… a device specific SBOM may be equivalent to a combination of the original SBOM and all of the distinct SBOM updates in all of the parent leaf nodes) Examiner Comments: This maps to generating an SBOM on a server, as Beard’s system generates and maintains SBOMs listing multiple components for applications executing on customer systems;
executing, on the server, a TIAP portal comprising a common vulnerabilities and exposures (CVE) service operative to receive CVEs from at least one CVE source (Col 5: ln 1-31, The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM based on a vulnerability database) Examiner Comments: This maps to executing a portal or service on the server to receive vulnerability data, as Beard’s validator systems access a vulnerability database for validation;
receiving, at the TIAP portal, a plurality of vulnerabilities from the at least one CVE source (Col 6: ln 34-67, The at least one vulnerability database 350 may be configured to communicate validation messages 351 to at least one of the plurality of validator systems 340) Examiner Comments: This maps to receiving a plurality of vulnerabilities, as the system receives validation messages relating to multiple vulnerabilities from the vulnerability database;
identifying, at the TIAP portal, an SBOM component of the plurality of SBOM components that is associated with a vulnerability of the plurality of vulnerabilities (Col 4: ln 17-57, The validator instructions may be configured to cause the validator processor to create a local copy of a SBOM blockchain. The local copy may be based on blocks communicated from other validator systems) Examiner Comments: This maps to identifying a vulnerable SBOM component, as Beard validates SBOM components against the vulnerability database to associate a component with a vulnerability.
Beard did not specifically teach
executing, on the server, the TIAP portal comprising an event service operative to receive telemetry events and usage events from a TIAP runtime being executed on the customer computer system in conjunction with the application being executed on the customer computer system;
after identifying the SBOM component that is associated with the vulnerability, determining, by the TIAP portal, a version of the SBOM component;
determining, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability;
determining, at the TIAP portal, whether the SBOM component was used by the application when said application was being executed on the customer computer system;
if the SBOM component is not used by the application, enabling a build of the application to proceed; and
a common vulnerabilities and exposures (CVE).
However, Araya (US 2016/0224461) teaches
executing, on the server, the TIAP portal comprising an event service operative to receive telemetry events and usage events from a TIAP runtime being executed on the customer computer system in conjunction with the application being executed on the customer computer system ([0071]-[0072], The following discussion describes specific analysis scenarios using Injected Instrumentation Application Monitoring and Management techniques. Specifically, application of those techniques to performance, application health, security and usability scenarios are described… an instrumentation point may record information at the start and the end of the execution of the portion of the computer application under test… For asynchronous execution of a computer application, the instrumentation point writes two separate messages that are later correlated with each other) Examiner Comments: This maps to an event service that receives telemetry events and usage events from a runtime, as Araya’s injected instrumentation collects execution events from the application on the customer system and reports them to a monitoring component;
determining, at the TIAP portal, whether the SBOM component was used by the application when said application was being executed on the customer computer system ([0071]-[0072], as cited above) Examiner Comments: This maps to determining whether the component was used during execution, as Araya’s instrumentation records the start and end of execution of each portion of the application under test, thereby establishing which portions were actually invoked;
if the SBOM component is not used by the application, enabling a build of the application to proceed ([0093]-[0115], In addition to overall health, the health monitoring may also include detecting unexpected errors in the computer application under test by capturing unexpected exceptions at each service and/or the application client… Security monitoring involves the detection of unauthorized access and attacks on a computer application under test… Such attacks may be eliminated by proactively injecting the appropriate filters into the generated target application in order to block such input being submitted to the SQL database) Examiner Comments: This maps to allowing the build to proceed when the component is not used, as Araya triggers its blocking and filtering actions only against code paths that are actually exercised, leaving unexercised paths to proceed without intervention.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Araya’s in order to enhance SBOM validation with runtime usage telemetry that confirms whether a vulnerable component is actually exercised, thereby producing a more accurate risk assessment and avoiding unnecessary blocking of builds whose vulnerable components are never invoked (Araya, [0071]-[0072]).
Beard and Araya did not specifically teach
after identifying the SBOM component that is associated with the vulnerability, determining, by the TIAP portal, a version of the SBOM component;
determining, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability; and
a common vulnerabilities and exposures (CVE).
However, Allen (US 2023/0195901 A1) teaches
after identifying the SBOM component that is associated with the vulnerability, determining, by the TIAP portal, a version of the SBOM component ( [0033] In Step 204, vulnerable components are identified using the application dependency specifications and a list of known vulnerable components… [0035] 2) identifying components corresponding to nodes of the dependency graph whose <component ID, version ID> labels are included in the list of known vulnerable components… [0042] In Step 206, candidate dependency specifications are selected for a vulnerable component. The candidate dependency specifications are upgrade targets and may be processed separately. The candidate dependency specifications may each specify a version ID for a component. The upgrade manager may select a candidate dependency specification that sets the version ID of the vulnerable component) Examiner Comments: This maps to determining the version of the SBOM component after that component has been identified as associated with the vulnerability, because Allen performs the vulnerable component identification in Step 204 and only then, in Step 206, resolves the version ID of that already identified vulnerable component;
determining, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability ( [0045] In Step 208, an upgraded version ID for a component is selected for a candidate dependency specification. The upgrade manager may select an upgraded version ID for the candidate dependency specification that removes the dependency of the application on the vulnerable component… [0047] If the candidate dependency specification directly sets the version ID of the vulnerable component, then the upgrade manager may select the first subsequent version ID that is clean (i.e., the first subsequent version ID that is not included in the known vulnerable components list)… [0050] The upgrade manager may generate and process candidate version dependency graphs until an upgraded version ID is found that removes the dependency on the vulnerable component. If no such version ID is found, then the earliest version ID with the fewest number of dependencies on vulnerable components may be selected) Examiner Comments: This maps to determining whether a fixed version exists to remediate the vulnerability, because Allen evaluates the subsequent version IDs of the vulnerable component for a clean version that removes the vulnerability and expressly accounts for the case in which no such version is found.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s and Araya’s teachings with Allen’s in order to resolve component versions only for components already confirmed to be vulnerable and to then determine whether a remediating version is available, thereby reducing the version resolution workload to the affected components and supplying actionable remediation guidance before a build decision is made (Allen, [0047], [0050]).
Beard, Araya, and Allen did not specifically teach
a common vulnerabilities and exposures (CVE).
However, Jadhav (US 2023/0244791) teaches
a common vulnerabilities and exposures (CVE) ([0062], In a further embodiment, once the CBOM has been updated and/or modified to conform to the desired CPE, the system may map the CPE(s) to Common Vulnerabilities and Exposures (CVEs)) Examiner Comments: This maps to the recited CVE, as Jadhav expressly maps bill of materials component identifiers to Common Vulnerabilities and Exposures (CVEs).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s, Araya’s, and Allen’s teachings with Jadhav’s in order to streamline and automate the process of generating a proper cybersecurity bill of materials for a device and to assist regulators, users, and manufacturers with verifying and effectively managing critical components of the devices by using the standardized CVE identifier (Jadhav, [0062]).
Regarding Claim 7, Beard, Araya, Allen, and Jadhav teach
The method of Claim 5.
Beard did not specifically teach
receiving, at the TIAP portal, the telemetry events from the TIAP runtime; and evaluating, at the TIAP portal, the telemetry events to qualify if presence of a vulnerable dependency is sufficient to abort the build of the application.
However, Araya teaches
receiving, at the TIAP portal, the telemetry events from the TIAP runtime; and evaluating, at the TIAP portal, the telemetry events to qualify if presence of a vulnerable dependency is sufficient to abort the build of the application ([0093]-[0115], In addition to overall health, the health monitoring may also include detecting unexpected errors in the computer application under test by capturing unexpected exceptions at each service and/or the application client… Upon aggregating a statistically significant amount of data, predictive models may be generated from the data… Security monitoring involves the detection of unauthorized access and attacks on a computer application under test) Examiner Comments: This maps to receiving and evaluating telemetry to qualify a vulnerable dependency, as Araya aggregates the collected event data and evaluates it against predictive models to determine whether the detected condition warrants a responsive action.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Araya’s in order to enhance SBOM validation with runtime usage telemetry that confirms whether a vulnerable component is actually exercised, thereby producing a more accurate risk assessment and avoiding unnecessary blocking of builds whose vulnerable components are never invoked (Araya, [0071]-[0072]).
Regarding Claim 8, Beard, Araya, Allen, and Jadhav teach
The method of Claim 5.
Beard did not specifically teach
receiving, at the TIAP portal, the telemetry events from the TIAP runtime; evaluating, at the TIAP portal, the telemetry events to obtain dynamic dependencies of components used by the application during execution on the customer computer system; and supplementing the SBOM with components associated with the dynamic dependencies to generate a supplemented SBOM.
However, Araya teaches
receiving, at the TIAP portal, the telemetry events from the TIAP runtime; evaluating, at the TIAP portal, the telemetry events to obtain dynamic dependencies of components used by the application during execution on the customer computer system; and supplementing the SBOM with components associated with the dynamic dependencies to generate a supplemented SBOM ([0093]-[0115], as cited above in Claim 7) Examiner Comments: This maps to obtaining dynamic dependencies and supplementing the SBOM, as Araya collects instrumentation data across all layers of the running application to identify the components actually exercised and augments the resulting inventory with that runtime data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Araya’s in order to enhance SBOM validation with runtime usage telemetry that confirms whether a vulnerable component is actually exercised, thereby producing a more accurate risk assessment and avoiding unnecessary blocking of builds whose vulnerable components are never invoked (Araya, [0071]-[0072]).
Regarding Claim 10, Beard, Araya, Allen, and Jadhav teach
The method of Claim 8.
Beard further teaches
implementing, at the TIAP portal, an abort decision based on the SBOM or on the supplemented SBOM (Col 4: ln 58-67, The validator instructions may be configured to cause the validator processor to add a new block to the SBOM blockchain in response to the device specific SBOM not being contained in the SBOM hash tree) Examiner Comments: This maps to implementing an abort decision based on the SBOM, as Beard conditions whether the SBOM update is accepted or rejected on the outcome of validating the generated or supplemented SBOM.
Regarding Claim 11, Beard, Araya, Allen, and Jadhav teach
The method of Claim 5.
Beard further teaches
comparing, at the TIAP portal, a first SBOM associated with a first build of the application with a second SBOM associated with a second build of the application; identifying, in response to comparing the first SBOM associated with the first build of the application with the second SBOM associated with the second build of the application, a vulnerability; and generating, at the TIAP portal, a visual representation of the vulnerability, wherein the visual representation shows which of the first build or the second build introduced the vulnerability (Col 4: ln 17-57, The validator instructions may be configured to cause the validator processor to create a local copy of a SBOM blockchain. The local copy may be based on blocks communicated from other validator systems. The validator instructions may be configured to cause the validator processor to build a SBOM hash tree. The SBOM hash tree may be based on data in the SBOM blockchain. The SBOM hash tree may comprise a root node with an original SBOM) Examiner Comments: This maps to comparing successive SBOMs and representing which build introduced the vulnerability, as Beard’s hash tree structure compares each SBOM update against the prior state and the resulting node topology renders which update introduced each change.
Regarding Claim 12, Beard, Araya, Allen, and Jadhav teach
The method of Claim 5.
Beard further teaches
performing, at the TIAP portal, vendor or package verification of each of the SBOM components included in the SBOM to enforce use of trusted sources (Col 4: ln 17-57, The SBOM hash tree may comprise a root node with an original SBOM. The original SBOM may be based on a specific medical device type. The original SBOM may be provided with the medical device by a medical device manufacturer… Each of the at least one leaf node may comprise a distinct SBOM update) Examiner Comments: This maps to vendor or package verification enforcing trusted sources, as Beard anchors validation to the original SBOM supplied by the device manufacturer and verifies each subsequent component update against that trusted baseline.
Regarding Claim 13, Beard teaches
A telemetry interception and analysis platform (TIAP) system, comprising:
a server comprising a database and a processor to run a TIAP portal comprising an event service operative to receive telemetry events from a TIAP runtime being executed on a customer computer system in conjunction with an application being executed on the customer computer system (Col 5: ln 1-27, The new block may comprise device specific SBOM changes communicated from at least one medical device. The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM in response to the device specific SBOM not being completely contained in the SBOM hash tree) Examiner Comments: This maps to a server running a portal with an event service, as Beard’s validator server receives and processes device specific event data reported from the customer device;
wherein the TIAP portal comprises a common vulnerability and exposure (CVE) service operative to receive a plurality of CVEs, wherein the plurality of CVEs are stored in the database (Col 5: ln 1-31, The validator instructions may be configured to cause the validator processor to validate at least one update in the device specific SBOM based on a vulnerability database) Examiner Comments: This maps to a CVE service that receives and stores a plurality of CVEs, as Beard’s validator draws vulnerability records from a vulnerability database that stores multiple vulnerabilities;
wherein the TIAP portal comprises a software build of materials (SBOM) service to: generate a SBOM used by the application being executed on the customer computer system, the SBOM comprising a plurality of SBOM components (Col 4: ln 17-57, The SBOM hash tree may be based on data in the SBOM blockchain… Each of the at least one leaf node may comprise a distinct SBOM update. The distinct SBOM update may comprise at least one update in a device specific SBOM) Examiner Comments: This maps to an SBOM service that generates an SBOM having multiple components, as Beard’s system generates and maintains device specific SBOMs listing plural components;
identify an SBOM component of the plurality of SBOM components that is associated with a vulnerability (Col 4: ln 17-57, The validator instructions may be configured to cause the validator processor to create a local copy of a SBOM blockchain. The local copy may be based on blocks communicated from other validator systems) Examiner Comments: This maps to identifying a vulnerable SBOM component, as Beard validates SBOM components against the vulnerability database to associate a component with a vulnerability.
Beard did not specifically teach
after identifying the SBOM component of the plurality of SBOM components that is associated with the vulnerability, determine, by the TIAP portal, a version of the SBOM component;
determine, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability;
determine whether the SBOM component was used by the application when the application was being executed on the customer computer system;
if the SBOM component is not used by the application, enable a build of the application to proceed; and
a common vulnerabilities and exposures (CVE).
However, Araya teaches
determine whether the SBOM component was used by the application when the application was being executed on the customer computer system ([0071]-[0072], an instrumentation point may record information at the start and the end of the execution of the portion of the computer application under test… the instrumentation may be used to inject the appropriate tracking information into the remote messages. Since the migration tool generates all layers of a target computing architecture (e.g. both clients and servers) correlation is possible) Examiner Comments: This maps to determining whether the component was used during execution, as Araya’s instrumentation records and correlates execution of each portion of the application on the customer system;
if the SBOM component is not used by the application, enable a build of the application to proceed ([0093]-[0115], In addition to overall health, the health monitoring may also include detecting unexpected errors in the computer application under test by capturing unexpected exceptions at each service… Security monitoring involves the detection of unauthorized access and attacks on a computer application under test) Examiner Comments: This maps to allowing the build to proceed when the component is not used, as Araya restricts its protective interventions to code paths actually exercised, so unexercised components do not trigger a stop.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s teaching with Araya’s in order to enhance SBOM validation with runtime usage telemetry that confirms whether a vulnerable component is actually exercised, thereby producing a more accurate risk assessment and avoiding unnecessary blocking of builds whose vulnerable components are never invoked (Araya, [0071]-[0072]).
Beard and Araya did not specifically teach
after identifying the SBOM component of the plurality of SBOM components that is associated with the vulnerability, determine, by the TIAP portal, a version of the SBOM component;
determine, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability; and
a common vulnerabilities and exposures (CVE).
However, Allen (US 2023/0195901 A1) teaches
after identifying the SBOM component of the plurality of SBOM components that is associated with the vulnerability, determine, by the TIAP portal, a version of the SBOM component ([0033] In Step 204, vulnerable components are identified using the application dependency specifications and a list of known vulnerable components… [0035] 2) identifying components corresponding to nodes of the dependency graph whose <component ID, version ID> labels are included in the list of known vulnerable components… [0042] In Step 206, candidate dependency specifications are selected for a vulnerable component… The upgrade manager may select a candidate dependency specification that sets the version ID of the vulnerable component) Examiner Comments: This maps to determining the version of the SBOM component after it has been identified as vulnerable, because Allen sequences the vulnerable component identification of Step 204 ahead of the version resolution of Step 206;
determine, by the TIAP portal, whether a fixed version of the SBOM component exists to remediate the SBOM component of the vulnerability ([0045] In Step 208, an upgraded version ID for a component is selected for a candidate dependency specification. The upgrade manager may select an upgraded version ID for the candidate dependency specification that removes the dependency of the application on the vulnerable component… [0047] … the upgrade manager may select the first subsequent version ID that is clean (i.e., the first subsequent version ID that is not included in the known vulnerable components list)… [0050] The upgrade manager may generate and process candidate version dependency graphs until an upgraded version ID is found that removes the dependency on the vulnerable component. If no such version ID is found, then the earliest version ID with the fewest number of dependencies on vulnerable components may be selected) Examiner Comments: This maps to determining whether a fixed version exists to remediate the vulnerability, because Allen searches for a clean subsequent version of the vulnerable component and expressly resolves the case in which no such version is found.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s and Araya’s teachings with Allen’s in order to resolve component versions only for components already confirmed to be vulnerable and to then determine whether a remediating version is available, thereby reducing the version resolution workload to the affected components and supplying actionable remediation guidance before a build decision is made (Allen, [0047], [0050]).
Beard, Araya, and Allen did not specifically teach
a common vulnerabilities and exposures (CVE).
However, Jadhav (US 2023/0244791) teaches
a common vulnerabilities and exposures (CVE) ([0062], In a further embodiment, once the CBOM has been updated and/or modified to conform to the desired CPE, the system may map the CPE(s) to Common Vulnerabilities and Exposures (CVEs)) Examiner Comments: This maps to the recited CVE, as Jadhav expressly maps bill of materials component identifiers to Common Vulnerabilities and Exposures (CVEs).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s, Araya’s, and Allen’s teachings with Jadhav’s in order to streamline and automate the process of generating a proper cybersecurity bill of materials for a device and to assist regulators, users, and manufacturers with verifying and effectively managing critical components of the devices by using the standardized CVE identifier (Jadhav, [0062]).
Regarding Claim 15, is a system claim corresponding to the method claim above (Claim 7) and, therefore, is rejected for the same reasons set forth in the rejection of claim 7.
Regarding Claim 16, is a system claim corresponding to the method claim above (Claim 8) and, therefore, is rejected for the same reasons set forth in the rejection of claim 8.
Regarding Claim 18, is a system claim corresponding to the method claim above (Claim 10) and, therefore, is rejected for the same reasons set forth in the rejection of claim 10.
Regarding Claim 19, is a system claim corresponding to the method claim above (Claim 11) and, therefore, is rejected for the same reasons set forth in the rejection of claim 11.
Regarding Claim 20, is a system claim corresponding to the method claim above (Claim 12) and, therefore, is rejected for the same reasons set forth in the rejection of claim 12.
Claim(s) 6, 9, 14, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Beard (US 11,150,888) in view of Araya (US 2016/0224461), in view of Allen (US 2023/0195901 A1) and Jadhav (US 2023/0244791), further in view of Karve (US 11,200,048).
Regarding Claim 6, Beard, Araya, Allen, and Jadhav teach
The method of Claim 5.
Beard, Araya, Allen, and Jadhav did not specifically teach
if the SBOM component is used by the application, aborting the build of the application.
However, Karve teaches
if the SBOM component is used by the application, aborting the build of the application (Col 2: ln 15-38, The program code combines a selection of the identified non-native program instructions and subjects the combined selection to a risk evaluation by the one or more non-native tools… The program code further selectively applies one or more modifications to the codified infrastructure in correspondence with the assigned risk identifier. The applied modification mitigates any defects in the source code) Examiner Comments: This maps to aborting the build when the component is used, as Karve intervenes in the pipeline against the identified defective instructions so that the original build containing them does not proceed unchanged.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s, Araya’s, Allen’s, and Jadhav’s teachings with Karve’s in order to integrate risk evaluation into the build workflow so that a build carrying a vulnerable component that is actually exercised is stopped, thereby improving security by preventing deployment of vulnerable code (Karve, Col 2: ln 15-38).
Regarding Claim 9, Beard, Araya, Allen, and Jadhav teach
The method of Claim 8.
Beard, Araya, Allen, and Jadhav did not specifically teach
using, at the TIAP portal, a list of the dynamic dependencies to assess whether to abort the build of the application.
However, Karve teaches
using, at the TIAP portal, a list of the dynamic dependencies to assess whether to abort the build of the application (Col 2: ln 15-38, The program code combines a selection of the identified non-native program instructions and subjects the combined selection to a risk evaluation by the one or more non-native tools. A result from the risk evaluation is received and the program code maps the received result to one or more corresponding lines the source code. The program code assigns a risk identifier to the corresponding one or more lines of the source code) Examiner Comments: This maps to using a list of dependencies to assess whether to abort, as Karve assembles the identified non-native instructions into a set and subjects that set to risk evaluation that drives the intervention decision.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Beard’s, Araya’s, Allen’s, and Jadhav’s teachings with Karve’s in order to integrate risk evaluation into the build workflow so that a build carrying a vulnerable component that is actually exercised is stopped, thereby improving security by preventing deployment of vulnerable code (Karve, Col 2: ln 15-38).
Regarding Claim 14, is a system claim corresponding to the method claim above (Claim 6) and, therefore, is rejected for the same reasons set forth in the rejection of claim 6.
Regarding Claim 17, is a system claim corresponding to the method claim above (Claim 9) and, therefore, is rejected for the same reasons set forth in the rejection of claim 9.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. 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.
/AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
