DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the amendment filed on March 20th, 2026. The amendments are linked to the original application filed on April 19th, 2022.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 20th, 2026, has been entered.
Response to Amendment
Regarding Claim Rejections – 35 U.S.C. 101 Rejection
The applicant has stated three different arguments against the proposed 101 rejection. The applicant states, “The claims (a) do not recite an abstract idea, under Step 2A, Prong 1, (b) incorporate any alleged abstract idea into a practical application under Step 2A, Prong 2, and (c) recite additional elements that amount to significantly more than any abstract idea, under Step 2B.”.
Regarding argument (a), the applicant states that the amended claims 1, 15, and 20 do not recite an abstract idea. The applicant then argues the three different limitations in these claims that the examiner has identified as abstract ideas. Accordingly, the applicant states limitation (1) has been removed and limitations (2) and (3) do not recite abstract ideas.
Regarding limitation (2), the applicant states the claimed amended limitation would be impossible to perform in a human mind because the machine learning model would be difficult or impossible to develop and maintain in the mind. Further, applying a machine learning model required accessing information stored within a computing system. The examiner has reviewed the remarks and amended claims and finds the applicants’ arguments persuasive and the amended limitations to be appropriate. Therefore, the examiner does not consider limitation (2) to be an abstract idea.
Regarding limitation (3), next the applicant argues that the amened limitation (3) recites a process which cannot be performed in a human mind because the operational environment is impossible for a human to operate, or perform, the claimed process in. The examiner has reviewed the remarks and the amended claims and finds the applicants’ argument persuasive. The examiner agrees the claimed process could not be performed in a human mind or with pen and paper. Further, even with the broadest reasonable interpretation, the applicant has amended the limitation to no longer recite an abstract process. Therefore, the examiner does not consider this limitation to be an abstract idea.
Regarding remaining arguments (b) an (c), the examiner has reviewed amended claims 1, 15, and 20 and has found the current amendments further define the claims to no longer recite mental process or abstract ideas. Per the Alice/Mayo test, this would result in a pass for step 2A, Prong 1 and would mean the current amended claims recite patent eligible subject matter. Because of this there is no further reasons for the examiner or the applicant to argue steps 2A, Prong 2 or Step 2B. regardless, the arguments made by the applicant were reviewed and considered as well and the examiner has withdrawn the rejection under 35 U.S.C. 101.
Regarding Claim Rejections – 35 U.S.C. 103 Rejection
The applicant argues that Bansal, in view of Bhandarkar, fails to teach the amended claims 1, 15, and 20. The applicant argues that the ML model in Bansal and the claimed model train their models on different training information and as a result both models produce different types of results, and the applicant provides further supporting arguments.
First, the applicant argues, “the historical model in Bansal predicts throughput data and not maximum request rates.”. The examiner respectfully disagrees. Basal (Detailed Description, pp. 3, [0028]) states: “The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org.” (emphasis added). As stated in the specification, Bansal does not predict throughput of an organization, but predicts a rate limit, which represents the maximum amount of access an organization has to a shared resources or server.
Next, the applicant argues, “the historical model in Bansal is trained on throughput data, not on records of maximum request rate modifications.”. The examiner respectfully disagrees. Bansal (Detailed Description, pp. 2, [0022]) states, “Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).”. As stated in the specification, Bansal discloses a model that is trained using historical data which is first processed by a log analyzer. However, as stated, other types of log information can be used, including maximum number of requests per a unit of time. The examiner would like to note that the number of requests in this section is different than throughput data as described by the applicant. The number of requests relates to a number indicating the n number of times a client has made a request. Throughput relates to the amount of information the that can be, or has been, transferred between two sources.
Next, the applicant argues that model in Bansal is not equivalent to the claimed model which “trains on cryptographically encoded distributed ledger records of historical maximum request rate modifications to predict a client-specific maximum request rate for a future time period.”. The examiner does not disagree with this statement. The examiner would like to point out that Bansal does not teach or disclose information on blockchains or distributed legers. Bansal merely recites a system that is able to use log information from clients, their request rates and times and produces a prediction to maximum rate which the clients can request from a shared resources such as a server. However, the claims are evaluated using the BRI per MPEP 2111. Using the BRI of the claim limitations, additional art can be used to teach the block chain and the storage of information in a cryptographically encoded blockchain. Further examples of encrypted blockchains is common, see Barger et al. A block chain is similar to a standard database, the main difference is a blockchain is considered a distributed database where each user has a copy of the data. Blockchains are merely storage schemes which can be applied in many different fields of computer science, including storing training data for machine learning models.
Next, the applicant argues that “Bansal cannot support a rejection of Claims 1, 15, and, 20” and “A rejection that relies on a reference describing training a historical model on throughput data to predict an organization's future throughput as an equivalent of training a model on historical maximum request rate data to predict a maximum request rate clearly violates MPEP 2144.06.”. The examiner respectfully disagrees. As stated above, the ML model in Basal does not output a prediction of an organization’s throughput, the model in Bansal outputs a rate limit which is used set maximum request rate for an organization for a period of time. This is fundamentally similar to the claimed invention which claims, “applying the trained machine learning model [i.e. Model proposed and trained in Bansal] to a set of input data [i.e. logged data to be analyzed by the log analyzer] including characteristics of a first target time period [historical data disclosed in Bansal [0022]] to determine a first maximum request rate for requests from the first client for the first target time period; [Historical model in Bansal outputs a rate limit]”. Therefore, the examiner does not believe this violates the MPEP and instead the BRI of some of the claim limitations can be taught in Bansal.
Next, the applicant argues that Bhandarkar fails to disclose request handling gateway as claimed in claims 1, 15, and 20. Further the applicant argues, “The static request rate limit represents "the maximum number of requests that the software component is able to process ... " (Bhandarkar, para. 33). Bhandarkar describes continually computing a throttling rate but not modifying the request rate limit.” And “The request rate limit in Bhandarkar is not a configurable value that can be configured per-client based on validated ledger records. Accordingly, Bhandarkar cannot disclose reconfiguring a request handling gateway to enforce a modified maximum request rate against a client's requests based on validating an encrypted ledger record, as recited in claims 1, 15, and 20.”. The examiner has evaluated the prior art and amended claims and finds this argument persuasive. As the claims have been amended, Bhandarkar fails to teach amendments as the scope of the claims have changed. The examiner agrees with the applicant and believes that Bhandarkar fails to teach key elements of amended claims and no longer relies on Bhandarkar as prior art.
Next, the applicant argues that Shahnaz fails to teach the missing elements of Bansal and Bhandarkar. Further stating, “However, nothing in Shahnaz suggests using distributed ledger entries to train a machine learning model or configuring a request handling gateway based on validating an encrypted ledger record, as recited in claims 1, 15, and 20.”. As stated by the applicant, Shahnaz is not relied upon to teach the missing elements form Banal or Bhandarkar, however the examiner does agree with the applicant and finds the argument persuasive. Shahnaz does disclose s generic Block chain system however Shahnaz fails to teach the added amended claims. Therefore, the examiner believes that Shahnaz fails to teach the missing elements and amendments and no longer relies on Shahnaz to teach claim limitations.
Finally, the applicant argues one of ordinary skill in the art would not have motivation to combine the arts Bansal, Bhandarkar and Shahnaz. As stated above, the examiner no longer relies on Bhandarkar and Shahnaz to teach elements of the amended claims. Therefore, any further argument or motivation to combine these arts is moot. However, after each amendment submitted the claims are revaluated and a complete and thorough search is completed by the examiner. During this reevaluation and search, the examiner was able to discover new art. The examiner believes the combination of prior art on record and the newly discovered art teaches the claimed subject matter. Further, the examiner believes a person of ordinary skill in the art would be motivated to use concepts from the arts on record to reproduce the claimed system. Therefore, the rejection under 35 U.S.C. 103 has been upheld, see 103 rejections below.
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-11 and 15-24 are rejected under 35 U.S.C. 103 as being unpatentable over Bansal et al, (Bansal et al, “PREDICTIVE RATE LIMITING SYSTEM FOR CLOUD COMPUTING SERVICES”, US 2021/0234890 A1, Filed 2020, hereinafter “Bansal”) in view of Barger et al, (Barger et al, “LIMITING DATA AVAILABILITY ON DISTRIBUTED LEDGER”, US 2022/0393858 A1 Filed 2021, hereinafter “Barger”).
Regarding claim 1, Bansal discloses, “A non-transitory computer readable medium comprising instructions which, when executed by one or more hardware processors cause performance of operations comprising:” (Detailed Description, pp. 5, [0048]; "FIG. 6 illustrates an example of a storage medium 600. Storage medium 600 may comprise an article of manufacture. In some examples, storage medium 600 may include any non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage. Storage medium 600 may store various types of computer executable instructions, such as instructions 602 to implement logic flows described above in FIGS. 1 through 4." This method proposed can be stored on memory devices as listed above. These instructions can be used to perform the operations listed in the other figures.)
“training a machine learning model to predict a maximum request rate for a target time period,” (Detailed Description, pp. 3, [0028]; “The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org.” Bansal discloses a historic machine learning model that will predict a rate limit for a particular client or organization.) And (Detailed Description, pp. 2, [0018]; “Historical data model generator 138 obtains historical data from log services 136 regarding previously processed requests for services and generates a historical data model for use by reverse proxy 122 in processing rate limiting requests to access services.” The Historic data model generator generates a model used to predict rate limits for customers. As disclosed in the specification the historical data is historical rate data from customers in a given period of time.)
“the maximum request rate corresponding to a maximum number of requests in a particular period of time that clients are permitted to initiate to access a shared resource, the training comprising:” (Detailed Description, pp. 2, [0022]; “Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This model is able to evaluate log data which includes evaluating max request rates from given clients for a period of time.)
“wherein the historical maximum request rate modification records are associated with at least one client among a plurality of clients, each historical maximum request rate modification record comprising:” (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” Bansal contains historical log data of different clients in a standard database. This data contains user information including request rates during specified times as well as max or minimum pull rates.)
“(a) a new maximum request rate for the at least one client and (b) characteristics of a period of time corresponding to the historical maximum request rate modification record,” (Detailed Description, pp. 3, [0027]; "Historical data model 214 is used to capture the time-sensitive and/or seasonality of incoming request traffic from clients and/or organizations." A model is used to capture the request rates and time of clients.) and (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical data used contains the rate limit of each client which would under the broadest reasonable interpretation be the maximum rate for that client.) and (Detailed Description, pp. 3, [0027]; "Historical data model 214 is used to capture the time-sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The historical data used contains time data. Bansal does not train it models from ledger data but use a database stored in memory as the data structure to hold the historical data.)
“training the machine learning model based on the set of maximum historical request rate modification records to generate a trained machine learning model;” (Detailed Description, pp. 4, [0039]; "At block 402, model generator 212 divides data 210 into a training data set, a cross-validation data set and a testing data set. At block 404, model generator selects a first machine learning model from a plurality of available machine learning models (e.g., artificial neural networks, decision trees, support vector machines, regression analysis, Bayesian networks, genetic algorithms, and so on). At block 406, model generator 212 trains the selected model on the training data set. At block 408, model generator 212 tunes one or more hyper-parameters for the model using the cross-validation data set." The historical model is trained on historical data. This data contains request rates and time data. The historical data is divided and used to train and tune the historical model. The component is called a model generator and as stated above, this will generate and train a machine learning model to be used by the system.)
“applying the trained machine learning model to a set of input data including characteristics of a first target time period to determine a first maximum request rate for requests from the first client for the first target time period;” (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical model, which is selected and trained by the model generator, Intakes historical data from the log analyzer to determine the request rate of a client. This rate is only for a given amount of time, such as a portion of a day or week.)
“modifying a configuration of a request handling gateway associated with the shared resource to modify the handling of requests from the first client,” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” This system is able to evaluate a user’s current request limit and, using historical data, generate a new request rate based on this inference. Once a new rate is determined the rate enforcer is updated in the system for a given user.)
“wherein modifying the configuration of the request handling gateway comprises modifying a particular maximum request rate for the first client from a second maximum request rate to the first maximum request rate,” (Detailed Description, pp. 4, [0038]; “FIG. 3 is a flow diagram 300 of example rate enforcer 202 processing according to some embodiments. At block 302, rate enforcer 202 receives a request for service from router 118. In an embodiment, the request includes an identifier of the org requesting one of services 124-126. At block 304, rate enforcer 202 gets a current threshold to be used for the org from concept drift detector 206. In another embodiment, rate enforcer 202 stores current thresholds received from concept drift detector 206 for one or more orgs internally and selects the current threshold for the org currently identified by the request. In an embodiment, each org has its own threshold.” This system includes a rate enforcer module. This will evaluate requests from clients and enforce rate limits. This system can receive updates the request rates of clients from different systems sources such as the historical data model and the concept drift detector.)
“wherein based on the configuration, the request handling gateway rejects and/or generates a notification corresponding to a request initiated by the first client that would result in a number of requests for the first target time period exceeding the first maximum request rate.” (Detailed Description, pp. 4, [0037]; “Rate enforcer 202 processes a request received from a client via router 118 before forwarding the request, if approved according to real time data model 204 and historical data model 214, to a selected service. Rate enforcer 202 validates whether the rate limit for a given client is reached or not. Rate enforcer 202 drops requests for an organization if the requests cause the organization to exceed the currently specified rate limit for the organization. If the rate limit is not reached, rate enforcer 202 forwards the request.” Bansal includes a rate enforcer module that is able to evaluate clients’ requests and determine if the request exceeds the stored rate threshold. This system is able to determine whether to allow or reject the request for service from the client.) And (Detailed Description, pp. 4, [0038]; “At block 306, if performance of the request by one of services 124-126 would cause the current threshold to be exceeded, then the request is denied at block 310 and an error message is sent back to the requesting client. In an embodiment, the error message includes a "HTTP 429-too many requests" message. The error message notifies the requesting client of the performance backlog so that the client can reschedule the request for a later point in time.” This is an example where they rate enforcer will generate a notification if the current rate for the client is exceeded or will be exceeded after the service is provided.)
Bansal alone fails to explicitly disclose:
“accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;”
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;”
“publishing the encrypted distributed ledger record to the cryptographically encoded distributed ledger; and”
“based on determining the cryptographically encoded distributed ledger validated the encrypted distributed ledger record,”
However, Barger discloses, “publishing the encrypted distributed ledger record to the cryptographically encoded distributed ledger; and” (Detailed Description, pp. 3, [0037] “In the example embodiments, a publisher of content (e.g., a user, a client, a blockchain peer, etc.) of a distributed ledger (e.g., a blockchain ledger, etc.) may encrypt content prior to publishing/storing the content on the distributed ledger. For example, the content may remain confidential while stored on the distributed ledger unless another entity is in possession of the encryption key (or corresponding decryption key) necessary to decrypt the encrypted content. A user in this system is able to publish a new block to the block chain, which is encrypted.)
“based on determining the cryptographically encoded distributed ledger validated the encrypted distributed ledger record,” (Detailed Description, pp. 13, [0142]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” This system uses an encoded block chain and is able to store different forms of data and validate that data with other users in the network.)
Barger alone fails to explicitly disclose:
“accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;”
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;”
The combination of Bansal and Barger disclose, “accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”. Bansal discloses, (Detailed Description, pp. 2, [0021]; “In an embodiment, log analyzer 208 runs "cron" jobs which run predefined Domain Specific Language (DSL) based queries on metrics collected by log services 136 to generate a database of historical data 210. Historical data 210 can then be used as an input for historical data model generation. Log analyzer 208 parses log information included in the collected metrics.” Bansal uses a historical log storage system to store their historical data used to train system models. This log is a form of memory or database which is accessed by the system to perform system tasks such as rate limiting.) Barger discloses, (Detailed Description, pp. 8, [0086]; “FIG. 5 illustrates a method 500 of limiting data availability on a blockchain ledger according to exan1ple embodiments. For example, the method 500 may be performed by a client, a blockchain peer, a smart contract, a server, or the like. Referring to FIG. 5, in 510, the method may include encrypting content with an encryption key to generate encrypted content. In some embodiments, the encryption key may be a symmetric encryption key that can be used to decrypt the content. In 520, the method may include storing the encrypted content on a distributed ledger.” This system uses a distributed database or blockchain. A blockchains can be used in place of standard databases located on computing systems. This is a system which discloses the use of an encrypted ledger to limit access to shared resources. This art does not disclose rate limiting; however, the concepts of this article can be used in combination of rate limiting. This article is used to disclose standard blockchain architecture.)
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” Bansal contains historical log data of different clients in a standard database. This data contains user information including request rates during specified times as well as max or minimum pull rates.) Barger discloses, (Detailed Description, pp. 9, [0095]; “The plurality of blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes/ peers may be present in the blockchain network including endorsing peers which simulate and endorse transactions proposed by clients and committing peers which verify endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 may perform the role of endorser node, committer node, or both.” This article discloses a standard block chain which is a distributed database. This system, or block chain concept, can be swapped with a standard database system for all users to ensure data transparency and accuracy.)
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system, as stated above, stores client and historical request data in a standard database. The data logged contains user information and historical data.) Barger discloses, (Detailed Description, pp. 3, [0037]; “In the example embodiments, a publisher of content (e.g., a user, a client, a blockchain peer, etc.) of a distributed ledger (e.g., a blockchain ledger, etc.) may encrypt content prior to publishing/storing the content on the distributed ledger. For example, the content may remain confidential while stored on the distributed ledger unless another entity is in possession of the encryption key (or corresponding decryption key) necessary to decrypt the encrypted content.” As stated above, this system discloses a standard encrypted blockchain. This system can be used to store data including individual client data and their data, such as historical use data.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the present application to combine Bansal and Barger. Basal teaches a system that is able to evaluate users historical usage data and evaluate and set maximum request rates for a particular user to a shared resource. Barger teaches a system which uses a blockchain to as a database to store transactions. One of ordinary skill would have motivation to combine a system which is able to evaluate and set request limits of a shared resource using historical data which is stored in a database and swap the database with a blockchain to store the transactions and train systems used the stored data, “This application can utilize a ledger that is a sequenced, tamper-resistant record of all state transitions of a blockchain. State transitions may result from chain code invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participating party (such as a peer node) can maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands, such as creates, updates, deletes, and the like. The ledger includes a blockchain (also referred to as a chain) which is used to store an immutable, sequenced record in blocks. The ledger also includes a state database which maintains a current state of the blockchain.” (Barger, Detailed Description, pp. 2, [0034]).
Regarding claim 2, Bansal discloses, “wherein the operations further comprise: receiving a new maximum request rate modification record;” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” This system uses real-time and historic models to evaluate predicted rates for clients based on their transactions and rates over time or in real time. When the system finds a new rate for a client the rate enforcer module is updated.)
“re-training the machine learning model based on the set of maximum historical request rate modification records and the new maximum request rate modification record to generate a re-trained machine learning model;” (Detailed Description, pp. 2-3, [0024]; "Over time the historical data models can become stale and the predictions may no longer be accurate. This situation requires a re-training phase which can be done in at least one of two ways. First, in one embodiment, a cron-based service can be started where historical data model 214 is re-trained on a predetermined fixed time schedule (e.g., once every few hours, once per day, etc.)." Once the historical model can be retrained on newer historical data. This retraining can be based on concept drift or part of a regular schedule. This retraining is designed to produce a new retrained and more accurate model) and (Detailed Description, pp. 3, [0024]; “Training (and re-training) of historical data model 214 is expensive from the standpoint of the time needed and computational resources consumed. Thus, training (and re-training) are to be performed only when necessary according to a measure of staleness.” This discloses that the models used for predicting max rates for clients are retrained to improve accuracy.)
“identifying characteristics of a second target time period for determining a second maximum request rate for the first client; and” (Detailed Description, pp. 3, [0027]; "Historical data model 214 captures this temporal behavior (e.g., client requests on certain days of the week) and accordingly predicts when an organization will become active based on past behavior. This is advantageous because if the historical data model gives an indication that an organization is about to send a burst of requests, bandwidth can be reserved on behalf of an org by rate enforcer 202 for the upcoming expected burst and bandwidth can be temporarily reduced for organizations predicted to be dormant during the expected burst." This system is able to identify different client system usage datapoints over a period of time and use that temporal data to generate predictions using the historical data model.)
“applying the re-trained machine learning model to the characteristics of the second target time period to determine the second maximum request rate for requests from the first client for the second target time period.” (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical model, which is selected and trained by the model generator, Intakes historical data from the log analyzer to determine the request rate of a client.) And (Detailed Description, pp. 4, [0034]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214." The concept drift detector will trigger an alert for when the historical model needs to be retrained or replaced. Therefore, the process of training the historical model is the same as the retraining process.) and (Detailed Description, pp. 3, [0028]; “The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org.” This system is able to reuse the trained model to produce predictions.)
Regarding claim 3, Bansal alone fails to explicitly disclose the limitations in this claim. However, Barger discloses, “wherein the plurality of system nodes maintain a respective plurality of copies of the cryptographically encoded distributed ledger.” (Detailed Description, pp. 14, [0150]; “This transaction record is then sent to all other nodes where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854-860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to every transaction making it exceedingly difficult to tamper with. Each node checks their entries with respect to a local copy of the blockchain 852 to verify that each transaction has sufficient funds. However, the transactions are not yet confirmed.” This system employs a standard block chain. In a block chain, each user has their own copy of the block chain.)
Barger alone fails to explicitly disclose:
“wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and”
However, the combination of Bansal and Barger discloses, “wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and”. Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system uses historical data for each client to determine a maximum request rate. This system uses historical data from a given user as well as the usage patterns.) Barger discloses, (Detailed Description, pp. 13, [0142]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” This system uses consensus mechanisms to determine if newly broadcast blocks from other users should be added to a client’s personally stored block chains.)
Regarding claim 4, Bansal discloses, “wherein each ledger entry in the target set of ledger specifies: (a) the first client, (b) a particular historical modification to the maximum request rate for the first client, and (c) time data associated with the particular historical modification to the maximum request rate for the first client.”
Bansal alone and Barger alone fail to explicitly disclose:
“wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and”
However, the combination of Bansal and Barger disclose, “wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). This model uses historical log data, which is data generated by a user at a given time, to determine the request rate of that user.) Barger discloses, (Detailed Description, pp. 2, [0031]; “The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers.” Since Bansal does not use Block chains, the examiner relies on Barger to teach an encrypted block chain. As stated previously, a block chain is merely a distributed database designed to store data. This is fundamentally similar to a standard database containing various entries.)
Regarding claim 5, Bansal discloses, “based on determining the first maximum request rate for requests from the first client for the first target time period:” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.) and (Detailed Description, pp. 2, [0020]; "Log services 136 collect metrics about requests and services performed by service provider 120. In an embodiment, metrics include processing log information accumulated from one or more services." The historical data logged can contain information about the number of requests. This can also include data about the changing request and pull rates overtime.) and (Detailed Description, pp. 2, [0021]; "Historical data model 214 is used to capture the time sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The data stored by the log analyzer can contain time data as well. As listed on the previous limitation this data can consist of changes in pull or request rates.)
“generating a candidate ledger entry specifying: (a) the first client, and” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.)
“(b) the first maximum request rate; and” (Detailed Description, pp. 2, [0022]; “Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system is able to use historical data to produce a max rate for a given client. This training data can include a given client and max rate limits.)
Bansal fails to explicitly disclose:
“broadcasting the candidate ledger entry to the plurality of system nodes.”
However, Barger discloses, “broadcasting the candidate ledger entry to the plurality of system nodes.” (Detailed Description, pp. 10, [0102]; “When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 724. When the committing peer validates the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set.” A block chain requires users to add new blocks to the chain. When this occurs, a user will broadcast the addition to their block chain to other user nodes for validation and updating of their block chains.)
Regarding claim 6, Bansal discloses, “setting, by a shared resource manager, the maximum request rate associated with the client to the first maximum request rate.” (Detailed Description, pp. 4, [0035]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214. Concept drift detector 206 dynamically determines the rate limit (e.g., current threshold) for an org (e.g., a client) that rate enforcer 202 uses to approve or deny routing of requests to services." The concept drift detector will take data from the historical model and the real time data model to determine a current threshold. When the model suggests an update, the current threshold stored by the rate enforcer would be updated.)
Bansal fails to explicitly disclose:
“based on broadcasting the candidate ledger entry to the plurality of system nodes: validating, by at least one of the plurality of system nodes executing operations specified by the consensus algorithm, the candidate ledger entry;”
“broadcasting, by the at least one of the plurality of system nodes, a new ledger entry based on the candidate ledger entry;”
“adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger; and”
However, Barger discloses, “based on broadcasting the candidate ledger entry to the plurality of system nodes: validating, by at least one of the plurality of system nodes executing operations specified by the consensus algorithm, the candidate ledger entry;” (Detailed Description, pp. 10, [0102]; “In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724.” As stated above, block chains are updated after a new block is added to a user’s own block chain. That user will broadcast the updates to other nodes or clients in the network.) and (Detailed Description, pp. 13, [0143]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” Once a client or node receives an update to the block chain, the system will use consensus mechanisms to ensure the update is valid. If it is valid then the new block is added to a block chain, and the cycle continues until each node contains identical copy of the block chains.)
“broadcasting, by the at least one of the plurality of system nodes, a new ledger entry based on the candidate ledger entry;” (Detailed Description, pp. 10, [0102]; “In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724.” As stated above, broadcasting of a new block to a block chain is common practice. This is how each node will update with new information or blocks.)
“adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger; and” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block.” A block chain usually adds blocks sequentially meaning that each new block is at the front of the chain.)
Regarding claim 7, Barger discloses, “wherein the cryptographically encoded distributed ledger is a blockchain, and” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together preventing tampering with blockchain data without breaking the hash links.” This article discloses the use of a encoded blockchain.)
“wherein adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger includes attaching a new block to the blockchain.” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together preventing tampering with blockchain data without breaking the hash links.” A central concept to block chains is that each user in the network contains their own copy of the block chain. When a new block is added to a block chain each of the connected nodes will validate and update their block chains with corresponding information or block.)
Regarding claim 8, Bansal discloses, “wherein the operations further comprise: subsequent to setting the maximum request rate associated with the first client to the first maximum request rate:” (Detailed Description, pp. 4, [0035]; "The rate limit is the average of a first threshold determined by real time data model 204 based at least in part on a flow of requests received in a first preceding period of time and a second threshold determined by historical data model 214 based at least in part on a flow of requests received in a second preceding period of time." The rate limiter contains the current threshold for a particular client. Threshold is determined by averaging the results of the real time data model and the historical model.)
“the first ledger entry specifying a second maximum request rate associated with the first client, the second maximum request rate being different than the first maximum request rate; and” (Detailed Description, pp. 2, [0019]; “FIG. 2 is a second example computing system according to some embodiments. FIG. 2 provides further details regarding service provider 120 of FIG. 1. Reverse proxy 122 includes rate enforcer 202 to apply near real-time thresholds for clients based at least in part on a short term, real-time data model 204 and a long-term, historical data model 214. Reverse proxy 122 starts off by applying a static rate limit for routing client requests and makes updates to rate limits based at least in part on real-time traffic according to real time data model 204 and historical request patterns according to historical data model 214.” Bansal does not use a block chain; however, it is able to identify, using the rate enforcer, an old rate limit and update the rate limit for a client based on the historical model inference. If one was to swap the database storage scheme in Bansal with a block chain, as in Barger, each update to the chain would be placed in the first entry location of the chain.)
“setting, by the shared resource manager, the maximum request rate associated with the first client to the second maximum request rate.” (Detailed Description, pp. 4, [0035]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214. Concept drift detector 206 dynamically determines the rate limit (e.g., current threshold) for an org (e.g., a client) that rate enforcer 202 uses to approve or deny routing of requests to services." The concept drift detector will take data from the historical model and the real time data model to determine a current threshold. When the model suggests an update, the current threshold stored by the rate enforcer would be updated.)
Bansal fails to explicitly disclose,
“detecting a first ledger entry added to the blockchain subsequent to the new ledger entry,”
However, Barger discloses, “detecting a first ledger entry added to the blockchain subsequent to the new ledger entry,” (Detailed Description, pp. 2, [0035]; “This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one. The block header includes a hash of the block's transactions, as well as a hash of the prior block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together.” A block chain will store update in a chain of blocks, where the first block is newest block to the chain.)
Regarding claim 9, Bansal discloses, “modifying a mapping of the plurality of clients to respective maximum request rates for the plurality of clients to include the second client and the second maximum request rate.” (Detailed Description, pp. 2, [0019]; “FIG. 2 is a second example computing system according to some embodiments. FIG. 2 provides further details regarding service provider 120 of FIG. 1. Reverse proxy 122 includes rate enforcer 202 to apply near real-time thresholds for clients based at least in part on a short term, real-time data model 204 and a long-term, historical data model 214. Reverse proxy 122 starts off by applying a static rate limit for routing client requests and makes updates to rate limits based at least in part on real-time traffic according to real time data model 204 and historical request patterns according to historical data model 214. Requests are passed to services 124 ... 126 if the requests meet the parameters set according to ongoing and dynamic analysis of real time data model 204, historical data model 214, and the current flow of requests.” This system is able to update and modify request rates of a shared resource or service.)
Bansal alone fails to explicitly disclose:
“detecting an addition of a smart contract to the cryptographically encoded distributed ledger,”
“wherein the smart contract specifies a second maximum request rate associated with a second client, the second client not among the plurality of clients; and”
“based on detecting the addition of the smart contract to the cryptographically encoded distributed ledger:”
However, Barger discloses, “detecting an addition of a smart contract to the cryptographically encoded distributed ledger,” (Detailed Description, pp. 5, [0059]; “The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chain code with conditions or other code elements subject to its execution.” This system uses smart contract in their block chain as well.)
“based on detecting the addition of the smart contract to the cryptographically encoded distributed ledger:” (Detailed Description, pp. 5, [0059]; “The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chain code with conditions or other code elements subject to its execution.” This system uses smart contracts in their distributed database. This system is able to identify these smart contracts in the chain.)
Barger alone fails to explicitly disclose:
“wherein the smart contract specifies a second maximum request rate associated with a second client, the second client not among the plurality of clients; and”
However, the combination of Bansal and Barger discloses, “wherein the smart contract specifies a second maximum request rate associated with a second client, the second client not among the plurality of clients; and” Bansal discloses, (Detailed Description, pp. 2, [0019]; “FIG. 2 is a second example computing system according to some embodiments. FIG. 2 provides further details regarding service provider 120 of FIG. 1. Reverse proxy 122 includes rate enforcer 202 to apply near real-time thresholds for clients based at least in part on a short term, real-time data model 204 and a long-term, historical data model 214. Reverse proxy 122 starts off by applying a static rate limit for routing client requests and makes updates to rate limits based at least in part on real-time traffic according to real time data model 204 and historical request patterns according to historical data model 214.” Bansal does not disclose the use of a smart contract or a block chain. However, Bansal discloses the use of a historical database to store historical data of users.) Barger discloses, (Detailed Description, pp. 5, [0063]; “FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a client node 260 transmitting a transaction proposal 291 to an endorsing peer node 281.” This article does disclose the use of a block chain, and one of ordinary skill in the art could swap the standard database scheme, as disclosed in Bansal, with a distributed database, as disclosed in Barger. This would then allow one to store historical data as smart contracts in a block chain.)
Regarding claim 10, Bansal discloses, “wherein the machine learning model is a long short-term memory (LSTM) recurrent neural network (RNN).” (Detailed Description, pp. 3, [0028]; "The model which is used to predict these values depends on which model performs best in model generator 212. Some models that can be incorporated include feed forward neural networks, support vector machines, long short-term memory networks (LSTMs)." The historical model used to determine the request rates of a client can be a LSTM network among other types.)
Regarding claim 11, Bansal discloses, “wherein the machine learning model is a long short-term memory (LSTM) recurrent neural network (RNN),” (Detailed Description, pp. 3, [0028]; "The model which is used to predict these values depends on which model performs best in model generator 212. Some models that can be incorporated include feed forward neural networks, support vector machines, long short-term memory networks (LSTMs)." The historical model used to determine the request rates of a client can be a LSTM network among other types.)
“wherein each ledger entry in the target set of ledger specifies: (a) the first client, (b) a particular historical modification to the maximum request rate for the first client, and (c) time data associated with the particular historical modification to the maximum request rate for the first client,” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.) and (Detailed Description, pp. 2, [0020]; "Log services 136 collect metrics about requests and services performed by service provider 120. In an embodiment, metrics include processing log information accumulated from one or more services." The historical data logged can contain information about the number of requests. This can also include data about the changing request and pull rates overtime.) and (Detailed Description, pp. 2, [0021]; "Historical data model 214 is used to capture the time sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The data stored by the log analyzer can contain time data as well. As listed on the previous limitation this data can consist of changes in pull or request rates.)
“wherein the operations further comprise: based on determining the first maximum request rate for requests from the first client for the first target time period:” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.) and (Detailed Description, pp. 2, [0020]; "Log services 136 collect metrics about requests and services performed by service provider 120. In an embodiment, metrics include processing log information accumulated from one or more services." The historical data logged can contain information about the number of requests. This can also include data about the changing request and pull rates overtime.) and (Detailed Description, pp. 2, [0021]; "Historical data model 214 is used to capture the time sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The data stored by the log analyzer can contain time data as well. As listed on the previous limitation this data can consist of changes in pull or request rates.)
“generating a candidate ledger entry specifying: (a) the first client, and” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.)
“(b) the first maximum request rate; and” (Detailed Description, pp. 2, [0022]; “Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system is able to use historical data to produce a max rate for a given client. This training data can include a given client and max rate limits.)
“setting, by a shared resource manager, the maximum request rate associated with the first client to the first maximum request rate,” (Detailed Description, pp. 4, [0035]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214. Concept drift detector 206 dynamically determines the rate limit (e.g., current threshold) for an org (e.g., a client) that rate enforcer 202 uses to approve or deny routing of requests to services." The concept drift detector will take data from the historical model and the real time data model to determine a current threshold. When the model suggests an update, the current threshold stored by the rate enforcer would be updated.)
“wherein the operations further comprise: subsequent to setting the maximum request rate associated with the first client to the first maximum request rate:” (Detailed Description, pp. 4, [0035]; "The rate limit is the average of a first threshold determined by real time data model 204 based at least in part on a flow of requests received in a first preceding period of time and a second threshold determined by historical data model 214 based at least in part on a flow of requests received in a second preceding period of time." The rate limiter contains the current threshold for a particular client. Threshold is determined by averaging the results of the real time data model and the historical model.)
“the first ledger entry specifying a second maximum request rate associated with the first client, the second maximum request rate being different than the first maximum request rate; and” (Detailed Description, pp. 2, [0019]; “FIG. 2 is a second example computing system according to some embodiments. FIG. 2 provides further details regarding service provider 120 of FIG. 1. Reverse proxy 122 includes rate enforcer 202 to apply near real-time thresholds for clients based at least in part on a short term, real-time data model 204 and a long-term, historical data model 214. Reverse proxy 122 starts off by applying a static rate limit for routing client requests and makes updates to rate limits based at least in part on real-time traffic according to real time data model 204 and historical request patterns according to historical data model 214.” Bansal does not use a block chain; however, it is able to identify, using the rate enforcer, an old rate limit and update the rate limit for a client based on the historical model inference. If one was to swap the database storage scheme in Bansal with a block chain, as in Barger, each update to the chain would be placed in the first entry location of the chain.)
“setting, by the shared resource manager, the maximum request rate associated with the first client to the second maximum request rate,” (Detailed Description, pp. 4, [0035]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214. Concept drift detector 206 dynamically determines the rate limit (e.g., current threshold) for an org (e.g., a client) that rate enforcer 202 uses to approve or deny routing of requests to services." The concept drift detector will take data from the historical model and the real time data model to determine a current threshold. When the model suggests an update, the current threshold stored by the rate enforcer would be updated.)
“modifying a mapping of the plurality of clients to respective maximum request rates for the plurality of clients to include the second client and the second maximum request rate, and” (Detailed Description, pp. 2, [0019]; “FIG. 2 is a second example computing system according to some embodiments. FIG. 2 provides further details regarding service provider 120 of FIG. 1. Reverse proxy 122 includes rate enforcer 202 to apply near real-time thresholds for clients based at least in part on a short term, real-time data model 204 and a long-term, historical data model 214. Reverse proxy 122 starts off by applying a static rate limit for routing client requests and makes updates to rate limits based at least in part on real-time traffic according to real-time data model 204 and historical request patterns according to historical data model 214. Requests are passed to services 124 ... 126 if the requests meet the parameters set according to ongoing and dynamic analysis of real time data model 204, historical data model 214, and the current flow of requests.” This system is able to update and modify request rates of a shared resource or service.)
“wherein the operations further comprise: receiving a new maximum request rate modification record;” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” This system uses real-time and historic models to evaluate predicted rates for clients based on their transactions and rates over time or in real time. When the system finds a new rate for a client the rate enforcer module is updated.)
“re-training the machine learning model based on the set of maximum historical request rate modification records and the new maximum request rate modification record to generate a re-trained machine learning model;” (Detailed Description, pp. 2-3, [0024]; "Over time the historical data models can become stale and the predictions may no longer be accurate. This situation requires a re-training phase which can be done in at least one of two ways. First, in one embodiment, a cron-based service can be started where historical data model 214 is re-trained on a predetermined fixed time schedule (e.g., once every few hours, once per day, etc.)." Once the historical model can be retrained on newer historical data. This retraining can be based on concept drift or part of a regular schedule. This retraining is designed to produce a new retrained and more accurate model) and (Detailed Description, pp. 3, [0024]; “Training (and re-training) of historical data model 214 is expensive from the standpoint of the time needed and computational resources consumed. Thus, training (and re-training) are to be performed only when necessary according to a measure of staleness.” This discloses that the models used for predicting max rates for clients are retrained to improve accuracy.)
“identifying characteristics of a second target time period for determining a second maximum request rate for the first client; and” (Detailed Description, pp. 3, [0027]; "Historical data model 214 captures this temporal behavior (e.g., client requests on certain days of the week) and accordingly predicts when an organization will become active based on past behavior. This is advantageous because if the historical data model gives an indication that an organization is about to send a burst of requests, bandwidth can be reserved on behalf of an org by rate enforcer 202 for the upcoming expected burst and bandwidth can be temporarily reduced for organizations predicted to be dormant during the expected burst." This system is able to identify different client system usage datapoints over a period of time and use that temporal data to generate predictions using the historical data model.)
“applying the re-trained machine learning model to the characteristics of the second target time period to determine the second maximum request rate for requests from the first client for the second target time period.” (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical model, which is selected and trained by the model generator, Intakes historical data from the log analyzer to determine the request rate of a client.) And (Detailed Description, pp. 4, [0034]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214." The concept drift detector will trigger an alert for when the historical model needs to be retrained or replaced. Therefore, the process of training the historical model is the same as the retraining process.) and (Detailed Description, pp. 3, [0028]; “The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org.” This system is able to reuse the trained model to produce predictions.)
Bansal alone fails to explicitly disclose:
“wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and”
“wherein the plurality of system nodes maintain a respective plurality of copies of the cryptographically encoded distributed ledger,”
“wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and”
“broadcasting the candidate ledger entry to the plurality of system nodes,”
“wherein the operations further comprise: based on broadcasting the candidate ledger entry to the plurality of system nodes: validating, by at least one of the plurality of system nodes executing operations specified by the consensus algorithm, the candidate ledger entry;”
“broadcasting, by the at least one of the plurality of system nodes, a new ledger entry based on the candidate ledger entry;”
“adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger; and”
“wherein the cryptographically encoded distributed ledger is a blockchain, and”
“wherein adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger includes attaching a new block to the blockchain,”
“detecting a first ledger entry added to the blockchain subsequent to the new ledger entry,”
“wherein the operations further comprise: detecting an addition of a smart contract to the cryptographically encoded distributed ledger,”
“wherein the smart contract specifies a second maximum request rate associated with a second client, the second client not among the plurality of clients; and”
“based on detecting the addition of the smart contract to the cryptographically encoded distributed ledger:”
However, Barger discloses, “wherein the plurality of system nodes maintain a respective plurality of copies of the cryptographically encoded distributed ledger,” (Detailed Description, pp. 14, [0150]; “This transaction record is then sent to all other nodes where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854-860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to every transaction making it exceedingly difficult to tamper with. Each node checks their entries with respect to a local copy of the blockchain 852 to verify that each transaction has sufficient funds. However, the transactions are not yet confirmed.” This system employs a standard block chain. In a block chain, each user has their own copy of the block chain.)
“broadcasting the candidate ledger entry to the plurality of system nodes,” (Detailed Description, pp. 10, [0102]; “When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 724. When the committing peer validates the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set.” A block chain requires users to add new blocks to the chain. When this occurs, a user will broadcast the addition to their block chain to other user nodes for validation and updating of their block chains.)
“wherein the operations further comprise: based on broadcasting the candidate ledger entry to the plurality of system nodes: validating, by at least one of the plurality of system nodes executing operations specified by the consensus algorithm, the candidate ledger entry;” (Detailed Description, pp. 10, [0102]; “In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724.” As stated above, block chains are updated after a new block is added to a user’s own block chain. That user will broadcast the updates to other nodes or clients in the network.) and (Detailed Description, pp. 13, [0143]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” Once a client or node receives an update to the block chain, the system will use consensus mechanisms to ensure the update is valid. If it is valid then the new block is added to a block chain, and the cycle continues until each node contains identical copy of the block chains.)
“broadcasting, by the at least one of the plurality of system nodes, a new ledger entry based on the candidate ledger entry;” (Detailed Description, pp. 10, [0102]; “In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724.” As stated above, broadcasting of a new block to a block chain is common practice. This is how each node will update with new information or blocks.)
“adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger; and” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block.” A block chain usually adds blocks sequentially meaning that each new block is at the front of the chain.)
“wherein the cryptographically encoded distributed ledger is a blockchain, and” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together preventing tampering with blockchain data without breaking the hash links.” This article discloses the use of an encoded blockchain.)
“wherein adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger includes attaching a new block to the blockchain,” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block. In this way, all transactions on the blockchain 722 are sequenced and cryptographically linked together preventing tampering with blockchain data without breaking the hash links.” A central concept to block chains is that each user in the network contains their own copy of the block chain. When a new block is added to a block chain each of the connected nodes will validate and update their block chains with corresponding information or block.)
“detecting a first ledger entry added to the blockchain subsequent to the new ledger entry,” (Detailed Description, pp. 2, [0035]; “This application can utilize a chain that is a transaction log which is structured as hash-linked blocks, and each block contains a sequence of N transactions where N is equal to or greater than one. The block header includes a hash of the block's transactions, as well as a hash of the prior block's header. In this way, all transactions on the ledger may be sequenced and cryptographically linked together.” A block chain will store update in a chain of blocks, where the first block is newest block to the chain.)
“wherein the operations further comprise: detecting an addition of a smart contract to the cryptographically encoded distributed ledger,” (Detailed Description, pp. 5, [0059]; “The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chain code with conditions or other code elements subject to its execution.” This system uses smart contract in their block chain as well.)
“based on detecting the addition of the smart contract to the cryptographically encoded distributed ledger:” (Detailed Description, pp. 5, [0059]; “The blockchain architecture configuration of FIG. 2A may process and execute program/application code 220 via one or more interfaces exposed, and services provided, by blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 can store and transfer data, and may be executed by nodes 204-210 in the form of a smart contract and associated chain code with conditions or other code elements subject to its execution.” This system uses smart contracts in their distributed database. This system is able to identify these smart contracts in the chain.)
Barger alone fails to explicitly disclose:
“wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and”
“wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and”
“wherein the smart contract specifies a second maximum request rate associated with a second client, the second client not among the plurality of clients; and”
However, the combination of Bansal and Barger discloses, “wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system uses historical data for each client to determine a maximum request rate. This system uses historical data from a given user as well as the usage patterns.) Barger discloses, (Detailed Description, pp. 13, [0142]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” This system uses consensus mechanisms to determine if newly broadcast blocks from other users should be added to a client’s personally stored block chains.)
“wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). This model uses historical log data, which is data generated by a user at a given time, to determine the request rate of that user.) Barger discloses, (Detailed Description, pp. 2, [0031]; “The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers.” Since Bansal does not use Block chains, the examiner relies on Barger to teach an encrypted block chain. As stated previously, a block chain is merely a distributed database designed to store data. This is fundamentally similar to a standard database containing various entries.)
“wherein the smart contract specifies a second maximum request rate associated with a second client, the second client not among the plurality of clients; and” Bansal discloses, (Detailed Description, pp. 2, [0019]; “FIG. 2 is a second example computing system according to some embodiments. FIG. 2 provides further details regarding service provider 120 of FIG. 1. Reverse proxy 122 includes rate enforcer 202 to apply near real-time thresholds for clients based at least in part on a short term, real-time data model 204 and a long-term, historical data model 214. Reverse proxy 122 starts off by applying a static rate limit for routing client requests and makes updates to rate limits based at least in part on real-time traffic according to real time data model 204 and historical request patterns according to historical data model 214.” Bansal does not disclose the use of a smart contract or a block chain. However, Bansal discloses the use of a historical database to store historical data of users.) Barger discloses, (Detailed Description, pp. 5, [0063]; “FIG. 2B illustrates an example of a blockchain transactional flow 250 between nodes of the blockchain in accordance with an example embodiment. Referring to FIG. 2B, the transaction flow may include a client node 260 transmitting a transaction proposal 291 to an endorsing peer node 281.” This article does disclose the use of a block chain, and one of ordinary skill in the art could swap the standard database scheme, as disclosed in Bansal, with a distributed database, as disclosed in Barger. This would then allow one to store historical data as smart contracts in a block chain.)
Regarding claim 15, Bansal discloses, “A method comprising:” (Abstract; "Examples include a method of predictive rate limiting for performing services requested by a client in a cloud computing system." This article discloses a method used predictive pull rate limiting.)
“training a machine learning model to predict a maximum request rate for a target time period,” (Detailed Description, pp. 3, [0028]; “The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org.” Bansal discloses a historic machine learning model that will predict a rate limit for a particular client or organization.) And (Detailed Description, pp. 2, [0018]; “Historical data model generator 138 obtains historical data from log services 136 regarding previously processed requests for services and generates a historical data model for use by reverse proxy 122 in processing rate limiting requests to access services.” The Historic data model generator generates a model used to predict rate limits for customers. As disclosed in the specification the historical data is historical data from customers in a given period of time.)
“the maximum request rate corresponding to a maximum number of requests in a particular period of time that clients are permitted to initiate to access a shared resource, the training comprising:” (Detailed Description, pp. 2, [0022]; “Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This model is able to evaluate log data which includes evaluating max request rates from given clients for a period of time.)
“wherein the historical maximum request rate modification records are associated with at least one client among a plurality of clients, each historical maximum request rate modification record comprising:” (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” Bansal contains historical log data of different clients in a standard database. This data contains user information including request rates during specified times as well as max or minimum pull rates.)
“(a) a new maximum request rate for the at least one client and (b) characteristics of a period of time corresponding to the historical maximum request rate modification record,” (Detailed Description, pp. 3, [0027]; "Historical data model 214 is used to capture the time-sensitive and/or seasonality of incoming request traffic from clients and/or organizations." A model is used to capture the request rates and time of clients.) and (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical data used contains the rate limit of each client which would under the broadest reasonable interpretation be the maximum rate for that client.) and (Detailed Description, pp. 3, [0027]; "Historical data model 214 is used to capture the time-sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The historical data used contains time data. Bansal does not train it models from ledger data but use a database stored in memory as the data structure to hold the historical data.)
“training the machine learning model based on the set of maximum historical request rate modification records to generate a trained machine learning model;” (Detailed Description, pp. 4, [0039]; "At block 402, model generator 212 divides data 210 into a training data set, a cross-validation data set and a testing data set. At block 404, model generator selects a first machine learning model from a plurality of available machine learning models (e.g., artificial neural networks, decision trees, support vector machines, regression analysis, Bayesian networks, genetic algorithms, and so on). At block 406, model generator 212 trains the selected model on the training data set. At block 408, model generator 212 tunes one or more hyper-parameters for the model using the cross-validation data set." The historical model is trained on historical data. This data contains request rates and time data. The historical data is divided and used to train and tune the historical model. The component is called a model generator and as stated above, this will generate and train a machine learning model to be used by the system.)
“applying the trained machine learning model to a set of input data including the characteristics of a first target time period to determine a first maximum request rate for requests from the first client for the first target time period;” (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical model, which is selected and trained by the model generator, Intakes historical data from the log analyzer to determine the request rate of a client. This rate is only for a given amount of time, such as a portion of a day or week.)
“modifying a configuration of a request handling gateway associated with the shared resource to modify the handling of requests from the first client,” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” This system is able to evaluate a user’s current request limit and, using historical data, generate a new request rate based on this inference. Once a new rate is determined the rate enforcer is updated in the system for a given user.)
“wherein modifying the configuration of the request handling gateway comprises modifying a particular maximum request rate for the first client from a second maximum request rate to the first maximum request rate,” (Detailed Description, pp. 4, [0038]; “FIG. 3 is a flow diagram 300 of example rate enforcer 202 processing according to some embodiments. At block 302, rate enforcer 202 receives a request for service from router 118. In an embodiment, the request includes an identifier of the org requesting one of services 124-126. At block 304, rate enforcer 202 gets a current threshold to be used for the org from concept drift detector 206. In another embodiment, rate enforcer 202 stores current thresholds received from concept drift detector 206 for one or more orgs internally and selects the current threshold for the org currently identified by the request. In an embodiment, each org has its own threshold.” This system includes a rate enforcer module. This will evaluate requests from clients and enforce rate limits. This system can receive updates the request rates of clients from different systems sources such as the historical data model and the concept drift detector.)
“wherein based on the configuration, the request handling gateway rejects and/or generates a notification corresponding to a request initiated by the first client that would result in a number of requests for the first target time period exceeding the first maximum request rate.” (Detailed Description, pp. 4, [0037]; “Rate enforcer 202 processes a request received from a client via router 118 before forwarding the request, if approved according to real time data model 204 and historical data model 214, to a selected service. Rate enforcer 202 validates whether the rate limit for a given client is reached or not. Rate enforcer 202 drops requests for an organization if the requests cause the organization to exceed the currently specified rate limit for the organization. If the rate limit is not reached, rate enforcer 202 forwards the request.” Bansal includes a rate enforcer module that is able to evaluate clients’ requests and determine if the request exceeds the stored rate threshold. This system is able to determine to allow or reject the request for service from the client.) And (Detailed Description, pp. 4, [0038]; “At block 306, if performance of the request by one of services 124-126 would cause the current threshold to be exceeded, then the request is denied at block 310 and an error message is sent back to the requesting client. In an embodiment, the error message includes a "HTTP 429-too many requests" message. The error message notifies the requesting client of the performance backlog so that the client can reschedule the request for a later point in time.” This is an example where they rate enforcer will generate a notification if the current rate for the client is exceeded or will be exceeded after the service is provided.)
Bansal alone fails to explicitly disclose:
“accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;”
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;”
“publishing the encrypted distributed ledger record to the cryptographically encoded distributed ledger; and”
“based on determining the cryptographically encoded distributed ledger validated the encrypted distributed ledger record,”
However, Barger discloses, “publishing the encrypted distributed ledger record to the cryptographically encoded distributed ledger; and” (Detailed Description, pp. 3, [0037] “In the example embodiments, a publisher of content (e.g., a user, a client, a blockchain peer, etc.) of a distributed ledger (e.g., a blockchain ledger, etc.) may encrypt content prior to publishing/storing the content on the distributed ledger. For example, the content may remain confidential while stored on the distributed ledger unless another entity is in possession of the encryption key (or corresponding decryption key) necessary to decrypt the encrypted content. A user in this system is able to publish a new block to the block chain, which is encrypted.)
“based on determining the cryptographically encoded distributed ledger validated the encrypted distributed ledger record,” (Detailed Description, pp. 13, [0142]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” This system uses an encoded block chain and is able to store different forms of data and validate that data with other users in the network.)
Barger alone fails to explicitly disclose:
“accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;”
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;”
However, the combination of Bansal and Barger discloses, “accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,” Bansal discloses, (Detailed Description, pp. 2, [0021]; “In an embodiment, log analyzer 208 runs "cron" jobs which run predefined Domain Specific Language (DSL) based queries on metrics collected by log services 136 to generate a database of historical data 210. Historical data 210 can then be used as an input for historical data model generation. Log analyzer 208 parses log information included in the collected metrics.” Bansal uses a historical log storage system to store their historical data used to train system models. This log is a form of memory or database which is accessed by the system to perform system tasks such as rate limiting.) Barger discloses, (Detailed Description, pp. 8, [0086]; “FIG. 5 illustrates a method 500 of limiting data availability on a blockchain ledger according to exan1ple embodiments. For example, the method 500 may be performed by a client, a blockchain peer, a smart contract, a server, or the like. Referring to FIG. 5, in 510, the method may include encrypting content with an encryption key to generate encrypted content. In some embodiments, the encryption key may be a symmetric encryption key that can be used to decrypt the content. In 520, the method may include storing the encrypted content on a distributed ledger.” This system uses a distributed database or blockchain. A blockchains can be used in place of standard databases located on computing systems. This is a system which discloses the use of an encrypted ledger to limit access to shared resources. This art does not disclose rate limiting; however, the concepts of this article can be used in combination of rate limiting. This article is used to disclose standard blockchain architecture.)
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;” Bansal discloses, (Detailed Description, pp. 2, [0021]; “In an embodiment, log analyzer 208 runs "cron" jobs which run predefined Domain Specific Language (DSL) based queries on metrics collected by log services 136 to generate a database of historical data 210. Historical data 210 can then be used as an input for historical data model generation. Log analyzer 208 parses log information included in the collected metrics.” Bansal uses a standard database to store historical log data. This data is accessed by the system to train their model to determine request rates of different users.) Barger discloses, (Detailed Description, pp. 9, [0095]; “The plurality of blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes/ peers may be present in the blockchain network including endorsing peers which simulate and endorse transactions proposed by clients and committing peers which verify endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 may perform the role of endorser node, committer node, or both.” This article discloses a standard block chain which is a distributed database. This system, or block chain concept, can be swapped with a standard database system for all users to ensure data transparency and accuracy.)
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system, as stated above, stores client and historical request data in a standard database. The data logged contains user information and historical data.) Barger discloses, (Detailed Description, pp. 3, [0037]; “In the example embodiments, a publisher of content (e.g., a user, a client, a blockchain peer, etc.) of a distributed ledger (e.g., a blockchain ledger, etc.) may encrypt content prior to publishing/storing the content on the distributed ledger. For example, the content may remain confidential while stored on the distributed ledger unless another entity is in possession of the encryption key (or corresponding decryption key) necessary to decrypt the encrypted content.” As stated above, this system discloses a standard encrypted blockchain. This system can be used to store data including individual client data and their data, such as historical use data.)
Regarding claim 16, Bansal alone fails to disclose the limitations of this claim. However, Barger discloses, “wherein the plurality of system nodes maintain a respective plurality of copies of the cryptographically encoded distributed ledger.” (Detailed Description, pp. 14, [0150]; “This transaction record is then sent to all other nodes where it is entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from among 854-860) authenticate the transaction by providing their shared secret key 862 (QKD). This quantum signature can be attached to every transaction making it exceedingly difficult to tamper with. Each node checks their entries with respect to a local copy of the blockchain 852 to verify that each transaction has sufficient funds. However, the transactions are not yet confirmed.” This system employs a standard block chain. In a block chain, each user has their own copy of the block chain.)
Barger alone fails to explicitly disclose:
“wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and”
However, the combination of Bansal and Barger discloses, “wherein the set of historical maximum request rate modification records are a set of ledger entries obtained from the cryptographically encoded distributed ledger maintained by a consensus algorithm executed on a plurality of system nodes, and” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system uses historical data for each client to determine a maximum request rate. This system uses historical data from a given user as well as the usage patterns.) Barger discloses, (Detailed Description, pp. 13, [0142]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” This system uses consensus mechanisms to determine if newly broadcast blocks from other users should be added to a client’s personally stored block chains.)
Regarding claim 17, Bansal discloses, “wherein each ledger entry in the target set of ledger specifies: (a) the first client, (b) a particular historical modification to the maximum request rate for the first client, and (c) time data associated with the particular historical modification to the maximum request rate for the first client.” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.) and (Detailed Description, pp. 2, [0020]; "Log services 136 collect metrics about requests and services performed by service provider 120. In an embodiment, metrics include processing log information accumulated from one or more services." The historical data logged can contain information about the number of requests. This can also include data about the changing request and pull rates overtime.) and (Detailed Description, pp. 2, [0021]; "Historical data model 214 is used to capture the time sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The data stored by the log analyzer can contain time data as well. As listed on the previous limitation this data can consist of changes in pull or request rates.)
Bansal alone and Barger alone fail to explicitly disclose:
“wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and”
However, the combination of Bansal and Barger discloses, “wherein identifying the characteristics of the target time period includes obtaining a target set of ledger entries from the cryptographically encoded distributed ledger, and” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). This model uses historical log data, which is data generated by a user at a given time, to determine the request rate of that user.) Barger discloses, (Detailed Description, pp. 2, [0031]; “The decentralized database includes an append-only immutable data structure resembling a distributed ledger capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records and no single peer can modify the database records without a consensus being reached among the distributed peers.” Since Bansal does not use Block chains, the examiner relies on Barger to teach an encrypted block chain. As stated previously, a block chain is merely a distributed database designed to store data. This is fundamentally similar to a standard database containing various entries.)
Regarding claim 18, Bansal disclose, “based on determining the first maximum request rate for requests from the first client for the first target time period:” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.) and (Detailed Description, pp. 2, [0020]; "Log services 136 collect metrics about requests and services performed by service provider 120. In an embodiment, metrics include processing log information accumulated from one or more services." The historical data logged can contain information about the number of requests. This can also include data about the changing request and pull rates overtime.) and (Detailed Description, pp. 2, [0021]; "Historical data model 214 is used to capture the time sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The data stored by the log analyzer can contain time data as well. As listed on the previous limitation this data can consist of changes in pull or request rates.)
“generating a candidate ledger entry specifying: (a) the first client, and” (Detailed Description, pp. 2, [0021]; "Log analyzer 208 parses log information included in the collected metrics. For example, log information could include a time series representation on what kind of API flows are called by clients, and/or a distribution of various flows based on time for different clients." Data from users is collected and stored to be used by the historical data model. The data entry contains a particular client's name.)
“(b) the first maximum request rate; and” (Detailed Description, pp. 2, [0022]; “Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system is able to use historical data to produce a max rate for a given client. This training data can include a given client and max rate limits.)
Bansal fails to explicitly disclose:
“broadcasting the candidate ledger entry to the plurality of system nodes.”
However, Barger discloses, “broadcasting the candidate ledger entry to the plurality of system nodes.” (Detailed Description, pp. 10, [0102]; “When the ordering service 710 initializes a new data block 730, the new data block 730 may be broadcast to committing peers (e.g., blockchain nodes 711, 712, and 713). In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724. Specifically, the committing peer can determine whether the read data that existed when the endorsers simulated the transaction is identical to the current world state in the state database 724. When the committing peer validates the transaction, the transaction is written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set.” A block chain requires users to add new blocks to the chain. When this occurs, a user will broadcast the addition to their block chain to other user nodes for validation and updating of their block chains.)
Regarding claim 19, Bansal discloses, “setting, by a shared resource manager, the maximum request rate associated with the first client to the first maximum request rate.” (Detailed Description, pp. 4, [0035]; "Concept drift detector 206 can also be used to detect decay and/or degradation of historical data model 214 and trigger an alert, which could be used by model generator 212 to rebuild/retrain the historical data model 214. Concept drift detector 206 dynamically determines the rate limit (e.g., current threshold) for an org (e.g., a client) that rate enforcer 202 uses to approve or deny routing of requests to services." The concept drift detector will take data from the historical model and the real time data model to determine a current threshold. When the model suggests an update, the current threshold stored by the rate enforcer would be updated.)
Bansal fails to explicitly disclose:
“based on broadcasting the candidate ledger entry to the plurality of system nodes: validating, by at least one of the plurality of system nodes executing operations specified by the consensus algorithm, the candidate ledger entry;”
“broadcasting, by the at least one of the plurality of system nodes, a new ledger entry based on the candidate ledger entry;”
However, Barger discloses, “based on broadcasting the candidate ledger entry to the plurality of system nodes: validating, by at least one of the plurality of system nodes executing operations specified by the consensus algorithm, the candidate ledger entry;” (Detailed Description, pp. 10, [0102]; “In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724.” As stated above, block chains are updated after a new block is added to a user’s own block chain. That user will broadcast the updates to other nodes or clients in the network.) and (Detailed Description, pp. 13, [0143]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” Once a client or node receives an update to the block chain, the system will use consensus mechanisms to ensure the update is valid. If it is valid then the new block is added to a block chain and the cycle continues until each node contains identical copy of the block chains.)
“broadcasting, by the at least one of the plurality of system nodes, a new ledger entry based on the candidate ledger entry;” (Detailed Description, pp. 10, [0102]; “In response, each committing peer validates the transaction within the new data block 730 by checking to make sure that the read set and the write set still match the current world state in the state database 724.” As stated above, broadcasting of a new block to a block chain is common practice. This is how each node will update with new information or blocks.)
“adding, by the plurality of system nodes, the new ledger entry to the respective plurality of copies of the cryptographically encoded distributed ledger; and” (Detailed Description, pp. 9, [0096]; “The distributed ledger 720 includes a blockchain which stores immutable, sequenced records in blocks, and a state database 724 (current world state) maintaining a current state of the blockchain 722. One distributed ledger 720 may exist per channel and each peer maintains its own copy of the distributed ledger 720 for each channel of which they are a member. The blockchain 722 is a transaction log, structured as hash-linked blocks where each block contains a sequence of N transactions. Blocks may include various components such as shown in FIG. 7B. The linking of the blocks (shown by arrows in FIG. 7A) may be generated by adding a hash of a prior block's header within a block header of a current block.” A block chain usually adds blocks sequentially meaning that each new block is at the front of the chain.)
Regarding claim 20, Bansal discloses, “A system comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the system to perform operations comprising:” (Detailed Description, pp. 5, [049]-[0050]; "FIG. 7 illustrates an example computing platform 700. In some examples, as shown in FIG. 7, computing platform 700 may include a processing component 702, other platform components 704 and/or a communications interface 706. [0050] According to some examples, processing component 702 may execute processing operations or logic for instructions stored on storage medium 600." This article discloses that the method described is designed to be run on a computer system containing processors connected to memory, which store the method instructions.)
“training a machine learning model to predict a maximum request rate for a target time period,” (Detailed Description, pp. 3, [0028]; “The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org.” Bansal discloses a historic machine learning model that will predict a rate limit for a particular client or organization.) And (Detailed Description, pp. 2, [0018]; “Historical data model generator 138 obtains historical data from log services 136 regarding previously processed requests for services and generates a historical data model for use by reverse proxy 122 in processing rate limiting requests to access services.” The Historic data model generator generates a model used to predict rate limits for customers. As disclosed in the specification the historical data is historical data from customers in a given period of time.)
“the maximum request rate corresponding to a maximum number of requests in a particular period of time that clients are permitted to initiate to access a shared resource, the training comprising:” (Detailed Description, pp. 2, [0022]; “Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This model is able to evaluate log data which includes evaluating max request rates from given clients for a period of time.)
“wherein the historical maximum request rate modification records are associated with at least one client among a plurality of clients, each historical maximum request rate modification record comprising:” (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” Bansal contains historical log data of different clients in a standard database. This data contains user information including request rates during specified times as well as max or minimum pull rates.)
“(a) a new maximum request rate for the at least one client and (b) characteristics of a period of time corresponding to the historical maximum request rate modification record,” (Detailed Description, pp. 3, [0027]; "Historical data model 214 is used to capture the time-sensitive and/or seasonality of incoming request traffic from clients and/or organizations." A model is used to capture the request rates and time of clients.) and (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical data used contains the rate limit of each client which would under the broadest reasonable interpretation be the maximum rate for that client.) and (Detailed Description, pp. 3, [0027]; "Historical data model 214 is used to capture the time-sensitive and/or seasonality of incoming request traffic from clients and/or organizations." The historical data used contains time data. Bansal does not train it models from ledger data but use a database stored in memory as the data structure to hold the historical data.)
“training the machine learning model based on the set of maximum historical request rate modification records to generate a trained machine learning model;” (Detailed Description, pp. 4, [0039]; "At block 402, model generator 212 divides data 210 into a training data set, a cross-validation data set and a testing data set. At block 404, model generator selects a first machine learning model from a plurality of available machine learning models (e.g., artificial neural networks, decision trees, support vector machines, regression analysis, Bayesian networks, genetic algorithms, and so on). At block 406, model generator 212 trains the selected model on the training data set. At block 408, model generator 212 tunes one or more hyper-parameters for the model using the cross-validation data set." The historical model is trained on historical data. This data contains request rates and time data. The historical data is divided and used to train and tune the historical model. The component is called a model generator and as stated above, this will generate and train a machine learning model to be used by the system.)
“applying the trained machine learning model to a set of input data including characteristics of a first target time period to determine a first maximum request rate for requests from the first client for the first target time period;” (Detailed Description, pp. 3, [0028]; "The input to historical data model 214 is historical data 210 which contains features extracted by log analyzer 208. The output of the historical data model are numeric values indicating the rate limit for each org." The historical model, which is selected and trained by the model generator, Intakes historical data from the log analyzer to determine the request rate of a client. This rate is only for a given amount of time, such as a portion of a day or week.)
“modifying a configuration of a request handling gateway associated with the shared resource to modify the handling of requests from the first client,” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” This system is able to evaluate a user’s current request limit and, using historical data, generate a new request rate based on this inference. Once a new rate is determined the rate enforcer is updated in the system for a given user.)
“wherein modifying the configuration of the request handling gateway comprises modifying a particular maximum request rate for the first client from a second maximum request rate to the first maximum request rate,” (Detailed Description, pp. 4, [0038]; “FIG. 3 is a flow diagram 300 of example rate enforcer 202 processing according to some embodiments. At block 302, rate enforcer 202 receives a request for service from router 118. In an embodiment, the request includes an identifier of the org requesting one of services 124-126. At block 304, rate enforcer 202 gets a current threshold to be used for the org from concept drift detector 206. In another embodiment, rate enforcer 202 stores current thresholds received from concept drift detector 206 for one or more orgs internally and selects the current threshold for the org currently identified by the request. In an embodiment, each org has its own threshold.” This system includes a rate enforcer module. This will evaluate requests from clients and enforce rate limits. This system can receive updates the request rates of clients from different systems sources such as the historical data model and the concept drift detector.)
“wherein based on the configuration, the request handling gateway rejects and/or generates a notification corresponding to a request initiated by the first client that would result in a number of requests for the first target time period exceeding the first maximum request rate.” (Detailed Description, pp. 4, [0037]; “Rate enforcer 202 processes a request received from a client via router 118 before forwarding the request, if approved according to real time data model 204 and historical data model 214, to a selected service. Rate enforcer 202 validates whether the rate limit for a given client is reached or not. Rate enforcer 202 drops requests for an organization if the requests cause the organization to exceed the currently specified rate limit for the organization. If the rate limit is not reached, rate enforcer 202 forwards the request.” Bansal includes a rate enforcer module that is able to evaluate clients’ requests and determine if the request exceeds the stored rate threshold. This system is able to determine whether to allow or reject the request for service from the client.) And (Detailed Description, pp. 4, [0038]; “At block 306, if performance of the request by one of services 124-126 would cause the current threshold to be exceeded, then the request is denied at block 310 and an error message is sent back to the requesting client. In an embodiment, the error message includes a "HTTP 429-too many requests" message. The error message notifies the requesting client of the performance backlog so that the client can reschedule the request for a later point in time.” This is an example where they rate enforcer will generate a notification if the current rate for the client is exceeded or will be exceeded after the service is provided.)
Bansal alone fails to explicitly disclose:
“accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;”
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;”
“publishing the encrypted distributed ledger record to the cryptographically encoded distributed ledger; and”
“based on determining the cryptographically encoded distributed ledger validated the encrypted distributed ledger record,”
However, Barger discloses, “publishing the encrypted distributed ledger record to the cryptographically encoded distributed ledger; and” (Detailed Description, pp. 3, [0037] “In the example embodiments, a publisher of content (e.g., a user, a client, a blockchain peer, etc.) of a distributed ledger (e.g., a blockchain ledger, etc.) may encrypt content prior to publishing/storing the content on the distributed ledger. For example, the content may remain confidential while stored on the distributed ledger unless another entity is in possession of the encryption key (or corresponding decryption key) necessary to decrypt the encrypted content. A user in this system is able to publish a new block to the block chain, which is encrypted.)
“based on determining the cryptographically encoded distributed ledger validated the encrypted distributed ledger record,” (Detailed Description, pp. 13, [0142]; “The collected data may be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The data recorded is time-stamped, cryptographically signed, and immutable. It is therefore auditable, transparent, and secure.” This system uses an encoded block chain and is able to store different forms of data and validate that data with other users in the network.)
Barger alone fails to explicitly disclose:
“accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,”
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;”
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;”
However, the combination of Bansal and Barger disclose, “accessing a set of historical maximum request rate modification records maintained by a cryptographically encoded distributed ledger,” Bansal discloses, (Detailed Description, pp. 2, [0021]; “In an embodiment, log analyzer 208 runs "cron" jobs which run predefined Domain Specific Language (DSL) based queries on metrics collected by log services 136 to generate a database of historical data 210. Historical data 210 can then be used as an input for historical data model generation. Log analyzer 208 parses log information included in the collected metrics.” Bansal uses a historical log storage system to store their historical data used to train system models. This log is a form of memory or database which is accessed by the system to perform system tasks such as rate limiting.) Barger discloses, (Detailed Description, pp. 8, [0086]; “FIG. 5 illustrates a method 500 of limiting data availability on a blockchain ledger according to exan1ple embodiments. For example, the method 500 may be performed by a client, a blockchain peer, a smart contract, a server, or the like. Referring to FIG. 5, in 510, the method may include encrypting content with an encryption key to generate encrypted content. In some embodiments, the encryption key may be a symmetric encryption key that can be used to decrypt the content. In 520, the method may include storing the encrypted content on a distributed ledger.” This system uses a distributed database or blockchain. A blockchains can be used in place of standard databases located on computing systems. This is a system which discloses the use of an encrypted ledger to limit access to shared resources. This art does not disclose rate limiting; however, the concepts of this article can be used in combination of rate limiting. This article is used to disclose standard blockchain architecture.)
“wherein the cryptographically encoded distributed ledger stores and validates cryptographically encoded historical maximum rate request modification records for the plurality of clients;” Bansal discloses, (Detailed Description, pp. 2, [0021]; “In an embodiment, log analyzer 208 runs "cron" jobs which run predefined Domain Specific Language (DSL) based queries on metrics collected by log services 136 to generate a database of historical data 210. Historical data 210 can then be used as an input for historical data model generation. Log analyzer 208 parses log information included in the collected metrics.” Bansal uses a standard database to store historical log data. This data is accessed by the system to train their model to determine request rates of different users.) Barger discloses, (Detailed Description, pp. 9, [0095]; “The plurality of blockchain peers (e.g., blockchain nodes 711, 712, and 713) may maintain a state of the blockchain network and a copy of the distributed ledger 720. Different types of blockchain nodes/ peers may be present in the blockchain network including endorsing peers which simulate and endorse transactions proposed by clients and committing peers which verify endorsements, validate transactions, and commit transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 may perform the role of endorser node, committer node, or both.” This article discloses a standard block chain which is a distributed database. This system, or block chain concept, can be swapped with a standard database system for all users to ensure data transparency and accuracy.)
“generating an encrypted distributed ledger record by encrypting the first maximum request rate and first client data according to an encryption schema specified by the cryptographically encoded distributed ledger;” Bansal discloses, (Detailed Description, pp. 2, [0022]; “Parsed log information is stored in historical data 210. Since the metrics data keeps growing over time as system 100 is running, log analyzer 208 serves as a coalescing and/or filtering component in the system to only store historical data filtered from logs that is useful by historical data model generator 138. In some embodiments, historical data 210 captures all information obtained and filtered by log analyzer over a period of time (e.g., weeks, months, years, and so on). Generally, the more data collected and fed to model generator 212, the better the results of predictive rate limiting by rate enforcer 202. Other types of log information can also be stored in historical data 210, such as frequency, type, and timing of requests; minimum, average and maximum number of requests per unit time; by client, by instance, by organization, by type, by sub-type, by API, hour of the day, day of the week, whether the day was a weekend, whether the day was a public holiday (This information would, for example, help determine whether the org is particularly active during the weekend or on a public holiday).” This system, as stated above, stores client and historical request data in a standard database. The data logged contains user information and historical data.) Barger discloses, (Detailed Description, pp. 3, [0037]; “In the example embodiments, a publisher of content (e.g., a user, a client, a blockchain peer, etc.) of a distributed ledger (e.g., a blockchain ledger, etc.) may encrypt content prior to publishing/storing the content on the distributed ledger. For example, the content may remain confidential while stored on the distributed ledger unless another entity is in possession of the encryption key (or corresponding decryption key) necessary to decrypt the encrypted content.” As stated above, this system discloses a standard encrypted blockchain. This system can be used to store data including individual client data and their data, such as historical use data.)
Regarding claim 21, Bansal discloses, “wherein the operations further comprise: detecting a triggering event; and” (Detailed Description, pp. 2-3, [0024]; “Over time the historical data models can become stale and the predictions may no longer be accurate. This situation requires a re-training phase which can be done in at least one of two ways. First, in one embodiment, a cron-based service can be started where historical data model 214 is re-trained on a predetermined fixed time schedule (e.g., once every few hours, once per day, etc.). Second, in another embodiment, retraining may be trigger based, where model decay is measured by concept drift detector 206.)” Bansal discloses two different methods to update request rates of a user. One is based on amount of time passing and the other is trigger based events.)
“based on detecting the triggering event, identifying characteristics of the first target time period and the applying of the trained machine learning model to the characteristics of the first target time period to determine the first maximum request rate for the first client,” (Detailed Description, pp. 3, [0024]; “Over time the historical data models can become stale and the predictions may no longer be accurate. This situation requires a re-training phase which can be done in at least one of two ways. First, in one embodiment, a cron-based service can be started where historical data model 214 is re-trained on a predetermined fixed time schedule (e.g., once every few hours, once per day, etc.). Second, in another embodiment, retraining may be trigger based, where model decay is measured by concept drift detector 206. If concept drift detector determines that the deployed historical data model 214 is stale, then predictions are no longer useful with the current version of the historical data model because the previously deployed model has not been trained to consider newly observed data points obtained by log analyzer 208.” Based on trigger events, Bansal is also able to reevaluate historical data and retrain the historical model to generate a new request rate of a user for a given amount of time.)
“wherein the triggering event is at least one of: passage of a predetermined period of time;” (Detailed Description, pp. 3, [0024]; “Over time the historical data models can become stale and the predictions may no longer be accurate. … Second, in another embodiment, retraining may be trigger based, where model decay is measured by concept drift detector 206. If concept drift detector determines that the deployed historical data model 214 is stale, then predictions are no longer useful with the current version of the historical data model because the previously deployed model has not been trained to consider newly observed data points obtained by log analyzer 208.” This system will recognize that after a given amount of time the model may become stale and will trigger retraining of the historical model to determine new request rates.)
“a detected change in a capacity of the shared resource to receive access requests; and a detected change in a request rate associated with a second client among the plurality of clients.” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” As stated above, the system is able to detect when a historical model becomes stale, which triggers the system to retrain models to produce new request rates. This system is able to also detect changes in request rates and can alter users’ rates based on given outputs of models and the system environment, I.e. available resources.)
Regarding claim 22, Bansal discloses, “wherein the plurality of clients are tenants of a multi-tenant computing environment,” (Detailed Description, pp. 1, [0016]; “FIG. 1 illustrates a first example computing system 100 according to some embodiments. Computing system 100 includes a plurality of instances of client computing systems such as instance 1 102 ... instance K 104, where K is a natural number.” Bansal discloses a system which contains many different clients and organization in a multi-computing system.)
“wherein each tenant among the plurality of clients is associated with a tenant identifier, and” (Detailed Description, pp. 1, [0016]; “In an embodiment, an instance (also known as a pod) is a set of hardware and services that hosts the applications and data for a set of customer organizations (called orgs herein). A single instance can house multiple orgs. Each instance includes a plurality of clients, such as client 1 106, client 2 108, ... client J 110 of instance 1, through client 1112, client 2 114, ... client L 116 of instance K 104, where J and L are natural numbers. In an embodiment, a client belongs to an org hosted by a cloud service provider (CSP) (e.g., organization). An org includes an identifier representing a client's version of a Software as a Service (SaaS) provided by the CSP and the data within an instance.” Bansal discloses a system with multiple clients and organizations. As stated, each organization has its own identifier.)
“wherein the request handling gateway enforces the first maximum request rate for the first client based on the tenant identifier associated with the first client.” (Detailed Description, pp. 4, [0038]; “FIG. 3 is a flow diagram 300 of example rate enforcer 202 processing according to some embodiments. At block 302, rate enforcer 202 receives a request for service from router 118. In an embodiment, the request includes an identifier of the org requesting one of services 124-126. At block 304, rate enforcer 202 gets a current threshold to be used for the org from concept drift detector 206. In another embodiment, rate enforcer 202 stores current thresholds received from concept drift detector 206 for one or more orgs internally and selects the current threshold for the org currently identified by the request. In an embodiment, each org has its own threshold.” The system uses a rate enforcer to handle gateway services. This rate enforcer is able to store max request rates for specified clients or organizations.)
Regarding claim 23, Bansal discloses, “wherein the shared resource has a fixed aggregate maximum request rate corresponding to a maximum number of requests the shared resource is configured to process in a particular period of time, and” (Detailed Description, pp. 4, [0034]; “For example, historical data model 214 might indicate that a first client sends out requests between 8 pm and 12 am every weekday. If there is a sudden surge in request traffic by a second client at 7:55 pm, the recommendation of real time data model 204 might be to take any available capacity (including the first client's capacity) to service this sudden surge in traffic. Historical data model 214 would curb the real time data model's reactive responses because the historical data model anticipates that the first client will send request traffic very soon and that the rate limit for the first client should not be lowered.” The system proposed in Bansal is able to monitor available bandwidth and request rates of users for a given period of time. Further, as stated in the example, there is finite number of available resources. The system can throttle a given user depending on their rate and other users’ rates as a whole.)
“wherein the operations further comprise: maintaining, for each client among the plurality of clients, a threshold maximum request rate, wherein a sum of the threshold maximum request rates for the plurality of clients does not exceed the fixed aggregate maximum request rate of the shared resource.” (Detailed Description, pp. 3, [0029]; “Real time data model 204 analyzes real time requests passing through reverse proxy 122 and provides guidance to rate enforcer 202 on how different clients are requesting services and how rate enforcer 202 can use this guidance to tune the rate limits (e.g., current thresholds) for these clients. Concept drift detector 206 adjusts the rates based on inputs from historical data model 214 and real time data model 204. Concept drift detector 206 outputs a numeric value which represents the rate limit for the org. This rate limit is input to rate enforcer 202 which intercepts the request, finds out the org id and then drops or accepts the request based on the rate limit of the org as per the concept drift detector.” This system discloses a rate enforcer which is only allowed to allocate available resources. There is no current computing system that is able to provide resources greater than the number of resources available. Therefore, each system is only allowed, as a whole, to allocate resources which are available.)
Regarding claim 24, Bansal discloses, “applying the trained machine learning model to characteristics of the first target time period to generate predicted maximum request rates for one or more second clients among the plurality of clients;” (Detailed Description, pp. 4, [0039]; “FIG. 4 is a flow diagram 400 of example model generator 212 processing according to some embodiments. At block 402, model generator 212 divides historical data 210 into a training data set, a cross-validation data set and a testing data set. At block 404, model generator selects a first machine learning model from a plurality of available machine learning models (e.g., artificial neural networks, decision trees, support vector machines, regression analysis, Bayesian networks, genetic algorithms, and so on). At block 406, model generator 212 trains the selected model on the training data set. At block 408, model generator 212 tunes one or more hyper-parameters for the model using the cross-validation data set. In machine learning, a hyperparameter is a parameter whose value is set before the learning process begins. By contrast, the values of other parameters are derived via training.” Bansal discloses a system that uses a trained machine learning model to produce a max request rate for a given client or organization in a set of organizations. This system will use historical data gathered by the system and analyzed by a log analyzer. This data is temporal and contains information such as max request rates for clients in a given time period.) and (Detailed Description, pp. 3, [0028]; “The output of the historical data model are numeric values indicating the rate limit for each org. The model which is used to predict these values depends on which model performs best in model generator 212.” The historic model is able to produce a max rate for a client with the given information.)
“determining whether a sum of the first maximum request rate for the first client and the predicted maximum request rates for the one or more second clients would exceed the fixed aggregate maximum request rate of the shared resource; and” (Detailed Description, pp. 4, [0037]; “Rate enforcer 202 processes a request received from a client via router 118 before forwarding the request, if approved according to real time data model 204 and historical data model 214, to a selected service. Rate enforcer 202 validates whether the rate limit for a given client is reached or not. Rate enforcer 202 drops requests for an organization if the requests cause the organization to exceed the currently specified rate limit for the organization. If the rate limit is not reached, rate enforcer 202 forwards the request.” The rate enforcer in Bansal is interpreted by the examiner to determine the request of a user and either allow or deny the user request based on a given threshold. This system would also be able to determine the total maximum available bandwidth for a given resource.)
“based on determining that the sum would exceed the fixed aggregate maximum request rate, modifying the first maximum request rate for the first client prior to generating the encrypted distributed ledger record.” (Detailed Description, pp. 4, [0038]; “FIG. 3 is a flow diagram 300 of example rate enforcer 202 processing according to some embodiments. At block 302, rate enforcer 202 receives a request for service from router 118. In an embodiment, the request includes an identifier of the org requesting one of services 124-126. At block 304, rate enforcer 202 gets a current threshold to be used for the org from concept drift detector 206. In another embodiment, rate enforcer 202 stores current thresholds received from concept drift detector 206 for one or more orgs internally and selects the current threshold for the org currently identified by the request. In an embodiment, each org has its own threshold. In another embodiment, a threshold is shared for a plurality of orgs. At block 306, if performance of the request by one of services 124-126 would cause the current threshold to be exceeded, then the request is denied at block 310 and an error message is sent back to the requesting client. In an embodiment, the error message includes a "HTTP 429-too many requests" message.” As stated above, if the system is unable to meet the users request, as it will overload the system, the user is notified, and the request is not completed. This would occur at the rate enforcer, which is able to use historical data and the current environment to modify a request of a user during times of limited bandwidth.)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL MICHAEL GALVIN-SIEBENALER whose telephone number is (571)272-1257. The examiner can normally be reached Monday - Friday 8AM to 5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Viker Lamardo can be reached at (571) 270-5871. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/PAUL M GALVIN-SIEBENALER/Examiner, Art Unit 2147
/ERIC NILSSON/Primary Examiner, Art Unit 2151
Prosecution Insights