Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Response to Arguments
Applicant’s arguments filed February 19, 2026 have been fully considered. After further consideration, the prior art of record still reads on Applicant’s amended claim language and new ground(s) of rejection are presented due to Applicant’s amendment.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
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 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1/10 recites, in relevant part:
" ... wherein the user-specified amount of the privacy currency denotes noise to be added to the data of the at least one subject partition upon servicing the query, such that the greater the user-specified amount of the privacy currency the less noise added ... "
The Examiner specifically directs this rejection to the limitation that the “privacy currency denotes noise to be added” to the data. This characterization of the privacy currency introduces subject matter that is not described in the specification as originally filed, whether expressly, implicitly, or inherently. See MPEP § 2163; Ariad Pharms., Inc. v. Eli Lilly & Co., 598 F.3d 1336, 1351 (Fed. Cir. 2010) (en bane) (“the test for sufficiency is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date”).
Newly added claim limitations must be supported in the specification through express, implicit, or inherent disclosure. MPEP § 2163. While there is no in haec verba requirement, the written description requirement is likewise not satisfied merely because a claim term or phrase can be loosely associated with concepts appearing somewhere in the specification. Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968 (Fed. Cir. 2002).
The Specification Never Describes the Privacy Currency as “Denoting Noise”
The Examiner has reviewed the specification in its entirety. At no point does the
specification describe the privacy currency - identified as ɛ and δ - as “denoting” indicating, representing, or otherwise being equated with noise. Rather, the specification consistently describes ɛ and δ as privacy parameters that relate to the degree of privacy protection or the output of a randomization algorithm, and consistently describes noise as something separately produced by a randomization algorithm M. The relevant passages are analyzed below.
What the Specification Says ɛ and δ Are
The specification assigns the following identities and definitions to ɛ and δ – none of which equate them with noise:
[0023]: ɛ is a “differential privacy parameter” used to characterize when a scheme is “ɛ differentially private.” δ is likewise a “differential privacy parameter.” The paragraph further states that “ɛ and δ are related to the randomization algorithm M and, all other factors remaining the same, the values of ɛ and δ decrease as the randomization algorithm provides greater randomization.” This describes ɛ and δ as parameters of a mathematical framework that are related to a randomization algorithm - not as values that denote the noise itself.
[0024]: “The parameter ɛ is an indicator of the difference between results 320-1 and 320-2.” This defines ɛ as an indicator of result divergence - a measure of distinguishability between two database outputs - not as a denotation of noise. δ is separately defined as denoting “the likelihood of information being accidentally leaked” - again, not noise.
[0029]: “ɛ and δ may be defined as privacy currencies, and the amount(s) of ɛ and δ provided by the data owner 460 may be defined as privacy allowances.” This is the definitional passage for the term “privacy currency.” The specification defines privacy currencies as amounts of the differential privacy parameters ɛ and δ not as amounts of noise.
[0030]: “The query may include a user-specified ɛ and/or a user-specified δ, the user-specified ɛ and/or a user-specified δ indicating a desired level of privacy protection and affecting the accuracy of the query results.” This is the closest the specification comes to describing what the user-specified privacy currency “indicates” or “denotes,” and it states that the currency indicates a desired level of privacy protection - not noise.
What the Specification Says Noise Is
In contrast, the specification consistently describes noise as something produced by a randomization algorithm, not as something the privacy currency “denotes”:
[0002]: “Differential privacy protects data by adding noise to numerical results.”
[0018]: “each time the database table 100 is queried, random noise is added to the data in the database table” - via “a randomization algorithm may be employed to add 'noise' of a uniform distribution.”
[0019]: “one can protect a database table against averaging attack ... by increasing the amount of noise added by the randomization algorithm.”
[0023]: The noise/randomization is the output of “randomization algorithm M” – a mathematical function that adds randomization to query outputs.
In every instance, noise is described as an output of the randomization algorithm M that is applied to the data when a query is serviced. The privacy currency (ɛ/δ) is a separate concept: a parameter that characterizes the privacy scheme. The specification never collapses these two distinct concepts into one by stating or implying that the privacy currency “denotes” the noise.
The Relationship Is Indirect and Inverse - Not “Denotation”
To be clear, the specification does describe a mathematical relationship between ɛ / δ and the degree of randomization ([0023]). From this, a person of ordinary skill in the art (POSITA) could infer that ɛ/δ values inversely relate to the amount of noise added by the randomization algorithm. However, an indirect inverse mathematical relationship between two distinct parameters does not constitute written description support for the proposition that one parameter “denotes” the other.
The word “denotes” means “to indicate, signify, or serve as a name or designation for” (Merriam-Webster). Claiming that the privacy currency “denotes noise to be added” characterizes the privacy currency as a representation of or proxy for the noise - as though specifying the currency amount is specifying the noise. The specification does not describe this. The specification describes the privacy currency as specifying a desired level of privacy protection ([0030]) or as a privacy parameter ([0023]-[0024]), which then separately affects how much randomization the algorithm applies. These are different concepts with different roles in the disclosed system architecture.
The Originally Filed Claims Confirm the Absence of This Concept
The originally filed claims (reproduced in [0040]-[0059]) further confirm that the applicant did not possess the concept of the privacy currency “denoting noise.” None of the twenty originally filed claims - including the broadest independent claims at [0040] (method) and [0049] (system) - recite or suggest that the privacy currency “denotes noise to be added.” The original claims describe the currency solely in terms of a specified amount that is compared to a remaining privacy allowance for the purpose of allowing or disallowing a query. Noise is not mentioned in any originally filed claim.
Conclusion
The amended limitation reciting that “the user-specified amount of the privacy currency denotes noise to be added to the data” introduces a characterization that is absent from the specification. The specification consistently describes:
The privacy currency (ɛ/δ) as a privacy parameter indicating a desired level of privacy protection ([0023], [0024], [0029], [0030]);
Noise as an output of a randomization algorithm M ( [0002], [0018], [0019], [0023]); and
An indirect, inverse mathematical relationship between ɛ/δ and the degree of randomization ([0023]) - which is not the same as one "denoting" the other.
The specification does not describe the privacy currency as denoting, indicating, representing, signifying, or being equated with noise. The amended limitation therefore introduces new matter that is not supported by express, implicit, or inherent disclosure in the specification as filed.
Applicant is invited to identify specific support in the specification as originally filed for the proposition that the user-specified amount of the privacy currency “denotes noise to be added” to the data.
Claims 1 – 20 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.
Claim 1/10 was amended to add several “wherein” clauses to the “receiving a query” step, including:
“... wherein the user-specified amount of the privacy currency denotes noise to be
added to the data of the at least one subject partition upon servicing the
query, such that the greater the user-specified amount of the privacy currency
the less noise added...”
These amended wherein clauses purport to define a relationship between the user-specified privacy currency and noise to be added to the data upon servicing the query. However, as set forth in the four independent grounds below, a person having ordinary skill in the art (POSITA) cannot determine the metes and bounds of the claimed subject matter with reasonable certainty. Per Nautilus, Inc. v. Biosig Instruments, Inc., 572 U.S. 898 (2014), a claim is indefinite if its claims, read in light of the specification and prosecution history, fail to inform those skilled in the art about the scope of the invention with reasonable certainty.
Ground 1: The Noise Limitations Fail to Interrelate with the Operative Method Steps
Per MPEP § 2172.01, “[i]f a claim fails to interrelate essential elements of the invention as defined by applicant(s) in the specification, the claim may be rejected under 35 U.S.C. 112(b) ... as indefinite.” See also MPEP § 2173.05(g) (functional language may render a claim indefinite where it fails “to provide a clear-cut indication of the scope of the subject matter embraced by the claim”); In re Swinehart, 439 F.2d 210, 213 (CCPA 1971).
Claim 1 recites five method steps (Assigning, Receiving, Comparing, Disallowing, and Allowing) and only the amended wherein clauses in the Receiving step references noise. The amended noise-related limitations in the “receiving” step are completely isolated from the remainder of the claimed method. The comparing step compares “at least a portion of the user-specified amount of privacy currency to a remaining privacy allowance for the subject partition.” The disallowing step and allowing step gate query processing based solely on the comparison of privacy currency to remaining privacy allowance. None of these downstream steps reference noise, require noise to be added, act upon the amount of noise, or depend in any way on the “denotes noise” or “less noise added” characterizations introduced in the amended receiving step.
This creates an indefiniteness problem because a POSITA cannot determine how the noise-related limitations affect the scope of the claimed method. Specifically, a POSITA cannot ascertain:
Whether the method requires noise to actually be added at any point during execution, or whether the “denotes noise” and “less noise added” language merely describes an inherent property of the privacy currency that need not be implemented;
Whether the noise-related limitations impose any additional structural or functional constraint on the method beyond what is already required by the comparing/disallowing/allowing steps, which operate entirely on privacy currency amounts and remaining privacy allowances - not on noise;
What acts a practitioner must perform (or refrain from performing) to satisfy the noise limitations, given that the claim's operative steps never instruct the practitioner to add noise, measure noise, or use noise in any decision-making capacity.
In other words, the amended noise limitations float within the “receiving” step as a descriptive characterization of the privacy currency but are never picked up, used, or acted upon by any subsequent step. A POSITA reading the claim as a whole cannot determine whether the noise limitations narrow the claim scope at all, or if so, how. The boundaries of the claimed subject matter are therefore not clearly delineated.
Ground 2: The Noise Limitation Is Self-Defeating - The Claim's Own Disallowing Step Negates the Condition Under Which Noise Is Added
The amended wherein clause defines the privacy currency as denoting “noise to be added to the data of the at least one subject partition upon servicing the query.” The phrase “upon servicing the query” establishes that noise is to be added contingent on the query being serviced. However, the claim's own operative steps include a pathway in which the query is never serviced:
“disallowing processing of the query when the comparing indicates that the at
least a portion of the user-specified amount of privacy currency is greater than the
remaining privacy allowance for the subject partition”
When the disallowing step is triggered, the query is not processed and is therefore never serviced. If the query is never serviced, the condition “upon servicing the query” is never satisfied. If that condition is never satisfied, no noise is ever added. And if no noise is ever added, the limitation that the privacy currency “denotes noise to be added ... upon servicing the query” describes an event that never occurs.
A POSITA cannot determine the metes and bounds of the noise limitation under this scenario. Specifically, a POSITA cannot ascertain:
Whether the “denotes noise to be added upon servicing the query” limitation is only operative when the query is allowed (making it a conditional limitation that applies in some executions of the method but not others);
Whether the limitation requires the noise to actually be added at some point, or merely requires the privacy currency to theoretically correspond to noise that would be added if the query were serviced - i.e., a hypothetical or latent property;
Whether the claimed method is satisfied by the disallowing pathway alone (in which case the noise limitation is never triggered and has no constraining effect), or whether the claim requires both the allowing and disallowing pathways to be practiced, with noise added only when the allowing step is reached.
The claim thus defines a characteristic of the privacy currency – “denotes noise to be added upon servicing the query” - that is contingent on a condition (servicing) that the claim's own method negates in at least one execution pathway. This renders the scope of the noise limitation uncertain, because a POSITA cannot determine whether or when the limitation must be satisfied during practice of the claimed method.
Ground 3: The Claim Recites Two Internally Inconsistent Characterizations of the Privacy Currency (See MPEP § 2173.05(b), § 2173.05(g))
Compounding the interrelation and self-defeating problems above, the amended “receiving” step introduces a characterization of the privacy currency that is internally inconsistent with the role of the privacy currency in the operative method steps.
In the operative steps (comparing, disallowing, allowing), the privacy currency functions as a budget/cost metric: it is a quantified amount that is compared against a remaining privacy allowance to determine whether a query should be processed. In this context, the privacy currency is a privacy parameter – consistent with the specification's definition of ɛ and δ as “privacy currencies” ([0029]) that indicate “a desired level of privacy protection” ([0030]).
In the amended wherein clauses, however, the privacy currency is recharacterized as something that “denotes noise to be added” to the data. The term “denotes” means to indicate, signify, or serve as a designation for. This characterization reframes the privacy currency as a representation of noise - a fundamentally different concept from a privacy budget/cost metric.
A POSITA is left unable to reconcile these two roles:
If the privacy currency “denotes noise,” then specifying a greater amount of it should logically correspond to specifying more noise (a direct relationship). Yet the claim simultaneously requires the opposite: “the greater the user-specified amount of the privacy currency the less noise added” (an inverse relationship).
If the privacy currency is a budget/cost metric (as used in the comparing/disallowing/allowing steps), it is unclear how it simultaneously “denotes” the noise that is to be added - the specification treats these as distinct concepts, with noise being an output of “randomization algorithm M” ([0018], [0019], [0023]) and the privacy currency being a parameter of the differential privacy framework ([0023], [0024], [0029]).
The claim thus assigns the privacy currency two incompatible identities: (1) a budget/cost metric compared against remaining allowances (operative steps), and (2) a quantity that “denotes noise to be added” yet is inversely related to noise (wherein clauses) - without explaining or reconciling the relationship between these two roles. A POSITA cannot determine the metes and bounds of what the “privacy currency” encompasses in the claim. See MPEP § 2173.05(b), § 2173.05(g).
Ground 4: The Specification's Contradictory Teachings Compound the Uncertainty (See MPEP § 2173.03)
Per MPEP § 2173.03, "[a] claim, although clear on its face, may also be indefinite when a conflict or inconsistency between the claimed subject matter and the specification disclosure renders the scope of the claim uncertain as inconsistency with the specification disclosure or prior art teachings may make an otherwise definite claim take on an unreasonable degree of uncertainty." See Cohn v. United States, 438 F.2d 993, 169 USPQ 379 (Ct. Cl. 1971).
The specification provides irreconcilable teachings about the relationship between the privacy currency (ɛ/δ), noise, and privacy protection:
Paragraph
Teaching
Relationship
0030
Greater ɛ/δ [Wingdings font/0xE0] less noise [Wingdings font/0xE0] “more privacy protection”
greater currency = less noise = more protection
0024
Smaller epsilon [Wingdings font/0xE0] more differential privacy
smaller currency = more protection
0019
Protect against attacks by “increasing the amount of noise”
More noise = more protection
0023
ɛ and δ decrease as randomization increases
Lower currency = more randomization/noise
Para 0030 teaches that greater ɛ/δ leads to less noise, which (according to para 0030) means “more privacy protection.” But para 0024 teaches that smaller ɛ provides more privacy, and para 0019 teaches that more noise provides more protection – i.e., less noise means less protection. The specification thus simultaneously teaches two mutually exclusive models of how the privacy currency relates to noise and protection:
Model A (para 0030): Greater currency [Wingdings font/0xE0] less noise [Wingdings font/0xE0] more protection
Model B (para 0019, 0023, 0024): Greater currency [Wingdings font/0xE0] less noise [Wingdings font/0xE0] less protection
Because the claim's “denotes noise” and “less noise added” limitations lack any operative connection to the downstream method steps (Ground 1), are self-defeating in the disallowance pathway (Ground 2), and create an internal identity conflict for the privacy currency (Ground 3), a POSITA must look to the specification to understand what functional role the noise limitations play in defining the scope of the claim. But the specification provides contradictory guidance about the very relationship the noise limitations purport to define, making it impossible to determine the intended scope with reasonable certainty.
Ground 5: “Greater” and “Less” are Relative Terms of Degree Without a Defined Standard (See MPEP § 2173.05(b))
Per MPEP § 2173.05(b), when claim language includes terms of degree, the claim must “provide some standard for measuring that degree” so that “one of ordinary skill in the art would understand what is claimed.” Claim language is indefinite when the specification does not provide a standard for ascertaining the requisite degree and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. See Seattle Box Co. v. Industrial Crating & Packing, Inc., 731 F.2d 818, 826 (Fed. Cir. 1984).
The claim recites: “such that the greater the user-specified amount of the privacy currency the less noise added.”
The terms “greater” and “less” are inherently comparative - they describe a directional relationship between two quantities (privacy currency amount and noise added) without establishing any defined standard or reference point. Specifically, a POSITA cannot determine:
Greater relative to what baseline? The claim does not define a reference amount of privacy currency against which “greater” is measured. It is unclear whether “greater” means greater than zero, greater than a previous query's specification, greater than some minimum threshold, or greater relative to a normalized scale. The specification does not provide a standard for this measurement. reference amount of noise against which “less” is measured. It is unclear whether “less” means less than a default noise amount, less than the noise that would be added at a lower currency amount, or less than some absolute quantity. The specification does not establish a baseline noise level from which “less” can be ascertained.
What is the nature of the functional relationship? The claim recites a directional monotonic relationship - as one quantity increases, the other decreases but does not specify the mathematical character of the relationship. A POSITA cannot determine whether the relationship is linear, logarithmic, exponential, step-function, or some other mapping. While the specification provides the ɛ differential privacy equation ([0023]), it never derives a formula relating the user-specified privacy currency to a specific quantity of noise. The specification describes noise as being added by “a randomization algorithm” ([0018], [0019]) but never provides the noise-generation function, noise distribution parameters as a function of ɛ / δ, or any other standard by which the “greater/less” relationship can be quantitatively ascertained.
This lack of a defined standard is compounded by the issues identified in Grounds 1 through 4. The noise limitations are disconnected from the operative method steps (Ground 1), are contingent on a condition the claim itself negates (Ground 2), create an internal identity conflict for the privacy currency (Ground 3), and cannot be resolved by reference to the specification's contradictory teachings (Ground 4).
In this context, the undefined comparative terms “greater” and “less” add a further layer of uncertainty: even if a POSITA could determine that a directional relationship exists, the POSITA cannot determine the degree, scale, or quantitative nature of that relationship from the claim, the specification, or the prosecution history. A POSITA reading this limitation cannot ascertain, with reasonable certainty, what quantum of “greater” privacy currency corresponds to what quantum of “less” noise or indeed whether the relationship must be precisely defined at all, or merely directionally correct. The scope of the limitation is therefore uncertain. As a result, the metes and bounds of the claims are not clear.
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claims 1 – 5, 10 and 14 – 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ebadi (Differential Privacy: Now it’s getting personal, 2015) in view of Hockenbrocht (US Pub. No. 2020/0250335 A1) in view of Kuchler (Kuchler, Cohere: Managing Differential Privacy in Large Scale Systems, 2023).
Per claim 1, Ebadi (Differential Privacy: Now it’s getting personal, 2015) teaches a method for restricting queries to a database according to a privacy budget comprising: assigning a first privacy allowance (reads on the budget map is B[r → E (r) | r ∈ T], initializing each new record’s/individual’s budget from E, see Ebadi Figure 3, Definition 4.7, Section 4.4 and Section 4.1 3rd and 4th full paragraph) to first data (reads on the first batch T of records which is the same as individuals r added to tv, see Ebadi Section 4.4 Subsection Input and Section 4.1 3rd and 4th full paragraph) in a database table (reads on the input rule introduces new records T into table variable tv and constructs the provenance table Id(T), see Ebadi Figure 3, Definition 4.7 and Section 4.4 Subsection Input), the first privacy allowance being an amount of a privacy currency (The Examiner asserts Ebadi repeatedly refers to budget and treats it as an amount per record, and deducts query costs – exactly the mechanics of currency, see Ebadi section 4 page 72 1st full paragraph and Section 4.1 3rd and 4th full paragraph), and assigning a second privacy allowance (reads on the budget map is B[r → E (r) | r ∈ T], initializing each new record’s/individual’s budget from E, see Ebadi Abstract 3rd paragraph, Section 3 1st paragraph under Definition 3.1, Figure 3, Definition 4.7, Section 4.4 and Section 4.1 3rd and 4th full paragraph) to second data (reads on for each individual r input to tv, see Ebadi Section 4.4 Subsection Input and Section 4.1 3rd and 4th full paragraph) in the database table (reads on the input rule introduces new records T into table variable tv and constructs the provenance table Id(T), see Ebadi Figure 3, Definition 4.7 and Section 4.4 Subsection Input), the second data being added (The Examiner asserts Ebadi does not mandate order of addition, but it is reasonable for one of ordinary skill in the art to conclude from Ebadi’s teachings that first data is the record for the first individual added and second data is the record for the second individual added, see Ebadi Section 4.1 3rd and 4th full paragraph and Section 4.4 Subsection Input) to the database table (reads on the input rule introduces new records T into table variable tv and constructs the provenance table Id(T), see Ebadi Figure 3, Definition 4.7 and Section 4.4 Subsection Input) after the first data is present (The Examiner asserts Ebadi does not mandate order of addition, but it is reasonable for one of ordinary skill in the art to conclude from Ebadi’s teachings that first data is the record for the first individual added and second data is the record for the second individual added, see Ebadi Section 4.1 3rd full paragraph and Section 4.4 Subsection Input) in the database table (reads on the input rule introduces new records T into table variable tv and constructs the provenance table Id(T), see Ebadi Figure 3, Definition 4.7 and Section 4.4 Subsection Input), the second privacy allowance being an amount of the privacy currency (The Examiner asserts Ebadi repeatedly refers to budget and treats it as an amount per record, and deducts query costs – exactly the mechanics of currency, see Ebadi section 4 page 72 1st full paragraph and Section 4.1 3rd and 4th full paragraph), and the database table being partitioned upon addition of the second data into a first partition including the first data and a second partition including the second data such that the first privacy allowance applies to the first partition and the second privacy allowance applies to the second partition (reads on Ebadi’s personalized differential privacy in the ProPer system that has records separated by budget and provenance, see Ebadi Section 3, Section 4.4, Figure 3, Section 4.1 and Section 4.3); receiving a query from a database user (reads on requesting a value of a query, see Ebadi Section 4.4 Subsection Query and Figure 3), the query comprising a specified amount of the privacy currency (reads on as queries are performed over time the budget for each individual decreases because each query has an associated cost map, see Ebadi Section 4 page 72 1st full paragraph, Section 4.1 3rd and 4th full paragraph and Section 4.4 Subsection Query), wherein servicing the query requires access to at least one subject partition, and the at least one subject partition comprises at least one of the first partition or the second partition (The Examiner construes this to be an obvious if not necessary limitation of Ebadi’s disclosure because the logical partitions that comprise the records each have their own budget/cost and must be accessed to satisfy any query, see Ebadi Section 4 page 72 1st full paragraph, Section 4.1 3rd and 4th full paragraph and Section 4.4 Subsection Query); and wherein the first partition and the second partition are partitioned such that the first partition includes only the first data, that was present in the database table before the second data was added to the database table, and the second partition includes only the second data, that was added to the database table after the first data was present in the database table (The Examiner asserts Ebadi does not mandate order of addition, but it is reasonable for one of ordinary skill in the art to conclude from Ebadi’s teachings that first data is the record for the first individual added and second data is the record for the second individual added, see Ebadi Section 4.1 3rd full paragraph and Section 4.4 Subsection Input); comparing, for the at least one subject partition, on a partition-by-partition basis, at least a portion of the specified amount of privacy currency to a remaining privacy allowance for the subject partition (reads on per individual and per query determining if there is sufficient budget to release the query, see Ebadi Section 4 page 72 1st full paragraph, Section 4.1 3rd and 4th full paragraph and Section 4.4 Subsection Query); disallowing processing of the query when the comparing indicates that the at least a portion of the specified amount of privacy currency is greater than the remaining privacy allowance for the subject partition (reads on silently dropping records from the arguments to queries if the presence of those records would break the privacy budget of an individual, see Ebadi Section 4 page 72 1st full paragraph, Section 4.1 3rd and 4th full paragraph and Section 4.4 Subsection Query); and allowing processing of the query when the comparing indicates that for each of the at least one subject partition the at least a portion of the specified amount of privacy currency is equal to or less than the remaining privacy allowance for the subject partition (reads on we can determine the set of individuals for which the query cost is acceptable – those who have sufficient budget, see Ebadi Section 4.4 Subsection Query). The prior art of record is silent on explicitly stating a user-specified amount of privacy currency for application on a partition-by-partition basis; and comparing, on partition-by-partition basis, specified privacy currency to remaining privacy allowance for the subject partition.
[Ebadi]
[Abstract 3rd paragraph]
This paper is about a new accounting principle for building differentially private programs. It is based on a simple generalisation of classic differential privacy which we call Personalised Differential Privacy (PDP). In PDP each individual has its own personal privacy level. We describe ProPer, a interactive system for implementing PDP which maintains a privacy budget for each individual. When a primitive query is made on data derived from individuals, the provenance of the involved records determines how the privacy budget of an individual is affected: the number of records derived from Alice determines the multiplier for the privacy decrease in Alice’s budget. This offers some advantages over previous systems, in particular its fine-grained character allows better utilisation of the privacy budget than mechanisms based purely on the concept of global sensitivity, and it applies naturally to the case of a live database where new individuals are added over time.
[Section 3 1st paragraph under Definition 3.1]
Personalised differential privacy allows each individual (record) to have its own personal privacy level. This may turn out to be a useful concept in its own right, but its main purpose in this work is as a generalisation that permits a more fine-grained accounting in the construction of classical differentially private mechanisms, and one which plays well with dynamic databases. The following proposition summarises the relation to “small-epsilon” differential privacy:
[Section 4 page 72 1st full paragraph]
In a prescriptive system the desired amount of privacy can be thought of as a budget, and in the literature it is often referred to as such. For ProPer this is an amount of privacy per record as described by some function E . But the principles described above know nothing of budgets – they are purely descriptive. It is therefore important to design a mechanism which is private even when the program fails to meet the intended goals. With personalised differential privacy this is a crucial question – because the budget itself is clearly a sensitive object. In a nutshell, the ProPer approach involves tracking the provenance of each record in any intermediate table (on which sensitive input record does it depend), and by silently dropping records from the arguments to statistical queries if the presence of those records would break the privacy budget of some individual. The provenance information is used to make that link.
[Section 4.1 3rd full paragraph]
The records that are input are the subject of our privacy concerns. We refer to those records as individuals. To provide E - differential privacy for the individuals, the protected system needs to maintain more information than just the mapping between table variables and tables. For each individual r that has been input to the system so far, a privacy budget for r needs to be maintained. Initially the budget will be E (r). As queries are performed over time the budget for each individual may decrease.
[Section 4.1 4th full paragraph]
There are two key issues that the system must address: (i) how much should the budget for each individual be decreased when a table is queried, and (ii) how do we prevent the budget from becoming negative (which would imply that we have violated privacy).
[Section 4.4 Subsection Input]
Input The program requests an input to be made and assigned to a table variable. The rule imposes a constraint on the records T which are input: it must be a set of records, and this set must be disjoint from the records previously input (the domain of B). This reflects the idea that the input records are the subject of privacy and represent unique individuals. The transition of the configuration is labelled with T to record that the environment chose to input T. The probability of the transition is 1, meaning that the choice of input is treated nondeterministically. The configuration is updated in two ways. Firstly, the table is converted to a provenance table by recording that the provenance of each record is itself. Secondly the budget for each new record is initialised from E .
[Section 4.4 Subsection Query]
Query Here the program is requesting the value of a query Qε(tv). To answer the query we must determine the eligible records, L, from the table tv, which can safely be involved in this query. To do this we first determine a Cost map C, which describes the privacy cost which would be inflicted upon individual r by releasing the query Qε(tv); the cost of an ε-differentially private query on tv to an individual r is ε multiplied by the number of records in tv which have provenance r. Given the cost map, we can determine A, the set of individuals for which this cost is Acceptable – i.e. those who have sufficient budget. Finally we can use A to determine L: it is the sub-table of records which depend at most on records in A.
Hockenbrocht (US Pub. No. 2020/0250335 A1) is relied upon to teach a user-specified amount of (reads on the client/user specifies a privacy budget/set of associated privacy parameters with each submitted query, see Hockenbrocht para 0022 – 0024 and 0036) privacy currency (reads on the limits on how much of the restricted data can be released in terms of a client/user, see Hockenbrocht para 0022 – 0024).
[0020] A client 104 is used to access the restricted data in the database 106. A client 104 is an electronic device such as a desktop, laptop, or tablet computer or a smartphone used by a human user to access the database 106. The client 104 and user may be, but are not necessarily, associated with the entities that manage the database 106 and/or DP system 102. Users of the client 104 include administrators and analysts. Administrators use the clients 104 to access the DP system 102 and/or database 106 to perform administrative functions such as provisioning other users and/or clients 104, and configuring, maintaining, and auditing usage of the system and/or database. The administrators may access the DP system 102 and database 106 directly via administrative interfaces that allow users with appropriate credentials and access rights to perform the administrative functions.
[0021] Analysts use the clients 104 to apply analytical queries 108 to the restricted data in the database 106. The clients 104 used by the analysts access the database 106 only through the DP system 102. Depending upon the embodiment, the analyst and/or client 104 may have an account provisioned by an administrator which grants the analyst or client certain rights to access the restricted data in the database 106.
[0022] The rights to the restricted data may be specified in terms of a privacy budget. The privacy budget describes limits on how much of the restricted data can be released. In one embodiment, the privacy budget is a numerical value representative of a number and/or type of remaining queries 108 available. The privacy budget may be specified in terms of a query, analyst, client 104, entity, globally, and/or time period. For example, the privacy budget may specify limits for an individual query, with each query having a separate budget. The privacy budget may also specify limits for an analyst or client, in which case the budget is calculated cumulatively across multiple queries from a client or analyst. For a privacy budget specified for an entity, such as an organization having multiple clients 104 and users, the privacy budget is calculated cumulatively across the multiple queries from clients and users associated with the entity. A global privacy budget, in turn, is calculated across all queries to the database, regardless of the source of the query. The privacy budget may also specify an applicable time period. For example, the privacy budget may specify that queries from particular clients may not exceed a specified budget within a given time period, and the budget may reset upon expiration of the time period. Depending upon the embodiment, client, as used herein, may alternatively or additionally refer to a user using the client to access the DP system 102, to a user account registered with the DP system 102, to a group of users or to a group of clients 104, and/or to another entity that is a source of queries.
[0023] As discussed above, a client 104 sends an analytical query 108 to the DP system 102 and also receives a differentially private response 112 to the query from the system. The queries 108 submitted by the client 104 may be simple queries, such as count queries that request the number of entries in the databases 106 that satisfy a condition specified by the client 104, or complicated queries, such as predictive analytics queries that request a data analytics model trained on the databases 106. Specific types of queries are discussed in more detail below.
[0024] Each query has an associated set of privacy parameters. The privacy parameters indicate the amount of restricted data to release from the database 106 to the client 104 in response to the query 108. The privacy parameters likewise indicate the amount of decrease in the relevant privacy budget (e.g., the budget for the client 104 or entity with which the client is associated) in response to the query 108. In one embodiment, the client 104 specifies a set of associated privacy parameters with each submitted query 108. In other embodiments, the privacy parameters are specified in other ways. The DP system 102 may associate privacy parameters with received queries (rather than obtaining the parameters directly from the query). For example, the DP system 102 may apply a default set of privacy parameters to queries that do not specify the parameters. The values of the default privacy parameters may be determined based on the client 104, analyst, query type, and/or other factors.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the differential privacy teachings of the prior art of record by integrating the user specified privacy teachings of Hockenbrocht (see para 0020 – 0024) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Hockenbrocht would have yielded predictable results and resulted in an improved system. It would have been recognized that implementing the explicit user specified privacy budget within the system of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such privacy budget specification features into similar systems, resulting in an improved system that uses all available known in the art techniques to maintain confidentiality of restricted data when making it available for querying (see Hockenbrocht para 0007). The motivation to combine the references is applied to all claims below this heading.
Kuchler (Kuchler, Cohere: Managing Differential Privacy in Large Scale Systems, 2023) suggests
stating a user-specified (reads on the user submitting the request of Kuchler Figure 2a and Section 3.2) amount of privacy currency for application (reads on the stated budget requirements of epsilon: 0.8 in the specific request of Kuchler Figure 2a) on a partition-by-partition basis (reads on tracking privacy budgets for these subsets separately and a per-block/partition RDP privacy filter, see Kuchler Section 4.1 and 4.4 1st paragraph. The Examiner construes the blocks in Kuchler are the same as the claimed partitions, see Kuchler Section 4.4 1st paragraph); comparing (reads on the combination of the per-block RDP filter’s checks whether there exists an order alpha and the feasibility/admission check that for each affected block j the request’s demand does not exceed that block’s remaining budget, see Kuchler Section 4.3 Subsection Optimization Problem and Section 4.4 1st paragraph. The Examiner asserts the per-block RDP filter’s checks and the optimization inequality at the bottom of page 8 is the explicit partition by partition//block by block comparison of the total requested currency/demand derived from Ci to the remaining allowance Bj for that block at RDP order alpha. Where acceptable is only feasible if for each block j there exists some alpha such that the inequality holds), on partition-by-partition basis (reads on a per-block/partition RDP privacy filter, see Kuchler Section 4.4 1st paragraph. The Examiner construes the blocks in Kuchler are the same as the claimed partitions, see Kuchler Section 4.4 1st paragraph), specified privacy currency (reads on the request’s privacy cost vector Ci, see Kuchler Section 2.2 and Appendix B) to remaining allowance (reads on Bj per block, the per-block remaining budget vector, see Kuchler Section 4.3 Subsection Optimization Problem); the user-specified amount of the privacy currency denotes noise to be added to the data of (reads on the stated budget requirements of epsilon: 0.8 in the specific request of Kuchler Figure 2a) the at least one subject partition upon servicing the query, such that the greater the user-specified amount of the privacy currency the less noise added (reads on tracking privacy budgets for these subsets separately and a per-block/partition RDP privacy filter, see Kuchler Section 4.1 and 4.4 1st paragraph. The Examiner construes the blocks in Kuchler are the same as the claimed partitions, see Kuchler Section 4.4 1st paragraph).
[Section 4.4 1st paragraph]
Kuchler uses block composition and instantiates it with an RDP privacy filter for each block. Under block composition, the overall mechanism satisfies (ϵ, δ)-DP, as long as the (ϵ, δ)-DP budget is not exceeded on any block. In Kuchler, each block, i.e., partition, corresponds to a block ID and there is a block for every possible combination of PAs and for each group. The assignment from users into groups (c.f. §4.2) and to a block within that group based on the users’ PAs is immutable and every user is only assigned to one block. The PAs (i.e., years, regions) have a public domain, and the assignment from users to groups is only based on their arrival time, and importantly, independent of other users’ assignments. As a result, every user only influences data releases computed on that user’s block, satisfying the requirements of block composition.
[Section 4.3 Subsection Optimization Problem]
Let R := {1, . . . , Rmax} be the index set of requests. A request Ri for i ∈ R is a tuple (Φi , Ci , Wi) consisting of a data requirement defining a subpopulation encoded as a propositional formula Φi over the PAs, a budget requirement expressed as a vector Ci ∈ R |A| ≥0 of RDP costs for different orders αa (for a ∈ A := {1, . . . , Amax}), and a weight Wi ∈ N. We introduce decision variables yi ∈ {0, 1} for i ∈ R, where yi = 1 means the request Ri is accepted, and yi = 0 means the request has been rejected. Let S := {1, . . . , Smax} denote the index set over all blocks. A block Sj for j ∈ S is a tuple (groupID, Ψj , Bj ) consisting of a group ID, a propositional formula Ψj over the PAs and a remaining budget Bj ∈ R A ≥0 for this block in this group. The remaining budget Bj of a block is determined by the difference of the unlocked budget according to Equation (1), and the accumulated allocation history.
We set the demand for a block d (α) ij = C (α) i if Φi ∧ Ψj is satisfiable, and 0 otherwise. This captures the fact that the demand for a block outside the selected subpopulation of a request is 0. Finally, to find the optimal set of requests to accept, we solve the optimization problem: max X i∈R yi · Wi s.t. X i∈R d (α) ij yi ≤ B (α) j [∀j ∈ S ∃α ∈ A]
[Appendix B]
In Figure 8, we provide a complete formulation of the ILP. Below, we provide explanations for each part. Notation. Let R := {1, . . . , Rmax}, N := {1, . . . , Nmax} and S := {1, . . . , Smax} denote index sets of the requests, groups and segments respectively. A request Ri for i ∈ R is a tuple (Di , Φi , Ci , Wi) consisting of a data requirement requesting Di ∈ N groups10 filtered by a propositional formula Φi over the PAs, a budget requirement expressed as a vector Ci ∈ R |A| ≥0 of RDP costs for different orders αa (for a ∈ A := {1, . . . , Amax}), and a weight11 Wi ∈ N. Groups are uniquely identified by their global ID j ∈ N , thus we do not differentiate between groups and their IDs (not to be confused with block IDs). The notion of segments is introduced in Section 4.3
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the differential privacy teachings of the prior art of record by integrating the differential privacy teachings of Kuchler (see Kuchler Section 4.3 Subsection Optimization Problem, Section 4.4 1st paragraph, Section 2.2 and Appendix B) to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Kuchler would have yielded predictable results and resulted in an improved system. Both teachings address the identical core challenge of privacy budget exhaustion in continuous differential privacy systems and it would have been recognized that implementing the explicit per block/partition comparing within the system of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such block/partition comparing features into similar systems, resulting in an improved system that uses all available known in the art techniques to prevent budget depletion and maintaining DP guarantees under continuous workloads. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests wherein the privacy currency is ɛ, wherein ɛ denotes a difference between results of the query on the database table and results of the query on a other database table (see Ebadi Definition 2.1 and associated text), wherein the other database table differs from the database table by one database record (see Ebadi Section 3 Subsection Definition 3.1 and Proposition 3.2 and Kuchler Section 2.2).
Per claim 3, the prior art of record further suggests wherein ɛ is such that the following equation holds: wherein Pr denotes probability in the range of 0 to 1, x denotes the database table, y denotes the other database table, M denotes a randomization algorithm, S denotes all subsets of the image of M, and e is Euler’s number (see Ebadi Section 3 Subsection Definition 3.1 and Proposition 3.2 and Kuchler Section 2.2).
Per claim 4, the prior art of record further suggests wherein the privacy currency is δ, wherein δ denotes the likelihood of information from the database table being accidentally leaked (see Ebadi Section 3 Subsection Definition 3.1 and Proposition 3.2 and Kuchler Section 2.2).
Per claim 5, the prior art of record further suggests wherein δ is such that the following equation holds: wherein ɛ denotes a difference between results of the query on the database table and results of the query on a other database table, wherein the other database table differs from the database table by one database record, Pr denotes probability in the range of 0 to 1, x denotes the database table, y denotes the other database table, M denotes a randomization algorithm, S denotes all subsets of the image of M, and e is Euler’s number (see Ebadi Section 3 Subsection Definition 3.1 and Proposition 3.2 and Kuchler Section 2.2 and 2.3).
Claim 10 is analyzed with respect to claim 1.
Claim 14 is analyzed with respect to claim 2.
Claim 15 is analyzed with respect to claim 3.
Claim 16 is analyzed with respect to claim 4.
Claim 17 is analyzed with respect to claim 5.
Claims 6 – 8 and 18 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ebadi in view of Hockenbrocht in view of Kuchler in view of Diffprivlib (Base class, 2020).
Per claim 6, the prior art of record suggests claim 1 and assigning a third privacy allowance to (reads on a privacy budget for each individual record, see Ebadi Figure 1, Section 4 Subsection: Descriptive vs Prescriptive Systems and Section 4.1) the first data (reads on an exemplary record of a plurality of records assigned to a table, see Ebadi Section 4.1 and Figure 1) in the database table (reads on the table that holds the records, see Ebadi Section 4.1 and Figure 1), the third privacy allowance being an amount of other privacy currency (reads on the amount of privacy for each record decreases with use, see Ebadi Section 4.1 and Figure 1), and assigning a fourth privacy allowance to (reads on a privacy budget for each individual record, see Ebadi Figure 1, Section 4 Subsection: Descriptive vs Prescriptive Systems and Section 4.1) the second data (reads on a different exemplary record of a plurality of records assigned to a table, see Ebadi Section 4.1 and Figure 1) in the database table (reads on the table that holds the records, see Ebadi Section 4.1 and Figure 1), the fourth privacy allowance being an amount of the other privacy currency (reads on the amount of privacy for each record decreases with use, see Ebadi Section 4.1 and Figure 1), such that the third privacy allowance applies to the first partition and the fourth privacy allowance applies to the second partition (reads on the amount of privacy is specific to the record/partition, see Ebadi Section 4.1 and Figure 1), and wherein the query further comprises a specified amount of the other privacy currency (reads on each request/query has a budget requirement/Ci, see Ebadi Section 4.4 Subsection: Query and Kuchler Section 3.2 and Section 4.3), the step of comparing further comprises comparing, for the at least one subject partition, on a partition-by-partition basis, at least a portion of the specified amount of other privacy currency to a remaining other privacy allowance for the subject partition (see Ebadi Section 4.4 Subsection: Query and Figure 1), the step of disallowing further comprises disallowing processing of the query when the comparing indicates that the at least a portion of the specified amount of other privacy currency is greater than the remaining other privacy allowance for the subject partition (reads on when the cost of the query exceeds the budget the results are excluded, see Ebadi Section 1 Subsection: Limitations of the Global Privacy Budget and Subsection Personalizsed Differential Privacy and Section 4 Subsection: Descriptive vs Prescriptive Systems and Section 4.1), and the step of allowing comprises allowing processing of the query when the comparing indicates that for each of the at least one subject partition the at least a portion of the specified amount of privacy currency is equal to or less than the remaining privacy allowance for subject partition and the at least a portion of the specified amount of other privacy currency is equal to or less than the remaining other privacy allowance for the subject partition (reads on when the cost of the query exceeds the budget the results are excluded, see Ebadi Section 4.4 Subsection: Query and Section 1 Subsection: Limitations of the Global Privacy Budget and Subsection Personalizsed Differential Privacy) . The prior art of record is silent on explicitly stating budgeting each of epsilon and delta as privacy currency.
Diffprivlib (Base class, 2020) suggests
assigning a third privacy allowance (reads on an epsilon budget ceiling of the accountant, see Diffprivlib Section Base class: Subsection epsilon and Examples and check(epsilon, delta)) and assigning a fourth privacy allowance to the second data in the database table, the fourth privacy allowance being an amount of the other privacy currency (reads on a delta budget ceiling of the accountant, see Diffprivlib Section Base class: Subsection delta and Examples and check(epsilon, delta)).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the differential privacy teachings of the prior art of record by integrating the ability to choose/assign any number of different values for a third and fourth privacy allowances in order to meet the unique needs of users of the technology. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of prior art of record would have yielded predictable results and resulted in an improved system. One of ordinary skill in the art would have been recognized that explicitly assigning different values for the privacy allowance values according to the needs of the specific users of the system of the prior art of record would have yielded predictable results because as in diffprivlib, it is within the capabilities of one of ordinary skill in the art to specify a budget for both delta and epsilon and monitor the use of both in order to determine when either value has been exhausted, in a system similar to that of the prior art of record in order to more precisely account for privacy across various data accesses. The combined teachings allow for one of ordinary skill in the art to specify desired values for both epsilon and delta for any number of different records in order to achieve desired privacy across queries. The motivation to combine the references is applied to all claims below this heading.
Per claim 7, the prior art of record further suggests wherein the privacy currency is ɛ, wherein ɛ denotes a difference between results of the query on the database table and results of the query on a other database table, wherein the other database table differs from the database table by one database record; and wherein the other privacy currency is δ, wherein δ denotes the likelihood of information from the database table being accidentally leaked (see Kuchler Section 2.2 and Section 2.3 and , see Diffprivlib Section Base class: Subsection epsilon, delta and Examples and check(epsilon, delta)).
Per claim 8, the prior art of record further suggests wherein ɛ and δ are such that the following equation holds: wherein Pr denotes probability in the range of 0 to 1, x denotes the database table, y denotes the other database table, M denotes a randomization algorithm, S denotes all subsets of the image of M, and e is Euler’s number (see Kuchler Section 2.2 and Section 2.3 and see Diffprivlib Section Base class: Subsection epsilon, delta and Examples and check(epsilon, delta)).
Claim 18 is analyzed with respect to claim 6.
Claim 19 is analyzed with respect to claim 7.
Claim 20 is analyzed with respect to claim 8.
Claim 9 and 11 – 13 are rejected under 35 U.S.C. 103 as being unpatentable over Ebadi in view of Hockenbrocht in view of Kuchler in view of AWS (AWS Clean Rooms Differential Privacy enhances privacy protection of your users’ data, 2023).
Per claim 9, the prior art of record suggests the method of claim 9. The prior art of record is silent on explicitly stating the database table is accessible through a data clean room, wherein a data provider in the data clean room controls access to at least one of the first data or the second data, and specifies at least one of the first privacy allowance or the second privacy allowance, and wherein the database user is a data subscriber in the data clean room that is granted access by the data provider to at least one of the first data or the second data.
AWS suggests
stating the database table is accessible through a data clean room (reads on a user’s database table referenced via a configured table is made available for querying within an AWS clean rooms collaboration, see paragraph text directly before Privacy budget section), wherein a data provider in the data clean room controls access to at least one of the first data or the second data (reads on the party contributing data/data provider sets policies that make their table available for querying thus controlling access to the contributed data inside the clean room, see 1st paragraph of Section: How differential privacy works in AWS Clean Rooms and see paragraph text directly before Privacy budget section), and specifies at least one of the first privacy allowance or the second privacy allowance (reads on the contributor configures differential privacy policy parameters specifying privacy allowances, see Section: Privacy budget and Section Noise added per query), and wherein the database user is a data subscriber in the data clean room that is granted access by the data provider to at least one of the first data or the second data (reads on a model where a data provider enables partners/data subscribers to query the provider’s data within the clean room after the provider configures policy to make the table available, see text 2 paragraphs before Section: How differential privacy works in AWS Clean Rooms and see paragraph text directly before Privacy budget section).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the differential privacy teachings of the prior art of record by integrating the ability to choose/assign any number of different privacy values in a data clean room in order to meet the unique needs of users of the technology. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of AWS to the teachings of the prior art of record would have yielded predictable results and resulted in an improved system. One of ordinary skill in the art would have been recognized that explicitly using AWS Clean Rooms to implement the differential privacy of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such Clean Room Differential Privacy features into similar systems. The motivation to combine the references is applied to all claims below this heading.
Claim 11 is analyzed with respect to claim 9. The prior art of record further suggests the database and the privacy administration module are included within a single device (The Examiner construes the AWS clean room to encompasses the administration module and the database into at least a single logical device, see AWS and Ebadi Figure 1 and Kuchler Figure 1).
Claim 12 is analyzed with respect to claim 11. The prior art of record further suggests first privacy allowance and the second privacy allowance are provided by an owner of the first data and the second data (reads on data providers, users Alice and Bob, maintain control over how their privacy budgets and how their data is used and accessed, see AWS and Ebadi Figure 1 and Section 4.2 and Section 6.1 and Kuchler Abstract, Section 3.3 and 4.1 – 4.2).
Claim 13 is analyzed with respect to claim 9.
Conclusion
The prior art of record still reads on Applicant’s unamended claims. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432