API Call Filtering via Unique UE Identifiers

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current network security systems face challenges in effectively distinguishing between authorized and unauthorized traffic, particularly in automated attacks, as they often require manual user interaction to thwart unauthorized access, which can hinder legitimate automated actions and increase costs for both users and service providers.

Innovation Solution

An API call filtering system that personalizes API requests by requiring a unique user equipment installation number (UEIN) for each request, using it to differentiate between ordinary and excessive request iterations, and incorporates a challenge-response mechanism to verify the authenticity of the UE, thereby limiting automated attacks while allowing legitimate access.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If automated filtering systems are used to block unwanted traffic, then the ability to separate wanted from unwanted traffic is improved, but the system complexity and cost increase

Engineering Contradiction:
Improvetraffic filtering effectivenessVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the API traffic filtering by creating individualized API instances for each user equipment (UE). Each API is uniquely identified and can be independently configured with specific rate limits and authentication parameters. This segmentation allows the system to handle different traffic types with different security policies without requiring a single complex monolithic filtering system.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary action by requiring authentication and establishing rate limits before actual API access occurs. The system pre-configures each individualized API with authorized user identities and predetermined rate thresholds, so that when requests arrive, the filtering decision can be made immediately based on pre-established criteria rather than requiring complex real-time analysis.

Inventive Principle:
Principle #10Preliminary action

2Object-affected harmful factors

If rate limiting is applied to all API requests, then automated attacks are reduced, but legitimate automated actions are also hindered

Engineering Contradiction:
Improveautomated attack reductionVSAvoidlegitimate automated access
Core Design Contradiction:
Object-affected harmful factorsVSEase of operation

Solution Approach 1:

The patent applies local quality by allowing different rate limits and authentication requirements for different individualized APIs. Each API can be configured with its own specific rate threshold based on the particular service, user, and security requirements. This means that legitimate automated actions on APIs with higher permitted rates are not hindered, while attacks on sensitive APIs with lower rates are effectively blocked.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

The patent implements dynamics by making rate limits configurable and adjustable for each individualized API. The system can dynamically modify rate thresholds, authentication methods, and other parameters based on observed traffic patterns, threat levels, and service requirements. This allows the system to adapt to changing conditions without requiring manual reconfiguration of a global policy.

Inventive Principle:
Principle #15Dynamics

3Reliability

If manual user interaction is required to thwart unauthorized access, then security is improved, but user convenience and productivity decrease

Engineering Contradiction:
Improveunauthorized access preventionVSAvoiduser access efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent applies self-service by implementing automated authentication and rate limiting enforcement that operates without requiring manual user intervention. The individualized APIs automatically verify user identities, check request rates against configured thresholds, and enforce access decisions. This eliminates the need for manual security checks while maintaining strong authentication, thereby preserving both security and user productivity.

Inventive Principle:
Principle #25Self-service

4Object-affected harmful factors

If individualized APIs with unique identifiers are implemented, then automated attacks become uneconomical, but the complexity of API management increases

Engineering Contradiction:
Improveattack cost effectivenessVSAvoidAPI management complexity
Core Design Contradiction:
Object-affected harmful factorsVSDevice complexity

Solution Approach 1:

The patent applies universality by creating a standardized framework for individualized APIs that can be applied across multiple services and users. The core mechanism of unique API identification, authentication, and rate limiting is universal and can be consistently applied to different APIs and user contexts. This standardized approach reduces management complexity compared to creating custom security solutions for each API.

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

Solution Approach 2:

The patent implements parameter changes by allowing flexible configuration of rate limits, authentication methods, and other parameters for each individualized API. Rather than requiring fundamentally different management approaches for different APIs, the system uses a consistent framework where parameters can be adjusted to meet specific requirements. This makes the system adaptable without increasing structural complexity.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentEP3629152B1Using individualized apis to block automated attacks on native apps and/or purposely exposed apis
Publication Date: 2023.11.08 SHAPE SECURITY INC
  • EP3629152B1 patent drawingFigure 1
  • EP3629152B1 patent drawingFigure 2
  • EP3629152B1 patent drawingFigure 3

AI summary

An API call filtering system filters responses to API call requests received, via a network, from UEs. The API call filtering system is configured to require personalized API call requests wherein each API call (except for some minor exceptions) includes a unique UE identifier ("UEIN") of the UE making the request. Using the UEIN, the web service or other service protected by the API call filtering system can be secured against excessive request iterations from a set of rogue UEs while allowing for ordinary volumes of requests of requests the UEs, wherein one or more boundaries between what is deemed to be an ordinary volume of requests and what is deemed to be excessive request iterations are determined by predetermined criteria.