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
Notice to Applicant
In response to the communication received on 09/10/2026, the following is a Final Office Action for Application No. 19011155.
Status of Claims
Claims 1-20 are pending.
Priority
As required by M.P.E.P. 201.14(c), acknowledgement is made of applicant’s claim for priority based on: 19011155 filed 01/06/2025 claims foreign priority to 10202400773V, filed 03/19/2024.
Response to Amendments
Applicant’s amendments have been fully considered.
Response to Arguments
Applicant’s arguments with respect to the claims have been considered but are moot in light of the new grounds of rejection, as necessitated by amendment.
As per the 101 rejection, Applicant argues that the claims are in favor of eligibility per Prong One of Step 2A, however Examiner respectfully disagrees. Per Prong One of Step 2A, the identified recitation of an abstract idea falls within at least one of the Abstract Idea Groupings consisting of: Mathematical Concepts, Mental Processes, or Certain Methods of Organizing Human Activity. Particularly, the identified recitation falls within the Mental Processes including concepts performed in the human mind (including an observation, evaluation judgment, opinion) and/or Certain Methods of Organizing Human Activity including managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules of instructions). Since the recitation of the claims falls into at least one of the above Groupings, there is a basis for providing further analysis with regard to Prong Two of Step 2A to determine whether the recitation of an abstract idea is deduced to being directed to an abstract idea. Thus, the rejection is maintained.
Applicant argues that the claims are in favor of eligibility per Prong Two of Step 2A, however Examiner respectfully disagrees. Per Prong Two of Step 2A, this judicial exception is not integrated into a practical application because the claim as a whole does not integrate the identified abstract idea into a practical application. The server, memory, processor, natural language processing, and/or machine learning models is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing/transmitting data. This generic processor server limitation is no more than mere instructions to apply the exception using a generic computer component. Further, server, memory, processor, natural language processing, and/or machine learning models to inter alia perform the function of verifying the LCA data as either valid data or invalid data, based on both the evaluated credibility of the LCA data source and the evaluated plausibility of the impact level which is mere instruction to apply an exception using a generic computer component which cannot integrate a judicial exception into a practical application. Accordingly, this/these additional element(s) does/do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. In other words, the present claims use a generic processing device and memory medium to inter alia perform the function of verifying the LCA data as either valid data or invalid data, based on both the evaluated credibility of the LCA data source and the evaluated plausibility of the impact level which is a concept that can be performed in the human mind. The processor is merely used to perform the function(s), and the processor does not integrate the abstract idea into a practical application since there are no meaningful limits on practicing the abstract idea. Thus, since the claims are directed to the determined judicial exception in view of the two prongs of Step 2A, the 2019 PEG flowchart is directed to Step 2B. Thus, the rejection is maintained.
Applicant argues that the claims are in favor of eligibility per Step 2B, however Examiner respectfully disagrees. Therein, the additional elements and combinations therewith are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. It is noted here that the additional elements are to be considered both individually and as an ordered combination. In this case, the claims each at most comprise additional elements of: server, memory, processor, natural language processing, and/or machine learning models. Taken individually, the additional limitations each are generically recited and thus does not add significantly more to the respective limitations. Further, server, memory, processor, natural language processing, and/or machine learning models to inter alia perform the function of verifying the LCA data as either valid data or invalid data, based on both the evaluated credibility of the LCA data source and the evaluated plausibility of the impact level which is mere instruction to apply an exception using a generic computer component which cannot provide an inventive concept in Step 2B (or, looking back to Step 2A, cannot integrate a judicial exception into a practical application). For further support, the Applicant’s specification supports the claims being directed to use of a generic computer/memory type structure. Taken as an ordered combination, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the limitations are directed to limitations referenced in Alice Corp. that are not enough to qualify as significantly more when recited in a claim with an abstract idea include the non-limiting or non-exclusive examples of MPEP § 2106.05. Thus, the rejection is maintained.
In an effort to further expedite prosecution, see: July 2024 Subject Matter Eligibility Examples, Example 47. Anomaly Detection. Per the analysis of claim 2 Example 47, the analysis refers to MPEP 2106.05(f) which provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Although the additional elements, e.g. (per Example 47) “using a trained ANN”, limits the identified judicial exceptions, e.g. (per Example 47) “detecting one or more anomalies in a data set using the trained ANN” and, e.g. (per Example 47) “analyzing the one or more detected anomalies using the trained ANN to generate anomaly data,” this type of limitation merely confines the use of the abstract idea to a particular technological environment, e.g. (per Example 47: neural networks) and thus fails to add an inventive concept to the claims. See MPEP 2106.05(h). As an exemplary direction for claim limitations to be eligible, see claims 1 and 3 of Example 47.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claims fall within statutory class of process or machine; hence, the claims fall under statutory category of Step 1.
Step 2 is the two-part analysis from Alice Corp. (also called the Mayo test). The 2019 PEG makes two changes in Step 2A: It sets forth new procedure for Step 2A (called “revised Step 2A”) under which a claim is not “directed to” a judicial exception unless the claim satisfies a two-prong inquiry. The two-prong inquiry is as follows: Prong One: evaluate whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). If claim recites an exception, then Prong Two: evaluate whether the claim recites additional elements that integrate the exception into a practical application of the exception. The claim(s) recite(s) the following abstract idea indicated by non-boldface font and additional limitations indicated by boldface font:
A server for facilitating a verification of life-cycle assessment (LCA) data, the server comprising: a memory configured to store instructions; and a processor configured to execute the stored instructions and configured to: detect LCA data from an LCA data source; identify information relating to a quality of the LCA data and a quality of the LCA data source using a natural language processing (NLP) technique; evaluate credibility of the LCA data source using a first machine learning model based on the identified information relating to the quality of the LCA data source; evaluate a plausibility of an impact level using a second machine learning model based on the identified information relating to the quality of the LCA data, wherein the credibility of the LCA data source and the plausibility of the impact level are separately evaluated based on the identified information relating to the quality of the LCA data source and the identified information relating to the quality of the LCA data, respectively; and verify the LCA data as either valid data or invalid data, based on both the evaluated credibility of the LCA data source and the evaluated plausibility of the impact level.
[or]
A method for facilitating a verification of life-cycle assessment (LCA) data, the method comprising: detecting LCA data from an LCA data source; identifying information relating to a quality of the LCA data and a quality of the LCA data source using a natural language processing (NLP) technique; evaluating credibility of the LCA data source using a first machine learning model based on the identified information relating to the quality of the LCA data source; evaluating a plausibility of an impact level using a second machine learning model based on the identified information relating to the quality of the LCA data wherein the credibility of the LCA data source and the plausibility of the impact level are separately evaluated based on the identified information relating to the quality of the LCA data source and the identified information relating to the quality of the LCA data, respectively; and verifying the LCA data as either valid data or invalid data, based on both the evaluated credibility of the LCA data source and the evaluated plausibility of the impact level.
The claim(s) recite(s) the following summarization of the abstract idea which includes facilitating a verification of life-cycle assessment (LCA) data executed by the additional element(s) of server, memory, processor, natural language processing, and/or machine learning models. This falls into at least the Abstract Idea Grouping of Mental Processes since the information can be analyzed by an abstract evaluation judgment process. Thus, per Prong One of Step 2A, the identified recitation of an abstract idea falls within at least one of the Abstract Idea Groupings consisting of: Mathematical Concepts, Mental Processes, or Certain Methods of Organizing Human Activity since the identified recitation falls within the Mental Processes including concepts performed in the human mind (including an observation, evaluation judgment, opinion).
Per Prong Two of Step 2A, this judicial exception is not integrated into a practical application because the claim as a whole does not integrate the identified abstract idea into a practical application. The server, memory, processor, natural language processing, and/or machine learning models is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing/transmitting data. This generic server, memory, processor, natural language processing, and/or machine learning models limitation is no more than mere instructions to apply the exception using a generic computer component. Further, verify the LCA data as either valid data or invalid data by a server, memory, processor, natural language processing, and/or machine learning models is mere instruction to apply an exception using a generic computer component which cannot integrate a judicial exception into a practical application. Accordingly, this/these additional element(s) does/do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The NLP and machine-learned model is used to generally apply the abstract idea without placing any limits on how the NLP and machine-learned model functions. Rather, these limitations only recite the outcome of the functions and do not include any details about how the functions via the NLP and machine-learned model are accomplished. See MPEP 2106.05(f). Thus, since the claims are directed to the determined judicial exception in view of the two prongs of Step 2A, the 2019 PEG flowchart is directed to Step 2B.
Per Step 2B, the additional elements and combinations therewith are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. It is noted here that the additional elements are to be considered both individually and as an ordered combination. In this case, the claims each at most comprise additional elements of: server, memory, processor, natural language processing, and/or machine learning models. Taken individually, the additional limitations each are generically recited and thus does not add significantly more to the respective limitations. The additional element of a NLP and/or machine-learned model is at best mere instructions to “apply” the abstract ideas, which cannot provide an inventive concept. See MPEP 2106.05(f). Further, verify the LCA data as either valid data or invalid data by a server, memory, processor, natural language processing, and/or machine learning models is mere instruction to apply an exception using a generic computer component which cannot provide an inventive concept in Step 2B (or, looking back to Step 2A, cannot integrate a judicial exception into a practical application). For further support, the Applicant’s specification supports the claims being directed to use of a generic computer/memory type structure at ¶0063 wherein “the processor 12 may include, but is not limited to, a microprocessor, an analogue circuit, a digital circuit, a mixed-signal circuit, a logic circuit, an integrated circuit, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), or any combination thereof.” Taken as an ordered combination, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the limitations are directed to limitations referenced in Alice Corp. that are not enough to qualify as significantly more when recited in a claim with an abstract idea include, as a non-limiting or non-exclusive examples: i. Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 134 S. Ct. at 2360, 110 USPQ2d at 1984 (see MPEP § 2106.05(f));
PNG
media_image1.png
18
19
media_image1.png
Greyscale
ii. Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 134 S. Ct. at 2359-60, 110 USPQ2d at 1984 (see MPEP § 2106.05(d));
PNG
media_image1.png
18
19
media_image1.png
Greyscale
iii. Adding insignificant extra-solution activity to the judicial exception, e.g., mere data gathering in conjunction with a law of nature or abstract idea such as a step of obtaining information about credit card transactions so that the information can be analyzed by an abstract mental process, as discussed in CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011) (see MPEP § 2106.05(g)); or
PNG
media_image1.png
18
19
media_image1.png
Greyscale
v. Generally linking the use of the judicial exception to a particular technological environment or field of use, e.g., a claim describing how the abstract idea of hedging could be used in the commodities and energy markets, as discussed in Bilski v. Kappos, 561 U.S. 593, 595, 95 USPQ2d 1001, 1010 (2010) or a claim limiting the use of a mathematical formula to the petrochemical and oil-refining fields, as discussed in Parker v. Flook. The courts have recognized the following computer functions inter alia to be well-understood, routine, and conventional functions when they are claimed in a merely generic manner: performing repetitive calculations; receiving, processing, and storing data (e.g., the present claims); electronically scanning or extracting data; electronic recordkeeping; automating mental tasks (e.g., process/machine/manufacture for performing the present claims); and receiving or transmitting data (e.g., the present claims).
The dependent claims do not cure the above stated deficiencies, and in particular, the dependent claims further narrow the abstract idea without reciting additional elements other than a database and the addressed NLP and machine learned model that integrate the exception into a practical application of the exception or providing significantly more than the abstract idea. Since there are no elements or ordered combination of elements that amount to significantly more than the judicial exception, the claims are not eligible subject matter under 35 USC §101.
Thus, viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20220366056 A1) hereinafter referred to as Lee in view of Moshir et al. (US 20140214610 A1) hereinafter referred to as Moshir.
Lee teaches:
Claim 1. A server for facilitating a verification of life-cycle assessment (LCA) data, the server comprising:
a memory configured to store instructions; anda processor configured to execute the stored instructions and configured to (¶0047 FIGS. 3A and 3B are flowcharts illustrating a method 300 of implementing zero-trust principles to the management of source codes, according to various aspects of the present disclosure. The various steps of the method 300, which are described in greater detail above, may be performed by one or more electronic processors, for example by the processors of a computer or server of a data controller transferring second-party data to a third-party (i.e., a data processor). In some embodiments, at least some of the steps of the method 300 may be performed by the processors of a computer or server implementing the code and developer security (CDS) module 160.):
detect LCA data from an LCA data source (¶0014 Some embodiments of the present disclosure disclose the implementation of zero-trust principles and techniques to source codes during the software development lifecycle. That is, no source code, or updates thereof, intended for execution in a network of managed compute facilities may be trusted and the security risk to the network that may be associated with the source code may be managed with the use of artificial intelligence to identify anomalous coding behavior (of the source code developer, for instance) and code execution behaviors. In some embodiments, source codes may be analyzed using machine learning algorithms to determine or identify the author or developer of the source code, i.e., attribute the source code to one or more code developers. For example, natural language processing (NLP) algorithms can be used to identify the coding style of code developers (e.g., by training the algorithms with a training dataset of source codes/updates, including those previously developed by the code developers) and strongly attribute new source codes or source code updates to specific developers based on the results of the NLP analysis. ¶0060 FIG. 4 is a flowchart illustrating a method 400 of implementing zero-trust principles to the management of execution of source codes in an execution environment of an organization's network of managed compute facilities, according to various aspects of the present disclosure. The various steps of the method 400, which are described in greater detail above, may be performed by one or more electronic processors, for example by the processors of a computer or server implementing the code and developer security (CDS) module 160.);
identify information relating to a quality of the LCA data and a quality of the LCA data source using a natural language processing (NLP) technique (Fig. 3A and ¶0014 Some embodiments of the present disclosure disclose the implementation of zero-trust principles and techniques to source codes during the software development lifecycle. That is, no source code, or updates thereof, intended for execution in a network of managed compute facilities may be trusted and the security risk to the network that may be associated with the source code may be managed with the use of artificial intelligence to identify anomalous coding behavior (of the source code developer, for instance) and code execution behaviors. In some embodiments, source codes may be analyzed using machine learning algorithms to determine or identify the author or developer of the source code, i.e., attribute the source code to one or more code developers. For example, natural language processing (NLP) algorithms can be used to identify the coding style of code developers (e.g., by training the algorithms with a training dataset of source codes/updates, including those previously developed by the code developers) and strongly attribute new source codes or source code updates to specific developers based on the results of the NLP analysis.);
evaluate credibility of the LCA data source using a first machine learning model based on the identified information relating to the quality of the LCA data source (Fig. 3A and ¶0049 The method 300 includes a step 320 to apply a first machine learning algorithm to the first portion of the source code. The method 300 includes a step 330 to generate, based on the applying the first machine learning algorithm, a confidence level measuring a level of contribution of a first code developer to a development of the first portion of the source code.);
evaluate a plausibility of an impact level using a second machine learning model based on the identified information relating to the quality of the LCA data, wherein the credibility of the LCA data source and the plausibility of the impact level are separately evaluated based on the identified information relating to the quality of the LCA data source and the identified information relating to the quality of the LCA data, respectively (Fig. 3A and ¶0051 The method 300 includes a step 340 to apply a second machine learning algorithm to the code development data. The method 300 includes a step 350 to generate, using a machine learning classifier based on applying the second machine learning algorithm, an anomaly indicator identifying a code development behavioral anomaly associated with the first code developer and occurring during the development of the source code ¶0053 The method 300 includes a step 360 to analyze the confidence level and the anomaly indicator. The method 300 includes a step 370 to identify, based on the analyzing, a security risk associated with use of the source code.); and
verify the LCA data as either valid data or invalid data, based on the evaluated credibility of the LCA data source and the evaluated plausibility of the impact level (¶0055 In some embodiments, a second portion of the source code includes an open source code developed by a second code developer using a second computing device. In such embodiments, the method 300 further comprises applying a third machine learning algorithm to the open source code; and generating, based on the third machine learning algorithm, a risk indicator indicating level of the security risk associated with executing the source code including the open source code. In some embodiments, the third machine learning algorithm is configured to generate the risk indicator based on a reputation score of the second code developer or information associated with changes made to one or more first previous releases of the open source code since a second previous release of the open source code identified as a trusted open source code. ¶0060 FIG. 4 is a flowchart illustrating a method 400 of implementing zero-trust principles to the management of execution of source codes in an execution environment of an organization's network of managed compute facilities, according to various aspects of the present disclosure.).
Although not explicitly taught by Lee, Moshir teaches in the analogous art of systems to intelligently assess and mitigate security risks on a mobile device:
wherein the credibility of the LCA data source and the plausibility of the impact level are separately evaluated based on the identified information relating to the quality of the LCA data source and the identified information relating to the quality of the LCA data, respectively (¶0027 enterprise versions and consumer versions of apps pose different challenges. When an enterprise deploys an app throughout its organization, the enterprise, expects the app to be of enterpriser quality. When an organization deploys an app, the organization may rely on the app for a portion of its business. Hence if the app is not capable of delivering the expected services, the organization may have losses such as financial loss or productivity loss. Furthermore, the organization may lose its competitive edge or productivity. An enterprise app should be ready to support the enterprise at a higher level than what is expected of consumer version. Thus, an enterprise app requires more formalized approach for product development. For example, it is expected for an enterprise app to follow the software development life cycles. It is common for manufacturers developing enterprise apps to have roadmaps, gather app requirements from market and customers, address scalability challenges, and have Quality Assurance (QA) metrics and measures. Hence, it is typical for organizations that wish to purchase an app for enterprise deployment to have concerns about the app manufacturer readiness to provide an enterprise ready app. … the organization needs to know if the manufacturer has fair and equitable End User License Agreement (EULA) that protects the organization against infringement of Intellectual Properties (IP) rights. In addition, it is common for app manufacturers to incorporate third party libraries such as Open Source Software into their product. It is important for the organization to know such information in order to properly assess the risks and rewards associated with the deployment of the app. ¶0030 This list of violations, along with the other gathered information regarding the manufacturer's website, its location, its level of co-operation, its app source code analysis, and its business data, is stored in the database of system 100 as a manufacturer profile (which includes as a plurality of attributes for the manufacturer) and is submitted (step 330) for calculation of a manufacturer risk score (step 334) by the risk calculation software module, which risk score can be used to help determine the credibility of the manufacturer to produce or maintain the mobile device application. ¶0256 Once a score for each category is calculated, it can be normalized based on the following logic: For any risk scenario, an impact needs to be calculated. In order to calculate the impact, a best case scenario and worst case scenario is calculated. For this purpose, the Calculator app is considered as the best case scenario benchmark. Calculator doesn't have any access to any data stored on the phone, doesn't use any storage, doesn't need access to Internet, etc. all it needs is CPU power and communication with a screen to get user input, do some calculations and return the result. Therefore the weight of impact on security by calculator is the lowest therefore the likelihood is the lowest {analysis of likelihood that another LCA data is trusted based on the impact level}).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the systems to intelligently assess and mitigate security risks on a mobile device of Moshir with the system for computer security using zero-trust principles and AI for source code of Lee for the following reasons:
(1) a finding that there was some teaching, suggestion, or motivation, either in the references themselves or in the knowledge generally available to one of ordinary skill in the art, to modify the reference or to combine reference teachings, e.g. Lee ¶0003 teaches that there is a need for improved computer security relative to source code and execution of applications originating from that source code;
(2) a finding that there was reasonable expectation of success since the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference, e.g. Lee teaches the implementation of zero-trust principles for source codes and application executions, and Moshir teaches a system for evaluating an application manufacturer's credibility to produce or maintain a mobile device application.; and
(3) whatever additional findings based on the Graham factual inquiries may be necessary, in view of the facts of the case under consideration, to explain a conclusion of obviousness, e.g. Lee at least the above cited paragraphs, and Moshir at least the inclusively cited paragraphs.
Therefore, it would be obvious to one skilled in the art at the time of the invention to combine the systems to intelligently assess and mitigate security risks on a mobile device of Moshir with the system for computer security using zero-trust principles and AI for source code of Lee. The rationale to support a conclusion that the claim would have been obvious is that "a person of ordinary skill in the art would have been motivated to combine the prior art to achieve the claimed invention and whether there would have been a reasonable expectation of success in doing so." DyStar Textilfarben GmbH & Co. Deutschland KG v. C.H. Patrick Co., 464 F.3d 1356, 1360, 80 USPQ2d 1641, 1645 (Fed. Cir. 2006). See MPEP 2143(G).
Lee teaches:
Claim 2. The server according to claim 1, wherein the processor is further configured to:obtain project data for a project from a project database; andstore the project data in a data storage as temporary data,wherein the data storage stores at least one of a trusted data source, an invalid data source, invalid data, and a valid data format (¶0031 In some embodiments, the CDS module 160 may include a machine learning algorithm that is configured to generate a risk indicator for executing the open source code (e.g., developed by the code developers 115a-115n and imported into the networked system 100 and stored in the database 150) based on a reputation score of one or more of the code developers 115a-115n. Further, the risk indicator may also depend on information associated with changes made to one or more previous releases of the open source code since a previous release of the open source code identified as a trusted open source code.).
Lee teaches:
Claim 3. The server according to claim 2, wherein the processor is further configured to identify the LCA data that needs to be verified among the project data stored as the temporary data, based on at least one of the invalid data source, the invalid data, and the valid data format stored in the data storage and an internal LCA database (¶0030 In some embodiments, the CDS module 160 may include a user behavioral analytic (UBA) machine learning algorithm that is trained on a training set of code development data (e.g., at least some of which are related to the coding activities, using the developer workstation 120 for instance, of the code developer 130 when developing source codes) to identify anomalous coding behaviors of the code developer 130. In some instances, source code check-ins, calls to source code libraries, accesses to program management or validation tools, request to include or merge changes to source codes, etc., may be some of the features or inputs of the UBA machine learning algorithm, and the CDS module 160 may apply the trained UBA machine learning algorithm on the code development data of the code developer 130 related to the source code and retrieved from the database 150 to identify anomalous coding behaviors of the code developer 130.).
Lee teaches:
Claim 4. The server according to claim 3, wherein the processor is further configured to identify the LCA data source whose credibility needs to be evaluated among the identified LCA data, based on the trusted data source saved in the data storage (¶0015 In some embodiments, the coding behavior of a code developer may be captured or documented as code development data and machine learning algorithms may be used on the code development data to identify coding behaviors that may be anomalies. For example, the coding behaviors of a code developer may be monitored for a fixed period to generate code development data associated with activities of the computing device of the code developer including information related to the coding behavior of the code developer when authoring source codes or updates.).
Lee teaches:
Claim 5. The server according to claim 1, wherein the first machine learning model is a classification machine learning model, and the second machine learning model is a regression machine learning model (¶0046 Although the above discussions pertain to an artificial neural network as an example of machine learning, it is understood that other types of machine learning methods may also be suitable to implement the various aspects of the present disclosure. For example, support vector machines (SVMs) may be used to implement machine learning. SVMs are a set of related supervised learning methods used for classification and regression. A SVM training algorithm— which may be a non-probabilistic binary linear classifier—may build a model that predicts whether a new example falls into one category or another. As another example, Bayesian networks may be used to implement machine learning. A Bayesian network is an acyclic probabilistic graphical model that represents a set of random variables and their conditional independence with a directed acyclic graph (DAG). The Bayesian network could present the probabilistic relationship between one variable and another variable. Another example is a machine learning engine that employs a decision tree learning model to conduct the machine learning process. In some instances, decision tree learning models may include classification tree models, as well as regression tree models. In some embodiments, the machine learning engine employs a Gradient Boosting Machine (GBM) model (e.g., XGBoost) as a regression tree model.).
Lee teaches:
Claim 6. The server according to claim 1, wherein the processor is configured to evaluate the credibility of the LCA data source by:collecting data including the information relating to the quality of the LCA data and the quality of the LCA data source from the LCA data source using a data collection module;extracting the information relating to the quality of the LCA data and the quality of the LCA data source from the collected data using a data extraction module;verifying the extracted information based on information obtained from a trusted LCA data source using a data verification module;evaluating the credibility of the LCA data source using a text classification module;predicting the credibility of the LCA data source using a credibility prediction module;evaluating themes of the LCA data source using a theme evaluation module;evaluating the quality of the LCA data using an LCA data analysis module; andgenerating a final evaluation result using a result generation module (¶0012 The present disclosure pertains to methods and systems for the implementation of zero-trust principles to the management of source codes and application executions according to various embodiments. Zero-trust principles include a set of system/network design principles with security as one of the primary goals that assume no person and device that has been granted access to a network of managed compute facilities is to be trusted, and the security of the network is to be bolstered with the continual monitoring of network activities while granting the person or device least-privileges on as-needed basis. ¶0014 natural language processing (NLP) algorithms can be used to identify the coding style of code developers (e.g., by training the algorithms with a training dataset of source codes/updates, including those previously developed by the code developers) and strongly attribute new source codes or source code updates to specific developers based on the results of the NLP analysis. For instance, coding styles such as but not limited to code formats, data object naming, programmatic/code structures, folder hierarchies/file naming, naming conventions, non-functional codes (e.g., embedded comments, etc.), spaces and other common meta-data, etc., may be analyzed using NLP algorithms and used to attribute source codes, or updates thereof, to specific code developers. In some instances, security risks to the network of managed compute facilities may be identified based on the attribution of the source code or update to specific developers and managed accordingly.).
Lee teaches:
Claim 7. The server according to claim 1, wherein the processor is further configured to search the LCA data in the LCA data source which is evaluated credible (¶0014 Some embodiments of the present disclosure disclose the implementation of zero-trust principles and techniques to source codes during the software development lifecycle. That is, no source code, or updates thereof, intended for execution in a network of managed compute facilities may be trusted and the security risk to the network that may be associated with the source code may be managed with the use of artificial intelligence to identify anomalous coding behavior (of the source code developer, for instance) and code execution behaviors. In some embodiments, source codes may be analyzed using machine learning algorithms to determine or identify the author or developer of the source code, i.e., attribute the source code to one or more code developers. For example, natural language processing (NLP) algorithms can be used to identify the coding style of code developers (e.g., by training the algorithms with a training dataset of source codes/updates, including those previously developed by the code developers) and strongly attribute new source codes or source code updates to specific developers based on the results of the NLP analysis.).
Lee teaches:
Claim 8. The server according to claim 7, wherein the processor is further configured to:for another LCA data that is not found in the LCA data source, analyse likelihood that the another LCA data is true based on the impact level; andgenerate an action item for a verifier based on the likelihood that the another LCA data is true (¶0014 Some embodiments of the present disclosure disclose the implementation of zero-trust principles and techniques to source codes during the software development lifecycle. That is, no source code, or updates thereof, intended for execution in a network of managed compute facilities may be trusted and the security risk to the network that may be associated with the source code may be managed with the use of artificial intelligence to identify anomalous coding behavior (of the source code developer, for instance) and code execution behaviors. In some embodiments, source codes may be analyzed using machine learning algorithms to determine or identify the author or developer of the source code, i.e., attribute the source code to one or more code developers. For example, natural language processing (NLP) algorithms can be used to identify the coding style of code developers (e.g., by training the algorithms with a training dataset of source codes/updates, including those previously developed by the code developers) and strongly attribute new source codes or source code updates to specific developers based on the results of the NLP analysis. . ¶0044 The values generated by the nodes 216 and 218 may be used by the node 222 in the output layer 206 to produce an output value for the artificial neural network 200. When the artificial neural network 200 is used to implement the machine learning algorithms of CDS module 160, the output value produced by the artificial neural network 200 may indicate a likelihood of an event (e.g., a confidence level measuring a level of contribution of a code developer to a development of the source code, an anomaly indicator identifying a code development behavioral anomaly associated with the code developer and occurring during the development of the source code, etc.)).
Lee teaches:
Claim 9. The server according to claim 7, wherein the processor is further configured to, for the LCA data that is found in the LCA data source, extract data relating to the quality of the LCA data, evaluate data completeness of the LCA data, evaluate the quality of the LCA data against pre-defined LCA data quality criteria, process the LCA data, and evaluate the plausibility of the impact level (¶0014 Some embodiments of the present disclosure disclose the implementation of zero-trust principles and techniques to source codes during the software development lifecycle. That is, no source code, or updates thereof, intended for execution in a network of managed compute facilities may be trusted and the security risk to the network that may be associated with the source code may be managed with the use of artificial intelligence to identify anomalous coding behavior (of the source code developer, for instance) and code execution behaviors. In some embodiments, source codes may be analyzed using machine learning algorithms to determine or identify the author or developer of the source code, i.e., attribute the source code to one or more code developers. For example, natural language processing (NLP) algorithms can be used to identify the coding style of code developers (e.g., by training the algorithms with a training dataset of source codes/updates, including those previously developed by the code developers) and strongly attribute new source codes or source code updates to specific developers based on the results of the NLP analysis.).
Lee teaches:
Claim 10. The server according to claim 2, wherein the processor is further configured to:check if all the LCA data has been verified;for the project that all the LCA data has been verified, send a verification result to the project database; andfor the project that at least a part of the LCA data has not been verified, send the verification result to the project database, and return the project to an applicant for an action (¶0029 In some embodiments, the code and developer security (CDS) module 160 may include machine learning capabilities or functionalities configured to analyze the source code and the code development data to attribute the source code to the code developer 130 (e.g., confirm whether the code developer 130 is in fact the developer of the source code and identify code development behavioral anomalies, respectively). For example, in some embodiments, the CDS module 160 may retrieve from the database 150 the source code and the code development data having information related to the coding activities of the code developer 130. In some instances, the CDS module 160 may include a natural language processing (NLP) machine learning algorithm that is trained on a training set of source codes (e.g., at least some of which are previously developed by the code developer 130).).
As per claims 11-20, the method tracks the system of claims 1-10, respectively, resulting in substantially similar limitations. The same cited prior art and rationale of claims 1-10 are applied to claims 11-20, respectively.
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 KURTIS GILLS whose telephone number is (571)270-3315. The examiner can normally be reached M-F 8-5 PM.
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, Jerry O’Connor can be reached on 571-272-6787. 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.
/KURTIS GILLS/Primary Examiner, Art Unit 3624
