Unified API Mediation for Multi-Manufacturer People Conveyors

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current elevator and escalator APIs are manufacturer-specific, requiring users to develop and maintain multiple systems for different manufacturers, leading to complex, time-consuming, and expensive integrations, and limiting maintenance capabilities across competitor equipment.

Innovation Solution

A unified application programming interface (API) system that translates and processes requests and responses between different elevator, escalator, and access gate systems, allowing integration and control through a single interface regardless of manufacturer.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If manufacturer-specific APIs are used for elevator and escalator systems, then each manufacturer can control their own equipment, but users must develop and maintain multiple separate systems for different manufacturers, increasing integration complexity and cost

Engineering Contradiction:
ImproveAPI compatibility across manufacturersVSAvoidnumber of API implementations
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent introduces a communication protocol that acts as an intermediary layer between external systems and manufacturer-specific elevator/escalator systems. This protocol translates requests from a unified interface into manufacturer-specific API calls, eliminating the need for users to implement multiple separate systems while preserving manufacturer control over their equipment.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent creates a universal communication protocol that can interface with multiple different manufacturers' systems through a single standardized interface. This multi-functional protocol handles various manufacturer-specific systems (e.g., Otis, Schindler, Kone) through one unified API, reducing integration complexity and cost while maintaining adaptability across different equipment types.

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

2Adaptability or versatility

If multiple manufacturer-specific APIs are implemented, then integration with different equipment is possible, but the integration process becomes complex, time-consuming and expensive

Engineering Contradiction:
Improvemulti-manufacturer integration capabilityVSAvoidintegration development time
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The communication protocol serves as a mediator that translates unified interface requests into manufacturer-specific API calls automatically. This eliminates manual integration work for each manufacturer, significantly reducing development time while maintaining the ability to integrate with multiple manufacturers' equipment.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent pre-implements the communication protocol with built-in translation capabilities for multiple manufacturers' systems. This preliminary preparation allows users to integrate with different manufacturers' equipment without needing to develop separate integration solutions for each, thereby reducing overall integration time and cost.

Inventive Principle:
Principle #10Preliminary action

3Adaptability or versatility

If manufacturer-specific APIs are used, then equipment control is maintained by manufacturers, but maintenance services for competitor equipment become difficult due to unknown communication protocols

Engineering Contradiction:
Improvemaintenance capability across manufacturersVSAvoidcommunication protocol knowledge required
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The communication protocol acts as a standardized intermediary that maintenance personnel can use to interface with any manufacturer's equipment uniformly. This eliminates the need for maintenance staff to learn multiple different communication protocols, making maintenance services accessible across all manufacturers while preserving each manufacturer's control over their equipment.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Adaptability or versatility

If multiple separate API systems are maintained, then manufacturer-specific functionality is preserved, but development, maintenance and testing costs increase

Engineering Contradiction:
Improvemanufacturer-specific controlVSAvoidintegration cost and effort
Core Design Contradiction:
Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The communication protocol serves as a cost-effective intermediary that preserves manufacturer-specific functionality while providing a unified interface for external systems. This approach maintains manufacturer control over their equipment's specific features while significantly reducing the development, maintenance and testing costs associated with multiple separate API systems.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent implements a universal communication protocol that can interface with multiple manufacturers' systems through a single standardized API. This multi-functional protocol reduces integration costs and effort while preserving manufacturer-specific control, as the same protocol handles various manufacturer systems without requiring separate development for each.

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

Data Source

PatentEP4592235A1A method, an arrangement and a people conveyor and/or an access gate system for handling application programming interface requests
Publication Date: 2025.07.30 KONE OYJ
  • EP4592235A1 patent drawingFigure 1
  • EP4592235A1 patent drawingFigure 2
  • EP4592235A1 patent drawingFigure 3

AI summary

An arrangement, a people conveyor and/or an access gate system and a method for handling people conveyor and/or access gate system application programming interface (API) requests, the method comprising receiving a request through a primary people conveyor and/or access gate system application programming interface (API), determining the target system of the request, based on the identified target system of the request being a first provider people conveyor and/or access gate system, sending the request, e.g. without processing, to an application programming interface (API) of the first provider people conveyor and/or access gate system, and based on the identified target system of the request being a second or further provider people conveyor and/or access gate system, processing the request and sending the processed request to an application programming interface (API) of the second or further provider people conveyor and/or access gate system and/or a controlling interface of the second or further provider people conveyor and/or access gate system.