Server API Execution Detection via Dynamic Certification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing network communication systems lack the ability to accurately detect when a second server is called by a client, particularly in systems requiring high security like Internet banking, due to the difficulty in recognizing and verifying the use of API services without masquerading.

Innovation Solution

A network communication method and system that generates and collates execution certification information based on dynamic common information, allowing the first server to detect the execution of the second server, thereby preventing masquerading and ensuring accurate detection.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If conventional API service usage is allowed without verification, then ease of operation is improved, but security and reliability deteriorate due to inability to detect masquerading

Engineering Contradiction:
Improveease of operationVSAvoidsecurity
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The web server performs preliminary actions by generating execution certification information and including it in the returned contents before the client makes the API call. This allows the server to have verification data ready in advance, enabling later detection of whether the API was actually called without adding complex verification steps during the API execution itself.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system implements feedback by having the client send the received execution certification information back to the web server after making the API call. The web server then compares this returned information with its own generated information to determine whether the API was actually executed, creating a closed-loop verification mechanism.

Inventive Principle:
Principle #23Feedback

2Reliability

If execution detection mechanisms are implemented, then security is improved, but device complexity increases due to additional verification steps

Engineering Contradiction:
ImprovesecurityVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The web server creates a copy of the execution certification information and includes it in the returned contents. The client simply echoes this copied information back to the server, avoiding the need for complex verification logic on either side. The server then compares the returned copy with its original to determine API execution status.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The execution certification information acts as an intermediary element between the web server and the API server. Instead of the web server directly monitoring or controlling the API server, it uses this certification information as a mediator to indirectly verify whether the API was called, simplifying the detection mechanism.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Measurement precision

If direct monitoring of API server is implemented, then measurement precision is improved, but device complexity increases due to direct control requirements

Engineering Contradiction:
Improvedetection accuracyVSAvoiddevice complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The execution certification information serves as an intermediary that enables the web server to monitor API server execution without requiring direct control or communication channels between the web server and API server. This maintains measurement precision while avoiding the complexity of direct monitoring infrastructure.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The API server essentially performs self-verification by including the execution certification information in its response to the client. The client then automatically returns this information to the web server, creating a self-service verification mechanism that achieves accurate detection without requiring the web server to implement complex monitoring of the API server.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP3279800B1Network communication method and network communication system
Publication Date: 2020.12.30 SECUREBRAIN CORP
  • EP3279800B1 patent drawingFigure 1
  • EP3279800B1 patent drawingFigure 2
  • EP3279800B1 patent drawingFigure 3

AI summary

[Objective] To provide a technique for allowing, in a network communication system consisting of a first server for sending contents to a client and a second server for executing an application upon being called from the client, the first server to appropriately detect that the second server is called. [Solution Means] In a communication method in a network communication system composed of a first server, a second server, and a client, when predetermined contents are sent to the client from the first server, API information for executing an application program of the second server is included in the contents, and the application is executed on the second server by an API call from the client. During this, the second server generates execution certification information on the basis of dynamic common information that changes dynamically, and sends to the client the execution certification information along with the application execution result. The client sends the execution certification information to the first server, and the first server detects the execution of the application program on the second server.