Software Authorization via Directed Graph State Transitions

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software authorization methods face challenges such as latency issues during critical program functionalities, disrupted communication, and security risks due to external module dependencies, making it difficult to integrate authorization processes without compromising performance or increasing security risks.

Innovation Solution

The method involves shifting complex authorization processes to non-critical latency times and using a central external module for licensing, allowing asynchronous authorization and controlling the authorization process through a directed graph of functionally equivalent implementations, enabling secure and efficient authorization without disrupting program flow.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If authorization processes are integrated into performance-critical program functionalities, then security protection is improved, but program flow latency increases

Engineering Contradiction:
Improvesecurity protectionVSAvoidprogram flow latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies preliminary action by performing authorization checks in advance during program loading or initialization phases, rather than interrupting critical functionalities. The authorization state is determined beforehand and stored, allowing performance-critical sections to execute without real-time authorization delays.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent segments the authorization process into separate phases: initial authorization determination, state storage, and conditional execution based on that state. This separates the authorization overhead from performance-critical program flow, allowing security verification to occur in non-critical sections while maintaining uninterrupted execution in essential functionalities.

Inventive Principle:
Principle #1Segmentation

2Reliability

If external modules are used for authorization, then security verification is improved, but device complexity and cost increase

Engineering Contradiction:
Improvesecurity verificationVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the authorization logic from external hardware modules and integrates it directly into the program code structure. By embedding authorization states and conditions within the code itself rather than relying on separate USB dongles or smart cards, the solution maintains security verification while reducing device complexity and eliminating the need for additional external authorization hardware.

Inventive Principle:
Principle #2Taking out (Extraction)

3Loss of substance

If external modules are centralized on a server, then material cost is reduced, but communication reliability deteriorates

Engineering Contradiction:
Improvematerial costVSAvoidcommunication reliability
Core Design Contradiction:
Loss of substanceVSReliability

Solution Approach 1:

The patent implements self-service authorization by embedding all necessary authorization data and verification logic directly within the program code. The system performs self-verification using internal authorization states without requiring external server communication, eliminating communication reliability issues while maintaining centralized authorization management through the embedded code structure.

Inventive Principle:
Principle #25Self-service

4Adaptability or versatility

If authorization processes are made controllable from outside, then adaptability is improved, but security risk increases

Engineering Contradiction:
ImproveadaptabilityVSAvoidsecurity risk
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The patent implements controlled adaptability through feedback mechanisms where authorization states are modified based on verified conditions rather than external manipulation. The system monitors and responds to authorization requests through predefined protocols, allowing adaptability in authorization behavior while preventing security risks by only accepting controlled, verified modifications to authorization states rather than allowing arbitrary external changes.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP2648125B1Method for authorising a program sequence
Publication Date: 2014.11.19 STEINBERG MEDIA TECHNOLOGIES GMBH
  • EP2648125B1 patent drawingFigure 1
  • EP2648125B1 patent drawingFigure 2
  • EP2648125B1 patent drawingFigure 3

AI summary

The present invention relates to a method for authorizing program execution. Software authorization is known in principle from the prior art, for example, by entering corresponding license keys or repeatedly using challenge-response protocols. However, the use of challenge-response protocols introduces latency into the program execution. Furthermore, the use of external modules for authorization represents a significant material, cost, and administrative burden. The object of the present invention is therefore to extend the known authorization methods in such a way that, despite centralization and the associated high latency and potentially disrupted communication, uninterrupted program execution is enabled even while protecting basic functionalities.This is achieved by allowing program flow data to be stored in various intended states and by storing at least one instruction of the program flow that accesses the data in different, functionally equivalent implementations. The set of implementations is a non-empty, finite multiset over the Cartesian product of the set of state indices of the intended data states with itself, and each implementation transforms the data from an input state to an output state. According to the invention, the set of state indices of the intended states and the multiset form a directed and acyclic (multi-)graph, with the intended states being the nodes and the implementations of the instruction being the edges and/or multiple edges of the graph.