How do you communicate R&D intellectual property rights with other teams?

It’s important to be aware that law can change from jurisdiction to jurisdiction. Having an understanding of IPR in the United States doesn’t guarantee protection, for instance, in other countries. You’ll want to talk to a licensed attorney with experience protecting IPR in each jurisdiction you want to ensure protection.

Nothing begins from a query, as a lawyer it is important to be curious about the new products that have been introduced in the market and their legality. For example, the idea of AI was introduced way back in 2004 but its applicability is now being debated. So the basic knowledge of the IPR Laws would enable a lawyer to draw a logical conclusion towards the right and wrong applicabilities of the new product. Taking the example forward, the idea that an AI can predict the next purchase of a consumer on an e-commerce website. Whether this information collection and predictability was ethical is the true legal debate and to what extent will decide the punishment in case of breach of the extent.

In corporates every R&D team must have full knowledge of state of the art in area they are working and plan to work so that there is no infringement. Extensive literature study is necessary before taking up projects. Every corporate must send their patent application as soon as some business outcome worth research is made which can be available on Patent databases for others to know. Some patents can be applied even if there is no immediate business outcome. In collaborations, this happens through discussions among 2 company teams. Corporate legal teams also help in making sure that there is no IPR issue. Researchers generally don't publish research where patent is likely to be filed. So no communication required there.

When defining the scope, document the state of the art as well as the background, i.e. what each party brings to the table. This will help defining goals and contributions, and should help resolving questions regarding ownership later.

There are 2 questions that can help with refining the information that need to be shared. Why share the info. and to whom it is shared? It is important to keep all the stakeholders and information handlers in the same page on the happenings of the project activities, ensuring clear communication across teams. Use of legal agreements like NDA, MoU, IPR can greatly help define terms of collaboration and extent of involvement required by each party. Moreover, it is crucial to formulate a strategic plan (both business and protection) making it almost obsolete without the key information to propel with the disseminated information against the ownership and first-hand stakeholders.

When I was younger, I didn't realize that the scope of R/D is fluid. You are moving into the unknown, otherwise it wouldn't be R/D! The scope should be: whatever makes the product better for the customer. R/D should be trying to find out exciting answers that make the customer more interested in the product. Sometimes this means that R/D adds to the scope of the product by discovering something brand new, outside the scope of the product development. Always bring your results to the executive and marketing teams with an eye for communicating clearly what you have (or intend) to discover and listen for how that can make the product even more enticing for your customers.

I would add to this that it is important also to understand each collaborator’s motivation for being part of the project. What are their expectations, especially in relation to what each party will be permitted to do (and not permitted to do) with the outputs from the collaboration. Being VERY clear on this upfront can avoid big problems down the line.

To be honest, while communicating one should know the audience or receiver of the R&D within the team. If you have a team of theorists - you should further task them with designing a hypothesis for the future legal framework given the current or future parameters. If you have a team of application-based litigators then you should task them with the observations of various jurisdictions. And lastly, if you have a team of seniors who are dependent on you to deliver a conclusion you should expect them to be explained in simplistic terms and seek questions for applicability in the current framework.

Be careful to avoid DIY efforts in preparing R&D IPR contracts. Effective contracts are custom tailored to include the facts, uniques goals, and applicable law. Haphazard drafting of contracts by people who do not know what they are doing may cause real problems down the line.

Negotiation works best if you are aware of the real intent of the party of the second part who is interested either in the exploration of the IP or the further R&D of the IP. Continuing on the earlier example of intelligent prediction based on past history, the party of the second part would have an intention to "favourable to the party" outcome, in short, it would want the consumer to buy what the second party is ready and willing to sell. In such case, the party of the first part should negotiate the limited and/or proper exploration of the IP in an ethical as well as in a standard expectation model.

The importance of the agreement cannot be over emphasised. Getting this right will set the tone of the collaboration and will affect the quality of the collaboration. Once the agreement of the terms is set right, R&D teams from both parties can start to work in earnest and not have to keep looking over their own shoulders and worry about their IPR being well protected. This will enable the sharing of research data and discussions to be effective, synergising the teams in collaboration.

Negotiating IP rights before engaging with an R/D partner is a critical step to cover early in your relationship. Some R/D partners will provide everything they do for you - drawings, data, software, and know-how. Others consider that to be their own IP / trade secret and they only provide results, not the details in how they were achieved. Figure out early if those details are important. If they are, expect to compensate your partners fairly for all their efforts. Expect to pay less if you get less and more if you get more. Finally, don't expect to have freedom-to-practice. Your R/D partners may not be able to guarantee this to you. Assume that you need to assess that freedom-to-practice on your own.

In my experience it’s useful to have a short (eg one page) summary of the key terms of the collaboration agreement, in layman’s terms. The summary can cover the roles of the parties, what they are contributing, what they will take away from the project and other significant rights or obligations.

Sharing is an important aspect of learning but one must be open to tasteful criticism as the idea expressed or the conclusion of the research may not have a universal palatability. One should be verbose in the attempt to explain and at the same time state what is required without revealing too much information about the R&D.

Documentation is king! Write a protocol for each meeting, agreed by all parties. Register not only the achievements made, but also whom the contributions came from. Saves you tears later.

Not everyone tags the efforts taken by the actual inventor of the IP, for example, we don't tag Alexander Graham Bell while looking at the latest model of the iPhone or Pixel with true Andriod experience. But, it is important to monitor the individuals who are improving/modifying and/or even downgrading and twisting its usage.

By all means, document the outcomes of he research and celebrate successes, but I would also encourage teams to reflect on "failures" as there are many things, if not more, to learn from what did not work as opposed to only what worked. The quality of the collaboration is often forged in the teamwork, the collective learnings and experiences and the appreciation of dedication and commitment of the team members. These could be monitored throughout the project and celebrated at the end. And yes. It is a warm fuzzy feeling.

Meticulous review of R&D outcomes, carried out with the same rigor as the project itself, not only paves the way for future research but also serves to elevate the scientific community as a whole. Given the ever-evolving healthcare landscape, such introspection is not just advisable; it is essential.

After +25 yrs in the private/public sector and +100 companies, IP by patenting has rarely paid off more than trade secrets that are rapidly developed. Time to market is an enormous advantage over building an IP fortress around your product. Moving swiftly from R/D to market generates revenue, the fundamental purpose of a company's existence. Lean manufacturing and lean development have demonstrated that customer preferences move faster than technical innovation and IP protection. I'd rather develop a product in less time and sell it than plan out a decade long IP strategy to protect it with patents. By the time you are ready to compete with me and my customers, we've already moved on to the next product.