The original 360° IP Strategy made a crucial distinction between identifying the need for IP and satisfying that need through concrete rights and measures. That distinction becomes even more important in digital business models. When value is created through software, data, algorithms, APIs, interfaces and digital workflows, the strategically important asset may not arrive as a clearly recognizable invention disclosure. It may emerge from the way information is collected, the way systems interact, the way an algorithm improves with use, or the way a workflow becomes embedded in the customer’s operations. The management task is therefore not to search only for patentable inventions. It is to identify which business-model functions must remain differentiated, controlled or difficult to substitute, and then design the appropriate IP architecture around them.

IP need begins with the business function, not the invention

Traditional IP processes often begin when development reports a technical solution. The legal question then follows: is it new, inventive and protectable? This sequence is useful for processing inventions, but it is too narrow for determining what the business actually needs from IP. A digital company can have valuable code, a unique dataset, an efficient training process or a powerful interface without anyone describing it as an invention. Conversely, a technically impressive invention may have little strategic importance if customers do not value it and competitors can reach the same outcome through an easy alternative.

The starting point must therefore be the function the business model needs to perform. Does the company need exclusive access to a source of operational data? Must it prevent competitors from reproducing a predictive service? Does it need to preserve control over an interface through which partners connect? Is the strategic objective to make a workflow difficult to replace, to secure ownership of externally developed code, to protect a model-improvement process, or to maintain the credibility of a digital service promise? These are IP-needs questions even before a specific right is selected.

This reverses the usual direction of thought. Instead of asking what existing development results can be protected, management asks where the business model would become vulnerable if another actor could copy, access, disclose, reimplement, bypass or appropriate a critical function. The vulnerability may concern competitors, suppliers, cloud providers, customers, developers, data contributors or platform partners. Each actor may have a different route to the same value layer.

The original separation between identifying and fulfilling IP need remains essential. In digital business models, IP need is the gap between the control required for commercial success and the control the company can currently exercise over a business-model function.

Map the digital value architecture before choosing protection

The next step is to decompose the customer benefit into the digital architecture that produces it. In a physical product, the analysis might connect customer requirements with components and technical features. In a digital system, the relevant architecture is more distributed. A reliable predictive-maintenance service, for example, may depend on sensors, data quality, transmission protocols, preprocessing routines, a diagnostic model, software deployment, an interface, service workflows, customer-specific integration and accumulated operational knowledge. The customer experiences one outcome, but many interdependent elements create it.

A useful analysis follows the chain from benefit to function, from function to asset, and from asset to dependency. The benefit may be lower downtime. The business function may be early fault detection. The assets may include labelled failure data, signal-processing logic, model parameters, software code and an alert workflow. Dependencies may include access to machine data, a cloud environment, open-source components, external developers, customer permissions and stable APIs. This chain reveals where value is created and where control can be lost.

Interfaces deserve particular attention because they are rarely neutral. An API determines who can connect, what information can be exchanged, which actions are permitted and how easily a complementary service can be built. A user interface determines how digital capability becomes visible and usable. An internal interface between software modules can determine whether the company can replace a supplier or migrate to another infrastructure. Interfaces are therefore technical, commercial and governance objects at the same time.

The analysis should also include digital workflows. A workflow may combine several ordinary elements in a sequence that creates a superior result. The competitive advantage can lie in how data is validated, decisions are escalated, human review is introduced, evidence is documented or recommendations are delivered. Protecting only the individual software modules may miss the system behaviour that customers actually value.

Digital IP need becomes visible only after the value architecture is mapped. The decisive object is not an isolated file, dataset or interface, but the combination of assets and dependencies that reliably produces the customer-relevant outcome.

Prioritise what must be controlled, not everything that is valuable

A digital system may contain hundreds of potentially relevant assets, but an IP strategy cannot treat all of them as equally important. The purpose of an IP-needs analysis is not to create the largest possible inventory. It is to identify the elements whose loss, imitation or uncontrolled use would materially weaken the company’s market position. This requires prioritisation based on business impact and competitive vulnerability.

Several questions help distinguish strategic assets from ordinary operating resources. How directly does the element contribute to customer choice, willingness to pay, retention or cost advantage? How easily can a competitor observe and reproduce it? Can the same customer benefit be achieved through a different technical route? Does the asset improve through accumulated use or data? Is it controlled internally, jointly created or dependent on a third party? How quickly does it change? Can misuse or infringement be detected and evidenced? What would happen if access were interrupted or a partner reused the asset independently?

These questions often produce different answers for data, software and interfaces. Raw data may be replaceable, while a curated and context-rich dataset is difficult to reproduce. Source code may be protected against copying, while the underlying functionality can still be independently reimplemented. A model may be hard to inspect from outside, making secrecy and evidence preservation more relevant than public disclosure. An API specification may need to be open enough to attract partners, while authentication, usage rules, rate limits and contractual permissions remain controlled.

The analysis must also distinguish value from exclusivity need. Some assets are valuable because everyone uses them, such as a standard or an open-source framework. The company may not need exclusivity over the shared layer; it may need freedom to use it, influence over its development, compliance with its licence terms and exclusive control over the differentiating layer built on top. Other assets may be strategically important precisely because access must remain restricted.

Prioritisation prevents the digital IP agenda from becoming an indiscriminate collection exercise. The strongest IP need exists where business impact is high, substitutability is low and the current control position is fragile.

Build a modern IP-needs matrix around rights and control mechanisms

The original IP-needs matrix connected customer benefit with the system components that generated it and compared the result with market and technology competitors. The updated matrix should preserve that logic while expanding the meaning of “system component” and “protection.” Its rows can represent customer outcomes or business-model functions. Its columns can represent hardware, software modules, algorithms, datasets, data pipelines, interfaces, user interactions, workflows, brands, regulatory evidence, partner contributions and external dependencies.

The matrix should then record more than whether an element is patentable. For each important relationship, the team can describe the desired control effect: prevent technical imitation, restrict access, secure ownership, preserve confidentiality, control reuse, maintain interoperability, prevent confusing market communication, retain evidence, ensure portability, create licensing leverage or reduce dependency. This makes the need operational before the legal instrument is chosen.

The response will usually be hybrid. A technical data-processing method may support a patent filing. Source code and interface documentation may require copyright ownership and clear development contracts. A training process, parameter set or implementation technique may be kept as a trade secret with documented access restrictions. Data access may depend on contracts, permissions, database structures, cybersecurity and technical authentication. A user-facing configuration may involve design, copyright, branding and contractual service terms. Open-source components require licence governance rather than attempted exclusivity.

The matrix should also contain the competitive route around the intended position. Could a competitor achieve the same benefit using different data, another model architecture or a substitute interface? Could a partner learn enough through integration to offer the service independently? Could a customer export the relevant data and switch to another provider? Could the company itself become locked into a supplier’s proprietary toolchain? These questions turn circumvention and dependency into design inputs.

A modern IP-needs matrix does not assign one right to one asset. It connects commercially relevant functions with the layered legal, technical and organisational controls required to make those functions defensible.

Turn the matrix into a living management process

A one-time workshop can reveal hidden assets, but digital value architectures change continuously. Software releases alter functionality. Models are retrained. New data sources are connected. APIs are opened to partners. Cloud services and open-source libraries are replaced. Customer workflows evolve after deployment. The IP need therefore changes throughout the lifecycle, and the matrix must become a recurring management instrument rather than a static project document.

The process requires an interdisciplinary team. Product management explains the customer outcome and commercial priorities. Software and data teams describe architecture, dependencies and development practices. Sales and service teams show how the system is used in reality. Cybersecurity identifies access and leakage risks. Procurement and partner management reveal external dependencies. Legal and IP specialists translate the required control effects into rights, contracts, documentation and governance. No single function sees the complete value architecture alone.

The output should be a decision register, not merely an asset list. Each priority need should have an owner, a chosen control mechanism, an evidence requirement, a timing decision and a review trigger. The trigger may be a new release, a change of model provider, an API launch, a partnership, a new data source, entry into another jurisdiction or a change in monetisation. This allows IP decisions to follow the development roadmap instead of arriving after the architecture is already fixed.

Management should also test whether the chosen measures produce the intended effect. Does the company actually control the data needed to operate the service? Is ownership of commissioned code documented? Can confidential know-how be identified and its access traced? Do patent claims cover the commercially relevant system behaviour rather than an incidental implementation? Are interface and licensing rules consistent with the desired ecosystem strategy? Can the company demonstrate what was created, by whom and when?

The modern purpose of IP-needs analysis is to create decision readiness. It gives management a repeatable way to recognise intangible value, identify vulnerabilities and combine legal rights, contracts, technical architecture and organisational evidence before competitive advantage escapes through the digital layers of the business model.

Supplementary content on the IPBA® platform:

Connected Products

Shows how a physical offering becomes a moving value architecture of hardware, software, data, services and interfaces, making lifecycle-based IP-needs analysis necessary.
👉 Read more

Predictive Maintenance and IP Management

Provides a concrete system example in which customer value is distributed across sensor architectures, data pipelines, analytics models, software, service workflows and operational know-how.
👉 Read more

Interoperability

Deepens the interface perspective by showing why APIs, data governance and system compatibility can become both value enablers and strategic control questions.
👉 Read more

Software Patent

Clarifies the role of patent protection for software and algorithms, supporting decisions about when a digital function should enter the patent layer of the IP-needs matrix.
👉 Read more

Layered IP Strategy

Explains how patents, copyright, trademarks and trade secrets can be combined around one product, service or business model instead of treating each right in isolation.
👉 Read more

AI Armor: The Essential Guide to Protecting Your AI Company’s Crown Jewels by Robert Plotkin

Applies layered protection to AI assets and shows why core technologies, proprietary data and confidential methods require coordinated patent and trade-secret decisions.
👉 Read more

Training at Theben AG: Protection of Digital Solutions with IP Design

Offers a practical company example of identifying and protecting software, databases, algorithms, user interfaces and other digital assets during the development process.
👉 Read more

Building Industry 4.0 – Umdasch Group Ventures Develops and Protects Digital Business Models with IP Design

Demonstrates how IP design can start from alternative digital business-model scenarios and systematically generate the rights required to protect them.
👉 Read more

Industrial IoT in Motion: Why Smart Manufacturing Turns IP into a System Question

Frames the central system question for connected manufacturing: who controls the relevant data, software, interfaces, models, standards, operating knowledge and commercial options?
👉 Read more

Symposium IP and Industry 4.0: IP Leaders Discuss the Challenges of Protecting Digital Business Models

Shows how industrial IP leaders approached the protection of data, software, machines, value chains and business models, and why IP teams must act as active co-designers.
👉 Read more