Container Workflow Execution for Flexible Microscope Program Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing computer program execution methods in a network are inflexible, leading to rigid processes and inefficiencies, making development and execution cumbersome.

Innovation Solution

Implementing a method that allows multiple return values from preceding function calls as separate parameters, with temporary storage and conditional program flow control, and utilizing a database for execution environments and interface definitions to enable flexible function calls and static typing, reducing runtime errors.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If executable modules are contained in isolated containers with sequential function calls, then security and stability are improved, but process flexibility and adaptability deteriorate

Engineering Contradiction:
Improvesecurity and stabilityVSAvoidprocess flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces a workflow engine as an intermediary layer between the containerized executable modules. This engine manages the execution flow, parameter passing, and coordination between modules, enabling flexible process orchestration while maintaining the isolation and security benefits of containers. The workflow engine acts as a mediator that provides adaptability without compromising the underlying container architecture.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system implements dynamic workflow definitions that allow process flows to be modified, adjusted, and reconfigured at runtime. The workflow engine can dynamically determine which executable modules to invoke, in what sequence, and with what parameters, thereby providing process flexibility while the modules themselves remain statically isolated in containers for security and stability.

Inventive Principle:
Principle #15Dynamics

2Device complexity

If rigid sequential processes are used, then system simplicity is maintained, but development time and complexity increase

Engineering Contradiction:
Improvesystem simplicityVSAvoiddevelopment time
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The patent segments the computer program into independent executable modules, each encapsulated in its own container. This segmentation allows modules to be developed, tested, and maintained independently, significantly reducing development time. The workflow engine then orchestrates these segmented modules, maintaining system simplicity through standardized interfaces and execution mechanisms.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system uses template-based workflow definitions that can be copied and reused across different applications and use cases. Pre-defined workflow templates accelerate development by providing ready-made process flows that can be instantiated and customized, reducing both development time and the complexity of creating new processes from scratch.

Inventive Principle:
Principle #26Copying

3Adaptability or versatility

If multiple return values are passed as separate parameters, then adaptability and workflow complexity are improved, but parameter management and interface definitions become more complex

Engineering Contradiction:
Improveworkflow flexibilityVSAvoidparameter management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The workflow engine implements a universal parameter passing mechanism that can handle multiple return values from executable modules through a standardized interface. This multi-functional parameter system allows the same interface structure to accommodate varying numbers and types of parameters, providing workflow flexibility without requiring complex custom interfaces for each scenario. The engine automatically manages the mapping between module outputs and workflow inputs.

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

Data Source

PatentEP3759594B1Method for executing a computer program in a computer network for controlling a microscope
Publication Date: 2025.12.17 CARL ZEISS MICROSCOPY GMBH
  • EP3759594B1 patent drawingFigure 1
  • EP3759594B1 patent drawingFigure 2A~2C
  • EP3759594B1 patent drawingFigure 3

AI summary

The invention relates to a method for executing a computer program in a computer network, in particular in order to control a microscope. Previously, in a computer network, a container managed, for example, by means of Docker is closed after a first function of a computer program has ended and the return value of the first function has been read in, and the value that has been read in is only copied into the standard input channel of a second function of the program, which second function is located in a different container, and the value that has been read in is then discarded. This allows only rigid processes. According to the invention, in the case of at least one function call of the second function in question, a plurality of return values from a plurality of preceding function calls is transferred as separate parameters. This enables considerably more complex and more flexible function calls. More flexibility in the execution of container-based functions of a computer program in a computer network can additionally be achieved in that the computer program also has, in addition to function calls, instructions for controlling the program flow, for example instructions for the conditional execution of program sections and jump instructions. In addition, the development of container-based computer programs can be simplified and accelerated by providing a database that contains the execution environments of the function modules and also the interface definitions thereof. The allows static typing of variables.