Middleware for Secure Cross-Network Task Automation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Cloud platform applications face communication gaps that hinder fully-automated end-to-end processes due to security restrictions, preventing direct communication from external networks to internal networks.

Innovation Solution

Implementing middleware within the internal network to facilitate communication between external applications and internal systems using a standardized REST API, enabling secure and automated task processing across networks.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Extent of automation

If direct communication from external cloud applications to internal network is allowed, then automation capability is improved, but network security is compromised

Engineering Contradiction:
Improveend-to-end process automationVSAvoidnetwork security risk
Core Design Contradiction:
Extent of automationVSObject-affected harmful factors

Solution Approach 1:

The patent introduces middleware as an intermediary component deployed within the internal network that receives requests from external cloud applications and forwards them to internal systems. This mediator enables automated end-to-end processes while maintaining security boundaries, as the middleware acts as a controlled gateway rather than allowing direct external access to internal networks.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If middleware is deployed within internal network to enable communication, then communication capability is improved, but device complexity increases

Engineering Contradiction:
Improvecommunication capabilityVSAvoidsystem architecture complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The middleware is designed as a universal communication framework that handles multiple communication scenarios through a single standardized interface. It provides unified authentication, authorization, and routing capabilities for various types of requests (data access, process invocation, file transfer), eliminating the need for separate communication mechanisms for each scenario and reducing overall system complexity.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The communication framework is segmented into distinct functional layers: a standardized interface layer for external applications, a middleware layer for authentication and routing, and internal system interfaces. This segmentation allows each layer to be independently developed, tested, and maintained, reducing the complexity of the overall system while improving adaptability.

Inventive Principle:
Principle #1Segmentation

3Ease of operation

If standardized API is implemented for communication, then ease of operation is improved, but implementation complexity increases

Engineering Contradiction:
ImproveAPI usage simplicityVSAvoidimplementation complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent implements standardized API interfaces that replicate common operational patterns and data structures used by external cloud applications. By copying these familiar interfaces into the internal network communication protocol, the system maintains ease of operation for developers while enabling secure internal communication. The standardized interfaces act as templates that simplify request formation and response parsing.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS11496443B2Middleware to enable end-to-end processes with limited network communication
Publication Date: 2022.11.08 SAP SE
  • US11496443B2 patent drawing
  • US11496443B2 patent drawing
  • US11496443B2 patent drawing

AI summary

Disclosed herein are system, apparatus, method, and computer program product embodiments for securing inter-network communications. An embodiment operates by generating a task request to be performed in a first network environment. The embodiment further operates by transmitting the task request to an application located in a second network environment. The embodiment further operates by receiving a task package from the application. The embodiment further operates by determining whether the task package includes a positive task value and, if so, calling a task in the first network environment based on the task package. The embodiment further operates by generating a creation status associated with an execution of the task in the first environment and transmitting the creation status to the application. Subsequently, the embodiment further operates by generating a final status associated with the execution of the task and transmitting the final status to the application.