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 .
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. GB2317542.5, filed on November 16, 2023.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant's arguments filed January 13, 2026 have been fully considered but they are not persuasive.
Applicant states that claims 1-20, which were rejected under 35 U.S.C. 112(b) ("112(b)") for being indefinite for failing to distinctly claim the subject matter.
Examiner states that claims 1, and 7 have been amended to clear up the rejections under 112(b) regarding the term ‘a dependency profiler report’ in line 13 of independent claim 1, and "the type of service component to be wrapped" in line 4 of claim 7, respectively. Claims 12, 17, and 20 have also been amended in the same way as claims 1 and 7. Claims 8 and 18 have been canceled in the amendments. However, the claims 6 and 16 still remain rejected under 112(b) as the claims still contains the term of "to be updated", and all claims except claims 6 and 16 have their previous rejections under 112(b) withdrawn. However, the addition of the phrase “[…] as soon as […]” in claim 3, line 6, and claim 6, line 3, is an indefinite term in the claims, and Examiner states that paragraph [0081] of the Specification recites the phrase, but does not provide a standard as to the definition of a component being updated as soon as a new version without a vulnerability being available. As a result, Examiner rejects claims 3 and 6 under 112(b) over the indefinite term “[…] as soon as […]” being present in the claims. Claims 14 and 16 inherit the rejections present in claims 3 and 6, respectively.
In pages 1-2 of the remarks, Applicant states that claims 1-6, 12-16, and 19-20 were rejected under 35 U.S.C. 102(a)(2) as being anticipated by Larkin et al. (US 20240289462 A1), hereinafter Larkin, and states that Larkin does not appear to disclose "detecting one or more known vulnerabilities anywhere [...]", or any of the amended claims, including claims 3 and 6. In particular, Applicant states that Larkin's paragraph [0174] discloses claim 3's "determining a reaction type dependent on the scoring value of the predefined sequence of dependencies [...]", prior to being amended. Larkin cites, in [0174] of the reference, "if severity scores do exceed values provided in an alert policy [...], then the build is aborted. Otherwise, nothing happens to the build or evaluation." Applicant does not claim that a build environment is needed for the dependency profiler operation, and that reaction types do not include aborting the process, and requests reconsiderations of the rejections under 35 U.S.C. 102 (“102 rejection”).
Examiner states that Larkin discloses the claim of "detecting one or more known vulnerabilities anywhere […]", as Larkin [0087] Fig. 1, remediation module 190 can locate and provide updates to problematic components identified by standard bill of materials (SBOM) module 180, disclosed in paragraph [0086], to which SBOM module assesses vulnerabilities of components used by an application, wherein the process stated for remediation module 190 in [0087] corresponds to the detection of one or more known vulnerabilities anywhere in the sequence of usage of the detected dependencies. As for the amended limitation of "wherein the response action is a combined scoring value of the one or more detected vulnerabilities", while it is stated in paragraphs [0086]-[0087] that a remediation module is present in Fig. 1 to assess vulnerabilities, and a score is stated in paragraph [0174] as “vulnerabilities’ severity scores”, Larkin does not suggest a “combined scoring value of the one or more detected vulnerabilities”. However, the reference of Kang et al. (US 20180129812 A1), hereinafter Kang, suggests the limitation of a combined scoring value for detected vulnerabilities, in paragraph [0129] Fig. 6, a package management system calculates a system security score based on the security scores of the packages in the system, and as packages increase the risk of exposing software vulnerabilities to a system in [0008] of Kang, suggest the limitation of calculating a combined score for vulnerabilities detected. The motivation for combining Larkin and Kang is to use an invention to obtain CVE records for software packages, and analyze the records to calculate scores across all potential dependencies and packages in a system to better assess risks, as stated by Kang [0019] and [0059]. Finally, claim 3's "determining a reaction type dependent on the scoring value of the predefined sequence of dependencies [...]", prior to being amended, is disclosed by Larkin's paragraph [0174], as the reaction of either doing nothing or aborting a build is dependent on a severity score that exceed values provided in an alert, and as a result, Examiner clarifies made in the previous Office Action for claim 3, which incorporates limitations that were previously made in the now canceled claim 8. Examiner now rejects independent claim 1 under 35 U.S.C. 103 over the prior arts of Larkin in view of Kang, with independent claims 12 and 20 also being rejected for similar rationale to claim 1 above. Claims 3-6, and 14-16 are also rejected under this 103 rejection over Larkin in view of Kang as being dependent on their respective independent claims.
In pages 2-3 of the remarks, Applicant states that claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Larkin in view of Cohen (US 20240291863 A1), and has been amended to recite "wherein a type of service component […] is configurable". Claims 9-11 are rejected as being unpatentable over Larkin in view of Singh (US 20120011493 A1), and Singh [0091] does not teach Applicant's "changing functional call parameters, thereby circumventing a vulnerability", which is found in claims 3 and 14 (where the limitations are from now canceled claim 8), where Applicant states that Singh's prioritizer has a number of code patches that compares against a number of rules, and a matching code patch to a rule assign a weight to the code patch, thereby influencing its priority, which contrasts the Applicant's own dependency profiler, which executes at software runtime to dynamically detect vulnerabilities in the existing code, and the references of Larkin, Singh, and Cohen do not teach or otherwise suggests amended claims.
Examiner states that claim 7 has been amended, but recites practically the same limitations as in the previous Office Action, and the Examiner maintains the previous rejection for claims 7 and 17 under 35 U.S.C. 103, modified to now be rejected over Larkin in view of Kang, further in view of Cohen. As for claims 9-11, in which the Applicant recites claim 3's "changing functional call parameters, thereby circumventing a vulnerability", from now canceled claim 8, Singh's paragraph [0091] Rule W states that a code change modifies at least one parameter of a vulnerable assembly routine, which combines with Larkin's Fig. 8, paragraph [0168]'s 'fixed versions of vulnerable components 826' in response to vulnerabilities being detected, teaches the limitations of claim 3. Examiner states that the combined teachings of Larkin in view of Singh, which also executes at run time, and does detect vulnerabilities in code in a dynamic fashion with various rules in Singh, corresponds with the Applicant’s limitations of claims 9 and 10, as stated in paragraph [0057] of the Specification. Examiner now rejects claim 3, 9-10, and 14 under 35 U.S.C. 103 over the prior arts of Larkin in view of Kang, further in view of Singh.
Claim Rejections - 35 USC § 112(b)
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.
Claims 3, 6, 14, and 16 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.
In claim 3, the term “[…] as soon as […]” in claim 3, line 5 is a relative term which renders the claim indefinite. The term “[…] as soon as […]” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Paragraph [0081] of the Specification recites the phrase, but does not provide a standard as to the definition of a component being updated as soon as a new version without a vulnerability being available, or at what point after the new version of the software vulnerability is created or otherwise made available the dependent component is marked as “to be updated”, such as within a few seconds or an hour later, is not made clear in the Specification.
The term “to be updated” in claim 6, line 2 is a relative term which renders the claim indefinite. The term “to be updated” renders the claim indefinite because it is unclear whether the limitation(s) following the phrase are part of the claimed invention. Although the term is specified to be performed at a later point in paragraph [0044] of the Applicant’s specification, it is not made clear in the claim that this is the case, and in the specification, it is not made clear at which later point in time an update can be made available, which renders the claim indefinite for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claim 14 recites similar limitations as in claim 3 above, and as a result, the deficiencies of the dependent claim 14 are inherited from dependent claim 3.
Claim 16 recites similar limitations as in claim 6 above, and as a result, the deficiencies of the dependent claim 16 are inherited from dependent claim 6.
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 performing a response action based on detecting one or more known vulnerabilities anywhere in the sequence of the usage of the detected dependencies, wherein the response action is 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 is compared to an admin supplied alert policy, and if the vulnerability severity scores exceeds the values provided in the alert policy, a message containing vulnerabilities responsible for failure is sent to the end user.);
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 a service component relating to the dependency as to be updated depending on the reaction type, as soon as 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 a 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 “wherein the performing of the response action comprises: 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” as soon as 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 a 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ting et al. (US 20200320203 A1, “CONTINUOUS RISK ASSESSMENT FOR ELECTRONIC PROTECTED HEALTH INFORMATION”)
Rao et al. (US 11503063 B2, “Systems And Methods For Detecting Hidden Vulnerabilities In Enterprise Networks”)
Xiao et al. (US 20250013744 A1, “VULNERABILITY ASSESSMENT METHOD AND ANALYSIS DEVICE”)
Hao et al. ("VD-HEN: Capturing Semantic Dependencies for Source Code Vulnerability Detection With a Hierarchical Embedding Network", 2023)
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