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 March 18, 2026.
Claims 1-2, 6, 12-14, 16, and 21-22 have been amended.
Claims 5 and 20 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 March 18, 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 as a whole either explicitly or implicitly for reasons advanced herein below: […]
Applicant submits that the proposed combination of Fink and Tomassini specifically fails to disclose or suggest that the first processor and the second processor processes datasets associated with problems in a mutually exclusive manner (see, for example, para [0018] of Applicant's published application), as recited in amended claims 1 and 6. The claimed system 100 provides separate processing of private and sensitive datasets at two different locations (i.e., a first dataset processing subsystem 102 operated by the first processor at an organization's end and a second dataset processing subsystem 122 operated by the second processor at a remote location) for solution selection (see, for example, para [0018] of Applicant's filed specification).
Applicant submits that Fink generally discloses and suggests separating the evolution service 15 from the candidate evaluation system 20 via a general, state of the art, firewall running on two distinct hosts; and the evolution service 15 transmitting the candidate individual 310 in an encrypted form through the firewall 17 to the candidate evaluation system 20. But 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). In Fink the evolution service 15 does not operate in a mutually exclusive manner with respect to the candidate evaluation system 20. However, as claimed in amended claims 1 and 6, the first processor and the second processor processes 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.
Examiner respectfully disagrees. FINK [0005] explicitly teaches maintaining data and process privacy for both customers and evolution service providers. Specifically, FINK [0005] teaches: “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, 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.” Under broadest reasonable interpretation, FINK [0005] teaches processing data in a mutually exclusive manner. The customer never accesses the evolution service’s algorithms, and the evolution service never accesses the customer’s private datasets. Additionally, processing at two different locations is explicitly taught by FINK [0018] “In an embodiment, the subsystems 15 and 20 run on physically distinct hosts, each within their own secure environment separated by the firewall 17.”
Applicant further argues:
Further, Applicant respectfully submits that Fink fails to disclose or suggest that the evaluated seed population is associated with one or more metrics to generate a metric dataset for transmission to the second processor. The claimed metric dataset represents an irreversible masked evaluated seed population, and the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population, as required by amended claims 1 and 6. To this end, Applicant submits that, as recited at para [0025] of the Applicant's filed specification, "f' in "m=f(X)" is explicitly an evaluation function, which takes private data 'X' as input and produces a metric value 'm' as output. It is further submitted that 'f' correlates the private data to an output (metric values) through a defined computational process. 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 but computes 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 claims 1 and 6, is not fundamentally correct.
Examiner respectfully disagrees. Applicant mischaracterizes the rejection. 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. If FINK sent back functions (f) along with their resulting metrics, the service provider would be able to recover the input data. The metrics, as claimed, are not restricted to a specific type of output, and they can be interpreted as the candidate solution outputs being sent back to the second processor.
Applicant further argues:
“Further, Applicant submits that reporting back of evaluation results to the evolution service 15 in Fink cannot be equated to irreversible masked seed population as, in the claimed invention, the masking is carried out such that the transformation cannot be reversed. Amended claims 1 and 6 explicitly require that the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population, thereby providing security and privacy for the seed population.”
Examiner respectfully disagrees. The claims or specification never disclose a transformation that cannot be reversed. The specification states “For instance, a private data may be represented as "X", the evaluation functions represented as "f1", "f2", ... , "fn" and the metrics as "m1", "m2", "mn", the relation between "X", "f" and "m" is defined as "m = f(X)". As such, an inverse function for "f" cannot be used to send back "X" by analyzing "m". One of ordinary skill in the art would recognize that the inverse function of
m
=
f
x
is
f
-
1
f
x
=
x
.
However, the claimed limitation states “associating, by the first processor, the evaluated seed population with one or more metrics to generate a metric dataset for transmission to the second processor, wherein the metric dataset represents an irreversible masked evaluated seed population, and wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population”. Under broadest reasonable interpretation, this limitation requires: (1) associating (i.e., pairing) each candidate solution (f) with its metric output (m), and (2) sending both to the second processor. If both f and m are sent, the second processor can compute
f
-
1
to recover the input data
X
. Based on this interpretation, sending both f and m does not provide security or privacy, because the input data can be recovered.
Applicant further argues:
“Further, it is submitted that the Applicant's published specification at, for instance, paragraphs [0026]-[0034] provides an example of how irreversible masking is carried out in the context of a diabetes-related evaluation. The best candidate selection unit 120 receives only function values of the parameters "x," "y," and "z" as the actual values are hidden. The processed metrics dataset is illustrated as a set of rules involving abstract "field" references (e.g., "field_ 1 <= 2.2 *field_ 2 ") that map to clinical interpretations without revealing the underlying private patient data. Fink does not disclose or suggest the claimed irreversible masked evaluated seed population in which the metric dataset comprises function values of parameters of the evaluated seed population such that an inverse function cannot be used to recover original data of the privately hosted datasets from the metric dataset. As such, the teachings of Fink are far removed from the teachings of the claimed invention. In fact, Fink teaches away from the claimed invention.”
Examiner respectfully disagrees. The example provided in [0026] is simply renaming clinical variable names to generic variables such as field_N, thereby “hiding” the actual values. However, the specification never discloses a mapping method from medical evaluation results to clinical interpretations that would prevent recovering patient data. More specifically, the example illustrated in paragraph [0026] states that in the metric dataset (field 1 <= 2.2*field 2) and (field 3 > 33) -> 18 would correspond to “if patient has a respiratory problem but not a neoplasms problem, then prescribe metformin-pioglitazone”. While a person with no prior knowledge of the clinical interpretation mapping would not know that 18 corresponds to “prescribe metformin-pioglitazone”, nothing in the specification or claims describe the steps that a person of ordinary skill in the art would follow to perform irreversible masking that prevents private data recovery.
Applicant further argues:
“Applicant respectfully submits that Tomassini fails to cure the deficiencies of Fink, in that Tomassini generally discloses and suggests parallel evolutionary computing concepts without any focus on data privacy, security, or irreversible masking, as disclosed in the claimed invention. Tomassini generally discloses and suggests a user specified termination condition and fails to specifically disclose or suggest selecting a best candidate solution by recursively processing the metrics dataset until a termination condition is reached, and in the event the termination condition is not reached then a next population is generated based on the best candidate solution, as required by amended claims 1 and 6. The termination condition, in the claimed invention, thus operates as part of a recursive loop over the metrics dataset, which is not pre-empted by Tomassini.
Further, it is submitted that Tomassini at page 3 provides examples of termination conditions as: "a fixed number of iterations or an acceptable level of fitness, or no improvement in solution quality over a given number of iterations. Furter, Tomassini at page 3 discloses a generic iterative loop ("repeat until termination") over a population with conventional fitness evaluation and does not disclose or suggest recursive processing of a metrics dataset that is distinct from the population itself, as required by amended claims 1 and 6.In the claimed invention, recursively processing the metrics dataset is a defined iterative operation over a specific data structure, which is not pre-empted by Tomassini.
Further, it is submitted that in the claimed invention, the termination condition directly determines whether a next population is generated based on the best candidate solution selected from the metrics dataset (see, for example, para [0035] of Applicant's published application). Whereas, in Tomassini, the termination condition generally ends the evolutionary loop. Tomassini is silent on generating a next population based on a best candidate selected from a masked metrics dataset, as required by amended claims 1 and 6. Therefore, the termination condition, as claimed in the amended claims 1 and 6, cannot be equated to termination condition of Tomassini. As such, the teachings of Tomassini are far removed from teachings of the claimed invention.”
Examiner respectfully disagrees. TOMASSINI was not relied upon for teaching “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”, instead, FINK was used. TOMASSINI was relied upon only for teaching that termination criteria can include a logical function applied to the metrics (e.g., no improvement in solution quality). FINK was relied upon for the iterative process of creating populations until termination. TOMASSINI and FINK both relate to evolutionary algorithms and a person of ordinary skill in the art would have been motivated to combine them, as stated in the previous office action.
Applicant further argues:
“Claims 8, 17 and 22 are rejected under 35 USC 103 as being unpatentable over Fink, Tomassini and Zhao ("Evolution as a Service: A Privacy-Preserving Genetic Algorithm for Combinatorial Optimization"). Applicant submits that Zhao fails to cure the deficiencies of Fink and Tomassini in view of amended claims 1 and 6. Claim 8 is dependent on amended claim 6 and claim 17 is dependent on amended claim 14 as such the proposed combination of Fink, Tomassini and Zhao fails to render the said claims obvious. Further, claim 22 has been amended and as such the proposed combination of Fink, Tomassini and Zhao fails to render the said claim obvious.”
Examiner respectfully disagrees. Applicant’s arguments regarding claims 8 and 17 are not persuasive because FINK and TOMASSINI teach amended claims 6 and 14, as shown in the 103 rejections below. 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. The 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 limitation is taught by ZHAO, as shown in the 103 rejections below.
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 1-4, 6-19, and 21-22 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 1:
The claim recites “associating […] the evaluated seed population with one or more metrics to generate a metric dataset for transmission to the second processor” and “wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population;”. Under broadest reasonable interpretation (BRI), both the evaluated seed population (i.e., candidate solutions) and associated metrics (i.e., output values of candidate solutions) are being sent to the second processor. Additionally, the second processor already possesses each candidate solution sent for evaluation, which leaves unclear how the recovery of private data is prevented. This contradicts the claimed limitation of “providing security and privacy for the seed population by the irreversible masked evaluated seed” so that private data cannot be recovered. Additionally, the BRI of “wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population” covers sending the inverse function along with the associated metrics of the candidate solutions. By sending the inverse function and the metrics (i.e., output values), you can directly retrieve the input data used to generate the metrics. It is unclear how security and privacy is being provided by a metric dataset which transmits evaluated seed populations as an inverse function and their associated metrics. Even if only the metrics are sent to the second processor, as suggested by specification paragraphs [0025] and [0033], which state “the metrics implementation unit 114 provides only the function values as one or more metrics datasets”, there is no irreversible masking process being performed on the metrics or candidates; it is merely transmitting the output values of the candidate evaluations. Therefore, the lack of clarity regarding the inverse function providing security and privacy for the seed population renders the claim indefinite under 35 USC § 112(b). For purposes of examination, and to the extent the limitation can be understood, the examiner will construe “provides an inverse function of the evaluated seed population providing security and privacy for the seed population” as the metric dataset sent to the second processor providing recovery prevention of the private data used to evaluate the seed populations (e.g., candidate solutions). This interpretation is consistent with the paragraphs [0025] and [0033] of the disclosure.
Regarding Claim 6:
The claim recites “receiving, by the second processor, a metric dataset associated with an evaluated seed population from the first processor, wherein the metrics dataset represents an irreversible masked evaluated seed population, and wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population”. Under BRI, both the evaluated seed population (i.e., candidate solutions) and associated metrics (i.e., output values of candidate solutions) are being received by the second processor. Additionally, the BRI of “wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population” covers receiving the inverse function along with the associated metrics of the candidate solutions. By receiving the inverse function and the metrics (i.e., output values), you can directly retrieve the input data used to generate the metrics. It is unclear how security and privacy is being provided by the received metric dataset. Even if only the metrics are received by the second processor, as suggested by specification paragraphs [0025] and [0033], which state “the metrics implementation unit 114 provides only the function values as one or more metrics datasets”, there is no irreversible masking process being performed on the metrics or candidates. The second processor already possesses each candidate solution, which leaves unclear how the recovery of private data is prevented. Therefore, the lack of clarity regarding the inverse function providing security and privacy for the seed population renders the claim indefinite under 35 USC § 112(b). For purposes of examination, and to the extent the limitation can be understood, the examiner will construe “provides an inverse function of the evaluated seed population providing security and privacy for the seed population” as the metric dataset received by the second processor providing recovery prevention of the private data used to evaluate the seed populations (e.g., candidate solutions). This interpretation is consistent with the paragraphs [0025] and [0033] of the disclosure.
Regarding Claims 14 and 22:
The claims recite “associating/associate the evaluated seed population with one or more metrics to generate a metric dataset, wherein the metric dataset represents an irreversible masked evaluated seed population, and wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population”. Under BRI, both the evaluated seed population (i.e., candidate solutions) and their respective metrics (i.e., output values of candidate solutions) are being associated to generate a metric dataset. Additionally, the BRI of “wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population” covers associating the inverse function along with the respective metrics of the candidate solutions. By associating the inverse function and the metrics (i.e., output values), you can directly retrieve the input data used to generate the metrics. It is unclear how security and privacy is being provided by the metric dataset. Furthermore, specification paragraphs [0025] and [0033] state “the metrics implementation unit 114 provides only the function values as one or more metrics datasets”, and thus there is no irreversible masking process being performed on the metrics or candidates. Therefore, the lack of clarity regarding the inverse function providing security and privacy for the seed population renders the claim indefinite under 35 USC § 112(b). For purposes of examination, and to the extent the limitation can be understood, the examiner will construe “provides an inverse function of the evaluated seed population providing security and privacy for the seed population” as the metric dataset providing recovery prevention of the private data used to evaluate the seed populations (e.g., candidate solutions). This interpretation is consistent with the paragraphs [0025] and [0033] of the disclosure.
Regarding Claims 2-4, 7-13, 15-19, and 21:
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-4, 6-7, 9-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.")
sending, by a first processor, a population generation request corresponding to a problem associated with a domain type to a second processor, wherein the first processor and the second processor processes sensitive datasets associated with the problem in a mutually exclusive manner; (FINK [0003] 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 [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; 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 [0032] teaches: "First, the customer uses the Candidate Evaluation System 20 (i.e., by a first processor) 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 (i.e., processes sensitive datasets associated with the problem in a mutually exclusive manner.)
evaluating, by the first processor, a generated seed population corresponding to the population generation request based on privately hosted sensitive datasets, wherein the seed population represents candidate solutions corresponding to the problem associated with the different domain types; (FINK [0003] 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., generated seed population, wherein the seed population represents candidate solutions) against the secure data set (i.e., based on 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., seed population) of candidate individuals (i.e., 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 [0009] teaches: "and evaluating one or more of the candidates individuals against the secure data set to determine measurements indicative of a fitness of each of the candidate individuals for a predetermined use.")
associating, by the first processor, the evaluated seed population with one or more metrics to generate a metric dataset for transmission to the second processor, wherein the metric dataset represents an irreversible masked evaluated seed population, and wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed 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., 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 (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: 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. Therefore, by 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, the Evolution Service 15 (i.e., second processor) would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) and the ID of the respective candidate solution (e.g.,
f
). Therefore, what is reported back by the Candidate Evaluation System 20 (i.e., first processor) to the Evolution Service 15 (i.e., second processor) is an irreversible masked evaluated seed population which prevents the recovery of private data.)
evaluating, by the first processor, a generated next population received from the second processor based on 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 seed population received from the second processor) against the secure data set (i.e., based on 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.”)
transmitting the 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 secure 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 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: […] 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. (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 datasets. (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 dataset. (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 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 4:
FINK in view of TOMASSINI teaches the elements of claim 1 as outlined above. FINK further teaches:
wherein the first processor associates the evaluated seed population with one or more metrics based on function values of the parameters of the evaluated seed population to generate the metrics dataset. (FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 (i.e., first processor) records measurements of performance (i.e., based on function values of the parameters) against the secure data set. The secure data set may be static or dynamic, such as where candidates are tested online against actual users. 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., associates the evaluated seed population [...] to generate the metrics 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.)
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 comprises: (FINK [0003] 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: “[0005] 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.")
receiving, by a second processor, a population generation request corresponding to a problem associated with a domain type from a first processor, wherein the first processor and the second processor processes sensitive datasets associated with the problem in a mutually exclusive manner; (FINK [0008] teaches: "receiving at a first server (i.e., by a second processor) of a receiving party a first secure request for evolution (i.e., 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 (i.e., from a first processor);” 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 (i.e., processes sensitive datasets associated with the problem in a mutually exclusive manner.)
generating, by the second processor, a seed population corresponding to the request, wherein the seed population represents candidate solutions corresponding to the problem associated with the domain type; (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 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 (i.e., by second processor) 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.”)
receiving, by the second processor, a metric dataset associated with an evaluated seed population from the first processor, wherein the metrics dataset represents an irreversible masked evaluated seed population, and wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population; (FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance against the secure data set. The secure data set may be static or dynamic, such as where candidates are tested online against actual users. 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 associated with an evaluated seed population from the first processor) are potentially reported back to the Evolution Service 15 (i.e., receiving, by 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." Furthermore, 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. Therefore, by 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, the Evolution Service 15 (i.e., second processor) would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) and the ID of the respective candidate solution (e.g.,
f
). Therefore, the evaluation results associated with their respective candidate ID’s (i.e., metric dataset) reported back by the Candidate Evaluation System 20 (i.e., first processor) to the Evolution Service 15 (i.e., second processor) represents an irreversible masked evaluated seed population which prevents the recovery of private data.)
selecting, by the second processor, 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 candidates solutions until a 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, by the second processor, 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 7:
FINK in view of TOMASSINI teaches the elements of claim 6 as outlined above. FINK further teaches:
wherein the second processor receives function values of parameters associated with the evaluated seed population in the form of the metrics dataset. (FINK [0033] teaches: "For each candidate evaluation, the Candidate Evaluation System 20 records measurements of performance (i.e., function values of the parameters) against the secure data set. The secure data set may be static or dynamic, such as where candidates are tested online against actual users. When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results (i.e., function values of parameters) each associated (i.e., associated with) with their candidate ID's (i.e., evaluated seed population) are potentially reported back to the Evolution Service 15 (i.e., the second processor receives) with the previous checkpoint key.” Examiner’s note: under broadest reasonable interpretation, in the form of the metrics dataset can be interpreted as the reported evaluation results with their respective candidate ID’s to inform the creation of the next population.)
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. TOMASSINI 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 comprises: (FINK [0003] 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: “[0005] 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 [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 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 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 (i.e., generating) new populations of candidates of possible optimizations from no prior candidates.”)
evaluating the generated seed population corresponding to the request based on 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., based on 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 [0042] teaches: "The Candidate Evaluation System 20, evaluates each individual against its data set in a secure environment (message M4).”)
associating the evaluated seed population with one or more metrics to generate a metric dataset, wherein the metric dataset represents an irreversible masked evaluated seed population, and wherein the irreversible masked evaluated seed population provides an inverse function of the evaluated seed population providing security and privacy for the seed population; (FINK [0033] teaches: "When all evaluation is complete (as determined by the domain-specific aspects of the Candidate Evaluation System 20), evaluation results (i.e., one or more metrics) each associated (i.e., associating [...] to generate a metric dataset) with their candidate ID's (i.e., the 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." Furthermore, 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. Therefore, by 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, the Evolution Service 15 would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) and the ID of the respective candidate solution (e.g.,
f
). Therefore, what is reported back by the Candidate Evaluation System 20 to the Evolution Service 15 is an irreversible masked evaluated seed population which prevents the recovery of private data.)
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 candidates solutions until a 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 based on 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., based on 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 15:
FINK in view of TOMASSINI teaches the elements of claim 14 as outlined above. FINK further teaches:
wherein the metrics dataset associated with the evaluated seed population masks the evaluated seed population by processing function values of the parameters of the evaluated seed population. (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." Furthermore, 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. Therefore, by 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, the Evolution Service 15 would not be able to retrieve the secure data set (e.g.,
X
) from the evaluation results (e.g.,
m
) and the ID of the respective candidate solution (e.g.,
f
). Therefore, what is reported back by the Candidate Evaluation System 20 to the Evolution Service 15 are masks resulting from processing (i.e., associating) the function values of the parameters (i.e., evaluation results) of the evaluated seed population (i.e., candidate solutions).)
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 respectively above, and further in view of ZHAO ("Evolution as a Service: A Privacy-Preserving Genetic Algorithm for Combinatorial Optimization"), hereafter FINK, TOMASSINI, and ZHAO respectively.
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
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