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 .
DETAILED ACTION
1. This action is responsive to: an original application filed on 12 May 2025.
2. Claims 1-20 are currently pending and rejected.
Information Disclosure Statement
3. The information disclosure statement (IDS) submitted on 12 June 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
4. No Priority claimed.
Drawings
5. The drawings filed on 12 May 2025 are accepted by the examiner.
Double Patenting
6. 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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents /process/ file/efs/guidance /eTD-info-I.jsp.
Claims 1-20 are rejected under the grounds of non-statutory obviousness-type double patenting, as they are deemed unpatentable over claims 1-20 of US Patent application No. 18635144. Although the conflicting claims are not identical, they are considered not patentably distinct from one another, as they convey the same inventive concept. Specifically, both sets of claims disclose a method for security risk assessment using Large Language modeling. Furthermore, it would have been obvious to one of ordinary skill in the art, at the time of the invention’s filing, to employ this approach to prevent and protect data from malware and network security, thereby rendering the claims unpatentable.
Claim Rejections - 35 USC § 103
7. 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-20 are rejected under 35 U.S.C §103 as being unpatentable over Eshman et al. (US Publication No. 20240039946), hereinafter Eshman and in view of Lance Mueller (US Publication No. 20230419223), hereinafter Mueller.
Regarding claim 1:
A computer implemented method of assessing a real time security risk from an external computing environment interfacing with a target computing environment, comprising (Eshman, abstract):
asking a large language model (LLM) to generate for each value of a plurality of values of each risk metric of a plurality of risk metrics, at least one question that is correlated with an answer related to said each value of said each risk metric (Eshman, ¶5, FIG.1), operations include generating a set of cybersecurity questions based on the industry type of a small business, transmitting the set of cybersecurity questions to a computing device of a representative of the business, and dynamically updating the set of cybersecurity questions to remove an irrelevant question determined based on a response to one or more other questions, generating a score based on answers to the set of cybersecurity questions that captures cyberattack readiness, determining a recommendation that reduces cybersecurity risk based on the answers to the set of cybersecurity questions, and conveying the score and recommendation to the computing device of the representative of the business
wherein each of the plurality of risk metrics is indicative of a security risk associated with the external computing environment interfacing with the target computing environment (Eshman, ¶53, ¶23), determines a score based on the input and result of the technology stack evaluation. In one embodiment, the score can be deemed a cybersecurity score that captures the readiness for a cyberattack or, in other words, the capacity to defend against a cyberattack. The cybersecurity score can also capture a level of compliance with applicable regulatory requirements. Alternatively, separate cybersecurity and compliance scores can be determined. The score can be a number (e.g., 1-100), letter (e.g., A, A+, B, C), or class or category (e.g., poor, fair, good, excellent). The score can be determined from various factors associated with the input and result of the technology stack evaluation. For example, an operating system version, presence or absence of virus protection, and password policy can be factors. Further, various weights can be associated with factors such that one factor can influence the score more than another factor.
obtaining a plurality of questions from the LLM, generated following said asking (Eshman, ¶19), cybersecurity assessment and remediation. In one embodiment, the cybersecurity assessment and remediation can be included as part of a tool for owners and employees of sole proprietorships or small businesses. The tool can generate an electronic questionnaire or form comprising a plurality of questions regarding the business and technology stack employed by the business. Further, the questionnaire can be dynamically responsive to input, including industry type, to focus on questions relevant to a business entity. Questionnaire responses can form the basis for generating a score and recommendation related to cyberattack readiness. The business technology stack can also be evaluated or tested.
obtaining a plurality of responses to the plurality of questions (Eshman, ¶19), The tool can generate an electronic questionnaire or form comprising a plurality of questions regarding the business and technology stack employed by the business. Further, the questionnaire can be dynamically responsive to input, including industry type, to focus on questions relevant to a business entity
Eshman does not explicitly suggest, analyzing mismatches between the plurality of responses and the plurality of values of the plurality of risk metrics; however, in a same field of endeavor Mueller discloses this limitation (Mueller, ¶85, claim 1), wherein processing questionnaire mapping and evidence collection results; receiving results of a vendor interview to close any potential gaps that are already identified; generating a draft vendor security risk report including a digital trust score; receiving a vendor security risk assessment response to verify a accuracy of the vendor risk report; generating a graphical representation of said digital trust score for display on a display device; and publishing a final vendor security risk assessment report including said graphical representation of said digital trust score.
Eshman does not explicitly suggest, computing a plurality of weights, each weight is associated with a risk metric for which a mismatch is identified, and computing an assessment of a real time security risk as an aggregation of the plurality of weights; however, in a same field of endeavor Mueller discloses this limitation (Mueller, ¶87), wherein, The data structure comprises a matrix of the categories, arranged in rows in FIG. 3 and rules arranged in columns in FIG. 3 that include, for example, degradation intervals 131 and degradation values 132 which establish weights for those items within a security category. The algorithm tracks the date 133 at which each item was visited, the age of the item 134, whether the item is evidence 135, the evidence grade for evidence 136, and whether the item was reviewed by an attorney or a member of the digital trust ecosystem 137. A final grade 138 is calculated for each item based on weightings of the various rules, and the grades for all categories are combined to generate the digital trust score 139. Those skilled in the art will appreciate that other factors may be used to evaluate categories and items within categories when determining the digital trust score. As well, other categories and items may be used as appropriate. The matrix represented by the data structure receives multidimensional time varying data and applies rules in real time to the data to generate the digital trust score. The cybersecurity risk assessment system generates a graphic display of the digital trust score.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of cybersecurity assessment and remediation 0f Eshman with the method of establishing weight for the security category disclosed in Mueller to identify risk factor as High, low or moderate, stated by Mueller at para.123.
Regarding claim 2:
wherein the plurality of risk metrics include at least one parameter indicating interaction between the external computing environment and the target computing environment, the at least one parameter defined according to a scope of interaction defining authorized interactions, wherein the mismatches indicate drift of the scope, and the assessment of the real time security risk indicates whether the drift of the scope is associated with increased security risk (Eshman, ¶43).
Regarding claim 3:
wherein the at least one parameter is extracted from a monitoring of touchpoints by the external computing environment and/or extracted from a monitoring of interfaces for defined data hosted by the target computing environment (Eshman, ¶34. ¶55).
Regarding claim 4:
wherein the plurality of responses to the plurality of questions represent best practices, and analyzing mismatches indicate benchmarking against the best practices (Eshman, ¶36).
Regarding claim 5:
wherein computing the assessment of the real time security risk comprises comparing the real time security risk to at least one of: best practices, defined risk threshold, defined policy, and actual engagement with the external computing environment (Eshman, ¶4).
Regarding claim 6:
wherein computing the assessment of the real time security risk comprises, identifying a plurality of real-time security risks according to the plurality of weights, ranking the plurality of real-time security risks according to the plurality of weights, and prioritizing recommendations for mitigation of at least one highest ranked real-time security risk (Eshman, ¶63).
Regarding claim 7:
further comprising automatically generating a report including at least one of: the plurality of values of the plurality of risk metrics, the plurality of questions, the plurality of responses, the mismatches, the plurality of weights, and the assessment of the real time security risk (Eshman, ¶55).
Regarding claim 8:
further comprising: defining a baseline according to the assessment of the real time security risk; iterating the computing the assessment of the real time security risk over a time interval by computing a current real time security risk; and monitoring changes and/or a trend of current real time security risk over the time interval (Eshman, ¶5).
Regarding claim 9:
wherein monitoring changes and/or the trend comprises computing a distance between the current real time security risk and the baseline, and analyzing the distance for detecting a significant change in security risk (Eshman, ¶48).
Regarding claim 10:
wherein the target computing environment is divided into a plurality of virtual boundaries each interacting with the external computing environment, wherein the assessment of the real time security risk is computed per virtual boundary (Eshman, ¶76).
Regarding claim 11:
wherein the external computing environment is one of a plurality of external computing environments, wherein the assessment of the real time security risk is computed for each of the plurality of external computing environments, and further comprising identifying at least one unsanctioned external computing environment, and generating an indication of the at least one unsanctioned external computing environment associated with the assessment of the real time security risk meeting a criteria (Eshman, ¶24).
Regarding claim 12:
wherein the assessment of the real time security risk is further computed based on profiles of external computing environments combined with assessed relationship scope extracted from the plurality of values of the plurality of risk metrics (Eshman, ¶23-24).
Regarding claim 13:
further comprising automatically generating, by a natural language processing (NLP) model and/or another LLM, a step-by-step remediation plan for reducing or eliminating the real time security risk, wherein the step-by-step remediation plan is at least one of: written in human readable language for implementation by a human, and code and/or a script for implementation by an automated process (Eshman, ¶48).
Regarding claim 14:
wherein the plurality of values of the plurality of risk metrics are automatically extracted and/or computed by at least one code sensor configured for automatically requesting gated access to security and/or compliance documents and/or datasets, and for autonomously gathering the security and/or compliance documents and/or datasets (Eshman, ¶48).
Regarding claim 15:
further comprising analyzing spending by the target computing environment on the services provided by the external computing environment and/or on security, for improving spending efficiency by optimizing costs while maintaining risk compliance (Eshman, ¶48).
Regarding claim 16:
further comprising, computing a statistical distance for mismatches between the plurality of responses and the plurality of values of the plurality of risk metrics, identifying at least one risk metric with highest statistical distance, and linking the at least one risk metric with highest statistical distance to a potential trigger event (Eshman, ¶41, ¶4).
Regarding claim 17:
wherein at least one risk metric is based on mapping and/or tracking dependencies beyond direct external computing environments, and the assessment of the real time security risk indicates risk in a supply chain ecosystem (Eshman, ¶3).
Regarding claim 18:
wherein the LLM is further fed existing real time data, and instructed to eliminate redundant questions by dynamically adapting to the existing real time data by focusing on what is missing. (Eshman, ¶5).
Regarding claim 19:
at least one processor executing a code for (Eshman, ¶4): asking a large language model (LLM) to generate for each value of a plurality of values of each risk metric of a plurality of risk metrics, at least one question that is correlated with an answer related to said each value of said each risk metric (Eshman, ¶5, FIG.1), operations include generating a set of cybersecurity questions based on the industry type of a small business, transmitting the set of cybersecurity questions to a computing device of a representative of the business, and dynamically updating the set of cybersecurity questions to remove an irrelevant question determined based on a response to one or more other questions, generating a score based on answers to the set of cybersecurity questions that captures cyberattack readiness, determining a recommendation that reduces cybersecurity risk based on the answers to the set of cybersecurity questions, and conveying the score and recommendation to the computing device of the representative of the business
wherein each of the plurality of risk metrics is indicative of a security risk associated with the external computing environment interfacing with the target computing environment (Eshman, ¶53, ¶23), determines a score based on the input and result of the technology stack evaluation. In one embodiment, the score can be deemed a cybersecurity score that captures the readiness for a cyberattack or, in other words, the capacity to defend against a cyberattack. The cybersecurity score can also capture a level of compliance with applicable regulatory requirements. Alternatively, separate cybersecurity and compliance scores can be determined. The score can be a number (e.g., 1-100), letter (e.g., A, A+, B, C), or class or category (e.g., poor, fair, good, excellent). The score can be determined from various factors associated with the input and result of the technology stack evaluation. For example, an operating system version, presence or absence of virus protection, and password policy can be factors. Further, various weights can be associated with factors such that one factor can influence the score more than another factor.
obtaining a plurality of questions from the LLM, generated following said asking (Eshman, ¶19), cybersecurity assessment and remediation. In one embodiment, the cybersecurity assessment and remediation can be included as part of a tool for owners and employees of sole proprietorships or small businesses. The tool can generate an electronic questionnaire or form comprising a plurality of questions regarding the business and technology stack employed by the business. Further, the questionnaire can be dynamically responsive to input, including industry type, to focus on questions relevant to a business entity. Questionnaire responses can form the basis for generating a score and recommendation related to cyberattack readiness. The business technology stack can also be evaluated or tested.
obtaining a plurality of responses to the plurality of questions (Eshman, ¶19), The tool can generate an electronic questionnaire or form comprising a plurality of questions regarding the business and technology stack employed by the business. Further, the questionnaire can be dynamically responsive to input, including industry type, to focus on questions relevant to a business entity
Eshman does not explicitly suggest, analyzing mismatches between the plurality of responses and the plurality of values of the plurality of risk metrics; however, in a same field of endeavor Mueller discloses this limitation (Mueller, ¶85, claim 1), wherein processing questionnaire mapping and evidence collection results; receiving results of a vendor interview to close any potential gaps that are already identified; generating a draft vendor security risk report including a digital trust score; receiving a vendor security risk assessment response to verify a accuracy of the vendor risk report; generating a graphical representation of said digital trust score for display on a display device; and publishing a final vendor security risk assessment report including said graphical representation of said digital trust score.
Eshman does not explicitly suggest, computing a plurality of weights, each weight is associated with a risk metric for which a mismatch is identified, and computing an assessment of a real time security risk as an aggregation of the plurality of weights; however, in a same field of endeavor Mueller discloses this limitation (Mueller, ¶87), wherein, The data structure comprises a matrix of the categories, arranged in rows in FIG. 3 and rules arranged in columns in FIG. 3 that include, for example, degradation intervals 131 and degradation values 132 which establish weights for those items within a security category. The algorithm tracks the date 133 at which each item was visited, the age of the item 134, whether the item is evidence 135, the evidence grade for evidence 136, and whether the item was reviewed by an attorney or a member of the digital trust ecosystem 137. A final grade 138 is calculated for each item based on weightings of the various rules, and the grades for all categories are combined to generate the digital trust score 139. Those skilled in the art will appreciate that other factors may be used to evaluate categories and items within categories when determining the digital trust score. As well, other categories and items may be used as appropriate. The matrix represented by the data structure receives multidimensional time varying data and applies rules in real time to the data to generate the digital trust score. The cybersecurity risk assessment system generates a graphic display of the digital trust score.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of cybersecurity assessment and remediation 0f Eshman with the method of establishing weight for the security category disclosed in Mueller to identify risk factor as High, low or moderate, stated by Mueller at para.123.
Regarding claim 20:
A non-transitory medium storing program instructions for assessing a real time security risk from an external computing environment interfacing with a target computing environment, which when executed by at least one processor, cause the at least one processor to (Eshman, ¶4): ask a large language model (LLM) to generate for each value of a plurality of values of each risk metric of a plurality of risk metrics, at least one question that is correlated with an answer related to said each value of said each risk metric (Eshman, ¶5, FIG.1), operations include generating a set of cybersecurity questions based on the industry type of a small business, transmitting the set of cybersecurity questions to a computing device of a representative of the business, and dynamically updating the set of cybersecurity questions to remove an irrelevant question determined based on a response to one or more other questions, generating a score based on answers to the set of cybersecurity questions that captures cyberattack readiness, determining a recommendation that reduces cybersecurity risk based on the answers to the set of cybersecurity questions, and conveying the score and recommendation to the computing device of the representative of the business
wherein each of the plurality of risk metrics is indicative of a security risk associated with the external computing environment interfacing with the target computing environment (Eshman, ¶53, ¶23), determines a score based on the input and result of the technology stack evaluation. In one embodiment, the score can be deemed a cybersecurity score that captures the readiness for a cyberattack or, in other words, the capacity to defend against a cyberattack. The cybersecurity score can also capture a level of compliance with applicable regulatory requirements. Alternatively, separate cybersecurity and compliance scores can be determined. The score can be a number (e.g., 1-100), letter (e.g., A, A+, B, C), or class or category (e.g., poor, fair, good, excellent). The score can be determined from various factors associated with the input and result of the technology stack evaluation. For example, an operating system version, presence or absence of virus protection, and password policy can be factors. Further, various weights can be associated with factors such that one factor can influence the score more than another factor.
obtain a plurality of questions from the LLM, generated following said asking (Eshman, ¶19), cybersecurity assessment and remediation. In one embodiment, the cybersecurity assessment and remediation can be included as part of a tool for owners and employees of sole proprietorships or small businesses. The tool can generate an electronic questionnaire or form comprising a plurality of questions regarding the business and technology stack employed by the business. Further, the questionnaire can be dynamically responsive to input, including industry type, to focus on questions relevant to a business entity. Questionnaire responses can form the basis for generating a score and recommendation related to cyberattack readiness. The business technology stack can also be evaluated or tested.
obtain a plurality of responses to the plurality of questions (Eshman, ¶19), The tool can generate an electronic questionnaire or form comprising a plurality of questions regarding the business and technology stack employed by the business. Further, the questionnaire can be dynamically responsive to input, including industry type, to focus on questions relevant to a business entity
Eshman does not explicitly suggest, analyze mismatches between the plurality of responses and the plurality of values of the plurality of risk metrics; however, in a same field of endeavor Mueller discloses this limitation (Mueller, ¶85, claim 1), wherein processing questionnaire mapping and evidence collection results; receiving results of a vendor interview to close any potential gaps that are already identified; generating a draft vendor security risk report including a digital trust score; receiving a vendor security risk assessment response to verify a accuracy of the vendor risk report; generating a graphical representation of said digital trust score for display on a display device; and publishing a final vendor security risk assessment report including said graphical representation of said digital trust score.
Eshman does not explicitly suggest, compute a plurality of weights, each weight is associated with a risk metric for which a mismatch is identified, and compute an assessment of a real time security risk as an aggregation of the plurality of weights; however, in a same field of endeavor Mueller discloses this limitation (Mueller, ¶87), wherein, The data structure comprises a matrix of the categories, arranged in rows in FIG. 3 and rules arranged in columns in FIG. 3 that include, for example, degradation intervals 131 and degradation values 132 which establish weights for those items within a security category. The algorithm tracks the date 133 at which each item was visited, the age of the item 134, whether the item is evidence 135, the evidence grade for evidence 136, and whether the item was reviewed by an attorney or a member of the digital trust ecosystem 137. A final grade 138 is calculated for each item based on weightings of the various rules, and the grades for all categories are combined to generate the digital trust score 139. Those skilled in the art will appreciate that other factors may be used to evaluate categories and items within categories when determining the digital trust score. As well, other categories and items may be used as appropriate. The matrix represented by the data structure receives multidimensional time varying data and applies rules in real time to the data to generate the digital trust score. The cybersecurity risk assessment system generates a graphic display of the digital trust score.
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to include the method of cybersecurity assessment and remediation 0f Eshman with the method of establishing weight for the security category disclosed in Mueller to identify risk factor as High, low or moderate, stated by Mueller at para.123.
Conclusion
7. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Monjour Rahim whose telephone number is (571)270-3890.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on 571-272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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 CANANDA) or 571-272-1000.
/Monjur Rahim/
Patent Examiner
United States Patent and Trademark Office
Art Unit: 2436; Phone: 571.270.3890
E-mail: monjur.rahim@uspto.gov
Fax: 571.270.4890
Prosecution Insights