DETAILED ACTION
Response to Amendment
Applicant's response with amendments filed on 03/12/2026 has been received and entered. Applicant has amended claims 1, 2, 7, 15, 46, 47, 56, 91, 92, 98, 101 and 103, canceled claim 19 and added claim 136. Claims 1-3, 7-8, 11-13, 15-16, 18, 20-22, 26-27, 46-47, 53, 56, 58, 91-92, 98, 101, 103 and 136 have been examined on the merits.
Response to Arguments
Applicant has concurrently filed a Terminal Disclaimer with this amendment to overcome the non-statutory double patenting rejection. The Terminal Disclaimer was approved on 03/12/2026.
Rejections under 35 USC § 101 for claims 1-3, 7, 8, 11-13, 15, 16, 18, 20-22, 26, 27, 46, 47, 53, 56, 58, 91, 92, 98, 101 and 103 are withdrawn in view of the amendments.
Applicant's arguments filed on 03/12/2026, pages 16-18 have been fully considered but they are not persuasive.
Regarding cited reference Cheng, applicant argues:
“[…] Cheng does not disclose "candidates having one or more risk factors associated with usage of artificial intelligence (AI), wherein the subset comprises files each of which includes an attribute or content indicative of AI usage", as clarified by the amended claims. Instead, Cheng describes: "a candidate code can be distinguished as AI generated by comparing predicted probabilities of the candidate code and machine-filled codes against a detection threshold" (Cheng, [0015]). As discussed during the interview, Cheng relates to distinguishing human code from AI-generated code. In other words, once provided with a code file, Cheng determines whether the code has been generated using AI (Cheng, [0067]). However, such analysis of content of a given file is distinct from "determining... files each of which includes an attribute or content indicative of AI usage" and "processing a set of input attributes... to generate an indication of whether the candidate comprises the one or more risk factors."
Ghosh is directed towards scanning, discovering, classifying and risk-scoring end-user computing tools (EUCTs) such as spreadsheets, specially programmed access files, process(es) implemented by an end user via at least one software programming language, etcetera. Since Ghosh identifies EUCTs, not files in which artificial intelligence (AI) was used, Examiner acknowledged that Ghosh does not disclose the target files as files generated, at least in part, using artificial intelligence (AI), and cited Cheng to cure this deficiency as Cheng discloses detecting and identifying AI-generated code.
An “EUCT” refers to a file embodying a computing tool accessible to an end user that transforms input data to produce output data and is not supported by standard software development and/or software control process(es) associated with computing tool distribution and/or use (see Ghosh, ¶[0057]). According to Ghosh (¶[0002]), EUCTs pose a risk to data processes and data security of systems within which the EUCTs are utilized, including reputational and financial risks, risks of fraud, data security risks, and the like if such EUCTs are not maintained, tracked, and/or utilized appropriately. Therefore, it is imperative to identify and classify them in terms of the type and extent of risk they present in order to mitigate such risks.
Cheng discloses identifying AI-generated code to provide transparency to the computer code generation process for a decision-making entity to perform an action (see ¶[0016]). The action can be securing a system handling sensitive data by patching the flagged candidate code for potential security risks. For instance, AI-generated malicious code can be introduced to a system that can induce potential security risks such as a data breach and expose sensitive data to malicious actors (see ¶[0087]).
Cheng is cited to cure the deficiencies of Ghosh in terms of identifying AI usage instead of EUCTs only, based on a Simple Substitution of One Known Element for Another to Obtain Predictable Results rationale, as one of ordinary skill in the art could have substituted identifying files that contain or are potentially generated at least in part using one or more artificial intelligence (AI) processes for EUCTs as both types of files/content may present particular security risks, and the results of the substitution would have been predictable. Ghosh is cited to perform the “determination…” step(s) based on attributes.
Regarding cited reference Posert, applicant argues:
“[…] Posert is silent as to "determining a subset of the candidates by processing a set of input attributes including (i) the attribute or content indicative of potential AI usage, and (ii) associated keywords for each candidate using a risk identification model to generate an indication of whether the candidate comprises the one or more risk factors" (Emphasis added.)
Instead, Posert discloses: "Features are measurable properties of end-user computing tools. The features can be manually specified or automatically determined. For instance, one feature can capture one or more business processes associated with an end-user computing tool or amount of money being dealt with by a tool. In accordance with one embodiment, particular features can be automatically identified based on training data comprising a set of end-user computing tools." (col. 5, lines 54-62). Since the features described by Posert do not include "(i) the attribute or content indicative of potential AI usage, and (ii) associated keywords", Posert fails to remedy the deficiencies of Ghosh and Cheng."
Ghosh, as discussed above, is directed towards scanning, discovering, classifying and risk-scoring end-user computing tools (EUCTs) such as spreadsheets, specially programmed access files, process(es) implemented by an end user via at least one software programming language, etcetera. Ghosh fails to disclose using a risk identification model to generate an indication of whether the candidate comprises the one or more risk factors wherein the risk identification model is trained using a training data set of previously identified and assessed candidates comprising one or more risk attributes. Ghosh does not employ a machine-learning model (e.g., risk identification model) but a scanning apparatus (i.e., target file scan system 102/ scanning apparatus 200) specially configured to determine a subset of the candidates by processing a set of input attributes including (i) the attribute or content indicative of potential Ghosh is “using a risk identification model” to perform this step.
However, in the same field of endeavor, Posert discloses a system and method based on machine learning and other approaches to automate discovery of risk associated with end-user computing tools (see abstract). In Posert, the scanner component 210 can search for file extensions associated with particular end-user computing tools (e.g., xsl, 123, gsheet, wdb, odb, mdf . . . ) and can analyze files (e.g. collections of data with a name) to determine if the files are end-user computing tools 110. For example, an end-user computing tool can be identified if a file relates to a software-based tool that includes at least one mathematical calculation or logical operation specified by an end user (see col. 3, line 51 to col. 4, line 12, FIG. 2). The classification system 100 (including model execution component, see FIG. 2) is configured to automatically discover, assess, or classify risk associated with end-user computing tools 110 and may use context information associated with or surrounding end-user computing tools 110 to perform risk classification. Some examples of context information include title of the author of the tool, associated business processes, a news feed, tool architecture, and the presence and amount of personally identifiable information (PPI) as well as other structured or rule-based information extracted from and end-user computing tool (see col. 3, lines 22-50). An unsupervised learning approach may be employed that performs cluster analysis. In such case, the end-user computing tools can be automatically clustered into groups or clusters based on similarity, for instance utilizing document clustering, or natural language processing and text analysis can be employed to automatically classify end-user computing tools (see col. 6, lines 6-38).
In Posert, a machine learning model is generated based on training data, wherein the training data corresponds to end-user computing tools and risk labels (e.g., a number of spreadsheets can be provided with labels indicating whether a particular spreadsheet is high risk or not, and the type of risk for example, financial) to train the model in accordance with a supervised learning approach. Once trained and fine-tuned, end-user computing tools can be provided and the model executed to classify each end-user computing tool in terms of risk (see col. 2, lines 40-50). The trained machine learning model performs risk assessment on the end-user computing tool to classify it in terms of risk extent (e.g., high, low, intermediate) based on features indicative of risk extent and/or training data (730), and the type of risk is identified (740) – see col. 8, lines 24-51 and FIG. 7; see also col. 4, line 37 to col. 5, line 5 and col. 7, line 61 to col. 8, line 23 and FIG. 6.
Features in Posert are, as noted by applicant, measurable properties of end-user computing tools. For instance, one feature can capture one or more business processes associated with an end-user computing tool or amount of money being dealt with by a tool (see col. 5, lines 54-62). However, the classification system 100, uses the EUCTs as the basis for model generation and classification, and context information (i.e., features) to improve classification (see col. 5, lines 29-40). Context information includes, but is not limited to, title of the author of the tool, associated business processes, a news feed, tool architecture, and the presence and amount of personally identifiable information (PPI) (e.g., a Social Security number) as well as other structured or rule-based information extracted from and end-user computing tool (see col. 3, lines 43-48). These features are attributes of EUCTs.
As previously stated, Ghosh is cited to teach “determining a subset of the candidates by processing a set of input attributes including (i) the attribute or content indicative of potential Posert is cited to cure the deficiencies of Ghosh in terms of “using a risk identification model” to perform this particular step.
Both Ghosh and Posert are directed towards scanning, discovering, classifying and risk-scoring end-user computing tools (EUCTs), not files in which AI was used. Cheng is cited to teach the target files as files generated, at least in part, using artificial intelligence (AI).
Therefore, Ghosh teaches “determining a subset of the candidates by processing a set of input attributes including (i) the attribute or content indicative of potential [[EUCT]], and (ii) associated keywords to generate an indication of whether the candidate comprises the one or more risk factors”, Cheng provides the teachings of identifying content indicative of AI usage and Posert provides the teachings of determining candidate files using a risk identification model.
Accordingly, given the broadest reasonable interpretation, Ghosh, Cheng and Posert teach all the limitations of the independent claims.
Claim Objections
Claim 2 is objected to because of the following informalities: “…wherein the subset of candidate is a first subset…” should read “wherein the subset of candidates is a first subset”.
Claims 13, 58 and 103 are objected to because of the following informalities: the last line recites “wherein the objects are indicative of dependency information comprising a type of dependency, a scan status, and a type of dependency”; “type of dependency” is recited twice, which is being considered by the Examiners as a typographical error. For examination purposes, Examiner is considering this limitation as “wherein the objects are indicative of dependency information comprising a type of dependency and a scan status”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 7, 8, 15, 46, 47, 53, 91, 92, 98 and 136 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), hereinafter Ghosh, in view of Cheng et al. (US 20240419801 A1), hereinafter Cheng, and Posert (US 11966930 B1), hereinafter Posert.
Regarding claim 1, Ghosh discloses a computer-implemented method, the method comprising:
accessing, by one or more computing devices, a repository of files stored on one or more computer-readable storage devices (at operation 802, access is enabled to particular file repositories of a data system to identify a plurality of candidate data files associated with one or more file repositories – see [0139], FIG. 8); and
determining, by the one or more computing devices, a subset of the files stored in the repository as candidates having one or more risk factors associated with usage of (at operation 804, a reduced set (i.e., subset) of candidate files is determined from the plurality of files after removing files not likely to include and/or embody a target file, such as an EUCT, based on the values for data properties associated with the files – see [0140]; the reduced set of candidate data files is identified by applying a hierarchy of scan criteria including a timeliness of file factor, a file type or other scan criteria – see [0141]; see also [0064-70] and FIG. 8), wherein evaluation of the one or more risk factors comprises:
determining a subset of the candidates by processing a set of input attributes including (i) the attribute or content indicative of potential (scan criteria is based on the data properties of a candidate file and may include timeliness of file factor (i.e., file age), type of file factor, calculations user factor, keyword factor, or owner role factor – see [0008]; the term “scan criteria” refers to a comparison, model, or algorithm that indicates a likelihood of a particular candidate data file or a particular set of candidate data files being based on data value(s) for one or more data properties associated with the scan criteria – see [0064], see also [0122-0129], FIG. 4, 5 and 7; “keyword factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody a target file based on whether the candidate data file includes one or more instances of a particular keyword in particular portions of the candidate data file or all portions of the candidate file – see [0068]; a set of keywords may be identified and/or otherwise determined that indicate a file is likely to include or embody a target file – see [0126]; see also [0055-84] and FIGs. 4, 5 and 7; at operation 804, the method determines, from the plurality of candidate files, a reduced set of candidate data files – see [0140]; the reduced set of candidate data files is identified by applying a hierarchy of scan criteria to the plurality of candidate data files; the hierarchy of scan criteria is applied iteratively, such that a first scan criteria is utilized to reduce the plurality of candidate files to determine a preliminary reduced candidate file set – see [0141]),
providing identification of a risk category for the subset of the candidates in accordance with the indication of whether each candidate in the subset of the candidates comprises the one or more risk factors (candidate files may embody the files stored on the shared file repositories may define a plurality of files that are candidates for a detailed scan to determine if the file is a target file (e.g., an EUCT); upon applying the plurality of scan criteria, as described herein, the resulting set of candidate files may represent those candidate files that are associated with values for certain data properties that indicate the candidate file may, or is likely to, include or embody a target file, such as an EUCT – see [0048]; the term “timeliness of file factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody target file based on the age of the candidate data file and/or time since the candidate file has been accessed and/or modified – see [0065]; the term “type of file factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody target file based on the file type associated with the candidate file – see [0066]; the term “calculations user factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody a target file based on whether a calculation operation or other calculation performance data is determined to be present within the candidate data file – see [0067]; the term “keyword factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody a target file based on whether the candidate data file includes one or more instances of a particular keyword in particular portions of the candidate data file (e.g., in the content of the candidate file) or all portions of the candidate file (e.g., in the filename, and/or the like) – see [0068]; the term “owner role factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody a target file based on a determined system or entity role assigned for an owner or creator of the candidate file – see [0069]; the term “target likelihood score” refers to electronically managed data that represents a probability a candidate data file is target file based on the various data and/or metadata properties associated with the candidate data file; in some embodiments, a target likelihood score is determined based on values for one or more scan criteria – see [0071]; the term “high target probability file” refers to a candidate data file associated with a target likelihood score determined to indicate the candidate data file is likely to include or embody a target file – see [0072]; [at operation 810] determin[ing] the reduced set of candidate data files comprises at least one high target probability file; the at least one high target probability file is/are determined based on at least the target likelihood score for each candidate data file in the reduced set of candidate data files; each high target probability file may be determined to be associated with a target likelihood score that is sufficiently high to suggest that the candidate file includes or embodies a target file, such as an EUCT; for example, the at least one high target probability file is/are determined based on the target likelihood score for the candidate file exceeding an target probability threshold; in this regard, the target probability threshold may embody a value above which a target likelihood score is determined as likely to indicate a candidate file includes or embodies a target file such as an EUCT – see [0144-46]).
Ghosh discloses identifying target files, such as EUCT files (e.g., specially programmed Microsoft Access files, custom calculation spreadsheets made in Microsoft Excel, one or more process(es) implemented by an end user via at least one software programming language, and the like) – see [0057]).
Ghosh does not disclose the target files as files generated, at least in part, using artificial intelligence (AI).
However, Cheng discloses systems and methods for detecting artificial intelligence (AI) generated computer code (see abstract) including target files as files generated, at least in part, using artificial intelligence (AI) (a candidate code can be distinguished as AI generated by comparing predicted probabilities of the candidate code and machine-filled codes against a detection threshold – see [0015]; a candidate code can be a stream of text that may be written in various programming languages (e.g., Python, Java, C, Swift, etc.) to solve a given problem, entered by an entity and saved in a memory – see [0030-41]).
Thus, Ghosh and Cheng each disclose identifying and analyzing a candidate file (e.g., in Ghosh EUCT file may be a user-implemented process via programming language) and/or code (e.g., in Cheng, the candidate code may be a process to solve a problem written in a programming language such as Python). A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the potentially AI-generated candidate code of Cheng could have been substituted for the EUCT-generated file (e.g., process(es) implemented by an end user via at least one software programming language) of Ghosh because both may present a particular security risk (see Ghosh [0002] and Cheng [0087]) and both may be used as the target file (i.e., subset of candidates) to identify security issues using similar criteria and file attributes and/or content. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of allowing the system and method to identifying a file and/or code generated using AI/EUCT in order to detect and or minimize security risks and issues.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the AI-generated code of Cheng for the EUCT file of Ghosh according to known methods to yield the predictable result of identifying a file and/or code generated using AI/EUCT in order to detect and or minimize security risks and issues.
Ghosh and Cheng fail to disclose using a risk identification model to perform the step of “determining a subset of the candidates by processing a set of input attributes including (i) the attribute or content indicative of potential Al usage, and (ii) associated keywords to generate an indication of whether the candidate comprises the one or more risk factors” and wherein the risk identification model is trained using a training data set of previously identified and assessed candidates comprising one or more risk attributes.
However, Posert discloses system and methods based on machine learning and other approaches to automate discovery of risk associated with end-user computing tools (see abstract) including using a risk identification model to generate an indication of whether the candidate comprises the one or more risk factors (classification system 100 is configured to automatically discover, assess, or classify risk associated with end-user computing tools 110; the classification system 100 can use context information associated with or surrounding end-user computing tools 110; examples of such context information are title of the author of the tool, associated business processes, a news feed, tool architecture, and the presence and amount of personally identifiable information (PPI) (e.g., a Social Security number) as well as other structured or rule-based information extracted from and end-user computing tool – see col. 3, lines 22-50; an unsupervised learning approach can be employed that performs cluster analysis; in this case, end-user computing tools can be automatically clustered into groups or clusters based on similarity, for instance utilizing document clustering; alternatively, natural language processing and text analysis can be employed to automatically classify end-user computing tools – see col. 6, lines 6-38; computer storage systems of an organization can be scanned to locate such tools [EUCTs] for example based on extensions or characteristics associated with the tools; once located (710) and retrieved (720), a trained machine learning model performs risk assessment on the end-user computing tool to classify it in terms of risk extent (e.g., high, low, intermediate) based on features indicative of risk extent and/or training data (730), and the type of risk is identified (740) – see col. 8, lines 24-51 and FIG. 7; see also col. 4, line 37 to col. 5, line 5; and col. 7, line 61 to col. 8, line 23 and FIG. 6; both FIGs. 6 and 7 illustrate a method of risk classification associated with EUCTs performed, for instance, by classification system 100 and model execution component 240 shown in FIG. 2, col. 5, lines 6-40),
wherein the risk identification model is trained using a training data set of previously identified and assessed candidates comprising one or more risk attributes (a machine learning model can be generated based on training data, wherein the training data corresponds to end-user computing tools and risk labels; for instance, a number of spreadsheets can be provided with labels indicating whether a particular spreadsheet is high risk or not, and the type of risk for example, financial, to train the model in accordance with a supervised learning approach; once trained and fine-tuned as needed, end-user computing tools can be provided and the model executed to classify each end-user computing tool in terms of risk; the risk can be classified in terms of type and extent, wherein the type of risk can be financial or reputational, for example, and the extent can be high or low – see col. 2, lines 40-50; computer storage systems of an organization can be scanned to locate such tools [EUCTs] for example based on extensions or characteristics associated with the tools; once located (710) and retrieved (720), a trained machine learning model performs risk assessment on the end-user computing tool to classify it in terms of risk extent (e.g., high, low, intermediate) based on features indicative of risk extent and/or training data (730), and the type of risk is identified (740) – see col. 8, lines 24-51 and FIG. 7; see also col. 4, line 37 to col. 5, line 5 and col. 7, line 61 to col. 8, line 23 and FIG. 6; examiner’s note: Posert uses end-user computing tools with labels indicating risk extent and/or type as training data for the machine-learning model used to determine risk associated with an EUCT (see col. 2, lines 40-50 and col. 4, line 25 to col. 5, line 5).
Posert, as well as Ghosh (see above), also discloses providing identification of a risk category for the subset of the candidates in accordance with the indication of whether each candidate in the subset of the candidates comprises the one or more risk factors (financial and reputational risks are distinct from technical risk associated with an end-user computing tool; financial risk concerns a potential for financial loss; reputational risk pertains to loss resulting from damage to an organization's reputation or good standing; technical risks concern the structure of end-user computing tools; for example, technical risks associated with a spreadsheet can include the presence of hidden cells, accuracy of complex computations, as well as identification of particular terms; although there can be some spillover, technical risk is distinct from financial and reputation risk as well as other risks such as regulatory risk – see col. 5, lines 17-28; at numeral 730, risk assessment is performed automatically on the end-user computing tool to classify the tool in terms of risk extent (e.g., high, low, intermediate . . . ) – see col. 8, lines 32-50; at 740, a type of risk associated with the risk extent is identified; in accordance with one aspect multiple machine learning models can be employed to determine different types of risks such as financial, reputational, and regulatory; alternatively, a single model can be constructed that performs classification with respect to various risk types; regardless of implementation, various types of risk can be determined with respect to an end-user computing tool; for example, an end-user tool can be classified as low risk for financial and regulatory purposes but high risk for reputational damage – see col. 8, lines 51-61; see also col. 7 line 21 - col. 8, line 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 method in Ghosh and Cheng to include using a risk identification model to perform the step of “determining a subset of the candidates…to generate an indication of whether the candidate comprises the one or more risk factors” and wherein the risk identification model is trained using a training data set of previously identified and assessed candidates comprising one or more risk attributes, as taught by Posert. One would have been motivated to make such a combination to ensure that risk associated with end-user computing tools can be identified automatically, prompting review, tracking and monitoring, thus reducing security issues, as recognized by Posert (see col. 1, lines 25-60).
Regarding claim 2, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 1 above. Furthermore, Ghosh discloses the method, wherein the subset of candidate is a first subset, and further comprising:
identifying a corresponding set of attributes for each candidate (“scan criteria” refers to a comparison, model, or algorithm that indicates a likelihood of a particular candidate data file or a particular set of candidate data files being based on data value(s) for one or more data properties associated with the scan criteria – see [0064]; scan criteria may include timeliness of file factor, type of file factor, calculations user factor, keyword factor, or owner role factor – see [0065-69], see also [0122-0129], FIG. 4);
determining a second subset of the candidates based on the corresponding set of attributes (at operation 804, the method determines, from the plurality of candidate files, a reduced set of candidate data files – see [0140]; the reduced set of candidate data files is identified by applying a hierarchy of scan criteria to the plurality of candidate data files; the hierarchy of scan criteria is applied iteratively, such that a first scan criteria is utilized to reduce the plurality of candidate files to determine a preliminary reduced candidate file set; the preliminary reduced candidate file set may subsequently be further reduced by a second scan criteria, and so on for subsequent scan criteria as described herein – [0141]; the scan criteria of the hierarchy of scan criteria are processed iteratively to continue to decrease the size of candidate files to be processed by processing the reduced set of candidate files via the next scan criteria in the hierarchy of scan criteria; in this regard, each subsequent iterative step may exclude any number of the remaining candidate files from consideration for scanning for a target file such as an EUCT; at operation 1004, the targeted file scanning apparatus 200 includes means, such as the target scanning circuitry 210, the communications circuitry 208, the input/output circuitry 206, and/or the processor 202, to apply a second scan criteria to the first reduced set of candidate data files – [0154]; for example, with respect to the second reduced set of candidate data files determined at operation 1004, the first additional scan criteria may be applied to further reduce this second reduced set of candidate data files and determine a third reduced set of candidate data files based on the additional scan criteria – see [0155]).
Ghosh fails to disclose performing one or more automated tests on the determined second subset of candidates.
However, Cheng discloses performing one or more automated tests on the determined second subset of candidates (Cheng presents the problem that there is a lack of practical tests on AI-generated code detection – see [0017]; AI-generated code might introduce errors or unpredictable behavior that could go undetected in traditional testing; identifying such code allows for targeted testing strategies to ensure the correctness and reliability of the software being developed – see [0024]; the action 610 can be creating code hooks including the flagged candidate code 608 that would flag code behavior and target testing strategies to ensure the correctness and reliability of the software being developed – see [0096], FIG. 4; please notice that the system can be configured to autonomously perform action 610 – see [0087]; examiner’s note: in Cheng, testing strategies are target as the candidate code behavior is flagged (identified); in Ghosh, the reduced set of candidate files have been identified through scan criteria iteratively and thus it would be obvious to target testing to a final (e.g., second) reduced set of candidate files using Cheng’s technique; see also Ghosh [0155]).
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 method in Ghosh to include performing one or more automated tests on the determined second subset of candidates, as taught by Cheng. One would have been motivated to make such a combination to ensure the correctness and reliability of the identified (flagged) candidate code and/or software, as recognized by Cheng (see [0024]).
Regarding claim 3, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 1 above. Furthermore, Ghosh discloses the method, wherein accessing the repository of files stored on one or more computer-readable storage devices further comprises:
accessing the repository of files in a first scan in accordance with a set of one or more scanning parameters (at operation 802, the method identifies a plurality of candidate data files associated with one or more file repositories – see [0139], FIG. 8);
identifying one or more files in the first scan in accordance with the set of one or more scanning parameters (at operation 804, the method determines, from the plurality of candidate files, a reduced set of candidate data files – see [0140]; the reduced set of candidate data files is identified by applying a hierarchy of scan criteria to the plurality of candidate data files; the hierarchy of scan criteria is applied iteratively, such that a first scan criteria is utilized to reduce the plurality of candidate files to determine a preliminary reduced candidate file set – see [0141]); and
using results of the first scan in a second scan, wherein using the results comprises filtering the one or more files identified in the first scan in accordance with a second set of one or more configurable scanning parameters selected from a group consisting of: target folders, target drives, file types, file age, file compression technology, scan depth, and keywords (scan criteria enables the identification of particular locations for scanning, allowing the method to focus on a limited number of storage locations and file characteristics (i.e., scan depth)– see [0045-46]; “data property” with respect to a candidate data file refers to a particular portion of metadata associated with the candidate data file or a particular portion of the content of a candidate data file and may include a filename, a file type, a file content length, a file size, a file content title, a file author, a last-accessed datetime, a file created datetime, a file storage location, and file permissions data – see [0062]; scan criteria is based on the data properties of a candidate file and may include timeliness of file factor (i.e., file age), type of file factor, calculations user factor, keyword factor, or owner role factor – see [0064-69], see also [0122-0129], FIG. 4; the hierarchy of scan criteria is applied iteratively, such that a first scan criteria is utilized to reduce the plurality of candidate files to determine a preliminary reduced candidate file set; the preliminary reduced candidate file set may subsequently be further reduced by a second scan criteria, and so on for subsequent scan criteria – see [0141]; the targeted file scanning apparatus 200 may identify the plurality of candidate data files by identifying all files stored within the one or more file repositories, and/or portions – see [0139]; the file repositories of the data system may embody a number of shared file repositories (e.g., shared drives) – see [0047]; each file repository may include any number of sub-repositories, folders, and/or the like – see [0089]; examiner’s note: the value for a file type data property of a particular candidate file is parsed from the file extension associated with the candidate file or determined from processing the data or metadata associated with the candidate file (see [0123]), which is how the file compression technology used can be determined by a person of ordinary skilled in the art as well; the owner role factor, in addition to associate a candidate file with an author/owner and their role, it is used to identify particular repositories for scanning).
Regarding claim 7, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 1 above. Furthermore, Ghosh discloses the method, wherein determining a subset of the files stored in the repository as candidates having one or more risk factors associated with (“data property” with respect to a candidate data file refers to a particular portion of metadata associated with the candidate data file or a particular portion of the content of a candidate data file and may include a filename, a file type, a file content length, a file size, a file content title, a file author, a last-accessed datetime, a file created datetime, a file storage location, and file permissions data – see [0062]; see also [0122-0129], FIG. 4), and wherein identifying one or more attributes of the file using one or more of file metadata, file location, or file contents comprises, for each file:
identifying a file name, file type, attributes specific to the file type, one or more file authors, and organizational information pertaining to the file (“filename”, “file type”,“file author” – see [0062]; the “owner role” which is a scan criteria factor, is based on the entity role assigned for an owner/creator of the candidate file (i.e., organizational information) – see [0069]; file type data property, for example, is parsed from the file extension (i.e., attribute specific to the file type), metadata or content of the candidate file – see [0123]);
identifying one or more dates of modification, dates of last access, and an author associated with the last modification (“timeliness of file factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody target file based on the age of the candidate data file and/or time since the candidate file has been accessed and/or modified – see [0065]; a data value for an owner (or author) data property of a candidate file is determinable based on the metadata or data associated with the candidate file; in some embodiments, the owner is represented by the data value for the data property embodying the last modifier of a particular candidate file – see [0127]);
determining a file size (data property includes file size – see [0062]);
identifying a location of the file in the repository with respect to one or more file system hierarchies in the repository (scan criteria that enables identification of particular locations for scanning enabling the method to focus on a limited number of storage locations and file characteristics – see [0045]; data property includes file storage location – see [0062]; each file repository may include any number of sub-repositories, folders, and/or the like; a file repository may be specially configured to define a particular file system that organizes stored files in particular locations – see [0089]);
determining security rights of the file in the repository (data property includes file permissions data – see [0062];
identifying one or more keywords within the file (“keyword factor” refers to a particular scan criteria that indicates whether a candidate data file is likely to include or embody a target file based on whether the candidate data file includes one or more instances of a particular keyword in particular portions of the candidate data file or all portions of the candidate file – see [0068]; a set of keywords may be identified and/or otherwise determined that indicate a file is likely to include or embody a target file – see [0126]; see also FIGs. 4, 5 and 7); and
identifying one or more attributes or content indicative of (Candidate files may embody the files stored on the shared file repositories may define a plurality of files that are candidates for a detailed scan to determine if the file is a target file (e.g., an EUCT) – see [0048]; the presence of a combination of keywords may indicate a higher likelihood that the candidate file includes or embodies a target file such as an EUCT – see [0126]; a data repository owned by a user or group of users with a second owner role, such as a data analytics owner role, may be included for scanning as likely to include (e.g., EUCTs) as a part of the nature of the role – see [0128]).
Ghosh discloses identifying target files, such as EUCT files (e.g., specially programmed Microsoft Access files, custom calculation spreadsheets made in Microsoft Excel, one or more process(es) implemented by an end user via at least one software programming language, and the like), essentially identifying EUCT usage – see [0057], [0126-0128]).
Ghosh does not disclose the target files as files generated, at least in part, using artificial intelligence (AI) (that is, AI usage).
However, Cheng discloses systems and methods for detecting artificial intelligence (AI) generated computer code (see abstract) identifying one or more attributes or content indicative of Al usage in the file (a candidate code can be distinguished as AI generated by comparing predicted probabilities of the candidate code and machine-filled codes against a detection threshold – see [0015]; a candidate code can be a stream of text that may be written in various programming languages (e.g., Python, Java, C, Swift, etc.) to solve a given problem, entered by an entity and saved in a memory – see [0030-41]; see also [0086-98] and FIGs. 1 and 4).
Thus, Ghosh and Cheng each disclose identifying and analyzing a candidate file (e.g., in Ghosh EUCT file may be a user-implemented process via programming language) and/or code (e.g., in Cheng, the candidate code may be a process to solve a problem written in a programming language such as Python that is AI-generated). A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the potentially AI-generated candidate code of Cheng could have been substituted for the EUCT-generated file (e.g., process(es) implemented by an end user via at least one software programming language) of Ghosh because both may present a particular security risk (see Ghosh [0002] and Cheng [0087]) and both may be used as the target file (i.e., subset of candidates) to identify security issues using similar criteria and file attributes and/or content. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of allowing the system and method to identifying a file and/or code generated using AI/EUCT in order to detect and or minimize security risks and issues.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the AI-generated code of Cheng for the EUCT file of Ghosh according to known methods to yield the predictable result of identifying a file and/or code generated using AI/EUCT in order to detect and or minimize security risks and issues.
Regarding claim 8, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 7 above. Furthermore, Ghosh discloses the method, wherein identifying the one or more attributes or content indicative of at least one of: a file extension associated with an a segment of code, or a number of lines of code (upon applying the plurality of scan criteria, as described herein, the resulting set of candidate files may represent those candidate files that are associated with values for certain data properties that indicate the candidate file may, or is likely to, include or embody a target file, such as an EUCT – see [0048]; file detection circuitry 260 includes hardware, software, firmware, and/or a combination thereof, configured to scan file content data of a modified data file to identify whether the file content data includes one or more data portions indicating the modified data file embodies an EUCT – see [0113]; a user may set particular file types associated with particular data programs known or otherwise determined by the user as likely to be associated with target files (e.g., likely to be associated with utilizing, creating, and/or owning EUCTs); the value for a file type data property of a particular candidate file is parsed from the file extension associated with the candidate file – see [0123]; the presence of one keyword indicates the candidate file may likely embody or include a target file such as an EUCT; the presence of a combination of keywords may indicate a higher likelihood that the candidate file includes or embodies a target file such as an EUCT – see [0126]; additionally, “file content data” and “calculation subprocesses” both of which are modifiable via EUCT – see [0081] and [0082]).
Ghosh discloses identifying target files, such as EUCT files (e.g., specially programmed Microsoft Access files, custom calculation spreadsheets made in Microsoft Excel, one or more process(es) implemented by an end user via at least one software programming language, and the like), essentially identifying EUCT usage – see [0057], [0126-0128]).
Ghosh does not disclose the target files as files generated, at least in part, using artificial intelligence (AI) (that is, AI usage).
However, Cheng discloses systems and methods for detecting artificial intelligence (AI) generated computer code (see abstract) identifying one or more attributes or content indicative of Al usage in the file (a candidate code can be distinguished as AI generated by comparing predicted probabilities of the candidate code and machine-filled codes against a detection threshold – see [0015]; a candidate code can be a stream of text that may be written in various programming languages (e.g., Python, Java, C, Swift, etc.) to solve a given problem, entered by an entity and saved in a memory – see [0030-41]; see also [0086-98] and FIGs. 1 and 4); and the method, wherein identifying the one or more attributes or content indicative of Al usage comprises identifying at least one of: a segment of code, or a number of lines of code (segments of code and/or lines of code are identified in order to be masked and determine if they have been AI-generated – se FIG. 1, [0027-74]; see also [0023-24]).
Thus, Ghosh and Cheng each disclose identifying and analyzing a candidate file (e.g., in Ghosh EUCT file may be a user-implemented process via programming language) and/or code (e.g., in Cheng, the candidate code may be a process to solve a problem written in a programming language such as Python that is AI-generated). A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the potentially AI-generated candidate code of Cheng could have been substituted for the EUCT-generated file (e.g., process(es) implemented by an end user via at least one software programming language) of Ghosh because both may present a particular security risk (see Ghosh [0002] and Cheng [0087]) and both may be used as the target file (i.e., subset of candidates) to identify security issues using similar criteria and file attributes and/or content. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of allowing the system and method to identifying a file and/or code generated using AI/EUCT in order to detect and or minimize security risks and issues.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the AI-generated code of Cheng for the EUCT file of Ghosh according to known methods to yield the predictable result of identifying a file and/or code generated using AI/EUCT in order to detect and or minimize security risks and issues.
Regarding claim 15, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 2 above. Furthermore, Ghosh discloses the method, wherein providing identification of a risk category for the subset of candidates comprises determining a risk score for each candidate using the corresponding set of attributes (the computer-implemented method further includes generating, for each candidate data file in the reduced set of candidate data files, a target likelihood score [i.e., risk score] that represents a probability the candidate data file is an end-user computing tool based on one or more data properties associated with the candidate data file – see [0005]; see also [0071], [0106] and [0143-0144]).
Regarding claim 46, Ghosh discloses a system comprising one or more computing devices and one or more storage devices storing instructions that are operable, when executed by the one or more computing devices, to cause the one or more computers to perform operations [of the method of claim 1] (“apparatus 200/250”, “processor 202”, “memory 204”, see FIG. 2A/2B). The remaining limitations of claim 46 are similar in scope to those of claim 1. Therefore, claim 46 is rejected for the same reasons as set forth in the rejection of claim 1 above.
Regarding claim 47, all limitations correspond to the system performing the method of claim 2. Therefore, claim 47 is being rejected on the same basis as claim 2.
Regarding claim 53, all limitations correspond to the system performing the method of claim 8. Therefore, claim 53 is being rejected on the same basis as claim 8.
Regarding claim 91, Ghosh discloses one or more non-transitory computer readable media storing instructions that are executable by a processing device, and upon such execution cause the processing device to perform operations [of the method of claim 1] (the process 900 is embodied by computer program code stored on a non-transitory computer-readable medium of a computer program product configured for execution to perform the computer-implemented process; the targeted file scanning apparatus 200 is specially configured by computer program instructions stored thereon, for example in the memory 204 and/or another component depicted and/or described herein, and/or otherwise accessible to the targeted file scanning apparatus 200, for performing the operations – see [0147]). The remaining limitations of claim 91 are similar in scope to those of claim 1. Therefore, claim 91 is rejected for the same reasons as set forth in the rejection of claim 1 above.
Regarding claim 92, all limitations correspond to the system performing the method of claim 2. Therefore, claim 92 is being rejected on the same basis as claim 2.
Regarding claim 98, all limitations correspond to the system performing the method of claim 8. Therefore, claim 98 is being rejected on the same basis as claim 8.
Regarding claim 136, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 2 above.
Furthermore, Ghosh discloses the method, wherein the set of input attributes are selected from the corresponding set of attributes (applying each of the scan criteria 402-410 may remove a set of candidate files from consideration for scanning as a possible target file (e.g., a possible EUCT), thus reducing the number of required detailed scanning operations significantly while prioritizing and improving the predictive execution of the scanning operation – see [0122]; the reduced set of candidate data files is identified by applying a hierarchy of scan criteria to the plurality of candidate data files; the hierarchy of scan criteria is applied iteratively, such that a first scan criteria is utilized to reduce the plurality of candidate files to determine a preliminary reduced candidate file set; the preliminary reduced candidate file set may subsequently be further reduced by a second scan criteria, and so on for subsequent scan criteria as described herein – [0141]).
Claims 11, 12, 56 and 101 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), and Posert (US 11966930 B1), as applied to claims 1, 46 and 91 above, in view of Murthy et al. (US 20240419794 A1), hereinafter Murthy.
Regarding claim 11, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 1 above.
Ghosh, Cheng and Posert fail to disclose the method, further comprising identifying one or more libraries and library versions installed on the one or more computer-readable storage devices.
However, Murthy discloses a method for identifying vulnerabilities across software code repositories (see abstract) wherein the method, further comprising identifying one or more libraries and library versions installed on the one or more computer-readable storage devices (vulnerability scans are run against the codebase and dependent libraries of the codebase to report any identified vulnerabilities and any action that needs to be taken (e.g., to use a new version number of a dependent library) – see [0014]; a plugin component of the build pipeline tool 114 can obtain application metadata (e.g., application name, deployment environment, deployment timestamp, and/or a list of dependent libraries including version information and timestamp information related to the dependent libraries – see [0036]).
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 method in Ghosh to include the method, further comprising identifying one or more libraries and library versions installed on the one or more computer-readable storage devices, as taught by Murthy. One would have been motivated to make such a combination to reduce the amount of time and resources needed to identify, track, and remediate vulnerabilities and proactively identify and manage software vulnerabilities across multiple code repositories, and possibly automatically remediate at least a portion of the identified vulnerabilities, as recognized by Murthy (see [0075]).
Regarding claim 12, Ghosh, Cheng, Posert and Murthy disclose all the claimed subject matter recited in claim 11 above.
Ghosh, Cheng and Posert fail to disclose the method, further comprising identifying vulnerabilities associated with each version of the identified library versions using a security vulnerability database, wherein the security vulnerability database comprises a set of determined security vulnerabilities associated with each version of the identified library.
However, Murthy discloses the method, further comprising identifying vulnerabilities associated with each version of the identified library versions using a security vulnerability database, wherein the security vulnerability database comprises a set of determined security vulnerabilities associated with each version of the identified library (vulnerability scans are run against the codebase and dependent libraries of the codebase to report any identified vulnerabilities and any action that needs to be taken – see [0014]; the vulnerability identification system 105 can have at least one associated database 106 configured to store data pertaining to, for example, a plurality of code repositories 107; the at least one associated database 106 can also be configured to store data pertaining to vulnerability information 108, which can correspond to, or be obtained from, a global vulnerability database, such as an NVD [[national vulnerability database]] – see [0023]; the build pipeline tool 114 can also obtain scan information from the at least one vulnerability scanner 112; the application metadata and the information related to the scanned vulnerabilities can be sent to the vulnerability validator 116 for further processing – see [0036]; the vulnerability validator 116 is further configured to perform one or more automated actions based on the analysis; for example, if the reported vulnerability corresponds to a dependent library version that needs to be updated, then a fix can be applied automatically by the vulnerability validator 116 – see [0039]; see also [0042], [0063] and [0070]).
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 method in Ghosh to include the method, further comprising identifying vulnerabilities associated with each version of the identified library versions using a security vulnerability database, wherein the security vulnerability database comprises a set of determined security vulnerabilities associated with each version of the identified library, as taught by Murthy. One would have been motivated to make such a combination to reduce the amount of time and resources needed to identify, track, and remediate vulnerabilities and proactively identify and manage software vulnerabilities across multiple code repositories, and possibly automatically remediate at least a portion of the identified vulnerabilities, as recognized by Murthy (see [0075]).
Regarding claim 56, all limitations correspond to the system performing the method of claim 11. Therefore, claim 56 is being rejected on the same basis as claim 11.
Regarding claim 101, all limitations correspond to the system performing the method of claim 11. Therefore, claim 101 is being rejected on the same basis as claim 11.
Claims 13, 58 and 103 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), and Posert (US 11966930 B1), as applied to claims 1, 2, 46, 47, 91 and 92 above, in view of Ackroyd et al. (US 20210326121 A1), hereinafter Ackroyd, and further in view of Verkruyse et al. (US 20250147957 A1), hereinafter Verkruyse.
Regarding claim 13, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 2 above.
Ghosh, Cheng and Posert fail to disclose the method, wherein identifying the corresponding set of attributes for each candidate comprises: evaluating associated input and output dependencies of each candidate, wherein the associated dependencies comprise one or more of libraries, files, or import modules; and displaying a visual representation of the input and output dependencies for each candidate on a graphical user interface, wherein the visual representation comprises an interconnected Al map of one or more objects representing a sequence of inputs to outputs in accordance with the dependencies at a specified-hierarchy level, wherein the objects are indicative of dependency information comprising a type of dependency, a scan status, and a type of dependency.
However, Ackroyd discloses systems and methods for scanning application code to determine cloud platform portability (see abstract) including the method, wherein identifying the corresponding set of attributes for each candidate comprises:
evaluating associated input and output dependencies of each candidate, wherein the associated dependencies comprise one or more of libraries, files, or import modules; and displaying a visual representation of the input and output dependencies for each candidate on a graphical user interface, wherein the visual representation comprises an interconnected (exemplary interface may include Dependency Map 410, Analysis Summary and Recommendation 420 and Dependency Details 430; Dependency Map 410 graphically illustrates dependencies and corresponding connections/relationships; Analysis Summary and Recommendation 420 provides details relating to dependencies, potential vendor lock-in, external services connections, un-used dependency imports, API connections, etc.; Dependency Details 430 may include type, dependency name, source and effort; other dependency data may be provided and illustrated; an overall risk assessment may be provided at 440 as indicated by a numerical representation – see [0032], FIG. 4; see also FIG. 3; examiner’s note: evaluation of dependencies (e.g., file dependencies) is presented via the analysis summary).
Ackroyd fails to disclose that the map is an AI map.
However, Verkruyse discloses systems and methods for integrating, analyzing, and reasoning over heterogeneous data at scale with a synergistic data processing infrastructure featuring a graph database core for unified data representation (see abstract) wherein the map is an AI map (a key feature of the UI is its ability to display data provenance information, ensuring transparency and traceability; for each data point or relationship stored in the semantic graph database 204, users can access, for example, the original file source, the algorithm or processing method used to extract or generate the data, an indication of whether the data was AI-generated or human-inputted, and/or a timestamp and/or version history of data modifications – see [0056]; the data loaders 208 employ a combination of user-guided processes, AI/ML techniques, and customizable mapping strategies to transform unstructured, structured, and/or time series data into a rich, interconnected graph representation within the semantic graph database 204 – see [0062]; see also [0075]).
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 method in Ghosh to include the method, wherein identifying the corresponding set of attributes for each candidate comprises: evaluating associated input and output dependencies of each candidate, wherein the associated dependencies comprise one or more of libraries, files, or import modules; and displaying a visual representation of the input and output dependencies for each candidate on a graphical user interface, wherein the visual representation comprises an interconnected map of one or more objects representing a sequence of inputs to outputs in accordance with the dependencies at a specified-hierarchy level, wherein the objects are indicative of dependency information comprising a type of dependency, a scan status, and a type of dependency, as taught by Ackroyd; and, the map being an AI map, as taught by Verkruyse. One would have been motivated to provide visual representation of the architecture of the scanned element(s), as recognized by Ackroyd (see [0009]); and, to make such a combination to allows users to understand the origin and processing history of any data within the system and ensuring transparency and traceability, as recognized by Verkruyse (see [0056]).
Regarding claim 58, all limitations correspond to the system performing the method of claim 13. Therefore, claim 58 is being rejected on the same basis as claim 13.
Regarding claim 103, all limitations correspond to the system performing the method of claim 13. Therefore, claim 103 is being rejected on the same basis as claim 13.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), and Posert (US 11966930 B1), as applied to claims 1, 2 and 15 above, in view of Hutton (US 9330264 B1), hereinafter Hutton.
Regarding claim 16, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 15 above. Furthermore, Ghosh discloses the method, wherein determining the risk score for each candidate comprises:
assigning a risk weight to each attribute in the corresponding set of attributes (the target likelihood score is generated by a determination algorithm that weights the various data properties processed for purposes of applying the hierarchy of scan criteria, and/or calculates the factor values to be altered by each weight based on the data value for each data property – see [0143]).
Ghosh discloses determining the number of keywords identified in the data or metadata of the target file – see [[0143].
Ghosh, Cheng and Posert fail to disclose determining a number of instances of each attribute in the corresponding set of attributes; and for each attribute, multiplying the risk weight with the number of instances of the attribute and aggregating to determine an aggregate risk score for the candidate as the risk score.
However, Hutton discloses a system and method for calculating a risk assessment for an electronic file (see abstract) including determining a number of instances of each attribute in the corresponding set of attributes; and for each attribute, multiplying the risk weight with the number of instances of the attribute and aggregating to determine an aggregate risk score for the candidate as the risk score (for a given purported file format, checks can be performed to see if the electronic file meets the standard for that file format; if a particular check is not satisfied—that is, the electronic file fails to satisfy some element of the standard for that file format—then that issue is flagged as having occurred; threat calculator 320 can take electronic file 105 and database 305, and calculate risk assessment 505 for electronic file 105; risk assessment 505 is calculated by multiplying the number of occurrences of each issue by the corresponding weight for that issue, and summing the products - see col. 6, lines 36-51)
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 method in Ghosh to include determining a number of instances of each attribute in the corresponding set of attributes; and for each attribute, multiplying the risk weight with the number of instances of the attribute and aggregating to determine an aggregate risk score for the candidate as the risk score, as taught by Hutton. One would have been motivated to make such a combination to provide shades of grey, to allow for blending this information into an overall decision-making process for that particular file or content thus increasing detection accuracy and reducing false positives, as recognized by Hutton (see col. 3, lines 25-30).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), and Posert (US 11966930 B1), as applied to claims 1, 2 and 15 above, in view of Hecht et al. (US 10607015 B1), hereinafter Hecht.
Regarding claim 18, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 15 above.
Ghosh, Cheng and Posert fail to disclose the method, further comprising, for each candidate: calculating a percentage of risk contribution for each attribute; and displaying the percentages in a risk score card comprising a visual representation of the percentages on a graphical user interface.
However, Hecht discloses systems and methods for automatically detecting and addressing security risks in code segments (see abstract) including the method, further comprising, for each candidate:
calculating a percentage of risk contribution for each attribute (combined risk score 550 may be an aggregation of risk scores 510, 520, and 530; combined risk score may weigh each of risk scores 510, 520, and 530 differently, for example, based on a predefined formula, or based on attributes of code segment 420; similar to each individual risk score 510, 520, and 530, combined risk score 550 may be represented in a variety of forms or formats including as a percentage – see col. 15, lines 7-17 and 39-42); and
displaying the percentages in a risk score card comprising a visual representation of the percentages on a graphical user interface (the risk score may be displayed to the developer, for example, within IDE 132 or through a user interface of computing device 130 – see col. 16, lines 25-30).
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 method in Ghosh to include the method, further comprising, for each candidate: calculating a percentage of risk contribution for each attribute; and displaying the percentages in a risk score card comprising a visual representation of the percentages on a graphical user interface, as taught by Hecht. One would have been motivated to make such a combination to allow developers to better understand the security implications or risks associated with the code, as recognized by Hecht (see col. 16, lines 25-37).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), and Posert (US 11966930 B1), as applied to claim 1 above, in view of Ferrie et al. (US 10318250 B1), hereinafter Ferrie.
Regarding claim 20, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 1 above.
Ghosh, Cheng and Posert fail to disclose the method, further comprising: grouping copies of a file in the subset of candidates as a single candidate; or grouping versions of a file in the subset of candidates as a single candidate.
However, Ferrie discloses systems and methods for locating functions (see abstract), including the method, further comprising: grouping copies of a file in the subset of candidates as a single candidate; or grouping versions of a file in the subset of candidates as a single candidate (the set of files may include a group of versions of the file – see col. 2, lines 1-5).
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 method in Ghosh to include the method, further comprising: grouping copies of a file in the subset of candidates as a single candidate; or grouping versions of a file in the subset of candidates as a single candidate, as taught by Ferrie. One would have been motivated to improve the functioning and ability of the system to locate/identify file functions, as recognized by Ferrie (see col. 3, lines 35-51).
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), and Posert (US 11966930 B1), as applied to claims 1 and 2 above, in view of Barday et al. (US 20220286482 A1), hereinafter Barday.
Regarding claim 21, Ghosh, Cheng and Posert disclose all the claimed subject matter recited in claim 2 above. Furthermore, Ghosh discloses the method, wherein determining the subset of candidates further comprises assigning a
using a calculator engine configured to enact one or more arithmetical and logical operations as a calculation on the candidates based on the corresponding set of attributes; and determining one or more assigned (the target likelihood score is generated by a determination algorithm that weights the various data properties processed for purposes of applying the hierarchy of scan criteria, and/or calculates the factor values to be altered by each weight based on the data value for each data property as described herein. In some embodiments, the target likelihood score represents a number of scan criteria that were met, a determined complexity of the file, a determined likelihood that the owner role of the owner of the candidate file owns a target file, and/or a combination thereof – see [0143]).
Cheng discloses labeling the candidate code in certain situation. For instance, labeling the flagged candidate code as plagiarized (see [0094]) or as containing redundancies, unnecessary complexity, or inefficient constructs for refactoring and optimizing the code for improved performance and maintainability (see [0097]).
Ghosh, Cheng and Posert fail to disclose assigning a label based on the calculation.
However, Barday discloses system and methos for performing assessments and monitoring of new versions of computer code for compliance (see abstract) including the method, wherein determining the subset of candidates further comprises assigning a label to each candidate in the subset of candidates, and wherein assigning comprises: using a calculator engine configured to enact one or more arithmetical and logical operations as a calculation on the candidates based on the corresponding set of attributes; and determining one or more assigned labels based on the calculation (the Risk Assessment Module 430 may be configured to automatically calculate the numerical Risk Level for each campaign within the system, and then use the numerical Risk Level to assign an appropriate Overall Risk Assessment to the respective campaign; a campaign with a Risk Level of 5 may be labeled with an Overall Risk Assessment as “Low Risk”- see [0127]).
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 method in Ghosh to include the method, wherein determining the subset of candidates further comprises assigning a label to each candidate in the subset of candidates, and wherein assigning comprises: using a calculator engine configured to enact one or more arithmetical and logical operations as a calculation on the candidates based on the corresponding set of attributes; and determining one or more assigned labels based on the calculation, as taught by Barday. One would have been motivated to provide transparency and clarity regarding risks and vulnerabilities in order to have adequate audits and oversight to minimize security incidents, as recognized by Barday (see [0056-78]).
Claims 22 and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), Posert (US 11966930 B1), and Barday et al. (US 20220286482 A1), as applied to claim 21 above, in view of Wang et al. (US 20230214751 A1), hereinafter Wang, and further in view of Aebig et al. (US 20100050264 A1), hereinafter Aebig.
Regarding claim 22, Ghosh, Cheng, Posert and Barday disclose all the claimed subject matter recited in claim 21 above.
Furthermore, Ghosh discloses removing the data portions that make the data file a target file (e.g., EUCT) as a remedy – see [0171].
Cheng discloses the method, further comprising enacting one or more actions on a subset of candidates identified based at least on the one or more assigned labels, the one or more actions comprising: retaining the subset of candidates for further assessment; deleting the subset of candidates from the repository; moving the subset of candidates to a new location in the repository; adding the subset of candidates to a maintained file inventory (action 610 may consist of removing the flagged candidate code (i.e., deleting) – see [0087-90]; action 610 may consist of approving the flagged candidate code and merging it into the main codebase (i.e., retaining, moving and adding) – see [0093]; action 610 may consist of flagging the candidate code for debugging, optimizing (i.e., retaining for further assessment) - see [0095] and [0097]).
Ghosh, Cheng, Posert and Barday fail to disclose the method, further comprising enacting one or more actions on a subset of candidates identified based at least on the one or more assigned labels, the one or more actions comprising: starting a workflow using a pre-built workflow template; and identifying copies of files within the subset of candidates.
However, Wang discloses a predictive workflow and analytics platform that integrates one or more machine learning (ML) models with an analytics user interface (UI) into a workflow task (see [0005]) including starting a workflow using a pre-built workflow template (the workflow task editor 250 provides a set of templates and a wizard that enables the developer 210 to create an analytics UI for a workflow task – see [0033]).
In addition, Aebig discloses a spreadsheet risk reconnaissance network (see abstract) including identifying copies of files within the subset of candidates (Review Duplicate File group provides the user with an indication of where redundancies exist and further investigation may need to take place; because these files had originated as another file, they will inherit the risk associated with the previous file – see [0290]).
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 method in Ghosh to include the method, further comprising enacting one or more actions on a subset of candidates identified based at least on the one or more assigned labels, the one or more actions comprising: starting a workflow using a pre-built workflow template, as taught by Wang; and identifying copies of files within the subset of candidates, as taught by Aebig. One would have been motivated to enable the user to execute a respective workflow task, as recognized by Wang (see [0007]); and, to provide the user with an indication of where redundancies exist and further investigation may need to take place, as recognized by Aebig (see [0290]).
Regarding claim 26, Ghosh, Cheng, Posert, Barday, Wang and Aebig disclose all the claimed subject matter recited in claim 22 above.
Furthermore, Wang discloses the method, wherein starting a workflow using a pre-built workflow template comprises:
generating a workflow task form configured to accept one or more user-inputs pertaining to values associated with an outcome of a task in accordance with a user-configured identification of one or more user-inputs solicited from one or more users or groups assigned to the task for completion of the task (developer (i.e., user) makes selection and workflow task editor provides a set of input fields to receive input from the developer, for instance, to indicate what is to be included in a section – see [0037]; the developer can select a workflow task UI for display, then drag-drop an analytics UI to where the developer would like it placed within the workflow task UI – see [0048]), wherein the user-configured identification of the one or more user-inputs comprises a set of questions indicated as required or optional for task completion (the workflow task editor queries the developer until all information required for a selected analytics UI control and ML model bound thereto has been input – see [0042]; in response to the user selecting a workflow task to execute, an analytics UI corresponding to the workflow task is rendered; one or more inference results are requested and received; and analytics UI control is populated with the one or more inference results for display to the user 208 within the analytics UI – see [0053]; see also [0035-36] and [0051-52]), and wherein the one or more users or one or more groups of users are dynamically assigned using a user-input value from a pre-configured metadata form (it can be determined that the developer has not provided input for series titles within a chart that is to be displayed and, in response, the developer is prompted to provide input descriptive of the series titles; if it is determined that the analytics UI is not complete, the process loops back; if it is determined that the analytics UI is complete, a metadata file is exported; in response to completing all required selections, the workflow task editor provides a metadata file that is executable in the workflow tasks systems – see [0052]; users are provided with comprehensive information that enables users to complete workflow tasks - see [0054]; see also [0035]).
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 method in Ghosh to include the method, further comprising enacting one or more actions on a subset of candidates identified based at least on the one or more assigned labels, the one or more actions comprising: starting a workflow using a pre-built workflow template, as taught by Wang. One would have been motivated to provide users with comprehensive information that enables them to complete workflow tasks in a time- and resource-efficient manner; thus, not only is execution of the workflow task faster and more efficient, but also expending technical resources is avoided, as recognized by Wang (see [0054]).
Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over Ghosh et al. (US 20250252079 A1), Cheng et al. (US 20240419801 A1), Posert (US 11966930 B1), Barday et al. (US 20220286482 A1), Wang et al. (US 20230214751 A1), and Aebig et al. (US 20100050264 A1), as applied to claim 26 above, and further in view of Jayapathi et al. (US 20230251854 A1), hereinafter Jayapathi.
Regarding claim 27, Ghosh, Cheng, Posert, Barday, Wang and Aebig disclose all the claimed subject matter recited in claim 26 above.
Ghosh, Cheng, Posert, Barday, Wang and Aebig fail to disclose the method, further comprising preventing the workflow from advancing based at least on the one or more user-inputs entered into the workflow task form.
However, Jayapathi discloses systems and methods for routing requests to a plurality of server clusters are disclosed, especially in a workflow management context (see abstract), including the method, further comprising preventing the workflow from advancing based at least on the one or more user-inputs entered into the workflow task form (if automated approval is impossible, a human user will be involved and the workflow will continue until all steps have been performed – see [0123]; the above series of steps may be monitored, interrupted, resumed or transferred at any time by means of a workflow management dashboard – see [0124]).
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 method in Ghosh to include the method, further comprising preventing the workflow from advancing based at least on the one or more user-inputs entered into the workflow task form, as taught by Jayapathi. One would have been motivated to provide finer control over workflow, as recognized by Jayapathi (see [0002]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DORIANNE ALVARADO DAVID whose telephone number is (571)272-4228. The examiner can normally be reached 9:00am-5:00pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip Chea can be reached at (571) 272-3951. 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.
/DORIANNE ALVARADO DAVID/Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights