DETAILED ACTION
This Action is a response to the filing received 3 October 2024. Claims 1-20 are presented for examination.
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
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 26 March 2025 is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 4-6, 13-17 and 19 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,141,046. Although the claims at issue are not identical, they are not patentably distinct from each other because with some minor variations in language, the subject matter of the identified presently pending claims is read on and obvious over the subject matter in the reference claims.
For example, reference claim 1 recites “receive filtering input for filter policies for the project to filter out specific types of scans and specific types of information from the scans after identifying the addition of the one or more security requirements and/or the removed one or more security requirements.” Presently pending claim 1 does not discuss the filtering input, but such is disclosed in pending claims 13 and 14. These claims describe the filtering out of types of scans and types of information. While they do not specify that the filtering input is “for filter policies for the project,” this is an interpretation of the context of presently pending claims 13 and 14 that is plain and rational based on the plain language of the filtering input. Further, while the pending claims do not recite that the filtering occurs “after identifying” the addition or removal of security requirements, the pending claims do not limit the order in which the filtering occurs with respect to the other operations, and as such the order defined by the pending claim is one possibility presented by the currently pending claims.
Further, currently pending claim 1 recites “wherein the results for the first security vulnerability scan provide a security rating for the one or more security requirements including non, partial and complete.” That the results for the first security vulnerability scan may include “a security rating” for the security requirements is a plain and reasonable interpretation of “results for the first security scan” in the context of evaluating a project against security requirements. Further, that the results may include none, partial and complete merely describes that the rating may indicate a degree of security rating ranging from complete compliance to complete non-compliance, including partial compliance. This is a reasonable interpretation of the range of a “security rating” that results from a security scan based on one or more requirements.
Any other differences between the identified currently pending claims and the identified reference claims are minor variations in language. Complete tables have been provided below comparing the currently pending claims to the reference claims.
Current Application
U.S. 12,141,046
1. A system, comprising: a microprocessor; and a computer readable medium, coupled with the microprocessor and comprising microprocessor readable and executable instructions that, when executed by the microprocessor, cause the microprocessor to:
1. A system, comprising: a microprocessor; and a computer readable medium, coupled with the microprocessor and comprising microprocessor readable and executable instructions that, when executed by the microprocessor, cause the microprocessor to:
receive first input regarding security characteristics of a project;
receive first input regarding security characteristics of a project;
scan the project for one or more security requirements based on the received first input;
scan the project for one or more security requirements based on the received first input;
build a list of security requirements for the project based on the received first input;
build a list of security requirements for the project based on the received first input;
use a machine learning process to identify addition of one or more security requirements and/or removal of one or more security requirements from the list of security requirements;
use a machine learning process to identify addition of one or more security requirements and/or removal of one or more security requirements from the list of security requirements;
13. The system of claim 1, wherein the microprocessor readable and executable instructions further cause the microprocessor to: receive filtering input … filter out one or more scans to be run during the first security vulnerability scan
14. The system of claim 1, wherein the microprocessor readable and executable instructions further cause the microprocessor to: receive filtering input … filter out scan results for scans run during the first security vulnerability scan
receive filtering input for filter policies for the project to filter out specific types of scans and specific types of information from scans after identifying the addition of the one or more security requirements and/or the removed one or more security requirements;
run a first security vulnerability scan using the list of security requirements with the additional one or more security requirements and/or the removed one or more security requirements; and
run a first security vulnerability scan using the list of security requirements with the additional one or more security requirements and/or the removed one or more security requirements; and
generate for display, results for the first security vulnerability scan, wherein the results for the first security vulnerability scan provide a security rating for the one or more security requirements including none, partial and complete.
generate for display, results for the first security vulnerability scan.
NOTE: compare also to similar independent claims 9 and 17
4. The system of claim 1, wherein the additional one or more security requirements are provided to a user to select which of the additional one or more security requirements will be used in the first security vulnerability scan.
2. The system of claim 1, wherein the additional one or more security requirements are provided to a user to select which of the additional one or more security requirements will be used in the first security vulnerability scan.
NOTE: compare also to similar dependent claims 10 and 18
5. The system of claim 4, wherein the selected additional one or more security requirements are stored for a second security vulnerability scan and wherein the selected additional one or more security requirements are associated with a specific type of project in a global repository.
3. The system of claim 2, wherein the selected additional one or more security requirements are stored for a second security vulnerability scan and wherein the selected additional one or more security requirements are associated with a specific type of project in a global repository.
NOTE: compare also to similar dependent claims 11 and 19
6. The system of claim 1, wherein the removal of the one or more security requirements are provided to a user to select which ones of the one or more security requirements will be removed in the first security vulnerability scan.
4. The system of claim 1, wherein the removal of the one or more security requirements are provided to a user to select which ones of the one or more security requirements will be removed in the first security vulnerability scan.
NOTE: compare also to similar dependent claims 12 and 20
13. The system of claim 1, wherein the microprocessor readable and executable instructions further cause the microprocessor to: receive filtering input, wherein the filtering input comprises prescan filter requirements and wherein the prescan filter requirements filter out one or more scans to be run during the first security vulnerability scan.
5. The system of claim 1, wherein the filtering input comprises prescan filter requirements and wherein the prescan filter requirements filter out one or more scans to be run during the first security vulnerability scan.
NOTE: compare also to similar dependent claim 13
14. The system of claim 1, wherein the microprocessor readable and executable instructions further cause the microprocessor to: receive filtering input, wherein the filtering input comprises after-scan filter requirements and wherein the after-scan filter requirements filter out scan results for scans run during the first security vulnerability scan.
6. The system of claim 1, wherein the filtering input comprises after-scan filter requirements and wherein the after-scan filter requirements filter out scan results for scans run during the first security vulnerability scan.
NOTE: compare also to similar dependent claim 14
15. The system of claim 1, wherein scanning the project for the one or more security requirements comprises at least one of: buffer overflow code, code correctness, command injection code, cookie security code, cross-site scripting code, dead code, header manipulation code, insecure randomness code, insecure data storage, insecure transport of data, insecure encryption key management, null deference code, out-of-bounds read code, insecure password management, a system information leak, and a Kubernetes misconfiguration.
7. The system of claim 1, wherein scanning the project for the one or more security requirements comprises at least one of: buffer overflow code, code correctness, command injection code, cookie security code, cross-site scripting code, dead code, header manipulation code, insecure randomness code, insecure data storage, insecure transport of data, insecure encryption key management, null deference code, out-of-bounds read code, insecure password management, a system information leak, and a Kubernetes misconfiguration.
NOTE: compare also to similar dependent claim 15
16. The system of claim 1, wherein building the list of security requirements comprises looking at attribute tags associated with the scan of the project.
8. The system of claim 1, wherein building the list of security requirements comprises looking at attribute tags associated with the scan of the project.
NOTE: compare also to similar dependent claim 16
17. A method, comprising: by a processor [[[performing the operations of the system of claim 1]]]
9. A method, comprising: by a microprocessor [[[performing the operations of the system of claim 1]]]
NOTE: compare also to similar independent claims 1 and 17
19. A non-transient computer readable medium having stored thereon instructions that cause a processor to execute a method, the method comprising instructions to: [[[perform the operations of the system of claim 1]]]
17. A non-transient computer readable medium having stored thereon instructions that cause a processor to execute a method, the method comprising instructions to: [[[perform the operations of the system of claim 1]]]
NOTE: compare also to similar independent claims 1 and 9
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. §§ 102 and 103 (or as subject to pre-AIA 35 U.S.C. §§ 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 7-9, 11-13 and 15-20 are rejected under 35 U.S.C. § 102(a)(1) as being anticipated by Bhalla et al., U.S. 2020/0159525 A1 (“Bhalla”)1.
Regarding claim 1, Bhalla teaches: A system, comprising: a microprocessor; and a computer readable medium, coupled with the microprocessor and comprising microprocessor readable and executable instructions that, when executed by the microprocessor (Bhalla, e.g., ¶30, “a computerized system for automation of task identification for a software asset from context data … at least one processor, at least one memory device … comprising computer readable instructions, that when executed by the at least one processor, cause the at least one processor to …”), cause the microprocessor to:
receive first input regarding security characteristics of a project (Bhalla, e.g., ¶63, “context extraction engine 104 may comprise code scanners, natural language processing tools, machine learning, and other tools …” See also, e.g., ¶69, “software context can also include information relating to the software asset release or change …” and ¶70, “if an organization wants to build a software asset to achieve a specific result, the organization may generate tickets comprising features of what the software asset should do. Tickets written in natural language can become the input to task identification …”);
scan the project for one or more security requirements based on the received first input; build a list of security requirements for the project based on the received first input (Bhalla, e.g., ¶72, “Machine learning and artificial intelligence can also be used to identify relationships between software features and technical context and provide a predicted subset of task requirements for the software asset …” See also, e.g., ¶79, “Software context information that can be gleaned automatically from electronic sources can be used to generate the task list …The knowledge database 108 is a knowledge repository of task guidelines … integration with the knowledge database occurs … during creation of the project, during the requirements phase, design phase … knowledge database 108 contains task requirement information for a wide variety of software applications … and is updated regularly to accommodate real-time requirements and security challenges. The knowledge database 108 comprises a plurality of tasks, with each task having an identification of a coding requirement, security requirement, or regularly requirement, and a recommended strategy for completion of the coding requirement … or remediation of the security requirement …” See also, e.g., ¶81, “selection module 110 is employed to select a plurality of task requirements for the software asset … applicable to the context data stored in the context database 106 for the software asset under development …”);
use a machine learning process to identify addition of one or more security requirements and/or removal of one or more security requirements from the list of security requirements (Bhalla, e.g., ¶81, “selection module 110 can also use … machine learning … to combine and/or match the information in the context database 106 with the tasks in the knowledge database 108 to generate a set of tasks pertinent to the software … Users can also have the capability of actioning the task list and provide a teaching set to the selection module 110 to enhance machine learning … if task T is required whenever certain context is extracted into the database, some users will note that the task is not applicable. The selection module 110 can then use feedback data provided by the developer to assist in task selection for future projects …” See also, e.g., ¶133, “New tasks may be found during the verification or logging of task completion that were not initially captured during context extraction … if the prioritized list excludes a task that a developer adds to the project, system can automatically add the task to the context profile … if a particular requirement is brought into the task list for a project and a developer considers that the task is not relevant to a particular project, the developer can remove the task …”);
run a first security vulnerability scan using the list of security requirements with the additional one or more security requirements and/or the removed one or more security requirements (Bhalla, e.g., ¶112, “Verification of task completion 426 can … be sent to a code scanner … Scanning the code 412 can also identify code vulnerabilities during coding or verification in software development, as well as extract additional context information from the code …”); and
generate for display, results for the first security vulnerability scan, wherein the results for the first security vulnerability scan provide a security rating for the one or more security requirements including none, partial and complete (Bhalla, e.g., ¶112, “If multiple scanners are being used to scan the software code, results from the multiple tools can be aggregated to provide a single verification result … verification result can appear as a flag inside a task view of the prioritized task list … or at various locations on the system graphical user interface …” See also, e.g., ¶113, “The requirements task list can be updated with the status of the tasks to verify task completion 426 based on the verification status of each of the listed tasks on the prioritized task list … a verification status can be multi-fold, and can be given one of a plurality of status levels, such as ‘Verification Pass’, ‘Verification Fail’, ‘Verification Partial Pass’, or ‘Pass’, with further details on how the verification status level was assigned …”).
Claims 17 and 19 are rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 17, Bhalla further teaches: A method, comprising: by a processor [[[performing the operations of the system of claim 1]]] (Bhalla, e.g., ¶111, “a method of automated task identification and verification …”); and with respect to claim 19, Bhalla further teaches: A non-transient computer readable medium having stored thereon instructions that cause a processor to execute a method, the method comprising instructions to: [[[perform the operations of the system of claim 1]]] (Bhalla, e.g., ¶30, “a computerized system for automation of task identification for a software asset from context data … at least one processor, at least one memory device … comprising computer readable instructions, that when executed by the at least one processor, cause the at least one processor to …”).
Regarding claim 2, the rejection of claim 1 is incorporated, and Bhalla further teaches: wherein the machine learning process includes at least one of a K-means clustering algorithm, a supervised machine learning algorithm, an unsupervised machine learning algorithm and a reinforcement machine learning algorithm (Bhalla, e.g., ¶133, “A learning feedback loop 518 can further monitor patterns of context extraction, augmentation, and addition by developers to create a model of context profiles using machine learning and/or artificial intelligence. New tasks may be found during the verification or logging of task completion that were not initially captured during context extraction. The learning feedback loop can then update the task selection so that these tasks are captured in future projects … the machine learning model can be updated when a task is added or removed from the task list, or when matching rules which match extracted context with tasks in the knowledge database are updated …” Examiner’s note: this is an example of a reinforcement machine learning algorithm).
Regarding claim 3, the rejection of claim 1 is incorporated, and Bhalla further teaches: wherein the project includes at least one of components, applications and libraries (Bhalla, e.g., ¶79, “knowledge database 108 contains task requirement information for a wide variety of software applications, contexts, and implementations …”).
Regarding claim 7, the rejection of claim 1 is incorporated, and Bhalla further teaches: wherein for the security rating for the one or more security requirements, a none security rating indicates a category for the project violates none of the one or more security requirements, a partial security rating indicates a category for the project violates some of the one or more security requirements, and a complete security rating indicates a category for the project violates all of the one or more security requirements (Bhalla, e.g., ¶112, “If multiple scanners are being used to scan the software code, results from the multiple tools can be aggregated to provide a single verification result … verification result can appear as a flag inside a task view of the prioritized task list … or at various locations on the system graphical user interface …” See also, e.g., ¶113, “The requirements task list can be updated with the status of the tasks to verify task completion 426 based on the verification status of each of the listed tasks on the prioritized task list … a verification status can be multi-fold, and can be given one of a plurality of status levels, such as ‘Verification Pass’, ‘Verification Fail’, ‘Verification Partial Pass’, or ‘Pass’, with further details on how the verification status level was assigned … A task with ‘Verification Pass’ can be further assessed as low risk and adequately addressed. A task marked as ‘Verification Fail’ can indicate a vulnerability was identified, a task has not been completed correctly or must be addressed, and that the task should be worked on or scrutinized again … A task marked with a ‘Verification Partial Pass’ can indicate that its controls and mitigation instructions need additional effort to confirm it as verified …” Examiner’s note: a verification pass indicates no requirement violated for the particular task (none rating), a verification fail indicates all requirements violated for the particular task which need further effort to fix (complete security rating), and a verification partial pass means at least some issues remain to be addressed or fixed for the particular task (partial security rating)).
Regarding claim 8, the rejection of claim 7 is incorporated, and Bhalla further teaches: wherein the one or more security requirements include confidentiality, integrity (Bhalla, e.g., ¶111, “Prioritization of the task requirements can be based in part on a quantitative measurement algorithm … for denoting risk for a particular weakness, confidentiality, or integrity …”) and availability (Bhalla, e.g., ¶46, “The term ‘task’ refers to any control or requirement for the purpose of compliance, obtaining a functionality, or addressing a risk … Non-limiting examples of non-functional requirements include … availability …”).
Regarding claim 9, the rejection of claim 8 is incorporated, and Bhalla further teaches: wherein the confidentiality security requirement includes confidentiality of data associated with the project (Bhalla, e.g., ¶46, “The term ‘task’ refers to any control or requirement for the purpose of compliance, obtaining a functionality, or addressing a risk … Non-limiting examples of non-functional requirements include … privacy (compliance to privacy laws) …”), the integrity security requirement includes integrity of data associated with the project (Bhalla, e.g., ¶46, “The term ‘task’ refers to any control or requirement for the purpose of compliance, obtaining a functionality, or addressing a risk … Non-limiting examples of non-functional requirements include … data integrity …”) and the availability security requirement includes availability of the project (Bhalla, e.g., ¶46, “The term ‘task’ refers to any control or requirement for the purpose of compliance, obtaining a functionality, or addressing a risk … Non-limiting examples of non-functional requirements include … availability …”).
Claims 18 and 20 are rejected for the additional reasons given in the rejection of claim 9 above (incorporating the rejections of claims 7 and 8).
Regarding claim 11, the rejection of claim 9 is incorporated, and Bhalla further teaches: wherein when the project includes data stored in a database that can be corrupted (Bhalla, e.g., ¶45, “term ‘software asset’ … Examples of software assets include but are not limited to … database …” See also, e.g., ¶54, “software context describes the characteristics of the software asset, including but not limited to the language, function, regulatory requirements, and connections of the software asset. In an example, an application or system may be described as having a set of attributes describing its behavior and state, which is more broadly defined as its ‘context’. Consider the set C containing the software context for a software asset … composed of n possible ways to describe a system or application … the set of context data C can be defined as:” and ¶¶55-61, “C={c1, … ci, … cn; 1<i<n}, where each ci context item contains context behavior or state about the software asset or application, and the values ci can be: … c3: The application makes use of a database …”), the scan of the project includes the integrity security requirement with a complete security rating (Bhalla, e.g., ¶113, “The requirements task list can be updated with the status of the tasks to verify task completion 426 based on the verification status of each of the listed tasks on the prioritized task list … a verification status can be multi-fold, and can be given one of a plurality of status levels, such as ‘Verification Pass’, ‘Verification Fail’, ‘Verification Partial Pass’, or ‘Pass’, with further details on how the verification status level was assigned … A task with ‘Verification Pass’ can be further assessed as low risk and adequately addressed. A task marked as ‘Verification Fail’ can indicate a vulnerability was identified, a task has not been completed correctly or must be addressed, and that the task should be worked on or scrutinized again … A task marked with a ‘Verification Partial Pass’ can indicate that its controls and mitigation instructions need additional effort to confirm it as verified …” Examiner’s note: a verification pass indicates no requirement violated for the particular task (none rating), a verification fail indicates all requirements violated for the particular task which need further effort to fix (complete security rating), and a verification partial pass means at least some issues remain to be addressed or fixed for the particular task (partial security rating)).
Regarding claim 12, the rejection of claim 9 is incorporated, and Bhalla further teaches: wherein when the project includes an application that is to continuously run in a cloud service (Bhalla, e.g., ¶46, “The term ‘task’ refers to any control or requirement for the purpose of compliance, obtaining a functionality, or addressing a risk … Non-limiting examples of non-functional requirements include … availability, capacity … dependency, deployment, deployment environment, disaster recovery … durability, efficiency (resource consumption for given load) … fault tolerance (e.g. operational system monitoring, measuring, and management) … maintainability (e.g. mean time to repair—MTTR), management, modifiability, network topology, operability, performance and/or response time (performance engineering), platform compatibility … reliability … resilience, resource constraints … response time … scalability … throughput …” Examiner’s note: these examples of non-functional requirements are descriptive of an application continuously run in a distributed networked (cloud) service), the scan of the project includes the availability security requirement with a complete security rating (Bhalla, e.g., ¶113, “The requirements task list can be updated with the status of the tasks to verify task completion 426 based on the verification status of each of the listed tasks on the prioritized task list … a verification status can be multi-fold, and can be given one of a plurality of status levels, such as ‘Verification Pass’, ‘Verification Fail’, ‘Verification Partial Pass’, or ‘Pass’, with further details on how the verification status level was assigned … A task with ‘Verification Pass’ can be further assessed as low risk and adequately addressed. A task marked as ‘Verification Fail’ can indicate a vulnerability was identified, a task has not been completed correctly or must be addressed, and that the task should be worked on or scrutinized again … A task marked with a ‘Verification Partial Pass’ can indicate that its controls and mitigation instructions need additional effort to confirm it as verified …” Examiner’s note: a verification pass indicates no requirement violated for the particular task (none rating), a verification fail indicates all requirements violated for the particular task which need further effort to fix (complete security rating), and a verification partial pass means at least some issues remain to be addressed or fixed for the particular task (partial security rating)).
Regarding claim 13, the rejection of claim 1 is incorporated, and Bhalla further teaches: wherein the microprocessor readable and executable instructions further cause the microprocessor to: receive filtering input, wherein the filtering input comprises prescan filter requirements and wherein the prescan filter requirements filter out one or more scans to be run during the first security vulnerability scan (Bhalla, e.g., ¶80, “Each task in the knowledge database 108 has tags delineating its relevance to a particular software context so that the tasks required for a particular software asset can be generated based on the context data of the software asset in the context database 106 …” See also, e.g., ¶111, “Relevant tasks are selected based on the context of the software asset, for example if the jurisdiction of the software is limited to Europe, then only tasks relevant to European-based requirements and standards will be selected, and not those specific to other jurisdictions …” and ¶112, “Verification of task completion 426 can be done … sent to a code scanner … Scanning the code 412 can also identify code vulnerabilities …”).
Regarding claim 15, the rejection of claim 1 is incorporated, and Bhalla further teaches: wherein scanning the project for the one or more security requirements comprises at least one of: buffer overflow code, code correctness, command injection code, cookie security code, cross-site scripting code, dead code, header manipulation code, insecure randomness code, insecure data storage, insecure transport of data, insecure encryption key management, null deference code, out-of-bounds read code, insecure password management, a system information leak, and a Kubernetes misconfiguration (Bhalla, e.g., ¶76, “a code scanner such as FortifyTM tracks analysis facts ct about an application where ct is a weakness detected in the application, such as by SQL injection, or by Insecure Transport …”).
Regarding claim 16, the rejection of claim 1 is incorporated, and Bhalla further teaches: wherein building the list of security requirements comprises looking at attribute tags associated with the scan of the project (Bhalla, e.g., ¶115, “From the context database 502 is created a link to the project 504, which includes a location where project settings can be updated 506, and a location where the software context can be updated 508 … a context database contains extracted context about the software asset defined as …” and ¶116, “Ccontext={c1, …, cj …” Examiner’s note: this context array comprises attribute tags).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 4-6 are rejected under 35 U.S.C. § 103 as being unpatentable over Bhalla in view of Tracy et al., U.S. 2004/0102923 A1 (“Tracy”)2.
Regarding claim 4, the rejection of claim 1 is incorporated, but Bhalla does not more specifically teach that the additional security requirements are presented to a user to select which of the additional security requirements will be included in the first security vulnerability scan. However, Tracy does teach: wherein the additional one or more security requirements are provided to a user to select which of the additional one or more security requirements will be used in the first security vulnerability scan (Tracy, e.g., ¶66, “requirements analysis generally involves selecting (by a human and/or some automated procedure) a list of standards and/or regulations … Selection of additional standards/regulations and/or requirements by a user is also contemplated … requirement(s) can be displayed …”) for the purpose of providing a semi-automated method for identifying appropriate security requirements, permitting the user to provide input regarding required and irrelevant requirements, and determining whether one or more software assets complies with the identified requirements set (Tracy, e.g., ¶¶10-18, 60-70).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for automated security requirements-based task identification as taught by Bhalla to provide that the additional security requirements are presented to a user to select which of the additional security requirements will be included in the first security vulnerability scan because the disclosure of Tracy shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for automatically identifying and certifying security requirements compliance to provide that the additional security requirements are presented to a user to select which of the additional security requirements will be included in the first security vulnerability scan for the purpose of providing a semi-automated method for identifying appropriate security requirements, permitting the user to provide input regarding required and irrelevant requirements, and determining whether one or more software assets complies with the identified requirements set (Tracy, Id.).
Regarding claim 5, the rejection of claim 4 is incorporated, and Bhalla further teaches: wherein the selected additional one or more security requirements are associated with a specific type of project in a global repository (Bhalla, e.g., ¶79, “knowledge database 108 contains task requirement information for a wide variety of software applications, contexts, and implementations …”).
Bhalla does not more particularly teach that the selected additional security requirements are stored for a second vulnerability scan. However, Tracy does teach: wherein the selected additional one or more security requirements are stored for a second security vulnerability scan (Tracy, e.g., ¶68, “the user can (continue to) add, delete and/or edit requirements … during performance of these steps, as well as subsequent to these steps upon, for example, receiving a new or updated … requirement …”) for the purpose of providing a semi-automated method for identifying appropriate security requirements, permitting the user to provide input regarding required and irrelevant requirements, and determining whether one or more software assets complies with the identified requirements set (Tracy, e.g., ¶¶10-18, 60-70).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for automated security requirements-based task identification as taught by Bhalla to provide that the selected additional security requirements are stored for a second vulnerability scan because the disclosure of Tracy shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for automatically identifying and certifying security requirements compliance to provide that the selected additional security requirements are stored for a second vulnerability scan for the purpose of providing a semi-automated method for identifying appropriate security requirements, permitting the user to provide input regarding required and irrelevant requirements, and determining whether one or more software assets complies with the identified requirements set (Tracy, Id.).
Regarding claim 6, the rejection of claim 1 is incorporated, but Bhalla does not more particularly teach that removal of one or more security requirements occurs by providing to a user an option to select which of the one or more security requirements will be removed from the first security vulnerability scan. However, Tracy does teach: wherein the removal of the one or more security requirements are provided to a user to select which ones of the one or more security requirements will be removed in the first security vulnerability scan (Tracy, e.g., ¶68, “the user can (continue to) add, delete and/or edit requirements … during performance of these steps, as well as subsequent to these steps upon, for example, receiving a new or updated … requirement …”) for the purpose of providing a semi-automated method for identifying appropriate security requirements, permitting the user to provide input regarding required and irrelevant requirements, and determining whether one or more software assets complies with the identified requirements set (Tracy, e.g., ¶¶10-18, 60-70).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for automated security requirements-based task identification as taught by Bhalla to provide that removal of one or more security requirements occurs by providing to a user an option to select which of the one or more security requirements will be removed from the first security vulnerability scan because the disclosure of Tracy shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for automatically identifying and certifying security requirements compliance to provide that removal of one or more security requirements occurs by providing to a user an option to select which of the one or more security requirements will be removed from the first security vulnerability scan for the purpose of providing a semi-automated method for identifying appropriate security requirements, permitting the user to provide input regarding required and irrelevant requirements, and determining whether one or more software assets complies with the identified requirements set (Tracy, Id.).
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Bhalla in view of Hicks et al., U.S. 2022/0035929 A1 (“Hicks”).
Regarding claim 10, the rejection of claim 9 is incorporated, and Bhalla further teaches: [the scan includes confidentiality security requirement] with a complete security rating (Bhalla, e.g., ¶113, “The requirements task list can be updated with the status of the tasks to verify task completion 426 based on the verification status of each of the listed tasks on the prioritized task list … a verification status can be multi-fold, and can be given one of a plurality of status levels, such as ‘Verification Pass’, ‘Verification Fail’, ‘Verification Partial Pass’, or ‘Pass’, with further details on how the verification status level was assigned … A task with ‘Verification Pass’ can be further assessed as low risk and adequately addressed. A task marked as ‘Verification Fail’ can indicate a vulnerability was identified, a task has not been completed correctly or must be addressed, and that the task should be worked on or scrutinized again … A task marked with a ‘Verification Partial Pass’ can indicate that its controls and mitigation instructions need additional effort to confirm it as verified …” Examiner’s note: a verification pass indicates no requirement violated for the particular task (none rating), a verification fail indicates all requirements violated for the particular task which need further effort to fix (complete security rating), and a verification partial pass means at least some issues remain to be addressed or fixed for the particular task (partial security rating). Examiner further notes that while lacking certain specific details, Bhalla does disclose a data confidentiality requirement (e.g., data privacy / compliance with privacy laws)).
Bhalla does not more particularly teach that the scan of the project includes the confidentiality security requirement when the project includes data with encrypted and restricted access. However, Hicks does teach: wherein when the project includes data with encrypted and restricted access, the scan of the project includes the confidentiality security requirement (Hicks, e.g., ¶179, “identify category includes the sub-categories of … risk assessment … access control … and data security …” See also, e.g., ¶180, “evaluation rating metrics (e.g., how the system, or portion thereof, is evaluated) includes a selection of process, policy, procedure, certification … allows the analysis system to quantify its evaluation … to generate an evaluation rating …” See also, e.g., ¶183, “analysis system module 17 communicates with physical assets of the system to discover the data … to obtain data regarding data segregation & boundary … encryption, identify & access management … and/or data protection.” See also, e.g., ¶185, “analysis system module 17 provides the gathered data to the analysis computing entity 16 … gathered data is processed alone, in combination with stored data (of the system being evaluated … in combination with analysis modeling (e.g., risk modeling, data flow modeling, security modeling, etc.) … analysis computing entity 16 produces an evaluation rating, to identify deficiencies, and/or to auto-correct deficiencies …”) for the purpose of evaluating a system in numerous ways, including evaluating an organization’s understanding of its system, requirements, security, policies and other aspects in order to provide compliance ratings and identify issues and vulnerabilities (Hicks, e.g., ¶¶168-191).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for automated security requirements-based task identification as taught by Bhalla to provide that the scan of the project includes the confidentiality security requirement when the project includes data with encrypted and restricted access because the disclosure of Hicks shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for evaluating a software and/or computing system based on a defined set of analysis parameters to provide that the scan of the project includes the confidentiality security requirement when the project includes data with encrypted and restricted access for the purpose of evaluating a system in numerous ways, including evaluating an organization’s understanding of its system, requirements, security, policies and other aspects in order to provide compliance ratings and identify issues and vulnerabilities (Hicks, Id.).
Claim 14 is rejected under 35 U.S.C. § 103 as being unpatentable over Bhalla in view of Blass et al., U.S. 2020/0364348 A1 (“Blass”)3.
Regarding claim 14, the rejection of claim 1 is incorporated, but Bhalla does not more particularly teach receiving filtering input comprising after scan filter requirements which filter out scan results for scans run during the first security vulnerability scan. However, Blass does teach: wherein the microprocessor readable and executable instructions further cause the microprocessor to: receive filtering input, wherein the filtering input comprises after-scan filter requirements and wherein the after-scan filter requirements filter out scan results for scans run during the first security vulnerability scan (Blass, e.g., ¶29, “scanner 300 can receive whitelist 308 … comprise parameters or other configuration data identifying artifacts 202 or portions of artifacts 202 to be ignored for vulnerability encoding purposes … receive whitelist 308 through … graphical user interfaces …” See also, e.g., ¶30, “Whitelist 308 can enable software developers to highlight false positive results … can be used as a filter for scanning results 302, such that whitelisted vulnerabilities are … not encoded …” and ¶31, “markers at lines 3 and 7 can instruct scanner 300 to suppress the reporting of security vulnerability at line 5 … by filtering scanning results 302 to remove any vulnerabilities reported between lines 3 and 7”) for the purpose of providing a machine-assisted method for identifying vulnerable software assets, permitting developer users to whitelist false positive security vulnerability identifications and reports, and to provide suggested means for remediating the non-whitelisted security vulnerabilities identified in the scan (Blass, e.g., ¶¶8-11, 25-31).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system and method for automated security requirements-based task identification as taught by Bhalla to provide for receiving filtering input comprising after scan filter requirements which filter out scan results for scans run during the first security vulnerability scan because the disclosure of Blass shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for identifying vulnerable software assets and preventing their deployment prior to remediation to provide for receiving filtering input comprising after scan filter requirements which filter out scan results for scans run during the first security vulnerability scan for the purpose of providing a machine-assisted method for identifying vulnerable software assets, permitting developer users to whitelist false positive security vulnerability identifications and reports, and to provide suggested means for remediating the non-whitelisted security vulnerabilities identified in the scan (Blass, Id.).
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191
1 As this reference is cited on the IDS filed 26 March 2025, it is not cited on the attached PTO-892
2 As this reference is cited on the IDS filed 26 March 2025, it is not cited on the attached PTO-892
3 As this reference is cited on the IDS filed 26 March 2025, it is not cited on the attached PTO-892
