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
This Office Action is in response to the communication and claim amendment filed on 06/11/2026; Claims 1 and 11 have been amended; Claims 1-15 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 06/11/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicants argue: Applicant argues at pages 6–7 that neither Rogers nor Hockenbrocht discloses (1) a first privacy budget service in which a first trusted party maintains a first instance of the privacy budget, (2) a second privacy budget service in which a second trusted party maintains a second instance of the privacy budget, or (3) that the first trusted party is different from the second trusted party — that is, that different trusted parties maintain different instances of the same privacy budget (Applicant Remarks/Arguments, pages 6-7). Applicant advances the same contention at page 6 in terms of different servers implementing different privacy budget services (Applicant Remarks/Arguments, page 6).
The Examiner respectfully disagrees with the Applicants as the following:
Claim construction. As an initial matter, Applicant offers no construction of "trusted party" and identifies no passage of either reference in support of the assertion. Claims are given their broadest reasonable interpretation consistent with the Specification. The Specification supplies the meaning of the terms Applicant relies upon.
With respect to the relationship between a trusted party and a server, the publication Specification states at par. [0043] that "[t]he Trusted Party 1 server 166 and the Trusted Party 2 server 172 are servers associated with a Trusted Party 1 and a Trusted Party 2, respectively, that provide the functionality of each Trusted Party," and at par. [0049]] refers to "the Trusted Party 1 server 166 (referred to herein as Trusted Party 1 166 for brevity)." The publication Specification then identifies the claimed servers with the Trusted Parties directly, stating at par. [0076] that a request is transmitted to "a first server implementing a first privacy budget service (e.g., Trusted Party 1 166)" and to "a second server implementing a second privacy budget service (e.g., Trusted Party 2 172)."
With respect to what makes the two trusted parties different from one another, the publication Specification states at par. [0065] that "[e]ach of the Trusted Parties 166, 172 are independent from each other (i.e., implemented on independent servers)," and further that "there is no requirement that the Trusted Parties 166, 172 be implemented on the same cloud platform; each can be implemented on a different cloud platform." The Specification thus expressly permits both trusted parties to reside on a common cloud platform, and nowhere requires that they be separate legal entities, separate organizations, or under separate ownership. The only separateness the Specification attributes to the first and second trusted parties is implementation on independent servers.
Accordingly, under the broadest reasonable interpretation, limitations (1) and (2) require a first and a second server, each implementing a privacy budget service and each maintaining its own instance of the privacy budget, and limitation (3) requires that those servers be independent of one another.
Regarding (1) and (2). Rogers discloses a first and a second server, each implementing its own privacy budget service and each maintaining its own instance of the privacy budget. Rogers Fig. 1 (p. 7) depicts Data Center 1 and Data Center 2, each containing an Application, a Budget Management Service, and a Budget Manager Data Store, with the two Budget Manager Data Stores connected by a bidirectional arrow. Rogers §6.1 (pp. 13–14) states that "the budget manager needs to be a distributed system so that it can be accessed/updated from different application execution platforms." Rogers §4 (p. 8) states that "budget management operations require a remote call to a distributed system because the budget management service needs to provide a consistent view to all application instances." Each Budget Management Service maintains the analyst's budget state in its own Budget Manager Data Store, and Rogers §4.2 (p. 10) discloses the interface by which that state is checked: "checkBudget(ID, cost), which returns either true or false."
Regarding “the same privacy budget”, Applicant's own formulation requires instances "of the same privacy budget." Rogers discloses precisely that. Rogers §6.1 states that "[e]ach analyst may access data from multiple data centers and each access must deduct from the same budget. Hence, the budget manager maintains eventual consistency across data centers." Rogers §4.2 (p. 10) confirms that Espresso was selected for "eventual consistency in cross-datacenter replication to ensure an analyst does not exceed a given budget," and Rogers §1.1 (p. 2) describes a budget management service "able to track each analyst's privacy budget over multiple data centers." The Budget Manager Data Store of Data Center 2 is therefore a second instance of the same privacy budget maintained in Data Center 1, and not a second, different budget.
Regarding (3). Under the construction set forth above, the first and second trusted parties are different where they are implemented on independent servers. Rogers' two Budget Management Services are implemented in separate data centers, each with its own Budget Manager Data Store, connected only by cross-datacenter replication. Implementation in separate data centers necessarily entails implementation on independent servers, which is more separation than par. [0065] requires and is consistent with par. [0065]'s express statement that the two may share a cloud platform.
Remaining limitations. Rogers does not expressly disclose that the request transmitted to the second server is a second request transmitted in addition to the first, that the response received is a second response, or that processing is in accordance with both responses. Those limitations are addressed by Hockenbrocht at par. [0128] and par. [0133] as set forth in the rejection below.
Dependent claims and claim 11. Applicant argues claims 2, 3, 5–8, 10, 12, 13, and 15 solely on the basis of their dependency, argues claim 11 solely for reasons similar to claim 1, and argues claims 4, 9, and 14 solely on the ground that Bernau and McSherry fail to remedy asserted deficiencies in Rogers and Hockenbrocht. As no deficiency exists for the reasons given above, those arguments are not persuasive for the same reasons.
The rejections are maintained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5-8, 10-13, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ryan Rogers et al. (“Rogers,” Linkedln’s Audience Engagemetns API: A Privacy Preserving Data Analytics System at Scale, November 17, 2020, pages 1-28), in view of Hockenbrocht et al. (“Hockenbrocht,” US 2019/0318121).
Regarding claim 1, Rogers teaches a method in one or more servers for managing privacy budgets, the method comprising:
(a) receiving a request to analyze a dataset (Rogers, §4, p.6: "The application entity, based on the request received from the analyst, generates queries to the underlying database),the dataset associated with a privacy budget corresponding to a number of times the dataset can be analyzed (Rogers: Rogers, §4.2, p.9: "We create one key per analyst of a table (or per use case which may have multiple tables), and the data against the key is atomically changed when we need to update the budget."; Rogers, §6, p.13: "In order to compute the parameters (εper, δ) that we use in each call to our algorithms2 over an entire sequence of interactions with the API, we also want to know how many queries the API will allow, denoted as l* that we term the call budget, which will effectively impact δ* ); Rogers, §1, p.2: "limit the number of accesses to the API, to prevent reconstructing the dataset, despite the noise that is added.");
(b) transmitting, to a first server that implements a first privacy budget service in which a first trusted party maintains a first instance of the privacy budge, a first request to determine whether there is sufficient privacy budget to analyze the dataset. a first request to determine whether there is sufficient privacy budget to analyze the dataset (Rogers, Fig. 1, p. 7, : Data Center 1 contains an Application, a Budget Management Service, and a Budget Manager Data Store; Fig. 1; § 4.2, p. 9: "We create one key per analyst of a table..., and the data against the key is atomically changed when we need to update the budget."; Rogers, §4, p.8: "budget management operations require a remote call to a distributed system because the budget management service needs to provide a consistent view to all application instances." =; Rogers, §4, p.7: "The application can independently invoke budget management functions, such as the following: Getting the available budget for an analyst to verify whether a query can even start to execute"; Rogers, §4.2, p.10: "To check whether an analyst’s ID has enough budget to run a query that will consume at most a given cost, we use checkBudget(ID, cost), which returns either true or false."; Rogers, §4.2, p.9: "the data against the key is atomically changed when we need to update the budget.");
(c) transmitting, to a second server that implements a second privacy budget service in which a second trusted party maintains a second instance the privacy budget, a request to determine whether there is sufficient privacy budget to analyze the dataset, wherein the second privacy budget service is independent from the first privacy budget service, and wherein the first trusted party is different from the second trusted party (Rogers, Fig. 1, p. 7, Data Center 2 contains an Application, a Budget Management Service, and a Budget Manager Data Store, the latter connected by a bidirectional arrow to the Budget Manager Data Store of Data Center 1; Rogers, §6.1, p.13–14: "the budget manager needs to be a distributed system so that it can be accessed/updated from different application execution platforms. Each analyst may access data from multiple data centers and each access must deduct from the same budget. Hence, the budget manager maintains eventual consistency across data centers."; Rogers, §4, p.8, “budget management operations require a remote call to a distributed system” because the budget management service needs to provide a consistent view to all application instances” ; Rogers, §4.2, p.10: "Espresso was chosen due to several reasons: eventual consistency in cross-datacenter replication to ensure an analyst does not exceed a given budget"; Rogers, §1.1, p.2: "our privacy budget management service that is able to track each analyst’s privacy budget over multiple data centers. Hence, we can ensure the budget is enforced across large scale systems in real-time.");
(d) receiving, from the first server, a first response indicating whether there is sufficient privacy budget, according to the first privacy budget service (Rogers, §4.2, p.10: " To check whether an analyst's ID has enough budget to run a query that will consume at most a given cost, we use checkBudget(ID, cost), which returns either true or false "; Rogers, §4, p.8: "If the budget is exhausted for an analyst then the budget management service does not allow the query to be executed and tells the application that the analyst has exhausted their entire budget.")
(e) receiving, from the second server, a response, indicating whether is sufficient privacy budget, according to the second privacy budget service (Rogers, §4.2, p.10: " To check whether an analyst's ID has enough budget to run a query that will consume at most a given cost, we use checkBudget(ID, cost), which returns either true or false " – the same interface is implemented by the budget management service in each data center (Fig. 1); Rogers, p.8: "If the budget is exhausted for an analyst then the budget management service does not allow the query to be executed and tells the application that the analyst has exhausted their entire budget."; Rogers, Fig. 1: the same Budget Management Service interface is implemented in each data center); and
(f) processing the dataset in accordance with the first response and the response (Rogers: §4, p. 8; ““Once the budget management service allows for the query to be evaluated, the application queries Pinot as it would have without the privacy system only now with the translated query … The DP library will then run the corresponding DP algorithm on the Pinot result."; pg. 8"If the budget is not depleted, yet what remains is less than the expected cost of the query, then we still do not evaluate the query."; Rogers, §6.1, p.14: "Once k* or ℓ* are depleted, we prevent the analyst from making any other queries." ).
Rogers teaches (b) transmitting, to a first server that implements a first privacy budget service in which a first trusted party maintains a first instance of the privacy budge, a first request to determine whether there is sufficient privacy budget to analyze the dataset; (c) transmitting, to a second server that implements a second privacy budget service in which a second trusted party maintains a second instance the privacy budget, a request to determine whether there is sufficient privacy budget to analyze the dataset, wherein the second privacy budget service is independent from the first privacy budget service, and wherein the first trusted party is different from the second trusted party; (d) receiving, from the first server, a first response indicating whether there is sufficient privacy budget, according to the first privacy budget service (e) receiving, from the second server, a response, indicating whether is sufficient privacy budget, according to the second privacy budget service ;(f) processing the dataset in accordance with the first response and the response.
As recited above, but Rogers does not explicitly disclose:
(c*) that the request transmitted to the second server is a second request, transmitted in addition to the first request of (b) for the same request to analyze the dataset;
(e*) that the response received from the second server is a second response, received in addition to the first response of (d) for the same request to analyze the dataset;
(f*) processing the dataset in accordance with the second response in addition to the first response.
Hockenbrocht discloses:
(c*) that the request transmitted to the second server is a second request, transmitted in addition to the first request for the same request to analyze the dataset (Hockenbroch: par. 0133, "The differentially private security system 102 accesses one or more privacy budgets"; Hockenbrocht: par. 0128, "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed." Note that Hockenbrocht determines budget sufficiency against more than one privacy budget for a single query, so that a single query occasions a second sufficiency determination against a second budget. Hockenbrocht is relied upon for this teaching only. The second server, the second privacy budget service, the second instance of the privacy budget, the independence of the two services, and the difference between the two trusted parties are each taught by Rogers as set forth above.);
(e*) that the response received from the second server is a second response, received in addition to the first response for the same request to analyze the dataset (Hockenbrocht: par. 0133, "The differentially private security system 102 accesses one or more privacy budgets relevant to the query."; Hockenbrocht: par. 0128, "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed " );
(f*) processing the dataset in accordance with the second response in addition to the first response (Hockenbrocht: par. 0128, "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed.").
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Hockenbrocht with the method and system of Rogers to include (c*) (e*), and (f*). One of ordinary skill would have been motivated to transmit a sufficiency request to, and receive a sufficiency response from, each of Rogers' two budget management services for a single request to analyze, and to process the dataset in accordance with both responses, for the following reasons.
Reason 1 - Rogers identifies the need.
Rogers maintains an instance of the same privacy budget in each of two data centers, and states the purpose expressly: "eventual consistency in cross-datacenter replication to ensure an analyst does not exceed a given budget" (Rogers, §4.2, p.10). Rogers also identifies the condition that puts that purpose at risk: "Each analyst may access data from multiple data centers and each access must deduct from the same budget. Hence, the budget manager maintains eventual consistency across data centers" (Rogers, §6.1, pp.13–14), and an analyst "may be initially assigned one data center… but can migrate to a different one" (Rogers, Fig. 1 caption). Because consistency across the two instances is only eventual, an analyst who migrates may be served by an instance whose state has not yet converged. Consulting each instance before permitting the query addresses that condition and directly serves Rogers' stated objective.
Reason 2 - Hockenbrocht supplies the technique and states its purpose.
Hockenbrocht performs the query only when the accounting for each budget is within its limit: "the sums…associated with each privacy budget…are each less than the maximum…the query is performed" (Hockenbrocht: par. 0135). Hockenbrocht further states that a single budget being within its limit is not sufficient: "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed" (Hockenbrocht: par. 0128). Hockenbrocht thus teaches determining sufficiency against each budget accessed for a query and permitting the query only when each is sufficient — the technique Rogers lacks for its second instance.
Reason 3 - the combination yields predictable results.
Both references are directed to enforcing a strict privacy budget on queries against a dataset so that the dataset cannot be reconstructed through repeated querying. Rogers already maintains an instance of the same budget in each of two data centers, each implementing the same sufficiency interface — "checkBudget(ID, cost), which returns either true or false" (Rogers, §4.2, p.10). Applying Hockenbrocht's technique of determining sufficiency against each budget before performing the query requires no modification of Rogers' architecture and produces a predictable result: two sufficiency responses rather than one, with the query performed only when both indicate sufficiency. This is the combination of prior art elements according to known methods to yield predictable results, and the use of a known technique to improve a similar system in the same way. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 416–421 (2007).
Regarding claim 2, the combination of Rogers and Hockenbrocht teaches the method of claim 1. The combination of Rogers and Hockenbrocht further teaches, wherein the processing includes:
determining that the first response and the second response both indicate there is sufficient privacy budget (Rogers: page 10, teaches that the budget management service determines whether sufficient budget exists via the checkBudget (ID, cost) function call which returns true or false; Hockenbrocht: par. [0135], "the sums...associated with each privacy budget...are each less than the maximum privacy spend...the query is performed."); par. [0128], teaches that "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed."); and
in response to the determining, analyzing the dataset and storing the results of the analyzing (Hockenbrocht: par. [0135], teaches that when both budget instances confirm sufficiency, the query is performed; Rogers: Figure 1, Data Store, page 9, Section 4.2 Espresso store).
Regarding claim 3, the combination of Rogers and Hockenbrocht teaches the method of claim 1. The combination of Rogers and Hockenbrocht further teaches wherein the processing includes:
analyzing the dataset (Rogers: page 6, "The application entity, based on the request received from the analyst, generates queries to the underlying database.");
determining that the first response and the second response both indicate there is sufficient privacy budget (Rogers: page 10, teaches that the budget management service determines whether sufficient budget exists via the checkBudget (ID, cost) function call which returns true or false; Hockenbrocht: par. 0135, "the sums...associated with each privacy budget...are each less than the maximum privacy spend...the query is performed."; par. 0128, further teaches that "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed."); and
in response to the determining, storing the results of the analyzing (Rogers: discloses an explicit Data Store component in its system architecture (Rogers, Figure 1) and uses an Espresso key-value store for data management. (Rogers, page 9.); Hockenbrocht: par. [0135], teaches that when BOTH budget instances confirm sufficiency, the query is performed and results are produced).
Regarding claim 5, the combination of Rogers and Hockenbrocht teaches the method of claim 1. The combination of Rogers and Hockenbrocht further teaches, wherein the processing includes:
determining that the first response indicates there is sufficient privacy budget and that the second response indicates there is insufficient privacy budget (Rogers: page 10, teaches that the budget management service determines whether sufficient budget exists via the checkBudget (ID, cost) function call which returns true or false; Hockenbrocht: par. 0128, "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed."; par. 0136, "if, for at least one privacy budget, the sum...is greater than the maximum privacy spend...a security action is performed."); and
in response to the determining, refraining from analyzing the dataset (Rogers: page 8, "does not allow the query to be executed."; Hockenbrocht: par. 0136, "a security action can include rejecting the query.").
Regarding claim 6, the combination of Rogers and Hockenbrocht teaches the method of claim 1. The combination of Rogers and Hockenbrocht further teaches wherein the processing includes:
analyzing the dataset (Rogers: page 6, "The application entity, based on the request received from the analyst, generates queries to the underlying database.").
determining that the first response indicates there is sufficient privacy budget and that the second response indicates there is insufficient privacy budget (Rogers: page 10, teaches that the budget management service determines whether sufficient budget exists via the checkBudget (ID, cost) function call which returns true or false; Hockenbrocht: par. 0128, "just because a privacy budget associated with one of a user and a group is not exceeded by a query doesn't guarantee that the query will be processed."; par. 0136, "if, for at least one privacy budget, the sum...is greater than the maximum privacy spend...a security action is performed."); and
in response to the determining, refraining from storing the results of the analyzing (Rogers: fig. 1, discloses an explicit Data Store component in its system architecture and uses an Espresso key-value store for data management; page 8, "does not allow the query to be executed."; Hockenbrocht: par. 0146, teaches that when at least one budget instance indicates insufficient, a security action is performed .. "providing a complete or partial set of query results to the client device while notifying the administrator or database manager that the query exceeded the maximum privacy spend.").
Regarding claim 7, the combination of Rogers and Hockenbrocht teaches the method of claim 1. The combination of Rogers and Hockenbrocht teaches wherein the processing includes:
determining that the first response and the second response both indicate there is insufficient privacy budget (Rogers teaches that the budget management service determines whether sufficient budget exists via the checkBudget(ID, cost) function call which returns true or false — false indicating insufficient budget. (Rogers, p. 10.) Hockenbrocht: par. 0135, a system maintaining two independent privacy budget instances — a personal budget and a group budget — and explicitly requires that EACH budget instance be evaluated before processing is permitted; Hockenbrocht: par. 0135, "the sums...associated with each privacy budget...are each less than the maximum privacy spend...the query is performed." "if, for at least one privacy budget, the sum...is greater than the maximum privacy spend...a security action is performed."); and
(b)in response to the determining, refraining from analyzing the dataset (Rogers: page 8, "does not allow the query to be executed.")
Regarding claim 8, the combination of Rogers and Hockenbrocht teaches the method of claim 1. The combination of Rogers and Hockenbrocht further teaches, wherein the processing includes:
analyzing the dataset (Rogers: page 6, "The application entity, based on the request received from the analyst, generates queries to the underlying database.");
determining that the first response and the second response both indicate there is insufficient privacy budget (Rogers teaches that the budget management service determines whether sufficient budget exists via the checkBudget (ID, cost) function call which returns true or false (Rogers, p. 10.); Hockenbrocht: par. 0135, teaches a system maintaining two independent privacy budget instances — a personal budget and a group budget; Hockenbrocht: par. 0135, "the sums...associated with each privacy budget...are each less than the maximum privacy spend...the query is performed."; par. 0136, "if, for at least one privacy budget, the sum...is greater than the maximum privacy spend...a security action is performed."); and
in response to the determining, refraining from storing the results of the analyzing (Rogers: fig. 1, discloses an explicit Data Store component in its system architecture and uses an Espresso key-value store for data management (Rogers, page 9); page 8, "does not allow the query to be executed."; Hockenbrocht: par. 0146, teaches that when at least one budget instance indicates insufficient, a security action is performed .. "providing a complete or partial set of query results to the client device while notifying the administrator or database manager that the query exceeded the maximum privacy spend.").
Regarding claim 10, the combination of Rogers and Hockenbrocht teaches the method of claim. The combination of Rogers and Hockenbrocht further teaches, wherein transmitting the first request includes: transmitting the first request via an application programming interface (API) call to the first privacy budget service (Rogers: page 2, we need to implement a budgeting tool into the API so that analysts cannot repeatedly query the dataset thus making noise addition pointless." ;page 8,“remote call to distributed system”; Section 4.2, page 10, "To check whether an analyst's ID has enough budget to run a query that will consume at most a given cost, we use checkBudget (ID, cost), which returns either true or false ")
Regarding claim 11, claim 11 is directed to a computing system for managing privacy budgets, the computing system comprising: one or more servers (Rogers: fig. 1; page 9, servers) ; and a non-transitory computer-readable medium (Rogers: fig. 1) storing instructions thereon that, when executed by the one or more servers associated with the method claimed in claim 1; claim 11 is similar in scope to claim 1, and is therefore rejected under similar rationale.
Regarding claim 12, claim 12 is similar in scope to claim 2, and is therefore rejected under similar rationale.
Regarding claim 13, the combination of Rogers and Hockenbrocht teaches the computing system of claim 11. The combination of Rogers and Hockenbrocht further teaches, wherein, to process the dataset, the instructions cause the computing system to:
determine that at least one of the first response or the second response indicates there is insufficient privacy budget (Rogers: page 10, teaches that the budget management service determines whether sufficient budget exists via the checkBudget (ID, cost) function call which returns true or false; Hockenbrocht: par. 0136, "if, for at least one privacy budget, the sum...is greater than the maximum privacy spend...a security action is performed."; par. 0135, "the sums...associated with each privacy budget...are each less than the maximum privacy spend...the query is performed"); and
in response to the determining, refrain from analyzing the dataset (Rogers: page 8, "does not allow the query to be executed.").
Regarding claim 15, claim 15 is similar in scope to claim 10, and is therefore rejected under similar rationale.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Ryan Rogers et al. (“Rogers,” Linkedln’s Audience Engagemetns API: A Privacy Preserving Data Analytics System at Scale, November 17, 2020, pages 1-28), in view of Hockenbrocht et al. (“Hockenbrocht,” US 2019/0318121), further in view of Bernau et al. (“Bernau,” US 10,380,366).
Regarding claim 4, the combination of Rogers and Hockenbrocht teaches the method of claim 2. The combination of Rogers and Hockenbrocht, further teaches comprising:
causing the first privacy budget service and the second private budget service to decrement the first instance of the privacy budget and the second instance of the privacy budget (Rogers: page 8, " If the budget is not depleted, yet what remains is less than the expected cost"; Rogers: Section 6.1, pages 13-14 "each access must deduct from the same budget."; Hockenbrocht, par. 0134, "for each privacy budget, the privacy spend associated with the query is added to the cumulative spend to determine if the sum exceeds the maximum privacy spend."; pars. [0125]-[0126], [0134], Hockenbrocht teaches both the personal budget 1225A and group budget 1235A are each independently updated per query) but does not explicitly disclose “atomically”.
However, in an analogous art, Bernau teaches a privacy budget management system in which privacy budget balance updates are recorded via a distributed ledger (Bernau: abstract, updates the balance for the privacy budget in the distributed ledger) Bernau further teaches that the privacy budget and associated data are stored in distributed ledger (Bernau: abstract, "a privacy budget for the data offer...stored in the distributed ledger).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bernau with the method and system of Rogers and Hockenbrocht to include “automatically”. One would have been motivated to ensure atomic all-or-nothing updates across distributed nodes (Bernau: abstract) One of ordinary skill in the art a reading Rogers' requirement for consistent cross-datacenter budget deduction and Hockenbrocht's requirement that each independent budget instance be decremented per query would have been motivated to apply Bernau's atomic distributed ledger update technique to ensure that both the first and second budget instances are decremented atomically — preventing the budget inconsistency that would result if one instance were decremented but the other were not due to a system failure between the two decrements. The combination yields predictable results with no unexpected outcomes. KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007).
Claim 9 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ryan Rogers et al. (“Rogers,” Linkedln’s Audience Engagemetns API: A Privacy Preserving Data Analytics System at Scale, November 17, 2020, pages 1-28), in view of Hockenbrocht et al. (“Hockenbrocht,” US 2019/0318121), further in view of Frank McSherry (“McSherry,” Privacy Integrated Queries An Extensible Platform for Privacy-Preserving Data Analysis, 2009, pages 1-20).
Regarding claim 9, the combination of Rogers and Hockenbrocht teaches the method of claim. The combination of Rogers and Hockenbrocht discloses dataset, the first privacy, and receiving the request to process the dataset but does not explicitly disclose wherein: “the dataset is included in a group of datasets,” “the privacy budget is defined for the group of datasets” and “receiving the request to process the dataset includes receiving a request to process the group of datasets.
However, in an analogous art, McSherry discloses
the dataset is included in a group of datasets (McSherry: page 19, Col. 2, integrated multiple independent data sources”; page 20, Col. 1, Data providers can use Privacy Integrated Queries (PINQ) to wrap arbitrary LINQ data sources), and
the privacy budget is defined for the group of datasets (McSherry: page 20, Col. 2, Data providers can use PINQ to wrap arbitrary LINQ data sources with a specified privacy allotment for each analyst.)
receiving the request to process the dataset includes receiving a request to process the group of datasets (McSherry: page 19, Col. 2, “analyses integrating multiple independent data sources”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of McSherry with the method and system of Rogers and Hockenbrocht to include the dataset is included in a group of datasets, the privacy budget is defined for the group of datasets and receiving the request to process the dataset includes receiving a request to process the group of datasets . One would have been motivated to organize multiple data sources under a single privacy allotment – a natural and well-known database management technique. The combination yields predictable result no unexpected outcomes. KSR Int’l Co. v. Teleflex., 550 U.S. 398 (2007).
Regarding claim 14, claim 14 is similar in scope to claim 9, and is therefore rejected under similar rationale.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
August 25th, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights