Patently Strategic Podcast: Prenuptial Patenting

In this month’s episode of Patently Strategic, Dr. Ashley Sloat leads a discussion into responsible engagement with engineering firms. Ashley and our patent panel walk you down the aisle and explore everything you need to know to experience marital bliss and an amicable divorce with engineering partners. This talk covers the full life cycle from vetting partners to post development concerns and everything in between – with particular focus on relationship complexities like IP ownership, assignment from engineering firm inventors back to you, and how to avoid the traps of viral IP.

Responsible Engagement with Engineering Firms

You have your big idea and now it’s time to breathe it into existence, but you need some help with the development. Like many others, you may turn to the aid of an engineering firm or dev shop. This relationship is a marriage of sorts. But it’s a marriage that is designed to inevitably end in divorce. How cleanly, smoothly, and successfully this separation goes depends on the steps that you take before it officially begins.

The end goals are a great product and clean asset separation. You’ll want your IP and any newly created devices, infrastructure, etc. – and the engineering firm will want to not be inhibited from doing their job with other clients going forward.

Relationship Stages 

In exploring how to reduce risks, while taking full advantage of the scaling efficiencies of outsourcing, we break down the required steps at every stage of the relationship – from the ups and downs of single life and dating, to the careful optimism of engagement and prenuptials, to the marital bliss of product development all the way through the inevitable divorce of project conclusion. Note that our metaphor intentionally leaves out the honeymoon. Welcome to startup life – there is no honeymoon!

Single Life

Single life is all about getting your act together before forming relationships. This is the time to get your IP, documents, and contracts in order.

• Reduce disclosure risk. Get an NDA before talking with anyone but know that your mileage may vary. Many investors won’t sign NDAs, but engineering firms should be willing to do so. A major risk, however, is over reliance on an NDA. Some signers take them more seriously than others and NDAs don’t define ownership lines, so …
• Inventorship/ownership. Get as much of your IP on file as possible to establish clear lines before talking with firms. This establishes your ownership of the idea versus whatever the engineering firm is bringing to the relationship. For patents specifically, provisional patent applications can be great low cost, low fidelity tools for establishing the earliest possible filing date for your idea and establishing a legal stake for your idea before speaking with anyone.

Dating

Now that you have your idea, an NDA in hand, and potentially a filed provisional patent application, it’s time to put yourself out there and start vetting potential partners. Outsourcing is a largely verified model, but this is potentially a major investment and not all potential partners are created equally, so you need to do your homework.

• Geography. Zoom has solved many problems, but not all of them. Consider the impact of time zones on communication complexities – and especially where engineers are actually located, which could be different from the sales folks you’ll deal with up-front. Legal jurisdiction could also be a major factor in settling any future dispute and laws governing ownership are usually the laws of the jurisdiction in which the IP is developed.
• Security. Consider security measures and how employees are vetted. Your partner’s employees will have access to sensitive data that could be publicly disclosed, sold to competitors, or otherwise misused.
• Conflict of interest management. How is your work firewalled both physically and digitally – especially a concern with larger firms that could also be working with competitors.
• Not all potential partners will have the domain expertise, licenses, or certifications required for your innovation and you don’t want them cutting their teeth on your dime.
• Working model. There’s a lot of variance out there in terms of economic models (time-based vs. fixed, rates, etc.), working models (open to augmentation), and receptiveness to some of the things we’re going to recommend later on.
• Cascading contractors. Ask if the firm subcontracts work. You lose control and visibility at every hop. If so, you will need to ensure they are taking the proper measures to protect your IP and confidential information. Consider requesting approval rights over subcontractors.

Engagement

You’ve found your partner and things are getting serious. It’s time to commit, but you first need to solidify terms and expectations. And like with any relationship, transparency is key. It’s easy to gloss over up front when times are good, trust hasn’t been tested, and time and resources feel abundant, but invest the time now, while you have all the leverage. This stage is heavily dependent upon contractual considerations including:

• Scope of Work. Both parties will benefit greatly from clear SOWs on matters like expectations, deliverables, timeframes, and guarantees.
• IP Ownership. Just because you paid for the work doesn’t necessarily mean you own the IP. This is a big topic and an even bigger pain point, but in order to enjoy the rights and benefits granted by your IP, you may have to transfer the rights from employees of the firm. IP assignments and “Work-for-Hire” provisions are essential to protecting your patents and copyrights.
• Agreements/Clauses. What causes termination and course of action? What’s the jurisdiction for issue resolution? Indemnity (who pays) and right to audit clauses, joinder agreements, etc.

Marriage

You’ve made your commitment official and are now working together in product development harmony. The pieces of the jigsaw start coming together. And while you’re delegating development responsibilities, you still need to take a very active role in what’s to come. Just because you’re married, it’s no time to start letting yourself go! Your responsibilities could include:

• Sources of innovation. Understand and keep inventory of sources of innovation contribution. This includes newly created code and devices vs. vendor-owned, open source, and off-the-shelf contributions.
• Maintain active ownership and possession of less tangible assets like code. When contracting out software development, remember that the actual code is your most intrinsic asset.
• Working mode impact. Know your role in development iterations in terms of invention capture and guarding against public disclosure. This is especially important with approaches like agile methodologies that employ a fast-paced, iterative nature.
• Patentability and FTO. Understand your role in patentability and freedom-to-operate. Engineering firms may conduct some light searching, but patentability and FTO responsibility rests on YOU and your PRACTITIONER.
• Open-source considerations. Take a very active role in the conversation around any open-source software inclusion. Some open-source licenses (especially copyleft) come with conditions that, once included, make it impossible to keep your code proprietary.
• FDA Compliance. Ensure responsibilities are clear around considerations for required documentation, use of medical grade materials, particular components, power requirements, etc.

Divorce

You’ve completed product development and reached the inevitable end of your relationship. Ideally, you will walk away with your product and your partner can go on to serve other clients without new constraints. If you take the right steps in the prior phases, this stage should be nearly automatic and very amicable. Maybe it’s a clean break or maybe you’ll still have a joint custody maintenance contract, but you should now be in a place with clear lines of ownership and celebrating the launch of your project. Your transition and exit plan should consider the following (well ahead of when you need it):

• Collect signatures. Where possible, get assignments/declarations signed before you fully disengage. And maintain a good relationship long term – you may need to follow-up on these for upwards of 15 to 20 years.
• Provide adequate notice as required by your contract.
• Transition ownership of infrastructure, code, devices, etc. to whomever will now be responsible, whether in-house, a new third party, etc.
• Lock up. Cutoff access to networks, systems, assets, and data. Require the vendor to destroy copies of data.
• Third-party monitoring. Consider monitoring the firm’s activity to be sure they’re complying with the agreement terms.

Key Takeaways

• Establish clear lines. Protect as much as possible before disclosure using provisionals.
• Do the diligence. Carefully vet potential partners. There are many factors to consider but skimping here could haunt you for a long time.
• Get good contracts. They only matter when things fall apart and pay particular attention to assignments and work for hire.
• Own your product. Maintain access to physical and digital assets at all times.
• Stay hands-on. Match an iterative IP approach to your development workflow.
• Avoid viral IP. Know what’s getting baked into your product and the implications of its commercial use.
• Exit gracefully. Divorce is inevitable – start thinking about your transition early in the process and then execute your well-thought exit plan.
• And of course, never go to bed angry 🙂

Discussion Panel

Ashley is also joined today by:

• Kristen Hansen, Patent Strategist at Aurora
• David Jackrel, President of Jackrel Consulting

Ashley Sloat

Ashley is Director of Patent Strategy at Aurora Consulting and a USPTO-registered patent practitioner who specializes in the development and management of patent portfolios for startup ventures and emerging growth […see more]

Josh Sloat

Josh Sloat serves as an Executive Technology Advisor with Aurora Consulting and provides consultation for patents in the software, information technology and telecommunications spaces. With over 15 years of engineering […see more]

Story originally seen here