As open innovation becomes more widespread, many of those involved in making partnership arrangements are finding it increasingly onerous to deal with the intellectual property (IP) issues involved. IP, as one battle-hardened licensing executive put it, "starts out as a pain in the ass and then spreads to the whole body". IP issues are slow, difficult and expensive to deal with, goes the complaint, and form an overhead that rarely benefits anyone but the lawyers.

As a patent attorney faced with the IP-related contractual issues that emerge throughout collaborations because IP issues were not sorted out at the beginning, I argue the opposite. Strong IP protection schemes are compatible with open innovation strategies, and working through them can strengthen partnerships by ensuring that everyone involved has a common view of the critical issues right from the start. IP negotiations don't have to hold things up, either - the key is to get organised.

Let's draw an analogy between closed and open innovation schemes and jigsaw puzzles and Lego blocks. A jigsaw puzzle is a 'closed' construction with a limited number of differently shaped elements that can be put together in one way to make one picture. Lego blocks, on the other hand, come in a variety of standard forms that can be put together in many ways to produce many objects. Each block has standard dimensions and connects in a standard way to other blocks. If open innovation is going to work as smoothly as putting together Lego blocks, partners need similarly rigorous and standardised definitions of the partnership's building blocks and of the business relationships between them. This is where lawyers and patent attorneys can help. The key is to find the appropriate business model for the collaboration from its earliest stages, and then use professional contractual management to serve that model.

When it comes to IP the first step is to define five basic forms of knowledge. The term 'knowledge' here includes IP and other proprietary assets (such as confidential know-how) that the parties need to consider when planning the collaboration. The first basic form is 'foreground' knowledge, generated within a collaboration. The second basic form is 'background' knowledge, generated outside the collaboration but necessary to create and exploit the foreground knowledge. It comes in two forms: that which is generated before the collaboration starts, and that which is generated during the development phase, but independent of the collaboration, and so is sometimes also known as 'sideground' knowledge.

Collaborations also involve 'improvements', which elaborate foreground and background knowledge after the development phase of the project.

Finally, the parties involved in such collaborations may also have access to 'other' assets, which are not necessary for the generation and exploitation of the foreground knowledge. Such assets can be excluded from the collaboration.

These definitions provide a transparent framework that open innovation partners can use to describe what each party is bringing to the collaboration, how its results will be shared, and what to do about the supporting knowledge that is needed to make the collaboration work, and that it generates.

Having defined the types and sources of knowledge, it then makes sense to split the project into various phases, each with a corresponding agreement and exit plan. The collaboration should start with an initial non-disclosure or confidentiality agreement (as a minimum requirement), to cover early negotiations. Sometimes, if the parties are going to collaborate on more than one project, or if the project is large, it might be appropriate to create a framing agreement to cover overall goals. Further agreements can support each phase of the collaboration, such as feasibility studies, development, prototyping, industrialisation and full-scale production, and commercial exploitation. The agreement for each phase should include a clearly defined exit strategy for the partners, in case the collaboration fails or is not continued as originally planned.

In each case, it's necessary to define a suitable way of sharing the knowledge generated by the collaboration, in respect to ownership, access and exploitation rights. This usually forms the backbone for the overall business model the parties plan to use. For example, there are at least six ways that ownership of foreground knowledge can be shared between two parties. Most obviously, it can be jointly owned. Or it could be divided into three parts: each party has exclusive ownership of one part that is strongly related to the background knowledge they brought to the project, while the third section is jointly owned.

A third approach divides the knowledge into three, but relates the exclusive parts to the expected improvements that each party makes. A fourth approach splits the foreground knowledge into two exclusive parts on the basis of the background knowledge each party brought. A fifth approach again splits the foreground knowledge into two exclusive parts, this time based on a combination of the background knowledge and the improvements each party was, or will be, able to bring. The last option is to assign all the foreground knowledge to one party. It's important to take account of the commercial interests of each party within the collaboration when dividing the ownership of foreground knowledge.

It is possible to take similar approaches to defining access rights to the foreground, background and sideground knowledge involved in the project for each party. In particular, when it comes to confidential know-how and other proprietary knowledge, it is important to agree how to share such knowledge between the parties, and the specific form and possible restrictions on access involved in the sharing.

Software technologies, for example, are usually protected by copyright and are often of a broad generic nature. Software could be shared as machine-readable object code (if necessary with an application programming interface), as human-readable source code, or in the form of 'black box' access, which provides just enough access to enable the code to work with other programs. It's also important to consider the legal impact of using software used under Open Source or Free Software licences.

This level of rigour and complexity may be daunting for a start-up or academic organisation engaging with a large company for the first time. But working through the process of defining the various types and sources of knowledge, and how each stage of the project will be handled, should improve the overall collaboration and its chances of success. Taking this approach need not necessarily delay the start of the project, either: if you sign an initial confidentiality agreement you can do your project planning while the other legal issues are sorted out in parallel.

Is rigorous IP protection compatible with the fast-moving world of open innovation? Definitely, because protecting IP is important, and working through the issues refines everybody's understanding of their collaboration. It is a learning process that the parties, used to closed innovation processes, must go through if they want to participate successfully in the bright new world of open innovation.

Last, but not least, sorting out the IP issues before the project begins should help avoid the sort of nasty surprises we all hate at the end of any game - like the jigsaw puzzle with one missing piece, or the counterfeit Lego blocks that don't quite fit together.