# US 2026/0093572 A1 · Intelligent Data Flow Control Valve

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

- Number: US 2026/0093572 A1
- Document ID: US20260093572A1
- Status: Published application
- Kind: A1
- Application number: 18/901,606
- Filed: 2024-09-30
- Published: 2026-04-02
- Earliest claimed: 2024-09-30
- Assignees: Oracle International Corporation
- Applicants: Oracle International Corporation
- Inventors: Mahesh Muthulankkat; Prabakar Paulsami
- Web page: https://patentgrep.com/patent/US20260093572A1

## CPC

- G06F 11/0793: {Remedial or corrective actions (recovery from an exception in an instruction pipeline G06F9/3861; by retry G06F11/1402; for recovering from a failure of a protocol instance or entity H04L69/40)}
- G06F 11/0709: {in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems}
- G06F 11/30: Monitoring
- H04L 67/60: Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources (admission control or resource allocation H04L47/70)
- H04L 69/321: Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
- 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

A system for intelligent data flow control monitors an activity stream of an integration layer that processes events from an upstream system and transmits data to a downstream system. Upon detecting a recoverable error between the integration layer and the downstream system, the system instructs the upstream system to pause sending additional events. The system continues monitoring the activity stream to detect when the recoverable error is fixed. Once the error is resolved, the system instructs the upstream system to resume sending events to the integration layer. This approach prevents data loss during temporary system disruptions while maintaining efficient event processing flow.

## Claims

### Claim 1

One or more non-transitory computer readable media comprising instructions which, when executed by one or more hardware processors, cause performance of operations comprising:
monitoring an activity stream of an integration layer that is configured to (a) receive events from an upstream system and (b) transmit data to a downstream system responsive to the events;
detecting, while monitoring the activity stream, a recoverable error between the integration layer and the downstream system;
responsive to detecting the recoverable error: instructing the upstream system to pause sending additional events to the integration layer;
after instructing the upstream system to pause sending additional events to the integration layer:
detecting that the recoverable error is fixed; and
responsive to detecting that the recoverable error is fixed: instructing the upstream system to resume sending additional events to the integration layer.

### Claim 2 (depends on 1)

The non-transitory media of claim 1, wherein detecting that the recoverable error is fixed comprises:
detecting that the integration layer has successfully processed one or more failed events received before the upstream system paused sending events to the integration layer.

### Claim 3 (depends on 1)

The non-transitory media of claim 1, wherein monitoring the activity stream of the integration layer comprises collecting error data from the integration layer, wherein the error data comprises hypertext transfer protocol (HTTP) status codes and error messages.

### Claim 4 (depends on 1)

The non-transitory media of claim 1, wherein the operations further comprise:
using a machine learning model to generate a learning report comprising one or more error detection parameters for detecting recoverable errors;
wherein the one or more error detection parameters comprise one or more of a hypertext transfer protocol (HTTP) status code, an error message pattern, a count of similar continuous errors, a time window for errors, or a time needed for recovery; and
wherein detecting the recoverable error is based at least in part on the one or more error detection parameters in the learning report.

### Claim 5 (depends on 4)

The non-transitory media of claim 4, wherein the learning report is user-reviewable, and wherein the operations further comprise receiving user input comprising one or more user adjustments to one or more error detection parameters in the learning report.

### Claim 6 (depends on 4)

The non-transitory media of claim 4, wherein the operations further comprise:
training the machine learning model to identify recoverable errors.

### Claim 7 (depends on 1)

The non-transitory media of claim 1, wherein the recoverable error comprises at least one of: a planned outage, an unplanned outage, a password expiration, or a permission issue.

### Claim 8 (depends on 1)

The non-transitory media of claim 1, wherein the operations further comprise routing retry requests to the integration layer based on stored instance identifiers associated with one or more failed events.

### Claim 9

A method comprising:
monitoring an activity stream of an integration layer that is configured to (a) receive events from an upstream system and (b) transmit data to a downstream system responsive to the events;
detecting, while monitoring the activity stream, a recoverable error between the integration layer and the downstream system;
responsive to detecting the recoverable error: instructing the upstream system to pause sending additional events to the integration layer;
after instructing the upstream system to pause sending additional events to the integration layer:
detecting that the recoverable error is fixed; and
responsive to detecting that the recoverable error is fixed: instructing the upstream system to resume sending additional events to the integration layer; wherein the method is performed by at least one device including a hardware processor.

### Claim 10 (depends on 1)

The method of claim 1, wherein detecting that the recoverable error is fixed comprises:
detecting that the integration layer has successfully processed one or more failed events received before the upstream system paused sending events to the integration layer.

### Claim 11 (depends on 9)

The method of claim 9, wherein monitoring the activity stream of the integration layer comprises collecting error data from the integration layer, wherein the error data comprises hypertext transfer protocol (HTTP) status codes and error messages.

### Claim 12 (depends on 9)

The method of claim 9, wherein the operations further comprise:
using a machine learning model to generate a learning report comprising one or more error detection parameters for detecting recoverable errors;
wherein the one or more error detection parameters comprise one or more of a hypertext transfer protocol (HTTP) status code, an error message pattern, a count of similar continuous errors, a time window for errors, or a time needed for recovery; and
wherein detecting the recoverable error is based at least in part on the one or more error detection parameters in the learning report.

### Claim 13 (depends on 12)

The method of claim 12, wherein the learning report is user-reviewable, and wherein the operations further comprise receiving user input comprising one or more user adjustments to one or more error detection parameters in the learning report.

### Claim 14 (depends on 12)

The method of claim 12, wherein the operations further comprise:
training the machine learning model to identify recoverable errors.

### Claim 15 (depends on 9)

The method of claim 9, wherein the recoverable error comprises at least one of: a planned outage, an unplanned outage, a password expiration, or a permission issue.

### Claim 16 (depends on 9)

The method of claim 9, wherein the operations further comprise routing retry requests to the integration layer based on stored instance identifiers associated with one or more failed events.

### Claim 17

A system comprising:
at least one device including a hardware processor;
the system being configured to perform operations comprising:
monitoring an activity stream of an integration layer that is configured to (a) receive events from an upstream system and (b) transmit data to a downstream system responsive to the events;
detecting, while monitoring the activity stream, a recoverable error between the integration layer and the downstream system;
responsive to detecting the recoverable error: instructing the upstream system to pause sending additional events to the integration layer;
after instructing the upstream system to pause sending additional events to the integration layer: detecting that the recoverable error is fixed; and
responsive to detecting that the recoverable error is fixed: instructing the upstream system to resume sending additional events to the integration layer.

### Claim 18 (depends on 17)

The system of claim 17, wherein detecting that the recoverable error is fixed comprises:
detecting that the integration layer has successfully processed one or more failed events received before the upstream system paused sending events to the integration layer.

### Claim 19 (depends on 18)

The system of claim 18, wherein monitoring the activity stream of the integration layer comprises collecting error data from the integration layer, wherein the error data comprises hypertext transfer protocol (HTTP) status codes and error messages.

### Claim 20 (depends on 18)

The system of claim 18, wherein the operations further comprise:
using a machine learning model to generate a learning report comprising one or more error detection parameters for detecting recoverable errors;
wherein the one or more error detection parameters comprise one or more of a hypertext transfer protocol (HTTP) status code, an error message pattern, a count of similar continuous errors, a time window for errors, or a time needed for recovery; and
wherein detecting the recoverable error is based at least in part on the one or more error detection parameters in the learning report.
