API Obfuscation via Polarization Library for IP Protection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Businesses face challenges in protecting their intellectual property as open APIs can be accessed by competitors, allowing them to deduce system knowledge and data, which can hinder collaboration between competitors working with the same customer.

Innovation Solution

The creation of an obfuscator API that uses a polarization library to rename endpoints and parameters of a root API, matching the structure of a distinct industry category, thereby preventing reverse engineering and maintaining intellectual property security while allowing competitors to interact through the obfuscated API.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If API endpoints and parameters are made human-readable and documented using standards like Swagger.io, then ease of operation and collaboration are improved, but intellectual property security deteriorates as competitors can easily copy and deduce system knowledge

Engineering Contradiction:
ImproveAPI usabilityVSAvoidIntellectual property security
Core Design Contradiction:
Ease of operationVSLoss of information

Solution Approach 1:

The patent applies inversion by creating obfuscated API endpoints that deliberately use non-descriptive, randomized naming conventions opposite to the clear, human-readable naming used in traditional APIs. This allows the system to maintain usability through documentation while actively preventing intellectual property deduction by making endpoint names meaningless to competitors

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent introduces an intermediary layer of obfuscation between the actual API functionality and the exposed interface. This intermediary layer includes obfuscated endpoint names and parameter names that act as a veil, allowing legitimate users to access functionality through documentation while blocking competitors from deducing the underlying system architecture and intellectual property

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If API documentation is made publicly accessible to enable collaboration, then productivity and collaboration are improved, but reliability of intellectual property protection deteriorates as competitors gain access to system knowledge

Engineering Contradiction:
ImproveCollaboration efficiencyVSAvoidIntellectual property protection
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The patent inverts the traditional approach to API documentation by generating documentation that describes obfuscated, non-descriptive endpoint names rather than clear, meaningful names. This allows collaboration to proceed through documented interfaces while the inverted naming convention prevents competitors from gaining intellectual property insights

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent segments the API interface into two distinct layers: the obfuscated public interface with randomized endpoint names for collaboration purposes, and the protected internal implementation. This segmentation allows productivity through documentation while maintaining reliability of intellectual property protection by isolating the meaningful naming from the exposed interface

Inventive Principle:
Principle #1Segmentation

3Ease of operation

If API endpoints use descriptive naming conventions, then ease of operation is improved, but device complexity increases due to the need for obfuscation mechanisms

Engineering Contradiction:
ImproveAPI usabilityVSAvoidSystem complexity
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent creates a copied interface layer that mimics the structure of traditional APIs but uses obfuscated naming conventions. This copy maintains the necessary endpoints and parameters for functionality while replacing descriptive names with randomized alternatives, thereby maintaining ease of operation through documentation while avoiding the complexity of implementing sophisticated obfuscation mechanisms

Inventive Principle:
Principle #26Copying

Data Source

PatentUS20240061734A1Application programming interface obfuscation systems and methods
Publication Date: 2024.02.22 BOOST SUBSCRIBERCO LLC
  • US20240061734A1 patent drawing
  • US20240061734A1 patent drawing
  • US20240061734A1 patent drawing

AI summary

A method for obfuscating an application programming interface (API) can include creating a polarization library. The library can include for each of a plurality of websites: website endpoints, corresponding website endpoint parameters, and an assigned industry category. An API structure of a root API to be obfuscated can be extracted, including root endpoints and corresponding root endpoint parameters. An industry category can be identified for the root API and a website is selected from the polarization library that is in an industry category that is distinct from the root API category. An obfuscator API is created with the extracted API structure using website endpoints and website endpoint parameters from the selected website that match the structure of the root API.