# US 2025/0094286 A1 · Fleetwide adaptive rate limiting gatekeeper apparatuses, processes and systems

> Agents: this data is available as JSON from the patentgrep API and MCP server — see https://patentgrep.com/llms.txt

- Number: US 2025/0094286 A1
- Document ID: US20250094286A1
- Status: Published application
- Kind: A1
- Application number: 18/943,782
- Filed: 2024-11-11
- Published: 2025-03-20
- Earliest claimed: 2022-06-07
- Assignees: Kaseya US LLC
- Applicants: Kaseya US LLC
- Inventors: Satish Kumar; Garrett Allen; Jesse Rhoads; Kathleen DeRusso; Kevin Vecchione; Richard Watson; Samantha Shandrow; Tushar Pradhan
- Web page: https://patentgrep.com/patent/US20250094286A1

## CPC

- G06F 9/54: Interprogram communication
- G06F 11/1448: {Management of the data involved in backup or backup restore}
- G06F 9/547: {Remote procedure calls [RPC]; Web services}
- H04L 63/101: {Access control lists [ACL]}
- H04L 63/108: {when the policy decisions are valid for a limited amount of time}
- G06F 2201/805: Real-time
- G06F 2209/504: Resource capping
- H04L 2463/121: Timestamp
- G06F: ELECTRIC DIGITAL DATA PROCESSING (computer systems based on specific computational models G06N)
- H04L: TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION (arrangements common to telegraphic and telephonic communication H04M)

## Abstract

The Fleetwide Adaptive Rate Limiting Gatekeeper Apparatuses, Processes and Systems (“FARLG”) transforms API call permission request, API call result request datastructure/inputs via FARLG components into API call permission response, API call result response outputs. An API call permission request datastructure associated with an API call of an application structured to identify an API and a set of scopes is obtained. A retry-after interval is determined for each scope in the set of scopes, in which existence of a retry-after interval for a scope indicates that the API previously returned a throttled response for the scope. A wait duration associated with the API call is determined as the maximum retry-after interval across retry-after intervals that exist for the set of scopes. An API call permission response datastructure structured to specify the wait duration is provided.

## Claims

### Claim 1

A method, comprising:
processing, via at least one processor from a component collection stored in a component collection storage of at least one memory, processor-executable instructions comprising:
obtain an API call permission request datastructure associated with an API call of an application, in which the API call permission request datastructure is structured to identify an API and a set of scopes;
determine a retry-after interval for each scope in the set of scopes, in which existence of a retry-after interval for a scope indicates that the API previously returned a throttled response for the respective scope;
determine a wait duration associated with the API call, in which the wait duration is determined as a maximum retry-after interval across retry-after intervals that exist for any scope in the set of scopes;
provide an API call permission response datastructure, in which the API call permission response datastructure is structured to specify the wait duration; and
in response to the wait duration being specified, prevent one or more clients of the API from making API call permission requests until the wait duration has passed.

### Claim 2 (depends on 1)

The method of claim 1, wherein the application includes a plurality of horizontally scaled nodes configured to send the API call permission request datastructure concurrently with one or more additional API call permission requests.

### Claim 3 (depends on 1)

The method of claim 1, wherein a rate-limit associated with a scope is adjusted in response to the API not publishing a rate-limit.

### Claim 4 (depends on 1)

The method of claim 1, wherein a machine learning technique is used to determine which scopes in the set of scopes specified in the API call permission request datastructure were under heavy load when the API previously returned a throttled response.

### Claim 5 (depends on 4)

The method of claim 4, wherein the machine learning technique is a neural network.

### Claim 6 (depends on 1)

The method of claim 1, wherein the API is configured to allow one or more clients to asynchronously submit details of a plurality of API call permission requests and a gatekeeper is configured to make the plurality of API call permission requests on behalf of the clients.

### Claim 7 (depends on 6)

The method of claim 6, wherein the gatekeeper is further configured to asynchronously send a plurality of API call permission responses back to the one or more clients.

### Claim 8

An apparatus, comprising:
a processor; and
computer memory holding computer program instructions that when executed by the processor improve an operation of a multi-tenant shared computing infrastructure by reducing tenant-level throttle responses from third party rate-limited APIs, the computer program instructions comprising:
provide a set of accessor usage profiles, at least one accessor usage profile representing legitimate behavior in the multi-tenant shared computing infrastructure by defining a time period, at least one usage constraint, and an accessor type,
operate upon receipt from an accessor of a request to access a given application in the multi-tenant shared computing infrastructure to select a given accessor usage profile from the set of usage profiles;
operate upon matching the accessor type to apply the at least one usage constraint in the given accessor usage profile with respect to the defined time period to determine whether the request to access the given application should proceed; and
respond to a determination that permitting the request to access triggers the at least one usage constraint in the given accessor usage profile with respect to the defined time period, to provide the given application a notification.

### Claim 9 (depends on 8)

The apparatus of claim 8, wherein the given application includes a plurality of horizontally scaled nodes configured to send the request concurrently with one or more additional API call permission requests.

### Claim 10 (depends on 8)

The apparatus of claim 8, wherein at least one of the third party rate-limited APIs includes a rate-limit that is not published.

### Claim 11 (depends on 8)

The apparatus of claim 8, wherein a machine learning technique is used to determine which scopes in a set of scopes specified in the request were under heavy load when the third party rate-limited APIs previously returned the tenant-level throttle responses.

### Claim 12 (depends on 8)

The apparatus of claim 8, wherein the third party rate-limited APIs are configured to allow one or more clients to asynchronously submit details of a plurality of API call permission requests and a gatekeeper is configured to make the plurality of API call permission requests on behalf of the clients.

### Claim 13 (depends on 12)

The apparatus of claim 12, wherein the gatekeeper is further configured to asynchronously send a plurality of API call permission responses back to the one or more clients.

### Claim 14

An apparatus, comprising:
at least one memory;
a component collection stored in the at least one memory, the component collection comprising a component collection storage; and
at least one processor disposed in communication with the at least one memory, the at least one processor executing processor-executable instructions from the component collection, the component collection storage structured with processor-executable instructions, comprising:
obtain, via the at least one processor, an API call permission request datastructure associated with an API call of an application, in which the API call permission request datastructure is structured to identify an API and a set of scopes, wherein the API has an unpublished rate-limit;
determine, via the at least one processor, a retry-after interval for one or more scopes in the set of scopes, in which existence of a retry-after interval for a given scope indicates that the API previously returned a throttled response for the given scope;
determine, via the at least one processor, a wait duration associated with the API call, in which the wait duration is determined as a maximum retry-after interval across retry-after intervals that exist for any scope in the set of scopes;
provide, via the at least one processor, an API call permission response datastructure, in which the API call permission response datastructure is structured to specify the wait duration; and
in response to the wait duration being specified, prevent one or more clients of the API from making API call permission requests until the wait duration has passed.

### Claim 15 (depends on 14)

The apparatus of claim 14, wherein the application includes a plurality of horizontally scaled nodes configured to send the API call permission request datastructure concurrently with one or more additional API call permission requests.

### Claim 16 (depends on 14)

The apparatus of claim 14, wherein the processor-executable instructions further comprise:
in response to determining the retry-after interval for each scope in the set of scopes, adjust one or more rate-limits associated with the one or more scopes in the set of scopes.

### Claim 17 (depends on 14)

The apparatus of claim 14, wherein a machine learning technique is used to determine which scopes in the set of scopes specified in the API call permission request datastructure were under heavy load when the API previously returned a throttled response.

### Claim 18 (depends on 17)

The apparatus of claim 17, wherein the machine learning technique is a neural network.

### Claim 19 (depends on 14)

The apparatus of claim 14, wherein the API is configured to allow one or more clients to asynchronously submit details of a plurality of API call permission requests and a gatekeeper is configured to make the plurality of API call permission requests on behalf of the clients.

### Claim 20 (depends on 19)

The apparatus of claim 19, wherein the gatekeeper is further configured to asynchronously send a plurality of API call permission responses back to the one or more clients.
