Protect the Transferable Core: Turning Customer-Specific Quantum Solutions into Scalable IP Positions with Johannes Trapp

1 . Starting Point and Central IP Question

The Decision Case concerns a young quantum technology company that makes existing quantum computing hardware usable for industrial applications. Its commercial advantage arises from a combination of:

• problem-specific algorithms,
• hardware-adapted implementation,
• workflow integration,
• performance tuning, and
• know-how gained through close collaboration with industrial customers.

Customer collaboration is of particular strategic interest. Individual projects generate knowledge about how an industrial problem can be structured for quantum computing, which technical adaptations are required, which performance barriers arise, and how the results can be integrated into existing processes. Some of this knowledge is initially closely tied to the specific customer case. At the same time, it may contain technical solutions that are valuable for other customers, industries, problem classes, or hardware platforms. These reusable solutions and capabilities increase the value Kipu can deliver to customers in its next project. They constitute Kipu’s competitive advantage and should therefore be protected.

This raises a central IP management question: Which elements of a customer-specific quantum technology solution contain a transferable technical core, and how can Kipu use this core to build scalable IP positions for future applications?

The Decision Case with Dr. Daniel Volz describes the overall IP management challenge facing quantum software companies:

👉 How Should Quantum Software Companies Build Their IP Strategy? Important industry topic with Dr. Daniel Volz

2 . Strategic Approach: Protect the Transferable Core

The starting proposition of this approach is: The scalable IP value of a quantum software company emerges where customer-specific learning can be translated into reusable technical capabilities.

For Kipu, this means viewing customer projects as a source of both technical differentiation and future portfolio development that increases the value delivered to customers. For example, a project may produce a new approach to problem representation, enable more efficient hardware adaptation, solve a recurring integration problem, or create a new form of hybrid processing. By identifying and selectively protecting these solutions, Kipu can safeguard its technical differentiation from competitors and use it in further customer projects.

The strategic task is to recognise early: Which of these elements have relevance beyond this particular customer case?

It is helpful to distinguish three layers:

Customer-Specific Layer  – Elements arising directly from the specific use case:

• customer-specific data,
• individual process conditions,
• specific system configurations,
• project-specific parameters,
• confidential application knowledge.

Transferable Technical Layer – Technical solutions that can be transferred to other settings:

• reusable problem representations,
• generic optimisation logic,
• hardware abstraction mechanisms,
• recurring hybrid workflows,
• technical integration patterns,
• performance improvements.

Application-Space Layer – Further potential uses of the same technical capability:

• other customers within the same industry,
• related industrial problem classes,
• additional industries,
• different quantum computing hardware,
• new product or service models.

The IP strategy should make these three layers visible during technical development.

3 . From the Customer Problem to the Transferable Technical Core

A customer-specific solution can be systematically broken down for this purpose.

• Problem Representation
  How is a real industrial problem translated into a form that can be addressed using a quantum or hybrid approach? How is it determined whether, and which, subtasks can be solved more efficiently using quantum or classical computing? Reusable modelling and decomposition logic may emerge here.
• Algorithmic Logic
  Which algorithmic building blocks generate the relevant technical or commercial advantage? What requirements do these algorithms have? Have these requirements been reduced in a specific way? Solutions that can also be used for related problem classes are of particular interest.
• Hardware Adaptation
  Is the solution tied to a particular quantum computing architecture? Which technical mechanisms enable the use of different quantum computing architectures or optimisation for specific hardware conditions? A solution that works across architectures can be especially valuable for a hardware-independent software company.
• Hybrid Integration
  How are classical processing and quantum computing connected? Recurring technical procedures, interfaces, and data flows can form a distinct, scalable component of the solution.
• Industrial Workflow Integration
  How is the result embedded in the customer’s actual process? Which technical adaptations were required to communicate with real-world ERP systems that may be difficult to integrate? Integration patterns may emerge here that can subsequently be transferred to other companies or industries.
• Customization
  Should the customer be able to adapt or manage the result independently, and is this feasible? Which configuration options do I provide to the customer, and in what form, to enable adjustments when circumstances change? Such capabilities are directly visible to customers and easy to compare. At the same time, these solutions are easier to transfer to other projects.

This breakdown connects technical understanding with a commercial question: Which technical capability can we use again?

The IP management discussion on digital business models follows a similar logic: the starting point is the specific customer benefit, followed by an analysis of where the value creation architecture offers a point of differentiation that can be controlled and is commercially relevant.

👉 From Customer Benefit to the Digital Control Point

4 . The Transferability Test

Kipu can apply a Transferability Test to each technically relevant component of a customer project, particularly within the Transferable Technical Layer and the Application-Space Layer.

• Reusability: Can the technical solution be used in further projects?
  The more often a mechanism can be reused, the greater its potential portfolio value.

• Abstraction Potential: Can a more general technical mechanism be derived from the specific implementation?
  The abstraction must remain technically sound and should capture realistic implementation variants.

• Application Breadth: In which other problem classes, industries, or customer processes could the same capability become relevant?
  A technical approach may therefore have greater commercial value than its original context initially suggests.

• Portability: Does the technical core remain relevant when the hardware, system environment, or integration architecture changes?
  Particularly in the dynamic quantum technology market, portability extends the strategic lifespan of an IP position.

• Separability: Can the transferable technical core be clearly separated from the customer’s confidential knowledge?
  This question is crucial for subsequent reuse, patenting, internal documentation, and collaboration.

• Visibility: Does the customer recognise the benefit available to them?
  Benefits that are clearly visible to customers carry more weight in purchasing decisions and are correspondingly more valuable.

• Economic Leverage: Which future opportunities does this technical position open up?
  These may include:

• • further customer projects,
  • new applications,
  • platform integration,
  • licensing,
  • strategic partnerships,
  • an investor narrative,
  • access to new markets.

These criteria provide a clear basis for prioritisation. A technical development with high Reusability, Application Breadth, Portability, Visibility, and Economic Leverage deserves particular attention in the IP portfolio.

5 . The Application-Space Map

The results can be consolidated in an Application-Space Map.

This turns a collection of individual projects into a structured picture of future technical options. For example: A customer project produces a specific optimisation for a logistics problem. Technical analysis reveals that an essential part of the solution lies in a particular problem decomposition and a hybrid control mechanism.

The Application-Space Map then asks:

• Does the same mechanism work for other logistics problems?
• Can it be transferred to production planning?
• Can it be used in energy optimisation?
• Does it work with different quantum computing architectures?
• Which technical features remain constant across these applications?

This makes the shared technical core visible. That core can then become the reference point for patenting, trade secret protection, software architecture, and portfolio development. This layered perspective is particularly relevant to quantum technology because practical value is often distributed across algorithms, hybrid workflows, problem encoding, benchmarking, data preparation, and other technical layers.

👉 Quantum Readiness in IP Management

6 . Contractual Architecture Must Enable Transferability

Customer collaborations have a major influence on whether a company can subsequently reuse the technical capabilities it develops. The contractual architecture should therefore reflect the technical Application-Space Map. Before or during a development project, the following categories in particular should be clearly defined:

• Background IP
  Which algorithms, software modules, tools, methods, and technical capabilities does Kipu already bring to the project?

• Project-Specific Results
  Which results are created exclusively for the specific customer and its particular application?

• Generic Improvements
  Which developments improve Kipu’s existing methods, algorithms, tools, or technical architectures more generally?

• Application Rights
  Which rights does the customer receive in the specific solution, and which future application spaces remain available to Kipu?

• Know-how and Confidentiality
  Which information comes from the customer’s confidential domain, and which generic technical insights can be developed further internally?

Contract design thus becomes part of the scaling strategy. The key management question is: Are we allowed to protect and reuse the knowledge gained from this project?

This capability is central to a quantum software company. Long-term enterprise value grows when projects generate cumulative technical learning and that learning can be translated into reusable capabilities. These reusable capabilities constitute Kipu’s competitive advantage. Their protection should therefore be permitted.

7 . Portfolio Architecture Built Around Core Positions and Application Positions

A portfolio architecture can then be developed from the Application-Space Map.

• Core Technology Positions: These address technical mechanisms that remain relevant across multiple applications.
• Application Positions: These protect particularly important specific applications or problem classes.
• Integration Positions: These address recurring technical interfaces with hardware, classical IT, or industrial workflows.
• Variant Positions: These cover relevant technical alternatives and further developments of the shared core.

This structure connects current customer projects with future growth opportunities. A new project can then be assessed using two questions:

Which existing Core Positions, Application Positions, Integration Positions, and, where relevant, Variant Positions do we use?

and

Which new transferable capabilities emerge here?

This enables ongoing monitoring of the relevance of the various capabilities (positions), allowing changes in their value to be identified and portfolio maintenance to be adjusted accordingly. For example, Application Positions that are used less frequently can be identified, so that protection for those gradually losing importance can be reduced step by step. At the same time, the portfolio grows alongside the company’s technical learning as new transferable capabilities emerge. These questions can also reveal future application spaces. This forward-looking perspective is particularly important in quantum technology. Market structures, dominant architectures, and commercial use cases continue to evolve. Companies therefore need to develop early hypotheses about which of today’s technical capabilities may acquire strategic significance in the future.

👉 Making Quantum IP Legible: Why Quantum Companies Need to Protect What May Become Strategic

Portfolio development thus becomes a learning process: Customer project → technical learning → next customer project └→ transferable capability → application space → IP position

Each project can strengthen the existing technical core, generate new variants, and reveal additional application spaces.

Outcome

The proposed strategy is: Protect the Transferable Core.

For a quantum software company, a substantial part of scalable enterprise value arises from the ability to translate technical insights from specific customer projects into reusable capabilities.

Kipu should therefore systematically examine the following questions for each customer project:

1. Which technical capabilities emerge from this project?
2. Which of them contain a transferable core?
3. To which applications, industries, and hardware environments can this core be transferred?
4. Which contractual terms preserve the necessary freedom to act?
5. Which IP positions protect the shared technical core and particularly attractive application spaces?

This creates an Application-Space Portfolio Architecture that connects current project work with future market opportunities. To monitor the portfolio, the following question should also be examined and documented for each customer project: Which of Kipu’s existing technical capabilities (positions) are used in this project?

The central question is:

“Which technical capabilities emerging from today’s customer projects can become scalable IP positions for tomorrow’s applications?”

Expert Profile: Johannes Trapp

Johannes Trapp is a German and European patent attorney, holds a Diplom in Physics, and is a partner at FLACH BAUER & PARTNER. His technical background includes physics, laser physics, and quantum information processing. Before entering the IP profession, he worked as a research associate in the research environment of Prof. Theodor W. Hänsch at LMU Munich.

His current patent practice covers physics and quantum optics, software, AI, blockchain technology, control methods, and algorithms, among other fields. His work also includes international patent strategies, patent infringement proceedings, portfolio optimisation, licensing strategies, and advice on the structure and design of IP processes for start-ups and medium-sized companies.