DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Amendments
This Office Action is in response to the amendment filed on 06/30/2026.
Claims 1-3, 6, 9, 14, 16, 18, and 22 have been amended.
Claims 4, 7, and 15 have been cancelled.
No new claims have been added.
The objections and rejections from the prior correspondence that are not restated herein are withdrawn.
Response to Arguments
Applicant's arguments filed on 06/30/2026 have been fully considered.
Applicant's arguments regarding the 35 U.S.C. 103 rejections of the previous office action have been fully considered but are not persuasive. Applicant argues:
“Applicant respectfully submits that the proposed combination of Fink and Tomassini fails to disclose or suggest each and every feature or the combination of features of amended claims 1 and 6 […].
Applicant submits that the proposed combination of Fink and Tomassini specifically fails to disclose or suggest such two processors that process datasets associated with problems in a mutually exclusive manner such that there is no exposure of semantics of data fields of the datasets between the first processor and the second processor, as recited in amended claim 1.”
Examiner respectfully disagrees. Amended claim 1 does not recite two processors that process datasets associated with problems in a mutually exclusive manner such that there is no exposure of semantics of data fields of the datasets between the first processor and the second processor. What amended claim 1 recites is “wherein the first processor processes sensitive datasets associated with a problem in a manner which is mutually exclusive to the second processor” and makes no mention of how semantics of data fields of the data sets are handled. Further, FINK [0016] teaches that the candidate evaluation service does not transmit data sets to the evolution service, and FINK [0007] teaches that the providers of evolution service provide services without giving access to customers to their evolution algorithms, code, and data, hereby making the entire process mutually exclusive.
Applicant further argues:
“Applicant submits that, in Fink, the evolution service 15 still processes candidate genetic material, checkpoint states, internal representations of the population, and translated candidate representations. Fink's evolution service 15 has access to the candidate representation types such as genomes, genes, and formatting and uses translators to convert candidates between formats (see, for example, para [0033] and [0037] of Fink). Fink at paragraph [0032] discloses that the customer communicates "configuration information regarding constraints of the search space for genetic material, variations and/or known parameters on algorithm, and selection of the representation" to the Evolution Service 15. This communication of search space constraints, known parameters on algorithm, and representation selection exposes semantics of the data domain from the customer to the Evolution Service 15, which is contrary to the amended claim requirement that "there is no exposure of semantics of data fields of the datasets between the first processor and the second processor." In Fink, the evolution service 15 does not operate in a mutually exclusive manner with respect to the candidate evaluation system 20, because it receives and processes domain-related configuration information. Whereas, as claimed in amended claim 1, the first processor and the second processor process sensitive datasets associated with problems in a mutually exclusive manner and there is no data exposure at both the ends i.e., there is no exposure of semantics of data fields of the datasets. As such, Fink, in fact, teaches away from the teachings of amended claim 1.”
Examiner respectfully disagrees. FINK [0007] and [0016] explicitly teach keeping processes segmented by the candidate evaluation service not transmitting the datasets and the evaluation service not providing access to their algorithms, code, and data. As noted above, FINK [0032] discloses that the evolution process is initiated by the Candidate Evaluation System 20 communicating configuration information regarding constraints of the search space for genetic material, variations and/or known parameters on algorithm, and selection of the representation by which the Candidate Evaluation System wishes to receive candidates. None of these are the customer datasets which might include competitive business-related data and/or health-related data and the like, which need protection from access by the third-party vendor, such as third-party evolution-as-a-service providers (see FINK [0005]). Further, what is communicated by the Candidate Evaluation system 20 to initiate the evolution process is information regarding Candidate Evaluation system 20 wishes to receive. The constraints of the search space for genetic material defines a candidate search space and sends no information about the customer dataset. The variations and/or known parameters on algorithm refer to the algorithm configuration information, which is accepted by Evolution Service 15, and does not carry any data from the customer dataset. The selection of the representation by which the candidate wishes to receive the candidates is specified in the initial request by the Candidate Evaluation system, such as the candidate individual being received in JSON format, as illustrated in FIG. 3, and described in FINK [0040]. Therefore, specifying that the Candidate Evaluation System wishes the received format to be JSON says nothing about their datasets. FINK’s disclosure is precisely for preventing access to customer data by any third-party service provider providing evolution-as-a-service, and thus FINK’s initial communication carries no information that would “expose” customer datasets to any third-party service provider.
Applicant further argues:
“Fink does not disclose or suggest candidate solutions that comprise functions of one or more parameters that are evaluated for private values of those parameters.
Fink's candidate solutions are not characterized as functions of parameters, and Fink does not describe evaluating such functions for private values of parameters derived from privately hosted datasets. The candidate representation in Fink is fundamentally different from the functional parameterized representation recited in amended claim 1, wherein the functions take private values as inputs and produce metric outputs.”
Examiner respectfully disagrees. FINK [0007] teaches that its disclosed technology is applicable to a wide variety of genetic material including candidate neural networks. Neural networks process inputs and produce outputs and therefore behave as functions. Further, FINK discloses that the customer datasets might include competitive business-related data and/or health related data and the like. As stated in the 103 rejections below, one or more parameters can be interpreted as the variables in the competitive business-related data and/or health-related data sets. By mode of example, one having ordinary skill in the art would recognize that a health-related variable, such as “blood pressure” would vary across different patients associated with the variable. In the case where the customer has health-related datasets, the one or more parameters are the variables, such as “blood pressure”, and the actual value of the variable is the private value of those parameters. As such, a customer having health-related datasets would be provided evolution-as-a-service for those variables.
Applicant further argues:
“As such, "f' cannot be equated to Fink's candidate ID, as candidate ID is only a unique identifier which is assigned to each candidate individual and is not applied to the secure data set to produce evaluation results. Further, in Fink the evaluation results are associated with candidate IDs, and not produced by candidate IDs (see, for example, para [0033] of Fink). Therefore, the candidate ID in Fink is not a function and it does not take any inputs to compute outputs for processing data. The candidate ID in Fink is simply a label or a tracking tag assigned to distinguish one candidate from another. Therefore, equating candidate ID to the function (f), recited in amended claim 1, is fundamentally misplaced.”
Examiner respectfully disagrees. As explained in the response to arguments of the previous office action, the examiner did not equate function (f) to the numerical ID value of a candidate solution. FINK [0033] discloses that each candidate solution has a candidate ID which is associated with its respective metrics, and thus each candidate ID identifies a solution. FINK discloses that the customers only report back candidate ID’s and their respective metrics to the service provider, never exposing a manner for recovering private datasets.
Applicant further argues:
“Applicant further submits that Fink's evolution service is designed to understand and process candidate representations, including genome, gene, and formatting information, and to use translators to convert candidates between formats (see, for example, paras [0033] and [0037] of Fink). Thus, Fink requires the evolution service to understand the structure and semantics of the candidate representations as it evolves, and the evolution service in Fink must be configured for a particular representation used for each domain. In contrast, amended claim 1 requires the second processor to select one or more candidate solutions based solely on the metric dataset, where the metric dataset comprises only output values of functions evaluated for private values and excludes the private values. Accordingly, in amended claim 1, the second processor operates on abstract metric outputs without exposure to the semantics of the underlying data fields or domain type.
Fink's domain-specific candidate-representation processing therefore does not teach or suggest the claimed metric abstraction for problems of different domain types.
Fink therefore does not disclose or suggest that selection of best candidate solution is performed based solely on a metric dataset from which private parameter values are excluded.”
Examiner respectfully disagrees. What is claimed in amended claim 1 is
transmit the evaluated next population to the second processor for selecting a best candidate solution until a termination condition is reached,
wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset, and
wherein the pre-determined criteria represent a logical function that applies to the metrics for indicating that the termination condition has reached for the solution selection.
As noted above, claim 1 does not require that the selection of the one or more candidate solutions to be based solely on the metric dataset, as there is no description of how the selection process is performed. Additionally, and as stated before, FINK [0016] explicitly discloses that the customer datasets are not transmitted to the evolution services, specifically to protect the dataset from access by third-party service providers, and thus the private parameter values are excluded from what is received by Evolution Service 15.
Applicant further argues:
“Fink does not disclose or suggest the claimed metric dataset that comprises only output values of functions of parameters of the evaluated seed population, wherein private values of the parameters are excluded, such that the privately hosted datasets are non-recoverable from the metric dataset. As such, the teachings of Fink are far removed from the teachings of the claimed invention, and, in fact, Fink teaches away from the claimed invention.”
Examiner respectfully disagrees. FINK does not teach away from the claimed invention. FINK’s Candidate Evaluation System records evaluation results each associated with their candidate ID, and reports back the evaluation results and the associated candidate ID’s to the Evolution Service 15. Therefore, the Evolution Service 15 would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) alone or the ID corresponding to the respective candidate solution (e.g.,
f
).
Applicant further argues:
“Further, it is submitted that Tomassini at page 3 provides examples of termination conditions as: "a pre-determined number of generations or time has elapsed or a satisfactory solution has been found or no improvement in solution quality has been taking place for a predetermined number of generations." Tomassini's termination condition is thus a conventional stopping criterion for a standard evolutionary loop. Even if Tomassini is considered to teach that a termination condition may be based on solution quality or fitness, Tomassini does not teach or suggest applying such a termination condition to the claimed metric dataset, which is a privacy-preserving data structure generated by the first processor and transmitted to the second processor after exclusion of private parameter values.”
Examiner respectfully disagrees. TOMASSINI is only relied upon for the pre-determined criteria that indicate the termination condition has been reached. FINK [0033] and [0042] disclose repeating the evolution process until an experiment-specific termination criteria is reached, but leave the particular criteria open.
Applicant further argues that neither TOMASSINI nor ZHAO cure the deficiencies of FINK. It should be noted that FINK is used to teach the newly added limitations, as already explained above, and further in more detail in the 103 rejections below. Further, FINK [0030] teaches that the candidate evaluation is performed by a mechanism of the customer’s own choosing. TOMASSINI relates to evolutionary algorithms, and one of ordinary skill in the art would have incorporated TOMASSINI’s specific termination condition when little is known about the underlying space.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 6 and 8-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claim 6:
The claim recites “wherein the second processor processes sensitive datasets”. However, the second processor never processes the privately hosted datasets directly and only receives a metric dataset associated with an evaluated seed population from the first processor. For purposes of examination, the limitation will be construed as “wherein the second processor processes a metric dataset associated with an evaluated seed population in a manner which is mutually exclusive to the first processor;”.
Regarding Claims 8-13:
The dependent claims inherit the deficiencies of their respective parent claims and are likewise rejected.
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, 6, 9-14, 16, 18-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over FINK (US 20190372935 A1) in view of TOMASSINI ("Parallel and Distributed Evolutionary Algorithms: A Review”), hereafter FINK and TOMASSINI, respectively.
Regarding Claim 1:
FINK teaches:
A system for optimized generation, evaluation and selection of solutions associated with problems of different domain types using distributed evolutionary computing, the system comprising: (FINK [0006] teaches: "The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner.")
a first processor, wherein the first processor is configured to: send a population generation request corresponding to a problem associated with a domain type to a second processor, wherein the first processor processes sensitive datasets associated with a problem in a manner which is mutually exclusive to the second processor; (FINK [0004] teaches: “With on-going developments in AI-related fields of machine learning, deep learning and evolutionary computing, AI techniques can be applied in every industry to address health, legal and business-related goals and problems. Essentially, at every current intersection between technology and a goal or problem, there is a potential AI solution. As professionals and companies operating in different industries recognize the benefits of utilizing AI-based solutions, various third-party AI vendors will emerge to provide the support for these solutions.” FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets. […] Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like (i.e., sensitive datasets), which needs to be protected from access by the third-party vendor.” FINK [0009] teaches: "transmitting a first secure request (i.e., send a population generation request) from a first server (i.e., a first processor, wherein the first processor is configured to) for evolution of a first population of candidate individuals in accordance with a set of domain factors (i.e., corresponding to a problem associated with a domain type) to a second server (i.e., to a second processor);” FINK [0032] teaches: "First, the customer uses the Candidate Evaluation System 20 to initiate contact with Evolution Service 15 (i.e., to a second processor) by communicating configuration information regarding constraints of the search space for genetic material, variations and/or known parameters on algorithm, and selection of the representation by which the Candidate Evaluation System wishes to receive candidates, etc." FINK [0028-0029] teaches: “The Candidate Evaluation System 20 is responsible for: […] a) Initiating requests from the Evolution Service 15 (with or without results from prior candidates, configuration updates, insecure checkpoint keys, etc.)” FINK [0006] teaches: “The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service (i.e., second processor) allows customers (i.e., first processor) who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner.” FINK [0016] teaches: “The embodiments disclosed allow for segmented security between domain-specific data sets being evaluated as part of a candidate evaluation service, wherein the data sets are not transmitted to the evolution service (i.e., wherein the first processor processes sensitive datasets associated with a problem in a manner which is mutually exclusive to the second processor) which is evolving candidates for evaluation. This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models to evaluate and then optimizing on those data sets in their own secure fashion.” FINK [0007] teaches: “The technology disclosed also allows providers of evolution services to provide services without giving access to customers to their evolution algorithms, code, and data. Thus protecting their valuable intellectual property.” Examiner’s note: Customers do not transmit their respective data sets to the evolution service and providers of the evolution service do not give access to customers to their evolution algorithms, code, and data, thereby performing the process in a manner which is mutually exclusive.)
evaluate a generated seed population corresponding to the population generation request using privately hosted sensitive datasets, wherein the seed population represents candidate solutions corresponding to the problem associated with the different domain types, (FINK [0004] teaches: “With on-going developments in AI-related fields of machine learning, deep learning and evolutionary computing, AI techniques can be applied in every industry to address health, legal and business-related goals and problems. Essentially, at every current intersection between technology and a goal or problem, there is a potential AI solution. As professionals and companies operating in different industries recognize the benefits of utilizing AI-based solutions, various third-party AI vendors will emerge to provide the support for these solutions.” FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets.” FINK [0028-0030] teaches: “The Candidate Evaluation System 20 (i.e., the first processor) is responsible for: […] b) Evaluating candidates (i.e., evaluate a generated seed population, […] wherein the seed population represents candidate solutions) against the secure data set (i.e., using privately hosted sensitive datasets) (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0008] teaches: "receiving at a first server of a receiving party a first secure request for evolution of a first population (i.e., a generated seed population) of candidate individuals (i.e., candidate solutions) in accordance with a set of domain factors (i.e., corresponding to the problem associated with the different domain types) established by a requesting party; creating by the receiving party a first population of candidate individuals and assigning a unique candidate identifier to each of the candidate individuals in the first population;" FINK [0009] teaches: "and evaluating one or more of the candidates individuals (i.e., evaluate a generated seed population corresponding to the population generation request) against the secure data set to determine measurements indicative of a fitness of each of the candidate individuals for a predetermined use.")
wherein the candidate solutions comprise functions of one or more parameters such that evaluating the generated seed population comprises evaluating the functions for private values of the one or more parameters, the private values being derived from the privately hosted sensitive dataset; (FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets. There is a need in the art for securing and protecting the third-party vendor technology, i.e., evolutionary computing processes and implementation algorithms, from access by customers. Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like (i.e., privately hosted sensitive datasets), which needs to be protected from access by the third-party vendor.” FINK [0007] teaches: “The technology disclosed is applicable to a wide variety of representations of genetic material ranging from individuals (genomes) representing e-commerce website parameters to candidate neural networks.” FINK [0043] teaches: “In one such implementation, the technology disclosed is used to generate candidate Neural Networks (i.e., wherein the candidate solutions comprise functions of one or more parameters) via evolution.” FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates against the secure data set (i.e., such that evaluating the generated seed population comprises evaluating the functions for private values of the one or more parameters) (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0033] teaches: “For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance against the secure data set (i.e., the private values being derived from the privately hosted sensitive dataset).” Examiner’s note: Under BRI, one or more parameters can be interpreted as the variables in the competitive business-related data and/or health-related data sets, and the private values of the one or more parameters can be interpreted as the actual values of the variables.)
associate the evaluated seed population with one or more metrics to generate a metric dataset for transmission to the second processor, wherein the metric dataset comprises output of the functions evaluated for the private values of the one or more parameters, and (FINK [0030] teaches: “b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements (i.e., output of the functions evaluated for the private values of the one or more parameters) about the candidates can be taken to inform the creation of the next population.” FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance (i.e., metric) against the secure data set. […] When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results (i.e., with one or more metrics) each associated (i.e., associate [...] to generate a metric dataset) with their candidate ID's (i.e., evaluated seed population) are potentially reported back to the Evolution Service 15 (i.e., for transmission to the second processor) with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." Examiner’s note: Under BRI, the metric dataset can be interpreted as evaluation results associated with the candidate ID’s that correspond to each evaluated candidate (i.e., the evaluated seed population).)
wherein the private values of the one or more parameters are excluded from the metric dataset such that the metric dataset irreversibly masks the evaluated seed population, and the privately hosted sensitive datasets are non-recoverable from the metric dataset; (FINK [0016] teaches: “The embodiments disclosed allow for segmented security between domain-specific data sets being evaluated as part of a candidate evaluation service, wherein the data sets are not transmitted to the evolution service (i.e., wherein the private values of the one or more parameters are excluded from the metric dataset) which is evolving candidates for evaluation. This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models to evaluate and then optimizing on those data sets in their own secure fashion.” FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., metrics dataset) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." Examiner’s note: Per paragraphs [0025]-[0026] of the present application, irreversible masks are defined as
m
=
f
(
X
)
where
m
is the metric,
f
is an evaluation function, and
X
is the private data. The metrics implementation unit 114 only provides the function values, and not the inputs to the functions. FINK teaches a similar process of only transmitting the evaluation results to the second server. Specifically, FINK discloses the Candidate Evaluation System 20 only reporting back the evaluation results (e.g., recorded measurements of performance against the secure data set) associated with their respective candidate ID. Therefore, the Evolution Service 15 would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) alone or the ID corresponding to the respective candidate solution (e.g.,
f
) (i.e., such that the metric dataset irreversibly masks the evaluated seed population, and the privately hosted sensitive datasets are non-recoverable from the metric dataset).)
evaluate a generated next population received from the second processor using the privately hosted sensitive datasets; (FINK [0033] teaches: "The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." FINK [0024] teaches: "c) Creating new populations of candidates from previous populations of priors, based on fitness data for each prior candidate." FINK [0028-0030] teaches: “The Candidate Evaluation System 20 (i.e., first processor) is responsible for: […] b) Evaluating candidates (i.e., generated next population received from the second processor) against the secure data set (i.e., using the privately hosted sensitive datasets) (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0031] teaches: “In the example below the Candidate Evaluation System 20 and the Evolution Service 15 are intended to be running on two distinct hosts, each within their own secure environments.”)
transmit the evaluated next population to the second processor for selecting a best candidate solution until a termination condition is reached, wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset, [...] (FINK [0009] teaches: “In a second exemplary embodiment, a process for evolving candidate individuals for optimization (i.e., for selecting a best candidate solution) against a secure data set includes: transmitting a first secure request from a first server for evolution of a first population of candidate individuals in accordance with a set of domain factors to a second server (i.e., to the second processor);” FINK [0028-0030] teaches: “The Candidate Evaluation System 20 (i.e., first processor) is responsible for: […] b) Evaluating candidates against the secu re data set (by a mechanism of its own choosing) such that enough measurements (i.e., metrics) about the candidates can be taken to inform the creation of the next population.” FINK [0024] teaches: "c) Creating new populations of candidates from previous populations of priors, based on fitness data for each prior candidate." FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., metrics dataset) are potentially reported back (i.e., transmit the evaluated next population) to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 (i.e., the second processor) repeats the process starting with creating a new candidate population (i.e., the next population) as describe above, unless some experiment-specific termination criteria is reached (i.e., until a termination condition is reached)." FINK [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4). The above process is repeated via a message M5 until an experiment specific criteria is reached (i.e., wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset, [...]) (message M6).")
FINK is not relied upon for teaching, but TOMASSINI teaches: […] wherein the pre-determined criteria represent a logical function that applies to the metrics for indicating that the termination condition has reached for the solution selection. (TOMASSINI [pg. 3, section 1.2.1 An introduction to genetic algorithms] teaches: "Possible termination conditions (i.e., pre-determined criteria […] for indicating that the termination condition has reached for the solution selection) are: a pre-determined number of generations or time has elapsed or a satisfactory solution has been found or no improvement (i.e., logical function) in solution quality (i.e., that applies to the metrics) has been taking place for a pre-determined number of generations.")
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of FINK and TOMASSINI before them, to include TOMASSINI’s pre-determined criteria for indicating that the termination condition has reached a solution in FINK’s method for providing secure evolution as a service. One would have been motivated to make such a combination in order to find optimal solutions for hard problems where little is known about the underlying search space (TOMASSINI [pg. 1, section 1.1. Introduction]).
Regarding Claim 2:
FINK in view of TOMASSINI teaches the elements of claim 1 as outlined above. FINK further teaches:
wherein the first processor evaluates the seed population in a distributed and a private manner using the privately hosted sensitive datasets. (FINK [0005] teaches: “Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like (i.e., privately hosted sensitive datasets), which needs to be protected from access by the third-party vendor.” FINK [0006] teaches: "The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system (i.e., first processor) from an evolution service. A firewall between the data sets and the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals (i.e., evaluates the seed population) in a secure manner (i.e., private manner)." FINK [0031] teaches: “[…] the Candidate Evaluation System 20 and the Evolution Service 15 are intended to be running on two distinct hosts, each within their own secure environments. FINK [0034] teaches: “Some of the modules can also be implemented on different processors or computers, or spread among a number of different processors or computers (i.e., distributed […] manner).”)
Regarding Claim 3:
FINK in view of TOMASSINI teaches the elements of claim 1 as outlined above. FINK further teaches:
wherein the first processor evaluates the seed population by processing the seed population in independently distributed nodes based on the privately hosted sensitive dataset. (FINK [0005] teaches: “Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like (i.e., privately hosted sensitive datasets), which needs to be protected from access by the third-party vendor.” FINK [0006] teaches: "The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system (i.e., first processor) from an evolution service. A firewall between the data sets and the evolution service allows customers (i.e., the first processor) who own their data sets (i.e., based on privately hosted sensitive dataset) to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals (i.e., evaluates the seed population by processing the seed population) in a secure manner." FINK [0031] teaches: “[…] the Candidate Evaluation System 20 and the Evolution Service 15 are intended to be running on two distinct hosts, each within their own secure environments. FINK [0034] teaches: “Some of the modules can also be implemented on different processors or computers, or spread among a number of different processors or computers. […] Note that candidate testing module 238 is part of Candidate Evaluation System 20 (i.e., first processor) running on a separate host (i.e., in independently distributed nodes) from the Evolution Service 15 as described above.")
Regarding Claim 6:
FINK teaches:
A system for optimized generation, evaluation and selection of solution associated with problems of different domain types using distributed evolutionary computing, the system comprising: (FINK [0004] teaches: “With on-going developments in AI-related fields of machine learning, deep learning and evolutionary computing, AI techniques can be applied in every industry to address health, legal and business-related goals and problems. Essentially, at every current intersection between technology and a goal or problem, there is a potential AI solution. As professionals and companies operating in different industries recognize the benefits of utilizing AI-based solutions, various third-party AI vendors will emerge to provide the support for these solutions.” FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets.” FINK [0006] teaches: "The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner.")
a second processor, wherein the second processor is configured to: receive a population generation request corresponding to a problem associated with a domain type from a first processor, wherein the second processor processes sensitive datasets associated with the problem in a manner which is mutually exclusive to the first processor; (FINK [0004] teaches: “With on-going developments in AI-related fields of machine learning, deep learning and evolutionary computing, AI techniques can be applied in every industry to address health, legal and business-related goals and problems. Essentially, at every current intersection between technology and a goal or problem, there is a potential AI solution. As professionals and companies operating in different industries recognize the benefits of utilizing AI-based solutions, various third-party AI vendors will emerge to provide the support for these solutions.” FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets. […] Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like (i.e., sensitive datasets), which needs to be protected from access by the third-party vendor.” FINK [0009] teaches: "transmitting a first secure request (i.e., receive a population generation request) from a first server (i.e., from a first processor) for evolution of a first population of candidate individuals in accordance with a set of domain factors (i.e., corresponding to a problem associated with a domain type) to a second server (i.e., a second processor, wherein the second processor is configured to: receive);” FINK [0032] teaches: "First, the customer uses the Candidate Evaluation System 20 to initiate contact with Evolution Service 15 by communicating configuration information regarding constraints of the search space for genetic material, variations and/or known parameters on algorithm, and selection of the representation by which the Candidate Evaluation System wishes to receive candidates, etc." FINK [0028-0029] teaches: “The Candidate Evaluation System 20 is responsible for: […] a) Initiating requests from the Evolution Service 15 (with or without results from prior candidates, configuration updates, insecure checkpoint keys, etc.)” FINK [0006] teaches: “The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service (i.e., second processor) allows customers (i.e., first processor) who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner.” FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance against the secure data set. […] When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., a metric dataset) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. FINK [0007] teaches: “The technology disclosed also allows providers of evolution services to provide services without giving access to customers to their evolution algorithms, code, and data (i.e., in a manner which is mutually exclusive to the first processor). Thus protecting their valuable intellectual property.” Examiner’s note: As noted in the 112(b) rejection above, the limitation is being interpreted as the second processor processing a metric dataset, not the sensitive dataset. Further, customers do not transmit their respective data sets to the evolution service and providers of the evolution service do not give access to customers to their evolution algorithms, code, and data, thereby performing the process in a manner which is mutually exclusive.)
generate a seed population corresponding to the population generation request, wherein the seed population represents candidate solutions corresponding to the problem associated with the domain type, and wherein the candidate solutions comprise functions of one or more parameters; (FINK [0008] teaches: "receiving at a first server of a receiving party a first secure request for evolution of a first population (i.e., a seed population corresponding to the population generation request) of candidate individuals (i.e., wherein the seed population represents candidate solutions) in accordance with a set of domain factors (i.e., corresponding to a problem associated with a domain type) established by a requesting party; creating by the receiving party a first population of candidate individuals and assigning a unique candidate identifier to each of the candidate individuals in the first population;" FINK [0021-0023] teaches: “The Evolution Service 15 is responsible for: a) Accepting configuration information regarding the constraints of Evolution from the Candidate Evaluation System 20. b) Creating new populations of candidates (i.e., generate a seed population) of possible optimizations from no prior candidates.” FINK [0043] teaches: “In one such implementation, the technology disclosed is used to generate candidate Neural Networks (i.e., wherein the candidate solutions comprise functions of one or more parameters) via evolution.” Examiner’s note: Under BRI, one or more parameters can be interpreted as the variables in the competitive business-related data and/or health-related data sets, and the functions of one or more parameters can be interpreted as candidate neural networks which take as input the variables in the competitive business-related data and/or health-related data sets.)
receive a metric dataset associated with an evaluated seed population from the first processor, wherein the metrics dataset comprises output of the functions evaluated for private values of the one or more parameters by the first processor, and (FINK [0030] teaches: “b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements (i.e., output of the functions evaluated for the private values of the one or more parameters) about the candidates can be taken to inform the creation of the next population.” FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance (i.e., metric) against the secure data set. […] When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's are potentially reported back to the Evolution Service 15 (i.e., receive a metric dataset associated with an evaluated seed population from the first processor) with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." Examiner’s note: Under BRI, the metric dataset can be interpreted as evaluation results associated with the candidate ID’s that correspond to each evaluated candidate (i.e., the evaluated seed population). Further, under BRI, the private values of the one or more parameters can be interpreted as the actual values of the variables in the competitive business-related data and/or health-related data sets.)
wherein the private values of the one or more parameters are excluded from the metric dataset such that the metric dataset irreversibly masks the evaluated seed population and the private values derived from privately hosted sensitive datasets are non-recoverable from the metric dataset; and (FINK [0016] teaches: “The embodiments disclosed allow for segmented security between domain-specific data sets being evaluated as part of a candidate evaluation service, wherein the data sets are not transmitted to the evolution service (i.e., wherein the private values of the one or more parameters are excluded from the metric dataset) which is evolving candidates for evaluation. This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models to evaluate and then optimizing on those data sets in their own secure fashion.” FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., metrics dataset) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." Examiner’s note: Per paragraphs [0025]-[0026] of the present application, irreversible masks are defined as
m
=
f
(
X
)
where
m
is the metric,
f
is an evaluation function, and
X
is the private data. The metrics implementation unit 114 only provides the function values, and not the inputs to the functions. FINK teaches a similar process of only transmitting the evaluation results to the second server. Specifically, FINK discloses the Candidate Evaluation System 20 only reporting back the evaluation results (e.g., recorded measurements of performance against the secure data set) associated with their respective candidate ID. Therefore, the Evolution Service 15 would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) alone or the ID corresponding to the respective candidate solution (e.g.,
f
) (i.e., such that the metric dataset irreversibly masks the evaluated seed population, and the private values derived from privately hosted sensitive datasets are non-recoverable from the metric dataset).)
select a best candidate solution by recursively processing the metrics dataset until a termination condition is reached, wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset, [...] wherein in the event the termination condition is not reached then a next population is generated by the second processor based on the best candidate solution. (FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0024] teaches: "c) Creating new populations of candidates from previous populations of priors, based on fitness data for each prior candidate." FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., metrics dataset) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 (i.e., the second processor) repeats the process starting with creating a new candidate population (i.e., the next population) as describe above, unless some experiment-specific termination criteria is reached." FINK [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4). The above process is repeated via a message M5 until an experiment specific criteria is reached (i.e., wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset, [...]) (message M6)." FINK [0016] teaches: “This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models (i.e., best candidate solution) to evaluate and then optimizing on those data sets in their own secure fashion.” Furthermore, wherein in the event the termination condition is not reached then a next population is generated by the second processor based on the best candidate solution can be understood as FINK’s process of using measured evaluation results associated with their respective candidate ID’s (i.e., metric dataset) to inform the creation of new populations to obtain optimal candidate solutions until an experiment specific criteria is reached. Moreover, paragraph [0036] of the present application states: “In an embodiment of the present invention, the next population generation unit 118 is configured to receive the one or more best candidate solution from the best candidate selection unit 120.” Under broadest reasonable interpretation, select a best candidate solution can be interpreted as the candidate solutions that inform the creation of the next population based on fitness data of prior candidates in order to obtain optimal candidate solutions (FINK [0006], [0016] and [0024]). Additionally, by recursively processing the metrics dataset until a termination condition is reached can be interpreted as this process of using previous candidate solutions to create new populations continues until an experiment specific termination condition is reached.)
However, FINK is not relied upon for teaching, but TOMASSINI teaches: [...] and wherein the pre-determined criteria represent a logical function that applies to the metrics for indicating that the termination condition has reached for the solution selection, and […] (TOMASSINI [pg. 3, section 1.2.1 An introduction to genetic algorithms] teaches: "Possible termination conditions (i.e., pre-determined criteria […] for indicating that the termination condition has reached for the solution selection) are: a pre-determined number of generations or time has elapsed or a satisfactory solution has been found or no improvement (i.e., logical function) in solution quality (i.e., that applies to the metrics) has been taking place for a pre-determined number of generations.")
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of FINK and TOMASSINI before them, to include TOMASSINI’s pre-determined criteria for indicating that the termination condition has reached a solution in FINK’s method for providing secure evolution as a service. One would have been motivated to make such a combination in order to find optimal solutions for hard problems where little is known about the underlying search space (TOMASSINI [pg. 1, section 1.1. Introduction]).
Regarding Claim 9:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. TOMASSINI further teaches:
wherein the pre-determined criteria include a process-related criterion, a result-related criterion, a number of population generations related criterion, and a time-related criterion. (TOMASSINI [pg. 3, section 1.2.1 An introduction to genetic algorithms] teaches: "Possible termination conditions are: a pre-determined number of generations or time has elapsed or a satisfactory solution has been found or no improvement in solution quality has been taking place for a pre-determined number of generations.")
Regarding Claim 10:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. FINK further teaches:
wherein the second processor stores the metrics dataset associated with the best candidate solution in a storage location in the event the termination condition is met, and wherein the metrics dataset is retrievable as an output dataset. (FINK [0025] teaches: “d) Securely reading/writing (i.e., stores) checkpoints of hidden representation representing evolution state (i.e., metrics dataset associated with the best candidate solution), so that such state can be resumed at any point in the future, only by the Evolution Service 15 (i.e., the second processor). Such state can be associated with an insecure key which is shared (i.e., retrievable as an output dataset) with the Candidate Evaluation System 20.” Furthermore, the Evolution Service 15 creates candidate populations for finding candidates until an experiment specific criteria is reached. Per [0042] of the present application: “The pre-determined criteria include a process-related criterion (e.g., total running time of generations or number of generations), a result-related criterion (e.g., accuracy measure of the current solutions), a number of population generations related criterion and a time-related criterion. In an example, the time related pre-determined criteria include expensive processing time, a deadline or any other event for stopping the solution selection process at a certain time, and taking the best candidate solutions based on limited resources.” Moreover, FINK [0033] teaches that the Evolution Service 15 repeats the process of creating new populations for the Candidate Evaluation System 20 in order to find optimal solutions until an experiment specific criteria is reached (i.e., in the event a termination condition is reached). FINK also teaches securely reading/writing checkpoints of hidden representations of evolution states (i.e., metrics dataset associated with the best candidate solution) so that such state can be resumed at any point in the future. Under broadest reasonable interpretation, in the event of a termination event, such as a termination caused by a time-related criterion, would result in the Evolution Service 15 storing the representation of the evolution state so that it can be retrieved at any point in the future for resuming the process, for which the Candidate Evaluation System has a shared insecure key for retrieving such state as an output dataset.)
Regarding Claim 11:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. FINK further teaches:
wherein the system is a self-learning unit that employs machine learning techniques for processing the metrics dataset to select the best candidate solution and generating the next population. (FINK [0018] teaches: “EaaS includes two primary components or subsystems/processes: an Evolution Service (i.e., wherein the system is a self-learning unit) and a Candidate Evaluation System.” FINK [0045] teaches: “Aspects of the invention can also apply to other population-based algorithms and population-based machine learning algorithms (i.e., that employs machine learning techniques) beyond evolution as well.” FINK [0030] teaches: “b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population (i.e., for processing the metrics dataset to select the best candidate solution and generating the next population).” FINK [0006] teaches: “the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models (i.e., to select the best candidate solution) to evaluate individuals in a secure manner.”)
Regarding Claim 12:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. FINK further teaches:
[…] sensitive datasets. (FINK [0005] teaches: “Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like, which needs to be protected from access by the third-party vendor. As such a need exists in the art for maintaining data and process privacy and security in an AI process involving one or more independent parties, e.g., customer and vendor.” FINK [0006] teaches: “The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner.”)
TOMASSINI further teaches: wherein the next population is generated by applying a mutation process and a cross-over process on the best candidate solution based on existing […] datasets. (TOMASSINI [pg. 3-4, section 1.2.1 An Introduction to genetic algorithms] and [pg. 11, section 1.3.3 Global Parallel Evolutionary Algorithms] teaches a pseudo-code for the evolutionary cycle that while a termination condition is not met, continue generating populations (e.g., generation = generation + 1) (i.e., next population) by calculating fitness, evaluating and selecting fitter individuals by fitness for reproduction (i.e., on the best candidate solution), and performing crossover and mutation (i.e., by applying a mutation process and a cross-over process) based on the existing population (i.e., based on existing datasets).”)
Regarding Claim 13:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. FINK further teaches:
wherein the second processor transmits the next population to the first processor for evaluation of the next population based on the privately hosted sensitive datasets and subsequent selection of the best candidate solution by the second processor until the termination condition is reached. (FINK [0009] teaches: “In a second exemplary embodiment, a process for evolving candidate individuals for optimization against a secure data set includes: transmitting a first secure request from a first server for evolution of a first population of candidate individuals in accordance with a set of domain factors to a second server;” FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0024] teaches: "c) Creating new populations of candidates from previous populations of priors, based on fitness data for each prior candidate." FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." FINK [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4). The above process is repeated via a message M5 until an experiment specific criteria is reached.")
Regarding Claim 14:
FINK teaches:
A method for optimized generation, evaluation and selection of solutions associated with problems of different domain types using distributed evolutionary computing, the method comprising (FINK [0004] teaches: “With on-going developments in AI-related fields of machine learning, deep learning and evolutionary computing, AI techniques can be applied in every industry to address health, legal and business-related goals and problems. Essentially, at every current intersection between technology and a goal or problem, there is a potential AI solution. As professionals and companies operating in different industries recognize the benefits of utilizing AI-based solutions, various third-party AI vendors will emerge to provide the support for these solutions.” FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets.” FINK [0006] teaches: "The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner.")
sending a population generation request corresponding to a problem associated with a domain type, wherein sensitive datasets associated with the problem are processed in a mutually exclusive manner; (FINK [0005] teaches: “By way of particular example, consider the generalized case where a third-party vendor offers Evolution-as-a-Service (“EaaS”), whereby the third-party vendor uses evolutionary computing to generate candidate code or models which are then made accessible to customers for optimization in the customer specific domain using customer specific data sets. […] Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like (i.e., sensitive datasets), which needs to be protected from access by the third-party vendor.” FINK [0008] teaches: "receiving at a first server of a receiving party a first secure request for evolution (i.e., sending a population generation request) of a first population of candidate individuals in accordance with a set of domain factors (i.e., corresponding to a problem associated with a domain type) established by a requesting party;” FINK [0006] teaches: “The technology disclosed securely separates the domain specific data sets being evaluated in a candidate evaluation system from an evolution service. A firewall between the data sets and the evolution service allows customers who own their data sets to use evolution securely while obtaining a population of potentially optimal candidate models to evaluate individuals in a secure manner (i.e., sensitive datasets associated with the problem are processed in a mutually exclusive manner).”)
generating a seed population corresponding to the population generation request, wherein the seed population represents candidate solutions corresponding to the problem associated with the different domain types, (FINK [0008] teaches: "receiving at a first server of a receiving party a first secure request for evolution of a first population (i.e., a seed population corresponding to the population generation request) of candidate individuals (i.e., wherein the seed population represents candidate solutions) in accordance with a set of domain factors (i.e., corresponding to a problem associated with the different domain types) established by a requesting party; creating by the receiving party a first population of candidate individuals and assigning a unique candidate identifier to each of the candidate individuals in the first population;" FINK [0021-0023] teaches: “The Evolution Service 15 is responsible for: a) Accepting configuration information regarding the constraints of Evolution from the Candidate Evaluation System 20. b) Creating (i.e., generating) new populations of candidates of possible optimizations from no prior candidates.”)
wherein the candidate solutions comprise functions of one or more parameters; (FINK [0043] teaches: “In one such implementation, the technology disclosed is used to generate candidate Neural Networks (i.e., wherein the candidate solutions comprise functions of one or more parameters) via evolution.” Examiner’s note: Under BRI, one or more parameters can be interpreted as the variables in the competitive business-related data and/or health-related data sets, and the functions of one or more parameters can be interpreted as candidate neural networks which take as input the variables in the competitive business-related data and/or health-related data sets.)
evaluating the generated seed population corresponding to the population generation request using privately hosted sensitive datasets; (FINK [0005] teaches: “Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like, which needs to be protected from access by the third-party vendor. As such a need exists in the art for maintaining data and process privacy and security in an AI process involving one or more independent parties, e.g., customer and vendor.” FINK [0008] teaches: "receiving at a first server of a receiving party a first secure request for evolution of a first population of candidate individuals in accordance with a set of domain factors established by a requesting party;” FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates (i.e., evaluating the generated seed population corresponding to the request) against the secure data set (i.e., using privately hosted sensitive datasets) (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4).”)
wherein evaluating the generated seed population comprises evaluating the functions for private values of the one or more parameters, the private values being derived from the privately hosted sensitive dataset; (FINK [0007] teaches: “The technology disclosed is applicable to a wide variety of representations of genetic material ranging from individuals (genomes) representing e-commerce website parameters to candidate neural networks.” FINK [0043] teaches: “In one such implementation, the technology disclosed is used to generate candidate Neural Networks via evolution.” FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates against the secure data set (i.e., wherein evaluating the generated seed population comprises evaluating the functions for private values of the one or more parameters) (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0033] teaches: “For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance against the secure data set (i.e., the private values being derived from the privately hosted sensitive dataset).”)
associating the evaluated seed population with one or more metrics to generate a metric dataset, wherein the metric dataset comprises output of the functions evaluated for the private values of the one or more parameters, and (FINK [0030] teaches: “b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements (i.e., output of the functions evaluated for the private values of the one or more parameters) about the candidates can be taken to inform the creation of the next population.” FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance (i.e., metric) against the secure data set. […] When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results (i.e., with one or more metrics) each associated (i.e., associating [...] to generate a metric dataset) with their candidate ID's (i.e., evaluated seed population) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." Examiner’s note: Under BRI, the metric dataset can be interpreted as evaluation results associated with the candidate ID’s that correspond to each evaluated candidate (i.e., the evaluated seed population). Further, under BRI, the private values of the one or more parameters can be interpreted as the actual values of the variables in the competitive business-related data and/or health-related data sets.)
wherein the private values of the one or more parameters are excluded from the metric dataset such that the metric dataset irreversibly masks the evaluated seed population, and the privately hosted sensitive datasets are non-recoverable from the metric dataset; (FINK [0016] teaches: “The embodiments disclosed allow for segmented security between domain-specific data sets being evaluated as part of a candidate evaluation service, wherein the data sets are not transmitted to the evolution service (i.e., wherein the private values of the one or more parameters are excluded from the metric dataset) which is evolving candidates for evaluation. This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models to evaluate and then optimizing on those data sets in their own secure fashion.” FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., metrics dataset) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." Examiner’s note: Per paragraphs [0025]-[0026] of the present application, irreversible masks are defined as
m
=
f
(
X
)
where
m
is the metric,
f
is an evaluation function, and
X
is the private data. The metrics implementation unit 114 only provides the function values, and not the inputs to the functions. FINK teaches a similar process of only transmitting the evaluation results to the second server. Specifically, FINK discloses the Candidate Evaluation System 20 only reporting back the evaluation results (e.g., recorded measurements of performance against the secure data set) associated with their respective candidate ID. Therefore, the Evolution Service 15 would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) alone or the ID corresponding to the respective candidate solution (e.g.,
f
) (i.e., such that the metric dataset irreversibly masks the evaluated seed population, and the privately hosted sensitive datasets are non-recoverable from the metric dataset).)
selecting a best candidate solution associated with the metrics dataset by recursively processing the metrics dataset associated with the evaluated seed population until a termination condition is reached, wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset, [...] wherein in the event the termination condition is not reached a next population is generated based on the best candidate solution; (FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates against the secure data set (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0024] teaches: "c) Creating new populations of candidates from previous populations of priors, based on fitness data for each prior candidate." FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's (i.e., metrics dataset) are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 repeats the process starting with creating a new candidate population (i.e., the next population) as describe above, unless some experiment-specific termination criteria is reached." FINK [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4). The above process is repeated via a message M5 until an experiment specific criteria is reached (i.e., wherein the termination condition is based on a pre-determined criterion associated with the metrics dataset) (message M6)." FINK [0016] teaches: “This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models (i.e., best candidate solution) to evaluate and then optimizing on those data sets in their own secure fashion.” Furthermore, wherein in the event the termination condition is not reached then a next population is generated by the second processor based on the best candidate solution can be understood as FINK’s process of using measured evaluation results associated with their respective candidate ID’s (i.e., metric dataset) to inform the creation of new populations to obtain optimal candidate solutions until an experiment specific criteria is reached. Moreover, paragraph [0036] of the present application states: “In an embodiment of the present invention, the next population generation unit 118 is configured to receive the one or more best candidate solution from the best candidate selection unit 120.” Under broadest reasonable interpretation, selecting a best candidate solution can be interpreted as the candidate solutions that inform the creation of the next population based on fitness data of prior candidates in order to obtain optimal candidate solutions (FINK [0006], [0016] and [0024]). Additionally, by recursively processing the metrics dataset until a termination condition is reached can be interpreted as this process of using previous candidate solutions to create new populations continues until an experiment specific termination condition is reached.)
evaluating the generated next population using the privately hosted sensitive datasets; (FINK [0028-0030] teaches: “The Candidate Evaluation System 20 is responsible for: […] b) Evaluating candidates (i.e., evaluating the next population) against the secure data set (i.e., using privately hosted datasets) (by a mechanism of its own choosing) such that enough measurements about the candidates can be taken to inform the creation of the next population.” FINK [0033] teaches: "The Evolution Service 15 repeats the process starting with creating a new candidate population (i.e., generated next population) as describe above, unless some experiment-specific termination criteria is reached." FINK [0005] teaches: “Likewise, the customer data sets, which might include competitive business-related data and/or health-related data and the like, which needs to be protected from access by the third-party vendor. As such a need exists in the art for maintaining data and process privacy and security in an AI process involving one or more independent parties, e.g., customer and vendor.”)
selecting the best candidate solution based on the next population until the termination condition is reached. (FINK [0033] teaches: “The Evolution Service 15 repeats the process starting with creating a new candidate population as describe above, unless some experiment-specific termination criteria is reached." FINK [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4). The above process is repeated via a message M5 until an experiment specific criteria is reached.”)
However, FINK is not relied upon for teaching, but TOMASSINI teaches: […] and wherein the pre-determined criteria represent a logical function that applies to the metrics for indicating that the termination condition has reached for the solution selection, and […] (TOMASSINI [pg. 3, section 1.2.1 An introduction to genetic algorithms] teaches: "Possible termination conditions (i.e., pre-determined criteria […] for indicating that the termination condition has reached for the solution selection) are: a pre-determined number of generations or time has elapsed or a satisfactory solution has been found or no improvement (i.e., logical function) in solution quality (i.e., that applies to the metrics) has been taking place for a pre-determined number of generations.")
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of FINK and TOMASSINI before them, to include TOMASSINI’s pre-determined criteria for indicating that the termination condition has reached a solution in FINK’s method for providing secure evolution as a service. One would have been motivated to make such a combination in order to find optimal solutions for hard problems where little is known about the underlying search space (TOMASSINI [pg. 1, section 1.1. Introduction]).
Regarding Claim 16:
FINK in view of TOMASSINI teaches the elements of claim 14 as outlined above. Additionally, the claim recites similar limitations as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding Claim 18:
FINK in view of TOMASSINI teaches the elements of claim 14 as outlined above. Additionally, the claim recites similar limitations as corresponding claim 9 and is rejected for similar reasons as claim 9 using similar teachings and rationale.
Regarding Claim 19:
FINK in view of TOMASSINI teaches the elements of claim 14 as outlined above. Additionally, the claim recites similar limitations as corresponding claim 10 and is rejected for similar reasons as claim 10 using similar teachings and rationale.
Regarding Claim 21:
FINK in view of TOMASSINI teaches the elements of claim 14 as outlined above. Additionally, the claim recites similar limitations as corresponding claim 12 and is rejected for similar reasons as claim 12 using similar teachings and rationale.
Claims 8, 17, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over FINK in view of TOMASSINI, as applied to claims 6 and 14 above, and further in view of ZHAO ("Evolution as a Service: A Privacy-Preserving Genetic Algorithm for Combinatorial Optimization"), hereafter ZHAO.
Regarding Claim 8:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. FINK further teaches:
wherein the second processor selects the best candidate solution associated with the metrics dataset based on […] selection techniques […] (FINK [0024] teaches: "c) Creating new populations of candidates from previous populations of priors, based on fitness data for each prior candidate." FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results each associated with their candidate ID's are potentially reported back to the Evolution Service 15 with the previous checkpoint key. The Evolution Service 15 (i.e., the second processor) repeats the process starting with creating a new candidate population (i.e., the next population) as describe above, unless some experiment-specific termination criteria is reached." FINK [0016] teaches: “This enables customers with secure data sets to use candidate evolution services securely by obtaining a population of potentially optimal candidate models (i.e., best candidate solution) to evaluate and then optimizing on those data sets in their own secure fashion.”)
FINK is not relied upon for teaching, but ZHAO teaches: on one or more selection techniques comprising a tournament selection technique, a ranking selection technique and a multi-objective selection technique. (ZHAO [pg. 8, section B. Problem Solving via PEGA] teaches the tournament selection technique. ZHAO [pg. 9, section C. Effectiveness Evaluation] teaches: "One possible explanation is that k-tournament selection always selects a dominant individual into next generation".)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of FINK, TOMASSINI, and ZHAO before them, to include ZHAO’s k-tournament selection technique in FINK and TOMASSINI’s method for providing secure evolution as a service. One would have been motivated to make such a combination in order to enable users to outsource evolutionary computation tasks to find optimal solutions in a privacy-preserving manner (ZHAO [pg. 1, Abstract]).
Regarding Claim 17:
FINK in view of TOMASSINI teaches the elements of claim 14 as outlined above. Additionally, the claim recites similar limitations as corresponding claim 8 and is rejected for similar reasons as claim 8 using similar teachings and rationale.
Regarding Claim 22:
The claim recites similar limitations as corresponding claim 14 and is rejected for similar reasons as claim 14 using similar teachings and rationale. However, FINK in view of TOMASSINI is not relied upon for teaching, but ZHAO teaches:
a non-transitory computer-readable medium having computer program code stored thereon, the computer-readable program code comprising instructions that, when executed by a processor, causes the processor to: (ZHAO [pg.9 , section B. Experimental Evaluation] teaches: "The experiment is performed on a personal computer running windows 10-64bit with an Intel Core i7-4790 CPU 3.6 GHz processor and 16 GB memory, which acts as the user. Also, the server running windows 10 64 bit with an Intel Core i7-10700 CPU 2.9 GHz processor, and 32 GB memory, which simulates two cloud servers.")
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of FINK, TOMASSINI, and ZHAO before them, to include ZHAO’s processor for task outsourcing in FINK and TOMASSINI’s method for providing secure evolution as a service. One would have been motivated to make such a combination in order to enable users to outsource evolutionary computation tasks to find optimal solutions in a privacy-preserving manner (ZHAO [pg. 1, Abstract]).
Conclusion
THIS ACTION IS MADE FINAL. 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 Alvaro S Laham Bauzo whose telephone number is (571) 272-5650. The examiner can normally be reached Mon-Fri 7:30 AM - 11:00 AM | 1:00 PM - 5:30 PM 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, Usmaan Saeed can be reached on (571) 272-4046. 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.
/A.S.L./Examiner, Art Unit 2146
/USMAAN SAEED/Supervisory Patent Examiner, Art Unit 2146
Prosecution Insights