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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 5-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 5 recites the limitation "...determining, at the TIAP portal, whether the identified SBOM component was used by the application when said application was being executed on the computer system..."
The claim earlier introduces "a customer computer system" (multiple times), but there is no prior reference to "a computer system." This creates indefiniteness because it's unclear if "the computer system" refers to the "customer computer system" or something else. The shift from "customer computer system" to "computer system" appears to be a drafting error or inconsistency.
Claim 13 recites the limitation "...identify at least one SBOM component that is associated with at least one of the vulnerabilities..."
The claim mentions "a common vulnerability and exposure (CVE) service operative to receive a plurality of CVEs," but does not explicitly introduce "vulnerabilities" beforehand. While CVEs are identifiers for vulnerabilities, the term "vulnerabilities" itself lacks a direct antecedent. This could be seen as indefinite because it's unclear what "the vulnerabilities" specifically refers to (e.g., the received CVEs or something broader).
Claim 13 recites the limitation "...in conjunction with an application being executed on the customer computer... generate a SBOM used by an application being executed on the customer computer system... determine whether the identified SBOM component was used by the application when said application was being executed... if the identified SBOM component is not used by the application..."
The claim introduces "an application" twice (once in the event service clause and once in the SBOM service clause), which could imply two distinct applications. Later references to "the application" and "said application" might be ambiguous about which one is meant. While context suggests they are the same, this could be challenged as lacking clear antecedent if interpreted as separate.
Claim 13 recites the limitation "...on a customer computer system in conjunction with an application being executed on the customer computer, ..."
The claim introduces "a customer computer system" but later refers to "the customer computer" (missing "system"). This inconsistency could raise an antecedent issue, as "the customer computer" lacks a direct prior reference.
Dependent Claims 6-12 and 14-20 are also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to cure the deficiencies of their independent claims.
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 11150888) in view of Karve (US 11200048) further in view of Jadhav (US 20230244791).
Regarding Claim 1, Beard (US 11150888) 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 root node may comprise SBOM data that is empty (NUL). 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. The distinct SBOM update may comprise at least one update from the original SBOM in the root node plus all of the previous distinct SBOM updates of the parent leaf nodes. In the case where the leaf node is directly connected to the root node, the distinct SBOM update may comprise at least one update from the original SBOM in the root node. Therefore, 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. In the case where the SBOM data in the root node is empty, each of the leaf nodes directly connected to the root node may comprise a distinct SBOM update that is equivalent to a device specific SBOM communicated from a medical device.) 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/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 new block may comprise device specific SBOM changes 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 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/service on the server to receive vulnerability data, as Beard's validator systems access a vulnerability database (analogous to CVE source) for validation;
receiving, at the TIAP portal, 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 central authority system 320 may be configured to communicate authorization messages 321 to the plurality of validator systems 340. The at least one central authority system 320 may be configured to communicate inventory data 322 to the at least one coordinator system 360. The at least one coordinator system 360 may be configured to communicate status data 361 to at least one client system 370. At least one of the at least one client system 370 may be configured to communicate status data requests 371 to at least one of the at least one coordinator system 360. 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 vulnerabilities, as the system accesses and receives data from the vulnerability database to check updates;
determining, at the TIAP portal, whether the SBOM contains SBOM components associated with at least one of the 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 if SBOM contains vulnerable components, as Beard searches and validates SBOM components against the vulnerability database to identify associated vulnerabilities.
Beard did not specifically teach
preventing, at the TIAP portal, an SBOM component from being used in an application build for the application when a vulnerability associated with that SBOM component exceeds a threshold,
a common vulnerabilities and exposures (CVE).
However, Karve (US 11200048) teaches
preventing, at the TIAP portal, an SBOM component from being used in an application build for the application when a 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, as Karve's system evaluates risk in code components, assigns risk identifier based on severity (threshold), and applies modifications to mitigate vulnerabilities before deployment in CI/CD 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 into Karve’s in order to integrate risk evaluation into CI/CD to mitigate defects, improving security by preventing deployment of vulnerable code by enabling the risk evaluation and modification of the non-native program instructions in the computer system in an effective manner (Karve [Summary]).
Beard and Karve did not specifically teach
a common vulnerabilities and exposures (CVE).
However, Jadhav (US 20230244791) 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).).
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 teaching into Jadhav’s in order to streamline and automate the process of generating a proper cybersecurity bill of materials for a device to assist regulators, users and manufacturers with verifying and effectively managing critical components of the devices (Jadhav [Summary]).
Regarding Claim 2, Beard, Karve 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, as Karve assigns risk identifiers to vulnerable code, which can be displayed in the pipeline for alerts.
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 into Karve’s in order to integrate risk evaluation into CI/CD to mitigate defects, improving security by preventing deployment of vulnerable code by enabling the risk evaluation and modification of the non-native program instructions in the computer system in an effective manner (Karve [Summary]).
Regarding Claim 3, Beard, Karve 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 threshold by alert policy, as Karve's severity and confidence levels set thresholds for alerting and modification in 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 into Karve’s in order to integrate risk evaluation into CI/CD to mitigate defects, improving security by preventing deployment of vulnerable code by enabling the risk evaluation and modification of the non-native program instructions in the computer system in an effective manner (Karve [Summary]).
Regarding Claim 4, Beard, Karve and Jadhav teach
The method of Claim 1.
Beard 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 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 root node may comprise SBOM data that is empty (NUL). 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.) Examiner Comments: This maps to analyzing container/environment, as Beard's SBOM is generated by analyzing installed software in the device's 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 11150888) in view of Araya (US 20160224461) further in view of Jadhav (US 20230244791).
Regarding Claim 5, Beard teach
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 root node may comprise SBOM data that is empty (NUL). 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. The distinct SBOM update may comprise at least one update from the original SBOM in the root node plus all of the previous distinct SBOM updates of the parent leaf nodes. In the case where the leaf node is directly connected to the root node, the distinct SBOM update may comprise at least one update from the original SBOM in the root node. Therefore, 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. In the case where the SBOM data in the root node is empty, each of the leaf nodes directly connected to the root node may comprise a distinct SBOM update that is equivalent to a device specific SBOM communicated from a medical device.) 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/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 new block may comprise device specific SBOM changes 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 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/service on the server to receive vulnerability data, as Beard's validator systems access a vulnerability database (analogous to CVE source) for validation;
receiving, at the TIAP portal, vulnerabilities from that 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 central authority system 320 may be configured to communicate authorization messages 321 to the plurality of validator systems 340. The at least one central authority system 320 may be configured to communicate inventory data 322 to the at least one coordinator system 360. The at least one coordinator system 360 may be configured to communicate status data 361 to at least one client system 370. At least one of the at least one client system 370 may be configured to communicate status data requests 371 to at least one of the at least one coordinator system 360. 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 vulnerabilities, as the system accesses and receives data from the vulnerability database to check updates;
identifying, at the TIAP portal, at least one SBOM component that is associated with at least one of the 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 if SBOM contains vulnerable components, as Beard searches and validates SBOM components against the vulnerability database to identify associated vulnerabilities.
Beard did not specifically teach
executing, on the server, a 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;
determining, at the TIAP portal, whether the identified SBOM component was used by the application when said application was being executed on the customer computer system;
and if the identified SBOM component is not used by the application, enabling a build of the application to proceed
a common vulnerabilities and exposures (CVE).
However, Araya (US 20160224461) teaches
executing, on the server, a 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. Performance analysis focuses on measuring the elapsed time to execute various portions of a computer application under test, and interpreting the results. For synchronous execution of a computer application, an instrumentation point may record information at the start and the end of the execution of the portion of the computer application under test, and then the difference of those two times provides the elapsed time. For asynchronous execution of a computer application, the instrumentation point writes two separate messages that are later correlated with each other. Specifically, to correlate the messages, 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 provided an external resource, which cannot be instrumented, is accessed. The following data, which pertains to application performance, may be collected by instrumentation:) Examiner Comments: This maps to executing an event service to receive telemetry events, as Araya's system injects sensors to collect runtime telemetry (events and usage) from the application on the customer system and reports to a monitoring component (portal);
determining, at the TIAP portal, whether the identified 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 if component was used, as Araya's telemetry sensors track event categories and measurements during execution, allowing determination of component usage (e.g., security events indicating vulnerability use);
if the identified 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. Exception events may include the following data: From the foregoing data collected by instrumentation, reports regarding the health of a computing application under test may include statistics on successful transactions, unsuccessful transactions, unsuccessful transactions, and unexpected system errors and/or exceptions. Statistics may include totals, averages, maxima and minima Issues may be categorized and presented into a histogram. Upon aggregating a statistically significant amount of data, predictive models may be generated from the data. Reports may include statistics on the basis of the following: Security monitoring involves the detection of unauthorized access and attacks on a computer application under test. Because the migration tool has access to both the original source code and the generated source code for a target computing architecture, certain classes of attacks may be protected against. For example, SQL Injection is a well-known attack vector enabled by direct user input being submitted to a SQL database without the computer application validating and authorizing the input SQL. 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. In order to identify unauthorized accesses, the following data may be collected requests submitted to the computer application's services: From the foregoing data collected by instrumentation, reports regarding the performance of a computing application under test may include security injections checked (per origin and per type), security injections filtered and/or corrected (per origin and per type), and atypical traces of service requests. Statistics on this data may include totals, averages, maxima and minima Issues may be categorized and presented into a histogram. Upon aggregating a statistically significant amount of data, predictive models may be generated from the data. Reports may include statistics on the basis of the following … Usability measurements support the analysis of user behavior at the user interface. Conventional approaches to test user behavior is to instrument client applications with third party code corresponding to third party analytics packages. However, since the migration tool has access to the source code of the original application and generates the source code for the target computer application, the migration tool may inject the appropriate instrumentation into the client facing portions of the generated application.) Examiner Comments: This maps to enabling build if not used, as Araya's security actions are triggered only on vulnerable processes; if not used (no crash/exploitation evidence), execution (or build) proceeds without hindrance.
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 into Araya’s in order to enhance SBOM validation by providing usage data to confirm if vulnerable components are active, allowing more accurate risk assessment and avoiding unnecessary blocks by enabling performing event categories of health, security and usability and reducing network calls across layers (Araya [Summary]).
Beard and Araya did not specifically teach
a common vulnerabilities and exposures (CVE).
However, Jadhav (US 20230244791) 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).).
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 teaching into Jadhav’s in order to streamline and automate the process of generating a proper cybersecurity bill of materials for a device to assist regulators, users and manufacturers with verifying and effectively managing critical components of the devices (Jadhav [Summary]).
Regarding Claim 7, Beard, Araya and Jadhav teach
The method of Claim 5.
Beard did not specifically teach
receiving, at the TIAP portal, 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, 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. Exception events may include the following data: From the foregoing data collected by instrumentation, reports regarding the health of a computing application under test may include statistics on successful transactions, unsuccessful transactions, unsuccessful transactions, and unexpected system errors and/or exceptions. Statistics may include totals, averages, maxima and minima Issues may be categorized and presented into a histogram. Upon aggregating a statistically significant amount of data, predictive models may be generated from the data. Reports may include statistics on the basis of the following: Security monitoring involves the detection of unauthorized access and attacks on a computer application under test. Because the migration tool has access to both the original source code and the generated source code for a target computing architecture, certain classes of attacks may be protected against. For example, SQL Injection is a well-known attack vector enabled by direct user input being submitted to a SQL database without the computer application validating and authorizing the input SQL. 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. In order to identify unauthorized accesses, the following data may be collected requests submitted to the computer application's services: From the foregoing data collected by instrumentation, reports regarding the performance of a computing application under test may include security injections checked (per origin and per type), security injections filtered and/or corrected (per origin and per type), and atypical traces of service requests. Statistics on this data may include totals, averages, maxima and minima Issues may be categorized and presented into a histogram. Upon aggregating a statistically significant amount of data, predictive models may be generated from the data. Reports may include statistics on the basis of the following: Usability measurements support the analysis of user behavior at the user interface. Conventional approaches to test user behavior is to instrument client applications with third party code corresponding to third party analytics packages. However, since the migration tool has access to the source code of the original application and generates the source code for the target computer application, the migration tool may inject the appropriate instrumentation into the client facing portions of the generated application.) Examiner Comments: This maps to receiving and evaluating telemetry to qualify vulnerable dependency, as Araya receives telemetry and evaluates patterns to detect vulnerabilities, determining if sufficient to trigger action (abort).
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 into Araya’s in order to enhance SBOM validation by providing usage data to confirm if vulnerable components are active, allowing more accurate risk assessment and avoiding unnecessary blocks by enabling performing event categories of health, security and usability and reducing network calls across layers (Araya [Summary]).
Regarding Claim 8, Beard, Araya and Jadhav teach
The method of Claim 5.
Beard did not specifically teach
receiving, at the TIAP portal, telemetry events from the TIAP runtime; and 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.
However, Araya teaches
receiving, at the TIAP portal, telemetry events from the TIAP runtime; and 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 ([0093]-[0115], as cited in claim 7) Examiner Comments: This maps to evaluating telemetry for dynamic dependencies, as Araya collects from multiple layers to identify dependencies and events during execution, supplementing analysis (analogous to SBOM) with dynamic 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 into Araya’s in order to enhance SBOM validation by providing usage data to confirm if vulnerable components are active, allowing more accurate risk assessment and avoiding unnecessary blocks by enabling performing event categories of health, security and usability and reducing network calls across layers (Araya [Summary]).
Regarding Claim 10, Beard, Araya and Jadhav teach
The method of Claim 8.
Beard teaches implementing, at the TIAP portal, an abort decision based on the generated 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 abort decision based on SBOM or supplemented, as Beard adds (or not) updates based on validation of generated/supplemented SBOM, implementing decision to allow or block.
Regarding Claim 11, Beard, Araya and Jadhav teach
The method of Claim 5.
Beard 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; generating, at the TIAP portal, a visual representation of vulnerabilities identified in the comparison of the first SBOM to the second SBOM, wherein the visual representation shows which build introduced 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. 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 SBOMs and generating representation, as Beard's hash tree compares versions to identify new updates (vulnerabilities), and blockchain logs show which "build" introduced changes, visually representable.
Regarding Claim 12, Beard, Araya and Jadhav teach
The method of Claim 5.
Beard teaches performing, at the TIAP portal, vendor or package verification of each component contained 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. The original SBOM may be the first SBOM generated once a specific medical device is put into operation. The root node may comprise SBOM data that is empty (NUL). 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.) Examiner Comments: This maps to vendor/package verification, as Beard's validation against database enforces trusted sources by checking versions and patches for components.
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 (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 TIAP portal with an event service, as Beard's validator server processes device-specific data (analogous to telemetry from runtime on customer systems)
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 new block may comprise device specific SBOM changes 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 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 the portal including a CVE service that receives and stores CVEs, as Beard's validator accesses and stores vulnerability data from a database for SBOM validation, with blockchain/database storing multiple vulnerabilities (plurality of CVEs);
wherein the TIAP portal comprises a software build of materials (SBOM) service to: generate a SBOM used by an 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. 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 root node may comprise SBOM data that is empty (NUL). 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. The distinct SBOM update may comprise at least one update from the original SBOM in the root node plus all of the previous distinct SBOM updates of the parent leaf nodes. In the case where the leaf node is directly connected to the root node, the distinct SBOM update may comprise at least one update from the original SBOM in the root node. Therefore, 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. In the case where the SBOM data in the root node is empty, each of the leaf nodes directly connected to the root node may comprise a distinct SBOM update that is equivalent to a device specific SBOM communicated from a medical device.) Examiner Comments: This maps to the portal including an SBOM service that generates an SBOM with components, as Beard's system generates and updates SBOMs for devices/applications on customer systems, listing multiple components;
identify at least one SBOM component that is associated with at least one of the 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 vulnerable SBOM components, as Beard searches and validates SBOM components against the vulnerability database to associate with vulnerabilities;
Beard did not specifically teach
determine whether the identified SBOM component was used by the application when said application was being executed on the customer computer system
and if the identified SBOM component is not used by the application, enable a build of the application to proceed
a common vulnerabilities and exposures (CVE).
However, Araya teaches
determine whether the identified SBOM component was used by the application when said application was 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. Performance analysis focuses on measuring the elapsed time to execute various portions of a computer application under test, and interpreting the results. For synchronous execution of a computer application, an instrumentation point may record information at the start and the end of the execution of the portion of the computer application under test, and then the difference of those two times provides the elapsed time. For asynchronous execution of a computer application, the instrumentation point writes two separate messages that are later correlated with each other. Specifically, to correlate the messages, 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 provided an external resource, which cannot be instrumented, is accessed) Examiner Comments: This maps to determining if the component was used, as Araya's telemetry sensors track event categories and measurements during execution, allowing determination of component usage (e.g., security events indicating vulnerability use);
and if the identified 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 and/or the application client. .... Upon aggregating a statistically significant amount of data, predictive models may be generated from the data. Reports may include statistics on the basis of the following: Security monitoring involves the detection of unauthorized access and attacks on a computer application under test. Because the migration tool has access to both the original source code and the generated source code for a target computing architecture, certain classes of attacks may be protected against. For example, SQL Injection is a well-known attack vector enabled by direct user input being submitted to a SQL database without the computer application validating and authorizing the input SQL. 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. In order to identify unauthorized accesses, the following data may be collected requests submitted to the computer application's services: …. Upon aggregating a statistically significant amount of data, predictive models may be generated from the data. Reports may include statistics on the basis of the following: Usability measurements support the analysis of user behavior at the user interface. Conventional approaches to test user behavior is to instrument client applications with third party code corresponding to third party analytics packages. However, since the migration tool has access to the source code of the original application and generates the source code for the target computer application, the migration tool may inject the appropriate instrumentation into the client facing portions of the generated application) Examiner Comments: This maps to enabling the build if the component is not used, as Araya's telemetry confirming non-usage to avoid unnecessary blocks.
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 into Araya’s in order to enhance SBOM validation by providing usage data to confirm if vulnerable components are active, allowing more accurate risk assessment and avoiding unnecessary blocks by enabling performing event categories of health, security and usability and reducing network calls across layers (Araya [Summary]).
Beard and Araya did not specifically teach
a common vulnerabilities and exposures (CVE).
However, Jadhav (US 20230244791) 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).).
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 teaching into Jadhav’s in order to streamline and automate the process of generating a proper cybersecurity bill of materials for a device to assist regulators, users and manufacturers with verifying and effectively managing critical components of the devices (Jadhav [Summary]).
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 11150888) in view of Araya (US 20160224461) and Jadhav (US 20230244791) further in view of Karve (US 11200048).
Regarding Claim 6, Beard, Araya and Jadhav teach
The method of Claim 5.
Beard, Araya and Jadhav did not specifically teach
if the identified SBOM component is used by the application, aborting the build of the application.
However, Karve teaches if the identified 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. 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 aborting build, as Karve applies modifications or mitigates if risk high, effectively aborting original build with vulnerable component.
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, Araya and Jadhav’s teaching into Karve’s in order to integrate risk evaluation into CI/CD to mitigate defects, improving security by preventing deployment of vulnerable code by enabling the risk evaluation and modification of the non-native program instructions in the computer system in an effective manner (Karve [Summary]).
Regarding Claim 9, Beard, Araya and Jadhav teach
The method of Claim 8.
Beard, Araya 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. 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 using dependencies to assess abort, as Karve evaluates non-native code (dependencies) for risk, triggering modifications or mitigation if high.
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, Araya and Jadhav’s teaching into Karve’s in order to integrate risk evaluation into CI/CD to mitigate defects, improving security by preventing deployment of vulnerable code by enabling the risk evaluation and modification of the non-native program instructions in the computer system in an effective manner (Karve [Summary]).
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.
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