DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-21 are pending. Claims 1, 8, and 15 are independent. Claims 1, 8, and 15 are amended.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/13/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/29/2026 has been entered.
Response to Arguments
Applicant’s arguments, see pages 11 and 12, filed 6/9/2026, with respect to the rejection of claims 1-21 under 35 USC 112(a) have been fully considered and are persuasive. The associated rejection(s) to the listed claim(s) has/have been withdrawn.
Applicant’s arguments, see pages 12-15, filed 6/29/2026, with respect to the rejection of claims 1-21 under 35 USC 103 have been fully considered.
Regarding the prior art of Nilekar:
These arguments are not persuasive. Examiner notes that the prior art of Nilekar uses a “predetermined security rule” (which reads on a “policy”) to validate information extracted from a request, which in a previous limitation was established to contain at least one from among a user identifier, a user credential, a device identifier, and a software package identifier. Given such a limited list of contents for a request subject to the security rule, it is clear that Nilekar is capable of performing the function of the prior art (applying a policy associated with a user identifier given a request containing a user identifier).
Regarding the prior art of Hacker:
These arguments are persuasive.
These rejections are withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of ROBINSON (Doc ID US 11792234 B1).
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, 3, 5-8, 10, 12-15, 17, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over ROBINSON (Doc ID US 11792234 B1), and further in view of DUAN et al (Doc ID US 11863586 B1), NILEKAR (Doc ID US 20220200962 A1), and HACKER et al (Doc ID US 20240211249 A1).
Regarding claim 1:
ROBINSON teaches:
determining a risk score associated with the software dependency installation package ((39) Col 9 lines 61-64 "The categorizer 418 identifies each of the browser extensions ... to determine the risk score associated with them." and "(41) Col 10 lines 27-29 "The correlator 420 uses the list ... in the risk repository 312 to match a browser extension received from a request of the client device 102.");
ROBINSON is directed to installation of browser extensions. However, there is no teaching in ROBINSON or the below secondary references which precludes the risk score repository of ROBINSON from storing a risk score associated with the “software dependency installation package” as taught by DUAN below.
determining, by applying the first policy associated with the first user identifier, that the software dependency installation package violates the first policy based on at least one of: a comparison of the determined risk score associated with the software dependency installation package with a risk threshold in the first policy, or an evaluation of the determined software license against a software license allow list or deny list in the first policy ((36) Col 9 lines 24-27 "If the aggregate risk has a value above the threshold value, then the browser extension is installed. If ... below the threshold value, then the browser extension is not installed." and (69) col 16 lines 3-12 "At block 810, the authorization is determined for the browser extension based on the identified policy. ... The policies can also specify the use of browser extension based on ... a user designation ...");
The “user designation” of ROBINSON is not unique to a particular user, as it describes a role. However, there is no teaching in ROBINSON or the below secondary references which precludes the “user designation” of ROBINSON from being modified with the “user identifier” as taught by NILEKAR below.
blocking the software dependency installation package from being installed in the software dependency management system in response to determining that the software dependency installation package violates the first policy ((69) Col 16 lines 3-4 "At block 810, the authorization is determined for the browser extension based on the identified policy." and (70) Col 16 lines 13-15 "Based on the authorization, either the browser extension is denied access for installation at block 812 or granted access for installation at block 814."); and
storing a log entry in an auditing system, the log entry including data indicating the blocking of the first request ((37) Col 9 lines 28-30 "The analyzer 314 further keeps a log of the browser extensions each time the browser extensions are used for the installation of the browser extensions.").
DUAN teaches the following limitation(s) not taught by ROBINSON:
A computer-implemented method comprising: receiving, by a proxy server from a first client network application executing on a first client device, a first request from a first user of the first client device (Col 17 lines 61-63 "Process 500 begins at 502 when an indication is received that a client device has made a request to a remote server for a package.");
detecting, by the proxy server, that the first request is for approval to download a software dependency installation package for installation in a software dependency management system (Claim 1 "… wherein the requested package is included as a dependency of a software build …");
Determining a risk score associated with a software installation, determining if the risk score violates a policy, blocking a download of the software based on a policy violation, and recording the blocked download are known techniques in the art, as demonstrated by ROBINSON. Further, processing requests from users for software dependency installation packages is a known technique in the art, as demonstrated by DUAN. It would have been obvious to a person having ordinary skill in the art (PHOSITA) before the effective filing date of the claimed invention to modify the software risk score determination and policy enforcement of ROBINSON with the software dependency installation package request processing of DUAN with the motivation to monitor and filter requested software packages for violations of policy. Processing external requests rather than only evaluating software locally is a solution that is obvious to try, and has been used to modify similar inventions.
NILEKAR teaches the following limitations not taught by the above combination:
determining a first user identifier associated with the first request, the first user identifier associated with the first user of the first client device ([0023] "… the at least one request may relate to a solicitation for at least one software package …" and [0024] "… the at least one request may include at least one from among a user identifier, a user credential, a device identifier, and a software package identifier.");
identifying a first policy associated with the first user identifier, wherein the first policy is applicable to software dependency installation requests from the first user of the first client device ([0074] "... the request may include at least one from among a user identifier ...", [0077] "At step S404, a determination may be made as to whether the request is to be forwarded … to a private computer network. The determination may be made … based on a predetermined security rule.", and [0079] "At step S406, the request may be authenticated ... based on a result of the determination. ... identifying information may be extracted from the request and used to authenticate the request.");
Linking policies to be enforced based on users, and directed to software downloads, is a known technique in the art, as demonstrated by NILEKAR. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the software dependency installation package manager of ROBINSON and DUAN with the user related policies of NILEKAR with the motivation to provide more options to the user regarding policies governing circumstances for allowing download of software packages. It is obvious to allow granular policies so that groups such as IT personnel can be granted the ability to use software deemed too risky for other users.
HACKER teaches the following limitations not taught by the above combination:
determining a software license associated with the software dependency installation package ([0029] "… the one or more compliance rules include one or more of: a rule on vulnerability, a rule on license compliance, a rule on policy compliance …");
Identifying policies based on software licenses is/are known technique(s) in the art, as demonstrated by HACKER. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the software dependency installation package manager of ROBINSON, DUAN, and NILEKAR with the license-related policies of HACKER with the motivation to provide more options to the user regarding policies governing circumstances for allowing download of software packages.
Regarding claim 3:
The combination of ROBINSON, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1, wherein blocking the first request in response to determining that the software dependency installation package violates the first policy comprises: transmitting a notification message to the client device indicating the blocking of the first request from transmission to a software dependency manager (ROBINSON (70) Col 16 lines 15-19 "At block 812, after the browser extension is denied access for installation, reports regarding the denial are provided to the end-user 106 of the client device 102 or to the administrator at IT module 214 from the mid-link server 108 at block 816.").
Regarding claim 5:
The combination of ROBINSON, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1, further comprising: receiving, by the proxy server from the first client network application executing on the first client device, a second request (DUAN Col 17 lines 61-63 "Process 500 begins at 502 when an indication is received that a client device has made a request to a remote server for a package.");
detecting, by the proxy server, that the second request is for a second software dependency installation package (DUAN Claim 1 "… wherein the requested package is included as a dependency of a software build …");
determining that the second software dependency installation package is on a deny list (DUAN Col 18 lines 5-7 "As one example, data appliance 102 can determine whether the request is associated with a blocked URL …"); and
blocking the second request in response to determining that the second software dependency installation package is on the deny list (DUAN Col 18 lines 7-8 "… if so, prevent download of the package from the remote server.").
Filtering software package requests against a blocked list and denying packages from blocked sources are known techniques in the art, as demonstrated by DUAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the software package security system of ROBINSON, DUAN, NILEKAR, and HACKER with the package source blacklist of DUAN with the motivation to prevent downloads of packages from untrusted or known malicious sources. It is obvious to incorporate a black list of sources from which downloads are not permitted.
Regarding claim 6:
The combination of ROBINSON, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1, further comprising: receiving, by the proxy server from a second client network application executing on a second client device, a second request from a second user of the second client device (DUAN Col 17 lines 61-63 "Process 500 begins at 502 when an indication is received that a client device has made a request to a remote server for a package.");
detecting, by the proxy server, that the second request is for approval to download the software dependency installation package for installation in the software dependency management system (DUAN Claim 1 "… wherein the requested package is included as a dependency of a software build …");
determining the risk score associated with the software dependency installation package (ROBINSON (39) Col 9 lines 61-64 "The categorizer 418 identifies each of the browser extensions ... to determine the risk score associated with them." and "(41) Col 10 lines 27-29 "The correlator 420 uses the list ... in the risk repository 312 to match a browser extension received from a request of the client device 102.");
determining a second user identifier associated with the second request, the second user identifier associated with the second user of the second client device (NILEKAR [0023] "… the at least one request may relate to a solicitation for at least one software package …" and [0024] "… the at least one request may include at least one from among a user identifier, a user credential, a device identifier, and a software package identifier.");
identifying a second policy associated with the second user identifier, wherein the second policy is applicable to software dependency installation requests from the second user of the second client device (NILEKAR [0074] "... the request may include at least one from among a user identifier ...", [0077] "At step S404, a determination may be made as to whether the request is to be forwarded … to a private computer network. The determination may be made … based on a predetermined security rule.", and [0079] "At step S406, the request may be authenticated ... based on a result of the determination. ... identifying information may be extracted from the request and used to authenticate the request.");
determining, based on the determined risk score associated with the software dependency installation package, that the software dependency installation package conforms to the second policy (ROBINSON (36) Col 9 lines 24-27 "If the aggregate risk has a value above the threshold value, then the browser extension is installed. If ... below the threshold value, then the browser extension is not installed." and (69) col 16 lines 3-12 "At block 810, the authorization is determined for the browser extension based on the identified policy. ... The policies can also specify the use of browser extension based on ... a user designation ..."); and
transmitting the second request to a software dependency manager in response to determining that the software dependency installation package conforms to the second policy (DUAN Col 18 lines 5-8 "As one example, data appliance 102 can determine whether the request is associated with a blocked URL, and if so, prevent download of the package from the remote server." Examiner notes that it is implicit that the request to the server is permitted when not otherwise blocked.).
Allowing download of software packages which are not in violation of policy is a known technique in the art, as demonstrated by DUAN. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the software package security system of ROBINSON, DUAN, NILEKAR, and HACKER with the software package download of DUAN with the motivation to allow trusted downloads to continue. It is obvious to allow download of packages which are deemed trustworthy rather than prevent any downloads of software. Other limitations in this claim are directed to the same limitations claimed in the parent claims, and are given the same motivation to combine as given to those claims above.
Regarding claim 7:
The combination of ROBINSON, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1, wherein determining the risk score associated with the software dependency installation package comprises: querying a vulnerability management database with an identifier for the software dependency installation package (ROBINSON (39) Col 9 lines 61-64 "The categorizer 418 identifies each of the browser extensions ... to determine the risk score associated with them." and "(41) Col 10 lines 27-29 "The correlator 420 uses the list ... in the risk repository 312 to match a browser extension received from a request of the client device 102.").
Regarding claim 8:
ROBINSON teaches:
A non-transitory machine-readable storage medium that provides instructions that, if executed by a processor, will cause said processor to perform operations comprising ((81) Col 17 lines 61-65 "Any machine-readable medium tangibly embodying instructions may be used ...For example, software codes may be stored in a memory. Memory may be implemented within the processor or external to the processor."):
The remainder of the limitations of claim 8 are rejected with the same justification, mutatis mutandis, as its counterpart claim 1.
Regarding claims 10, 12-15, 17, and 19-21:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 1, 3, and 5-8 above.
Claims 2, 4, 9, 11, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over ROBINSON (Doc ID US 11792234 B1), DUAN et al (Doc ID US 11863586 B1), NILEKAR (Doc ID US 20220200962 A1), and HACKER et al (Doc ID US 20240211249 A1) as applied to claims 1, 8, and 15 above, and further in view of ARDILA et al (Doc ID EP 3166279 A1).
Regarding claim 2:
The combination of ROBINSON, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1,
ARDILA teaches the following limitations not taught by the combination of ROBINSON, DUAN, NILEKAR, and HACKER:
further comprising: receiving configuration data from a software dependency management system, the configuration data including settings and parameters for security policies for software dependency installation packages ([0084] "… Upon receiving the configuration input from administrator 12 …"); and
generating a set of policies based on the received configuration data ([0084] "... security management system 10 may automatically generate newly configured … security policies … using policy/rule module 20 (110).").
Generating security policies based on configuration input is a known technique in the art, as demonstrated by ARDILA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the software package security system of ROBINSON, DUAN, NILEKAR, and HACKER with the security policy generation of ARDILA with the motivation to provide the user with the capability of tailoring the types of security policies to be used with the system. It is obvious to generate the security policies based on configuration data acquired from the management system.
Regarding claim 4:
The combination of ROBINSON, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1,
ARDILA teaches the following limitations not taught by the combination of ROBINSON, DUAN, NILEKAR, and HACKER:
further comprising: receiving a set of policies associated with a software dependency management system from a configuration server, wherein one or more policies in the set of policies are associated with a client device identifier ([0067] "… Threat control module 17 may present an interface with security policies and device information stored in ... committed policy database 24. In one example, the interface of FIG. 6C may include a device name 621 ...").
Processing security policies from a server which are associated with a device identification is a known technique in the art, as demonstrated by ARDILA. It would have been obvious to a PHOSITA before the effective filing date of the claimed invention to modify the software package security system of ROBINSON, DUAN, NILEKAR, and HACKER with the device-associated security policies of ARDILA with the motivation to provide the user with the capability of tailoring the types of security policies to the types of devices in use with the system. It is obvious to include device identifiers with the security policies so that an administrator can see at a glance which devices are being affected.
Regarding claims 9, 11, 16, and 18:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 2 and 4 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON BINCZAK whose telephone number is (703)756-4528. The examiner can normally be reached M-F 0800-1700.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/BRANDON BINCZAK/Examiner, Art Unit 2437
Prosecution Insights