Interchange Server Mediating Client API Translation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing image upload services require clients to install multiple service provider-specific programs and APIs, leading to memory constraints and burdensome updates, as well as risks of processing errors due to the uniqueness of each service provider's API.

Innovation Solution

An intermediary interchange server manages communication between client devices and multiple service-offering servers using a common program and API, translating input data into service-specific formats and handling responses, allowing clients to access various services without needing unique APIs for each provider.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple service provider-specific programs and APIs are installed on the client device, then access to multiple image upload services is enabled, but memory constraints and device complexity increase

Engineering Contradiction:
Improveaccess to multiple servicesVSAvoidmemory burden
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a common program that acts as an intermediary between the client device and multiple service providers. This common program includes a service selection screen generation unit that creates unified interfaces, a service selection unit that manages provider selection, and a service execution unit that handles communication. By mediating all interactions through this single common program, the system eliminates the need to install multiple provider-specific programs, thus reducing memory burden while maintaining access to multiple services.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The common program is designed with universal functionality to handle multiple service providers through a single interface. It includes a service selection screen generation unit that can generate interfaces for different providers, a service selection unit that manages provider selection, and a service execution unit that adapts communication protocols. This multi-functional design allows one program to replace multiple specialized programs, reducing device memory requirements while maintaining versatility.

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

2Reliability

If service provider-specific APIs are used, then accurate communication with each service is achieved, but the risk of processing errors increases due to API uniqueness

Engineering Contradiction:
Improvecommunication accuracyVSAvoidprocessing errors
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The common program serves as an intermediary layer between the client and service providers, standardizing communication protocols. The service execution unit within the common program handles all API interactions, translating between the unified interface and provider-specific requirements. This mediation reduces processing errors by centralizing error handling and validation logic in one location, while maintaining accurate communication with each provider through standardized translation layers.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The service execution unit dynamically changes communication parameters based on the selected service provider. It adapts data formats, protocols, and interaction patterns according to the target provider's requirements while maintaining a consistent interface for the user. This parameter adaptation allows accurate communication with each provider without exposing the user to provider-specific complexities or error risks.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If multiple provider-specific programs are installed, then service access is enabled, but update burden and maintenance complexity increase

Engineering Contradiction:
Improveservice access capabilityVSAvoidupdate burden
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The common program consolidates functionality to access multiple service providers into a single updateable unit. Instead of managing updates for multiple separate provider-specific programs, the system only needs to update the common program, which contains the service selection screen generation unit, service selection unit, and service execution unit. This universal design dramatically reduces update burden and maintenance complexity while preserving access to multiple services.

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

Solution Approach 2:

The patent merges multiple provider-specific program functionalities into a single common program that handles service selection, interface generation, and execution. By combining what would otherwise be separate updateable components into one unified program, the system eliminates the need for multiple update cycles and reduces maintenance overhead, while still providing access to diverse service providers through the integrated architecture.

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentEP2321738B1Client device, information processing system and associated methodology of accessing networked sevices
Publication Date: 2019.01.23 SONY GROUP CORP
  • EP2321738B1 patent drawingFigure 1
  • EP2321738B1 patent drawingFigure 2
  • EP2321738B1 patent drawingFigure 3

AI summary

A system makes it possible to use services offered by a plurality of servers different from one another is realized with the use of a common API. The system includes a plurality of service-offering servers, a client that uses services offered by the plurality of service- offering servers, and an interchange server that performs intermediary processing when the client uses a service. The client performs communication with the interchange server while using a common API when using any service among a plurality of services offered by the plurality of service-offering servers. The interchange server uses a unique API, which is unique to the service-offering server that offers the service selected by the client, to execute a processing sequence that is unique to the service-offering server. The client may use any service among services offered by the plurality of service-offering servers with the use of a common API without any need to use a unique API, which is unique to each of the plurality of service-offering servers.