Security Module Internal Virtual Terminal for Inter-Application Communication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing security modules lack a simple and flexible method for inter-application data exchange, particularly when an application is introduced after the security module is already operational, and current methods like the 'Sharable Interface' require additional interfaces and memory management complexities.

Innovation Solution

Implementing a security module with an internal virtual terminal that redirects commands between applications, allowing them to communicate using conventional commands and enabling the use of existing APDU interfaces and Clear on Deselect (CoD) memory, while providing a virtual interface for data exchange.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the Sharable Interface is used for data exchange between applications, then applications can exchange data securely, but the called application must provide an interface and Clear on Deselect memory cannot be used

Engineering Contradiction:
Improvesecure data exchangeVSAvoidinterface provision requirement
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces a virtual terminal as an intermediary component that mediates communication between applications. Instead of requiring the called application to provide a Sharable Interface, the virtual terminal acts as a mediator that receives commands from the first application and forwards them to the second application, thereby eliminating the interface provision requirement while maintaining secure data exchange

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The virtual terminal provides universal communication capabilities that work with any application regardless of whether it implements specific interfaces. It offers a standardized command interface that can interact with multiple different applications, making the system more adaptable and versatile without requiring each application to provide custom interface implementations

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

2Adaptability or versatility

If existing applications are not modified for inter-application communication, then application compatibility is maintained, but a new communication mechanism must be introduced

Engineering Contradiction:
Improveapplication compatibilityVSAvoidcommunication mechanism
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The virtual terminal serves as an intermediary that bridges existing applications without requiring modifications to them. It intercepts and forwards commands between applications, allowing legacy applications to communicate seamlessly while maintaining their original code and interface designs, thus preserving compatibility without adding complexity to existing applications

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The communication mechanism is segmented into distinct components: the virtual terminal handles command routing and protocol management, while existing applications remain independent and unmodified. This segmentation isolates the complexity to the virtual terminal layer, allowing existing applications to remain simple and compatible

Inventive Principle:
Principle #1Segmentation

Data Source

PatentEP2740070B1Mechanism for communicating between two applications on a safety module
Publication Date: 2018.10.10 GIESECKE & DEVRIENT EPAYMENTS GMBH
  • EP2740070B1 patent drawingFigure 1
  • EP2740070B1 patent drawingFigure 2
  • EP2740070B1 patent drawingFigure 3

AI summary

The invention describes a method for operating a safety module, having the steps of transmitting data from a first application (10) to a second application (12) in the safety module and of using the transmitted data in the second application (12). The transmitted data comprises a command for the second application (12). The second application (12) carries out the command in the use step. In the transmission step, the first application (10) calls an internal diversion to the second application (12). The safety module diverts the command internally in such a way that it is received by the second application (12) as a conventional command which is received from outside the safety module.