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 .
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 12/30/2025 has been entered.
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.
Response to Arguments
Applicant’s arguments, see page 10, filed 12/30/2025, with respect to the rejection of claims 1-21 under 35 USC 112(a) have been fully considered and are persuasive. The associated rejections to the listed claim(s) have been withdrawn.
Applicant’s arguments, see pages 10-12, filed 12/30/2025, with respect to the rejection of claims 1-21 under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of NILEKAR (Doc ID US 20220200962 A1) and HACKER et al (Doc ID US 20240211249 A1).
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-21 are rejected under 35 U.S.C. 112(a) as failing to comply with the enablement requirement. The claims contain subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Regarding claims 1, 8, and 15:
Claim 1 recites, “… determining a risk score …; determining a first user identifier …; determining a software license …”. The claim goes on to recite, “… identifying a first policy associated with the first user identifier …; determining, based on the determined risk score associated with the software dependency installation package and the determined software license, that the software dependency installation package violates the first policy …”. Claims 8 and 15 recite similar language. The limitation of determining a policy, directed to a user identifier, has been violated based on a risk score and software license information is not enabled; See MPEP § 2164.
The test of enablement is whether one reasonably skilled in the art could make or use the invention from the disclosures in the patent coupled with information known in the art without undue experimentation; United States v. Telectronics, Inc., 857 F.2d 778, 785, 8 USPQ2d 1217, 1223 (Fed. Cir. 1988). The factors to be considered when determining whether there is sufficient evidence to support a determination that a disclosure does not satisfy the enablement requirement and whether any necessary experimentation is “undue” include, but are not limited to: (a) the breadth of the claims; (b) the nature of the invention; (c) the state of the prior art; (d) the level of one of ordinary skill; (e) the level of predictability in the art; (f) the amount of direction provided by the inventor; (g) the existence of working examples; and (h) the quantity of experimentation needed to make or use the invention based on the content of the disclosure; In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988).
As to (a) the breadth of the claims, the current scope of the claims encompasses requests for software dependency packages, where a risk score and license information associated with the package, and a user identifier associated with the request, are determined. Also within the scope of the claims are policies and policy violations directed to user identifiers. The breadth of the claims, on its own, does not require undue experimentation.
As to (b) the nature of the invention, it is presented as an automatic process which obtains the risk score, license, and identification, identifies a policy directed to the user identification, and determines a policy violation based on the risk score and license. The nature of this determination is not known in the art, and would require undue experimentation for one skilled in the art to achieve these results.
As to (c) the state of the prior art and (d) the level of skill in the art, the general state and level of skill in the computer security policy art is generally expansive. The state of the art and level of skill in the art do not by themselves warrant undue experimentation.
As to (e) the level of predictability in the art, the overall predictability of the computer security policy art is high. The level of predictability does not, by itself, warrant undue experimentation.
As to (f) the amount of direction provided by the inventor, none is provided. Direction in the specification is limited to determining a violation of policy as one skilled in the art would expect (i.e. a high risk score violating a policy related to risk scores). Undue experimentation would be required in light of the light of direction by the inventor.
As to the (g) existence of working examples, none are provided. The drawings are silent regarding the use of user identification as part of a policy which may be violated.
As to the (h) quantity of experimentation needed, there is no particular evidence in the record to indicate the quantity of experimentation that one of ordinary skill in the art would need to implement the present invention. However, analysis of this factor in light of the other factors present suggest the amount of experimentation required to make and use the invention is undue.
The majority of factors for which there is evidence suggest that undue experimentation is required. After weighing all of the factors and all the evidence of record, the totality of the evidence suggests that it would require undue experimentation to make and use the claimed invention.
Regarding claims 2-7, 9-14, and 16-21:
They are dependent on one or more rejected claims, and thus inherit those rejections. This rejection could be overcome by overcoming the rejection(s) to any claims upon which these claims depend, or by amending the claims such that they are no longer dependent on any rejected claim.
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, 5-8, 12-15, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over ROSENDAHL et al (Doc ID US 20200110873 A1), and further in view of DUAN et al (Doc ID US 11863586 B1), BETTINI et al (Doc ID US 20130347094 A1), NILEKAR (Doc ID US 20220200962 A1) and HACKER et al (Doc ID US 20240211249 A1).
Regarding claim 1:
ROSENDAHL teaches:
determining a risk score associated with the software dependency installation package ([0097] "The threat level analyzer container 120 generates a threat level assessment score based on the probed results.");
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 policy ([0058] "... response engine 142 responds to a high threat level ... by performing an action ... such as … 2) freezing network access for the app container 104 (e.g., by blocking all network transmissions) …"); and
storing a log entry in an auditing system, the log entry including data indicating the blocking of the first request ([0098] "The threat level analyzer container 120 generates 440 a report to present in a user interface. … which is further illustrated in ... FIGS. 2A-2C.").
DUAN teaches the following limitation(s) not taught by ROSENDAHL:
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 software, 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 ROSENDAHL. Further, processing requests for software 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 package threat assessment of ROSENDAHL with the software package request system of DUAN with the motivation to monitor and filter requested software packages for violations of policy. It is obvious to determine whether a requested software package represents a threat before allowing it to be downloaded.
NILEKAR teaches the following limitations not taught by the combination of ROSENDAHL and DUAN:
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 ([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.");
Using policies based on users 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 package security system of ROSENDAHL 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 combination of ROSENDAHL, DUAN, and NILEKAR:
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 …");
determining, based on the determined risk score associated with the software dependency installation package and the determined software license, that the software dependency installation package violates the first policy ([0030] "... a rule on license compliance specifies software materials are incompliant if under one or more certain software licenses … and/or software license version …" and [0040] "… a rule on vulnerability specifies that a software material is incompliant if a vulnerability at or above a vulnerability severity score is identified ...");
Using policies based on software licenses, and identifying policy violations are known techniques 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 package security system of ROSENDAHL, 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 5:
The combination of ROSENDAHL, 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 ROSENDAHL, 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 ROSENDAHL, 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 a 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 (ROSENDAHL [0097] "The threat level analyzer container 120 generates a threat level assessment score based on the probed results.");
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 (HACKER [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 …");
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 (ROSENDAHL [0058] "... response engine 142 responds to a high threat level ... by performing an action ... such as … 2) freezing network access for the app container 104 …". Examiner notes that it is implicit that scores not exceeding the threshold do not violate policy.); and
transmitting the second request to a software dependency manager in response to determining that the second software dependency installation package conforms to the 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 ROSENDAHL, 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.
Regarding claim 7:
The combination of ROSENDAHL, 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 (ROSENDAHL [0038] "… Vulnerabilities may lie ... within ... program libraries 110, components of program libraries 110, container configuration data 114, program libraries 152, ..., and so on. These vulnerabilities may be referred to as ... (CVEs). ... threat database 132 includes a database of CVE identifiers ... used to identify the associated CVEs ...").
Regarding claim 8:
ROSENDAHL 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, comprising ([0103] "The storage unit 516 includes a machine-readable medium 522 on which is stored instructions 524 .... The instructions 524 may also reside ... within the processor 502 … during execution …"):
The remainder of the limitations of claim 8 are rejected with the same justification, mutatis mutandis, as its counterpart claim 1.
Regarding claims 12-15 and 19-21:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claims 5-8 above.
Claims 2, 4, 9, 11, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over ROSENDAHL et al (Doc ID US 20200110873 A1), DUAN et al (Doc ID US 11863586 B1), BETTINI et al (Doc ID US 20130347094 A1), 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 ROSENDAHL, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1,
ARDILA teaches the following limitations not taught by the combination of ROSENDAHL, 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 ROSENDAHL, 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 ROSENDAHL, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1,
ARDILA teaches the following limitations not taught by the combination of ROSENDAHL, 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 ROSENDAHL, 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.
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over ROSENDAHL et al (Doc ID US 20200110873 A1), DUAN et al (Doc ID US 11863586 B1), BETTINI et al (Doc ID US 20130347094 A1), 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 COOLEY (Doc ID US 9154520 B1).
Regarding claim 3:
The combination of ROSENDAHL, DUAN, NILEKAR, and HACKER teaches:
The computer-implemented method of claim 1,
COOLEY teaches the following limitations not taught by the combination of ROSENDAHL, DUAN, NILEKAR, and HACKER:
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 (Col 9 lines 21-25 "... at step 308 one or more of the systems ... provide the endpoint device with at least one notification indicating that the attempt … to download the file has been blocked based … on the potential policy violation …").
Sending a notification of a blocked software package download is a known technique in the art, as demonstrated by COOLEY. 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 ROSENDAHL, DUAN, NILEKAR, and HACKER with the blocked package notification of COOLEY with the motivation to provide the user with knowledge of a blocked download. It is obvious to provide notification so that a user is aware of why a requested package is not delivered, rather them believe there is an error in the system.
Regarding claims 10 and 17:
These claims are rejected with the same justification, mutatis mutandis, as their counterpart claim 3 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.
/BB/Examiner, Art Unit 2437
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437