Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
In pages 1-2 of the remarks, Applicant states that claims 3, 6, 14, and 16 rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter, with claims 3 and 14 reciting the limitation “to be updated”, as well as in claims 6 and 16. The term “when” replaces the phrase “as soon as”, which resolves the 112(b) rejections, as it was previously ambiguous as to when the status of “to be updated” is marked on a dependent component’s new version is available. As a result, the rejections made under 112(b) are withdrawn.
In pages 2-3 of the remarks, Applicant has amended the claims to advance prosecution, and in particular, the independent claims now recite blocking one or more function calls to one or more of the detected dependencies, by use of dependency profiler wrapper code. Applicant states that Larkin fails to teach or suggest “blocking, by the dependency profiler wrapper code, one or more function calls to one or more of the detected dependencies […]” of the amended limitations of the independent claims 1, 12, and 20, as Larkin, at best, aborts or blocks the entire build in paragraphs [0171]-[0174], and does not suggest blocking individual vulnerable dependencies or function calls to those dependencies, nor does it provide a score. Applicant also states that Kang’s paragraph [0020] describes a system security score is based on an open-source software package; the open-source software package is separate from the dependency package comprising the dependencies of the software package, and no system security score is assessed for the dependency package itself. For these reasons, Applicant states that the cited references fail to teach or suggest every limitation in the amended claims, and requests withdrawal of all claims under 103.
Applicant's arguments filed June 5, 2026 have been fully considered but they are not persuasive. Examiner disagrees with the Applicant regarding the amended limitations of the independent claims 1, 12, and 20, specifically the limitation of “blocking, by the dependency profiler wrapper code, one or more function calls to one or more of the detected dependencies based on detecting one or more known vulnerabilities”, and “wherein the action is based on a combined scoring value of the one or more detected vulnerabilities” is disclosed in the prior art of Larkin in paragraph [0194] Fig. 15, steps 1540-1550 describes that the TIAP portal determines if an SBOM component is associated with at least one of the listed vulnerabilities, and if so, prevents the SBOM component from being used in the application build, effectively blocking the function call to the detected dependency, and [0174] states that vulnerability severity scores are determine by the TIAP. The prevention of an individual SBOM component from being utilized in the application build is evaluated after the vulnerabilities are received from at least one CVE source in step 1530, and when the component contains one of the vulnerabilities, it is prevented from execution in the application build to protect the build from being infected by the vulnerability. As a result of the prior art rejecting the amended limitations of the claims, in particular, the amended limitations of independent claims 1, 12, and 20, Examiner maintains all previous rejections, including claims 1, 4-6, 12, 15-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Larkin et al. (US 20240289462 A1), hereinafter Larkin, in view of Kang et al. (US 20180129812 A1), hereinafter Kang. All other 103 rejections have their rationales for rejections maintained.
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.
Claims 1, 4-6, 12, 15-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Larkin et al. (US 20240289462 A1), hereinafter Larkin, in view of Kang et al. (US 20180129812 A1), hereinafter Kang.
Regarding claim 1, Larkin discloses ‘a computer-implemented method for protecting a software code against a security vulnerability, wherein the software code comprises at least one software code component, comprising a function call to a service component, whereby each function call represents a dependency, the method comprising’ ([0041] Insecure components can be replaced with more secure alternative to mitigate security vulnerabilities and risks. [0069] Interception library is created by TIAP and is used to intercept API calls made by an application function and record API calls as a telemetry event. Paragraph [0084] further describes a native library API function as part of an application dependency chain.):
‘generating a dependency profiler report comprising a plurality of published common vulnerabilities and exposures (CVE)’ ([0198] Fig. 17, SBOM is generated based on TIAP process, and step 1740 identifies vulnerable components based on CVE sources that are received in TIAP portal in step 1730. TIAP portal corresponds to dependency profiler report comprising a plurality of published CVEs.),
‘integrating a dependency profiler and dependency profiler wrapper code with the at least one software code component’ ([0084] Fig.1, TIAP runtime module. TIAP runtime can interpose on any function, and can insert interception hooks into an application's dependency chain. This allows the TIAP to gather information about an API request, including parameters and call stack information, wherein call stack information can contain dependencies from the dependency chain in a function of an application. Interception hooks on a function correspond to a dependency profiler on a software code component. [0073] TIAP runtime can run within a loaded process address space, providing TIAP services, corresponding to dependency profiler wrapper code. The TIAP runtime augments a software code component with additional services provided by the TIAP services.);
‘intercepting, at runtime of the software code component, the function call to at least one API of the service component, thereby detecting dynamically both direct dependencies and transitive dependencies anywhere in a sequence of usage between software code components’ ([0084] Functions can be called to a native library API, and is redirected to a TIAP runtime, before being trampolined back to a native library, as seen in Fig. 4. [0196] Fig. 16B, step 1692, telemetry events are evaluated to obtain dynamic dependencies of components used by an application during execution on customer computer system. [0196] Fig. 16B, step 1694, dynamic dependencies are added to the SBOM, and in [0171] components can be directly or indirectly/transitively imported to the code as defined by the SBOM, corresponding to detecting dependencies in a dynamic fashion anywhere in the sequence of usage in the code.);
‘recording by the dependency profiler wrapper code a sequence of usage of the detected dependency in the dependency profiler report, wherein the recording indicates a call to any function call’ ([0102] Fig. 4 shows commands being intercepted, first executed by an application 410, then intercepted and collected by interception library 430, and is then executed by a native library 420. Interception of code in an order from CMD1 to CMDN, including dependencies, corresponding to a sequence of usage of detected dependencies in a profiler report when accounting for the dependency chain in paragraph [0084]. [0096] Telemetry events are collected by TIAP runtime via an interception such as CMD1 431 shown in Fig. 4.);
‘and blocking, by the dependency profiler wrapper code, one or more function calls to one or more of the detected dependencies based on detecting one or more known vulnerabilities anywhere in the sequence of the usage of the detected dependencies, wherein the blocking is based on a scoring value of the one or more detected vulnerabilities’ ([0087] Fig. 1, remediation module 190 can locate and provide updates to problematic components identified by SBOM module 180, disclosed in paragraph [0086], to which SBOM module assesses vulnerabilities of components used by an application. Updated versions are intended to fix issues identified by remediation module 190 identified by SBOM module 180. Paragraph [0175] further discusses the possibility of a vulnerable dependency presenting an issue with a build as stated in [0174], where a message containing vulnerabilities that caused the failure is reported for TIAP to display to the end user. [0174] Vulnerabilities’ severity scores are compared to an admin supplied alert policy, and if the vulnerability severity scores exceed the values provided in the alert policy, a message containing vulnerabilities responsible for failure is sent to the end user. [0194] Fig. 15, steps 1540-1550 describes that the TIAP portal determines if an SBOM component is associated with at least one of the listed vulnerabilities, and if so, prevents the SBOM component from being used in the application build, effectively blocking the function call to the detected dependency, and [0174] states that vulnerability severity scores are determine by the TIAP.);
Larkin does not appear to disclose, but Kang teaches the limitation of “combined scoring value of the one or more detected vulnerabilities” ([0129] Fig. 6, a package management system calculates a system security score based on the security scores of the packages in the system, corresponding to a combined scoring value of the one or more detected vulnerabilities, which paragraph [0008] describes as packages increasing the risk of exposing software vulnerabilities to a system.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "combined scoring value of the one or more detected vulnerabilities" in a computer-implemented method for protecting a software code against a security vulnerability for and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to search the National Vulnerability Database (NVD) for information relating to software packages in the operation system for CVE records, and use a CVE record analysis to search for CVE records and analyze a total of the CVSS values and calculate the CVE security scores of the software packages (Kang [0019], [0059]).
Regarding claim 4, Larkin discloses the limitations of claim 1 as recited above. Larkin also discloses ‘further comprising: retrieving information about known vulnerabilities including information about dangerous sequences of dependencies causing a security issue with the service component’ ([0152] CVE service 740 identifies which components have known vulnerabilities 741, by way of CVEs. [0084] API request information is collected by way of collecting information on an application's dependency chain, including call stack information. Dependency chain contains dependent components of a function that has interception hooks.);
Regarding claim 5, Larkin discloses the limitations of claim 1 as recited above. Larkin also discloses ‘further comprising: retrieving information about known vulnerabilities including information about dangerous function call parameter values, each of which being indicative of a security issue with the service component’ ([0152] CVE service 740 identifies which components have known vulnerabilities 741, by way of CVEs. [0084] API request information is collected by way of collecting information on an application's dependency chain, including parameters. Paragraphs [0086] has an SBOM module and [0147] having an API service 736, and both modules can assess vulnerabilities of components being used in an application.);
Regarding claim 6, Larkin discloses the limitations of claim 1 as recited above. Larkin also discloses ‘further comprising: marking the service component relating to the dependency as “to be updated” depending on the reaction type, when a version without the vulnerability is available’ ([0168] Fig. 8, fixed versions of vulnerable components 826 can be included into a script that is made available for a user to download, wherein making a script available for a user to download to fix vulnerable components corresponds to marking a service component relating to a dependency as to be updated as soon as a new version of the service component being available. [0190] states that the “fixed” versions of components is defined as a version of the component that has its vulnerabilities eliminated, as reported in the CVEs run against the components.);
Regarding claim 12, Larkin discloses similar limitations also present in independent claim 1, and Larkin also discloses ‘a runtime dependency security computer system for protecting a software code against a security vulnerability, the system comprising’ (Claim 7 recites a system to perform the functions of remediating security vulnerabilities in code.):
‘one or more processors and a memory operatively coupled to the one or more processors, wherein the memory stores program code portions which, when executed by the one or more processors, enable the one or more processors to:’ ([0200] Data processing system can include a processor to execute instructions, a memory coupled with the processor to store instructions that can be executed by the processor.).
Regarding claim 15, Larkin discloses the limitations of claim 12 as recited above. Larkin also discloses similar limitations present in dependent claim 4 above.
Regarding claim 16, Larkin discloses the limitations of claim 12 as recited above. Larkin also discloses similar limitations present in dependent claim 6 above.
Regarding claim 20, Larkin discloses similar limitations also present in independent claim 1, and Larkin also discloses ‘a computer program product for securing a software code against a security vulnerability, wherein the software code comprises at least one software code component, some of which comprising a function call to a service component, whereby each function call represents a dependency’ (Claim 12 describes a computer program product. [0041] Insecure components can be replaced with more secure alternative to mitigate security vulnerabilities and risks. [0069] Interception library is created by telemetry interception and analysis platform (TIAP) and is used to intercept API calls made by an application function and record API calls as a telemetry event. Paragraph [0084] further describes a native library API function as part of an application dependency chain.):
‘the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by one or more computing systems or controllers to cause the one or more computing systems to:’ (Claim 12's computer program product comprises at least one non-transitory computer-readable storage medium containing computer-readable program code. The code is executable by a computer system.).
Claims 7, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Larkin in view of Kang, further in view of Cohen (US 20240291863 A1).
Regarding claim 7, Larkin discloses the limitations of claim 1 as recited above. Larkin does not appear to disclose, but Cohen teaches ‘wherein the integrating a dependency profiler with the at least one software code component further comprises: generating the dependency profiler wrapper code for a called library dynamically, wherein the type of service component to be wrapped with the dependency profiler wrapper code is configurable’ ([0122] Wrapped API is stated to include a framework for encapsulating an API, or alternatively, an API wrapper can add a layer of code to a native API. [0122] Generating a wrapped API includes accessing native API code and altering code to perform different and/or additional functionalities, corresponding to a service component being configurable before wrapping the service component.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Larkin, Kang, and Cohen before them, to include Cohen’s ‘wherein the integrating a dependency profiler with the at least one software code component further comprises: generating the wrapper code for a called library dynamically’ in Larkin’s method performing ‘protecting a software code against a security vulnerability’. One would have been motivated to make such a combination to enhance security by encapsulating an API, which is a wrapped API, to replace a native API, so that when a trigger event is detected, the wrapped API can be invoked in place of the native API to establish a virtual barrier between code and a native API to thwart cybersecurity threats, as taught by Cohen [0125] and [0127].
Regarding claim 17, Larkin discloses the limitations of claim 12 as recited above. Larkin in view of Cohen also teach similar limitations present in dependent claim 7 above.
Claims 3, 9-10, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Larkin in view of Kang, further in view of Singh et al. (US 20120011493 A1), hereinafter Singh.
Regarding claim 3, Larkin discloses the limitations of claim 1 as recited above. Larkin also discloses “further comprising performing a response action comprising: determining a reaction type dependent on the scoring value of a predefined sequence of dependencies, wherein the reaction type includes marking one or more dependent components as “to be updated” when a new version of the service component without the vulnerability is available” ([0174] If severity scores do exceed values provided in an alert policy, the build containing the intercepted calls, including dependencies, then the build is aborted. Otherwise, nothing happens to the build or evaluation. [0168] Fig. 8, fixed versions of vulnerable components 826 can be included into a script that is made available for a user to download, wherein making a script available for a user to download to fix vulnerable components corresponds to marking a service component relating to a dependency as to be updated as soon as a new version of the service component being available. [0190] states that the “fixed” versions of components is defined as a version of the component that has its vulnerabilities eliminated, as reported in the CVEs run against the components.);
Larkin does not appear to disclose, but Kang teaches the limitation of “combined scoring value of a predefined sequence of dependencies” ([0129] Fig. 6, a package management system calculates a system security score based on the security scores of the packages in the system, corresponding to a combined scoring value of the one or more detected vulnerabilities, the packages in the system are equivalent to a predefined sequence of dependencies. Paragraph [0008] describes as packages increasing the risk of exposing software vulnerabilities to a system.).
Therefore, one of ordinary skill in the art would have been capable of applying this known method of "combined scoring value of the one or more detected vulnerabilities" in a computer-implemented method for protecting a software code against a security vulnerability for and the results would have been predictable to one of ordinary skill in the art. The one of ordinary skill in the art would have been motivated to search the National Vulnerability Database (NVD) for information relating to software packages in the operation system for CVE records, and use a CVE record analysis to search for CVE records and analyze a total of the CVSS values and calculate the CVE security scores of the software packages (Kang [0019], [0059]).
Larkin in view of Kang does not appear to disclose, but Singh teaches the limitations of “changing function call parameters, thereby circumventing a vulnerability” ([0091] Rule W states that a code change modifies at least one parameter of a vulnerable assembly routine, and when combining the 'fixed versions of vulnerable components 826' in Fig. 8, paragraph [0168] of Larkin in response to vulnerabilities being detected, corresponds to changing function call parameters to circumvent a vulnerability.);
“and changing a function call sequence, thereby circumventing the vulnerability” ([0072] Rule D states that a code change modifies control flow before assembly instructions for a string operation, and when combining the 'fixed versions of vulnerable components 826' in Fig. 8, paragraph [0168] of Larkin in response to vulnerabilities being detected, corresponds to the limitation of changing a function call sequence.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Larkin, Kang, and Singh before them, to include Singh’s ‘changing function call parameters, thereby circumventing a vulnerability’ and ‘changing a function call sequence, thereby circumventing a vulnerability’ in Larkin’s method performing ‘protecting a software code against a security vulnerability’. One would have been motivated to make such a combination to enhance security by having weights signify importance to changes in code and give code changes higher prioritize when more weight is placed on the type of change, as taught by Singh [0006].
Regarding claim 9, Larkin discloses the limitations of claim 1 as recited above. Larkin does not appear to disclose, but Singh teaches the limitations of ‘wherein the dependency profiler changes function call arguments for the function call to the service component based on values of the function call arguments being known to be vulnerable for the software code’ ([0091] Rule W states that a code change modifies at least one parameter of a vulnerable assembly routine, corresponding to changing function call parameters to circumvent a vulnerability, when combining the 'fixed versions of vulnerable components 826' in Fig. 8, paragraph [0168] of Larkin in response to vulnerabilities being detected.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Larkin, Kang, and Singh before them, to include Singh’s ‘wherein the dependency profiler changes function call arguments for the function call to the service component based on values of the function call arguments being known to be vulnerable for the software code’ in Larkin’s method performing ‘protecting a software code against a security vulnerability’. One would have been motivated to make such a combination to enhance security by having weights signify importance to changes in code and give code changes higher prioritize when more weight is placed on the type of change, especially with regards to Rule W, as taught by Singh [0006] and [0091].
Regarding claim 10, Larkin discloses the limitations of claim 1 as recited above. Larkin also discloses a ‘the dependency profiler wrapper code’ ([0073] TIAP runtime can run within a loaded process address space, providing TIAP services, corresponding to dependency profiler wrapper code.);
Larkin does not appear to disclose, but Singh teaches the limitations of ‘wherein code changes a sequence of function calls to the service component based on specific sequences of function calls being known to be vulnerable for the software code’ ([0072] Rule D states that a code change modifies control flow before assembly instructions for a string operation, corresponds to the limitation of changing a function call sequence.).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Larkin, Kang, and Singh before them, to include Singh’s ‘wherein code changes a sequence of function calls to the service component based on specific sequences of function calls being known to be vulnerable for the software code’ in Larkin’s ‘dependency profiler wrapper code’ method performing ‘protecting a software code against a security vulnerability’. One would have been motivated to make such a combination to enhance security by having weights signify importance to changes in code and give code changes higher prioritize when more weight is placed on the type of change, especially with regards to Rule D, as taught by Singh [0006] and [0072].
Regarding claim 14, Larkin discloses the limitations of claim 12 as recited above. Larkin also discloses similar limitations present in dependent claim 3 above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOMMY MARTINEZ whose telephone number is (703)756-5651. The examiner can normally be reached Monday thru Friday 8AM-4PM 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, Jorge L. Ortiz-Criado can be reached at (571) 272-7624 on Monday thru Friday 7AM-7PM ET. 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.
/T.M./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights