Open Innovation needs IP architecture before collaboration starts

Open Innovation begins with a strategic choice

Open Innovation does not mean that every innovation task should be opened to external partners. It means that companies need to decide where external knowledge, external capabilities or external market access can create better results than an internal project alone. This decision is strategic because different innovation tasks require different forms of openness.

Some tasks are suitable for universities because scientific depth, exploratory research or access to specialized methods is needed. Other tasks are better suited for start ups because speed, technological focus or entrepreneurial experimentation is more important than established process reliability. Customers may be the right partners when the innovation problem is closely connected to operational use, unmet needs or market acceptance. Suppliers may be essential when system integration, manufacturing feasibility, component know how or value chain👉 A series of activities that create and deliver value in a product for end-users. knowledge determines whether an idea can become a product.

The IP management question is therefore not simply whether a cooperation is attractive. The better question is what part of the innovation task should be opened, to whom, under which conditions and with which control points. A company may open a research question without opening its product roadmap. It may share a technical interface without disclosing its full system architecture. It may invite customer input without giving away the strategic logic behind future product generations. It may use supplier knowledge without allowing the supplier to reuse customer specific learning in uncontrolled ways.

This distinction matters because Open Innovation creates value through exchange. But exchange is not neutral. Every shared drawing, prototype, data set, technical explanation, test result, customer insight or software component can change the knowledge position of the parties. A company that enters Open Innovation without a clear view of its own knowledge assets may create value for the project and weaken its own position at the same time.

Open Innovation should therefore start with an internal clarification. What is the innovation problem? Why is an external partner needed? Which internal assets are critical? Which parts may be shared? Which parts must remain protected? Which results would be valuable if the project succeeds? Which future business options must remain open? These questions define the strategic boundary of the collaboration.

Partner selection is also IP selection

Open Innovation partners are usually selected for their technical, commercial or scientific contribution. This is necessary, but not enough. Partner selection also creates an IP position. Different partners bring different rights, different knowledge bases, different disclosure cultures, different commercial expectations and different constraints.

A university may bring research capability, laboratories, scientific staff and access to new methods. At the same time, it may have publication interests, public funding obligations, doctoral research requirements and institutional rules on ownership. A start up may bring a focused technology, a software stack or a prototype, but may also have investors, existing license obligations, open source dependencies or a need to preserve freedom for its own business model👉 A business model outlines how a company creates, delivers, and captures value.. A supplier may bring manufacturing know how or component expertise, but may want to use project learning for other customers. A customer may bring market knowledge and use case clarity, but may expect privileged access to the result.

These different positions are not obstacles to collaboration. They are part of the logic of collaboration. But they must be made visible early. Otherwise, the company may misunderstand what the partner can actually contribute and what the partner is allowed or willing to grant. A technical capability is not the same as a usable IP position. A partner may be able to develop a solution but may not be free to transfer all required rights. A partner may own valuable background IP but may only license it narrowly. A partner may contribute data but may not be able to authorize broader reuse. A partner may contribute software that is technically useful but legally difficult to embed in a commercial product.

For this reason, Open Innovation requires a partner related IP review before the project becomes operational. This review should examine the partner’s background IP, existing obligations, ownership situation, confidentiality requirements, publication interests, freedom to contribute, rights to data, software dependencies and expected exploitation position. The goal is not to create suspicion. The goal is to create clarity.

This is especially important when the cooperation involves several parties. In multiparty projects, innovation can become a web of contributions. One party provides data. Another develops algorithms. A third party supplies hardware. A university validates results. A customer tests the solution. If the IP position of each contribution is not understood, the project may later produce a result that no one can exploit cleanly. Open Innovation therefore requires a shift in mindset. Partner fit is not only about expertise and trust. It is also about compatibility between contribution, rights position and business intent.

Background IP must be separated from new results

The central distinction in many Open Innovation projects is the distinction between background IP and newly created results. Background IP includes everything a party already brings into the project: patents, trade secrets, software, data sets, technical documentation, test methods, designs, prototypes, process knowledge, customer insights, algorithms, models, specifications and practical experience. Newly created results are what emerges from the cooperation itself. 

This distinction sounds simple. In practice, it is often difficult because innovation rarely follows clean legal categories. A new prototype may be built during the cooperation, but the most important design choice may rely on one party’s earlier testing experience. A software tool may be improved jointly, but its architecture may have existed before the project. A data based solution may be trained during the cooperation, but its performance may depend on data collected outside the project. A technical solution may be jointly discussed, but the inventive contribution may come from one engineer who used confidential background knowledge from her own company. 

If these issues are not documented, the parties may later disagree about ownership, use rights and economic value. One party may see the result as jointly created. Another may see it as an improvement of its pre existing technology. A third party may believe that it only contributed general feedback, while the others view that feedback as essential to the final solution. These different perceptions can block commercialization even if the technical project was successful. 

Good Open Innovation Management therefore requires a contribution map. The company should record what each party brings into the cooperation, what may be used only for the project, what may be used beyond the project, what remains exclusively owned by the contributing party and what happens if the project result depends on that background. This map does not need to be overly bureaucratic, but it must be clear enough to avoid later ambiguity. 

The same applies to improvements. Many collaborations create improvements to background technology. This is often more difficult than ownership of completely new results. If a supplier improves a customer specific process during a joint development project, who owns the improvement? If a start up adapts its software to a corporate partner’s use case, who may use the adapted version? If a university develops a method based on industrial data, who may use the method for future research or commercial work? 

These questions should be addressed before the project starts. Otherwise, the answer may depend less on strategy and more on bargaining power after value has already been created. 

Data needs its own rules

Data is often treated as supporting material in Open Innovation projects. That view is too narrow. In digital products, AI systems, connected devices, platform models, MedTech, GreenTech, smart manufacturing👉 Data-driven industrial production using connected systems, software and analytics. and service based business models, data can be one of the most important assets in the cooperation. 

Data raises questions that are different from classical patent👉 A legal right granting exclusive control over an invention for a limited time. ownership. Who provided the data? Who may access it? Who may combine it with other data? Who may use it to train models? Who owns derived data, aggregated insights, annotations, labels, models, test results or performance benchmarks? Can data be reused for other projects? Can it be shared with subcontractors? Can it be stored after the project ends? Can it be used for regulatory purposes, product improvement or commercial analytics? 

If these questions are not addressed, data can become a source of hidden dependency. A company may develop a strong solution but remain dependent on a partner’s data access. A partner may gain insights from another company’s operations and use them to improve its own offering. A jointly trained model may contain value that is difficult to allocate because the input data, the model architecture and the training work came from different parties. 

Data rules should therefore be separated from general IP clauses. They should define data categories, access levels, permitted uses, storage rules, deletion obligations, security requirements, derived data rights, model training permissions and post project use. They should also address whether data may be used only for project performance or also for product improvement, benchmarking, AI training, documentation, regulatory submissions or future commercial services. 

Open Innovation involving data should never rely on a vague statement that each party keeps its own rights. That may be true at a formal level, but it does not answer the practical question of what the parties may do with the knowledge and outputs generated from data use. 

Publication and protection must be coordinated

Open Innovation often brings together parties with different publication cultures. Universities and research institutions may need to publish. Start ups may need visibility to attract investors, employees or customers. Corporates may need confidentiality until patent filings, product launches, regulatory steps or market positioning decisions are complete. Customers may want to communicate innovation success. Suppliers may want to show technical capability. 

These interests can be compatible, but only if publication rules are designed early. The problem is not publication itself. The problem is uncontrolled timing, uncontrolled scope and unclear review. A scientific paper may destroy novelty👉 Requirement that an invention must be new and not previously disclosed. for a patent filing. A conference presentation may reveal system architecture before trade secret👉 Protects confidential business info for competitive advantage. decisions have been made. A customer case study may disclose operational data or technical performance details. A public project announcement may create expectations before ownership and exploitation rights are settled. 

Open Innovation therefore requires a publication and disclosure process. The parties should define what counts as a publication, who must review it, how much time is available for review, whether patent filings may delay disclosure, which information must be removed and how confidential information is handled. This should include scientific publications, press releases, investor presentations, website content, social media, trade fair materials, technical documentation and customer references. 

The same logic applies to patent filings. If a result may be patentable, the parties need rules for invention disclosure, inventorship assessment, ownership, filing responsibility, cost sharing, prosecution control, territorial scope and enforcement. Joint ownership may sound fair, but it can be difficult in practice. Depending on the jurisdiction, joint owners may have different default rights. Even where the law provides a rule, the business outcome may not be suitable. Joint ownership can lead to unclear responsibilities, strategic deadlock and weak enforcement if the parties do not define how the rights will be used. 

Publication and protection are therefore not separate tracks. They are connected. A company that wants to use Open Innovation strategically must coordinate scientific openness, market communication, patent timing and confidentiality. Otherwise, the project may accidentally convert a protectable advantage into public knowledge before the company has decided how value should be captured. 

Know how flow is the most underestimated risk

Many Open Innovation projects focus on formal IP rights. Patents, contracts, ownership clauses and license rights receive attention because they are visible. Know how flow is less visible, but often more important. 

In a real collaboration, people exchange practical knowledge constantly. Engineers explain why a certain solution failed before. Product managers describe customer behavior. Manufacturing experts discuss tolerances and process limits. Software developers reveal assumptions behind architecture choices. Service teams explain failure patterns. Regulatory specialists explain what will or will not be accepted. Data teams describe cleaning methods, annotation choices or model evaluation criteria. 

This exchange is necessary. Without it, Open Innovation remains superficial. But it also means that valuable know how can move from one organization to another in a way that is difficult to trace. The risk👉 The probability of adverse outcomes due to uncertainty in future events. is not only intentional misuse. The larger risk is that knowledge becomes absorbed into the partner’s general capability. After several workshops, design iterations and technical reviews, people may no longer distinguish clearly between their own prior knowledge, project learning and information received from the other side. 

This is why Open Innovation requires know how boundaries. Companies should define what information may be shared at each project stage. Early phases may use abstract problem descriptions, limited data sets, controlled technical interfaces or anonymized examples. Deeper technical exchange may require stronger contractual protection, restricted project teams, clean rooms, access logs, documentation routines and explicit use limitations. 

Offboarding is also important. When a project ends, the parties should clarify what must be returned, deleted, retained or archived. They should document which materials were exchanged, which outputs were created and which information may continue to be used. This is particularly important when the cooperation ends without a commercial product. Even a failed project can transfer valuable know how. 

The objective is not to stop knowledge exchange. The objective is to make knowledge exchange intentional. Open Innovation works best when people can collaborate deeply because the boundaries are clear enough to create confidence. 

Exploitation rights determine whether collaboration creates business value

A successful Open Innovation project is not complete when a prototype works or a research question is answered. The decisive question is whether the result can be used in business. This requires exploitation rights. 

Exploitation rights define who may use the result, for which purpose, in which territory, for which products, for which customer groups and under which economic conditions. They also define whether use is exclusive or non exclusive, whether sublicensing is allowed, whether affiliates are included, whether improvements are covered, whether source code or technical documentation must be provided and whether rights survive termination of the cooperation. 

These questions should be answered before success creates pressure. Once a result has value, positions become more difficult. A partner may demand broader rights. A company may realize that it needs exclusivity. A university may insist on research use. A start up may need the result for its own product. A supplier may want to use the knowledge for other customers. A customer may expect preferential access. If none of this has been anticipated, collaboration can become blocked at exactly the moment when it should move into commercialization. 

Exploitation logic should therefore be part of project design. The parties should distinguish between research use, internal use, commercial use, field limited use, customer specific use and platform use. They should also decide whether the result will be assigned to one party, jointly owned, licensed, split by field of use or governed by options. In some cases, one party should own the result and grant defined use rights to the others. In other cases, different elements should be allocated to the party best positioned to exploit them. 

Licensing👉 Permission to use a right or asset granted by its owner. is often the bridge between joint creation and controlled commercialization. A party may own background IP but grant project specific use rights. A jointly created result may be licensed back to one partner for a defined field. A company may grant a partner rights for one application while keeping another application exclusive. A start up may receive commercialization rights while the corporate partner secures access for its own products. The legal form should follow the strategic logic. 

This is why Open Innovation and licensing belong together. Licensing is not only a later transaction. It is often the mechanism that makes collaboration usable without forcing the parties into rigid ownership structures.

Open Innovation must be connected to portfolio strategy

Open Innovation does not happen in a vacuum. It affects the company’s IP portfolio. It may create new patentable inventions👉 A novel method, process or product that is original and useful., new trade secrets, new software assets, new data positions, new design options, new technical documentation and new contractual rights. It may also reveal gaps in the existing portfolio. 

For example, collaboration with a customer may show that the company’s patent portfolio protects the core product, but not the service layer where future value will be created. A supplier project may reveal that key process knowledge is not patented and not properly protected as a trade secret. A start up cooperation may show that the company has strong hardware protection but weak software or data control. A university project may create scientific results that need to be translated into a portfolio position before publication. 

This means that Open Innovation should feed portfolio management👉 Strategic management of diverse assets to optimize returns and balance risk.. The IP function should not wait until the end of the project. It should monitor emerging results, identify protectable contributions, assess whether patent filings are needed, decide what should remain secret and determine whether the portfolio needs to be adjusted around the collaboration. 

At the same time, portfolio strategy should guide Open Innovation. A company should know which areas are strategically open, which areas require exclusive control and which areas can be used for ecosystem building. Some IP positions may be suitable for sharing because broader adoption increases value. Other positions must remain tightly controlled because they define differentiation. Some technologies may be licensed into adjacent markets. Others should only be used internally. Some data assets may support collaboration. Others should never leave the company. 

A mature Open Innovation strategy therefore links project decisions to portfolio decisions. The company should not only ask what the collaboration may create. It should ask how the collaboration changes the meaning, value and vulnerability of the existing portfolio. 

Governance before the first workshop

Many Open Innovation projects are launched through workshops, pilot projects, research agreements or informal technical exchanges. The energy of the beginning is important, but it can also create risk. People want to solve problems, not wait for governance. Yet the first workshop can already include sensitive information. The first data exchange can already create rights issues. The first prototype discussion can already shape inventorship, ownership and disclosure. 

Open Innovation governance should therefore be lightweight enough to support cooperation, but clear enough to prevent avoidable conflicts. It should define project roles, approval steps, information categories, permitted disclosures, documentation rules, IP review gates, publication review, data handling, partner access and escalation paths. It should also define who has authority to approve the transition from exploratory exchange to deeper technical collaboration. 

This governance should not be owned by legal alone. Open Innovation connects R&D, IP management, legal, business development, procurement, data protection, information security, product management and corporate strategy. Each function sees a different risk and a different value opportunity. If governance is designed only as a contract review, it may miss the business logic. If it is designed only as innovation management, it may miss the IP exposure. If it is designed only as compliance, it may block useful cooperation. 

Good governance translates IP into practical behavior. It tells project teams what they may share, when they must involve IP experts, how to document contributions, how to handle partner materials, how to respond to publication requests and how to flag potentially protectable results. It also helps management understand whether a collaboration is strategically safe, commercially attractive and operationally controllable. 

The aim is not to slow innovation. The aim is to avoid the situation in which technical progress creates legal uncertainty, commercial deadlock or loss of knowledge control. Governance gives Open Innovation a reliable operating structure. 

What companies need for Open Innovation

Open Innovation creates value when companies know what should be opened, what must remain controlled and how external contributions can be converted into usable business results. It is not enough to invite partners into the innovation process👉 A structured journey of creating and implementing new ideas.. The company must define the innovation task, select partners with a clear understanding of their IP position and establish rules before valuable knowledge begins to move. 

• Companies need a clear map of background IP, data, software, know how, trade secrets, customer insights and technical materials that each party brings into the collaboration. They also need rules for newly created results, improvements, publication, patent filings, confidentiality, data use and post project exploitation. Without this separation, successful collaboration can lead to ownership disputes, blocked commercialization or unintentional disclosure. 
• They must also manage know how flow as a strategic risk. The most valuable knowledge in Open Innovation is often exchanged informally through workshops, technical explanations, testing, iteration and problem solving. This knowledge exchange should be intentional, documented and limited where necessary, without destroying the trust and openness needed for effective collaboration. 
• Finally, companies need exploitation clarity. Open Innovation only becomes strategically useful when the path from shared problem solving to value use is defined. Ownership, licensing, field of use, exclusivity, sublicensing, improvements, data rights and termination consequences must be aligned with the business objective of the cooperation. 

Open Innovation is therefore not the opposite of IP management. It is one of the areas where IP management becomes most important. The more open the innovation process becomes, the more companies need structure, documentation, governance and strategic clarity. Openness creates opportunity. IP architecture makes that opportunity usable.