Configurable API Access Constraints via Dynamic Filter Segmentation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional APIs in distributed software systems are inflexible, requiring a custom design for each external view and necessitating updates whenever internal services change, limiting their ability to provide customizable access constraints based on various factors.

Innovation Solution

The development of a customizable API system that allows dynamic configuration of access constraints based on user authorization levels, licenses, access groups, and operational modes, enabling the API to be adjusted by an orchestrator or network operator to restrict access to internal data and software components.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a static, monolithic API definition is used, then the API structure is simple and fixed, but the system cannot provide customizable access constraints or adapt to changing internal services

Engineering Contradiction:
Improvecustomizable access constraintsVSAvoidAPI configuration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the monolithic API definition into multiple independent filter components, each handling a specific access constraint dimension (user access level, authorization, license, access group, operational mode). This allows each filter to be configured and adjusted independently, providing customizable access constraints without requiring complex monolithic changes.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent transforms the static API definition into a dynamic system where filter configurations can be adjusted at runtime based on operational conditions, user roles, and service changes. The orchestrator can modify filter settings without regenerating the entire API, enabling adaptability while maintaining manageable complexity through centralized control.

Inventive Principle:
Principle #15Dynamics

2Productivity

If internal services change, then the system functionality is updated, but a new API must be generated and external resources must be updated

Engineering Contradiction:
Improveservice update efficiencyVSAvoidAPI regeneration time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent establishes filter templates and configurations in advance that define access constraints for different scenarios. When internal services change, the pre-configured filters can be selectively applied or adjusted without requiring complete API regeneration, significantly reducing update time and improving service deployment efficiency.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent creates a universal filter configuration system that can handle multiple access constraint types (user level, authorization, license, access group, operational mode) through a unified framework. This multi-functional approach allows a single API definition to serve multiple service configurations, eliminating the need to generate new APIs for each service change.

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

3Reliability

If a northbound service gateway is created to hide internal data, then external user access is controlled, but the design requires custom development and cannot easily adapt to service changes

Engineering Contradiction:
Improvedata securityVSAvoidgateway design complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements data security through configurable filter parameters rather than hard-coded gateway logic. Access constraints are defined by adjustable parameters (user access level, authorization credentials, license keys, access groups, operational modes) that can be modified to adapt to service changes while maintaining security. This parameter-driven approach reduces design complexity compared to custom gateway development.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11579950B2Configuring an API to provide customized access constraints
Publication Date: 2023.02.14 CIENA CORP
  • US11579950B2 patent drawing
  • US11579950B2 patent drawing
  • US11579950B2 patent drawing

AI summary

A computing system includes a processing device and a memory device configured to store an Application Programming Interface (API) and computer software. The computer software has a plurality of software components configured to enable the processing device to utilize internal data for performing a plurality of functions. The API is configured to define interactions between the software components and is further configured to define access constraints with respect to the computing system. The access constraints are configured to restrict access by an end user associated with the computing system with respect to the internal data and software components. Also, the computer software is configured to adjust the access constraints of the API.