Patently Strategic - Patent Strategy for Startups
Patently Strategic - Patent Strategy for Startups
Prenuptial Patenting: 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.
Both parties come to the relationship with existing assets – IP, software, prototypes, ideas, documentation, etc. More will be created collaboratively throughout the course of the relationship. But how do you ensure you exclusively get back out what you came with and also get what you contributed and uniquely paid for?
In this month’s episode, Dr. Ashley Sloat, President and Director of Patent Strategy here at Aurora, leads a discussion into Responsible Engagement with Engineering Firms, or what we affectionately refer to here as “Prenuptial Patenting”. Ashley and our all star patent panel walk you down the aisle and explore everything you need to know to experience marital bliss and an amicable divorce with your 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.
Ashley is also joined today by our always exceptional group of IP experts including:
⦿ Kristen Hansen, Patent Strategist at Aurora
⦿ David Jackrel, President of Jackrel Consulting
** Resources **
⦿ Show Notes
⦿ Slides
** Follow Aurora Consulting **
⦿ Home
⦿ Twitter
⦿ LinkedIn
⦿ Facebook
⦿ Instagram
And as always, thanks for listening!
---
Note: The contents of this podcast do not constitute legal advice.
WEBVTT
00:05.170 --> 00:08.766
Good day and welcome to the Patently Strategic Podcast, where we discuss all things at
00:08.768 --> 00:12.454
the intersection of business, technology, and patents. This podcast
00:12.502 --> 00:16.366
is a monthly discussion amongst experts in the field of patenting. It is for inventors,
00:16.438 --> 00:19.726
founders, and IP professionals alike, established or aspiring.
00:19.798 --> 00:23.154
And in today's episode, we're tying the knot, clinking our glasses, and taking
00:23.192 --> 00:26.262
a deep dive into patent nuptials. You have your big idea,
00:26.336 --> 00:29.322
and now it's time to breathe it into existence. But you need some help with
00:29.336 --> 00:32.862
the development. Like many others, you turn to the aid of an engineering firm or
00:32.876 --> 00:36.358
dev shop. This relationship is a marriage of sorts, but it's a marriage
00:36.394 --> 00:39.874
that's designed to inevitably end in divorce. How cleanly, smoothly,
00:39.922 --> 00:43.194
and successfully this separation goes depends on the steps you take before
00:43.232 --> 00:46.594
it officially begins. In this month's episode, Dr. Ashley Sloat,
00:46.642 --> 00:49.854
President and Director of Patent Strategy here in Aurora, leads a discussion into
00:49.892 --> 00:53.598
responsible engagement with engineering firms, or what we affectionately refer to here
00:53.624 --> 00:57.178
as Prenuptial patenting. Ashley and our All Star patent panel
00:57.214 --> 01:00.654
walk you down the aisle and explore everything you need to know to experience
01:00.752 --> 01:04.138
marital bliss in an amicable divorce with your engineering partners.
01:04.234 --> 01:07.774
This talk covers the full lifecycle from vetting partners to post development
01:07.822 --> 01:11.950
concerns and everything in between, with particular focus on relationship complexities
01:12.010 --> 01:15.450
like IP ownership assignment from engineering firm Inventors back to you.
01:15.500 --> 01:18.774
And how to avoid the traps of viral IP. Ashley is joined today
01:18.812 --> 01:22.678
by are always exceptional group of IP experts, including Kristen Hanson,
01:22.714 --> 01:26.302
patent strategist here at Aurora, and David Jack Row, president of Jacques
01:26.326 --> 01:30.054
Consulting. And now just one quick announcement before joining the panel. We're very
01:30.092 --> 01:33.370
excited to share that we have been invited to speak at this year's Innovator MD
01:33.430 --> 01:36.822
World Congress. This is the world's largest physician innovation event.
01:36.896 --> 01:40.246
It'll be happening both virtually on zoom and in person in San Francisco,
01:40.318 --> 01:44.046
August 17 to the 20th. Ashley will be on site and conducting a
01:44.048 --> 01:48.046
workshop covering the most common patenting mistakes made by inventors and startups.
01:48.118 --> 01:51.622
She'll highlight best practices for not making the mistakes in the first place. And we'll
01:51.646 --> 01:55.234
explore available remedial options in cases where it's too late for avoidance.
01:55.342 --> 01:58.762
We're really looking forward to the conference and this talk. There was a guidebook
01:58.786 --> 02:01.926
we could hand to inventors on the first day following conception of their idea.
02:02.048 --> 02:05.382
This would be it. We've included a link in the show notes that you can
02:05.396 --> 02:09.046
use for more details on tickets and how to attend. Now, without further ado,
02:09.118 --> 02:12.270
I'll hand it over to your host and part time marriage counselor. Take it away,
02:12.320 --> 02:13.170
Ashley.
02:17.790 --> 02:21.838
This whole conversation today is around engagement with
02:21.924 --> 02:26.150
engineering firms and around how to effectively secure
02:26.210 --> 02:29.350
IP while engaging with engineering firms.
02:29.670 --> 02:33.278
And so kind of thinking through this not only as a patent practitioner,
02:33.314 --> 02:36.838
but almost as like a divorce attorney or something like that,
02:36.924 --> 02:40.498
because it's all about the
02:40.524 --> 02:44.026
preparation and thinking through how things could go wrong,
02:44.208 --> 02:48.506
how they might go wrong, and hoping that you never have to enact
02:48.578 --> 02:51.922
some of these documents that you ultimately create. And so kind
02:51.936 --> 02:55.718
of just, again, kind of walking through all stages of that relationship with an engineering
02:55.754 --> 02:59.434
firm and so hopefully talking about today, again,
02:59.472 --> 03:02.906
key considerations for working with firms who owns the IP
03:02.978 --> 03:06.454
resulting from the relationship. And obviously this can be drafted to be really any
03:06.492 --> 03:09.022
party, but just how do you make sure that you own what you want to
03:09.036 --> 03:12.418
own and then ownership of IP versus inventorship of
03:12.444 --> 03:16.550
IP and then whose responsibility is novelty and inventiveness
03:16.610 --> 03:20.606
of the new price? I think sometimes there's some ambiguity,
03:20.678 --> 03:24.120
at least for the client, around whose responsibility that is.
03:25.350 --> 03:28.682
Obviously there's huge value in a patent and there's
03:28.706 --> 03:32.482
some of the strongest forms of protection, but there's also lots of other forms of
03:32.496 --> 03:36.682
IP trademarks, copyright, trade secret design,
03:36.756 --> 03:41.170
patents. And so there's also immense value to outsourcing
03:41.610 --> 03:45.046
your product development. It's obviously time
03:45.108 --> 03:48.634
tested. There was a recent study that found that over 90%
03:48.732 --> 03:52.118
of respondents worked with a partner to develop and manufacture
03:52.154 --> 03:55.694
their IoT solution. Some 43% of software
03:55.742 --> 03:58.210
companies outsource their software development.
03:58.890 --> 04:02.914
Obviously these companies that have the capability to
04:02.952 --> 04:05.906
develop products for other companies, they have huge infrastructure.
04:05.978 --> 04:09.514
So the client doesn't have to develop that infrastructure. They have
04:09.612 --> 04:12.010
relationships with existing partners.
04:12.990 --> 04:16.186
It reduces the client's upfront commitment. You can
04:16.248 --> 04:20.246
also leverage their expertise that they have in house and it allows
04:20.258 --> 04:23.126
you just to move a lot quicker. Right? Because hiring is expensive.
04:23.198 --> 04:26.386
Hiring takes a long time. And how do you hire for somebody
04:26.508 --> 04:30.178
with expertise that you personally don't have? It can be hard to
04:30.204 --> 04:33.610
just partnering with a devshop can be a lot easier. We're not saying
04:33.660 --> 04:36.778
you have to, but I know a lot of companies do it. There's a lot
04:36.804 --> 04:40.318
of value there and it's obviously also highly flexible, right?
04:40.464 --> 04:43.606
You can do an MVP, you can do different features with them,
04:43.668 --> 04:46.560
you can scale it up and tailor it back as needed.
04:47.190 --> 04:51.334
But I think the biggest problem that we've seen is
04:51.432 --> 04:54.562
navigating what you're going to own at
04:54.576 --> 04:58.298
the end of it versus what the firm
04:58.334 --> 05:02.438
is going to own at the end of it. Right. Because everybody brings
05:02.474 --> 05:05.902
different things to the partnership and you have to figure out a way to
05:05.916 --> 05:09.286
take those puzzle pieces back apart at the end and everybody
05:09.348 --> 05:12.420
get what they thought they should get out of that relationship.
05:13.110 --> 05:17.146
And so kind of walking through, we kind of correlated this obviously
05:17.268 --> 05:19.810
with dating because it is very much like dating.
05:20.790 --> 05:25.498
You have a single life where you're trying to get all your
05:25.524 --> 05:29.930
house in order, get your IP in order, get your documents
05:29.990 --> 05:33.998
in order, get your contracts in order. Then you're going to go through dating
05:34.034 --> 05:37.918
and vetting different partners, maybe getting recommendations from
05:37.944 --> 05:41.110
other partners that you work with, having meetings.
05:41.550 --> 05:44.698
There's going to be an engagement or pre nuptial period where you're going to work
05:44.724 --> 05:48.794
for the contract with that potential engineering firm.
05:48.902 --> 05:51.682
And then there's the marriage, which is the actual product development where you're kind of
05:51.696 --> 05:55.450
working together in harmony to develop this product. And then ultimately,
05:55.770 --> 05:58.714
most likely, you're going to have some kind of divorce at the end of it
05:58.752 --> 06:02.770
to basically divvy back up the IP and
06:02.880 --> 06:06.250
then you walk away with your developed product and they go back and serve other
06:06.300 --> 06:09.826
clients. And so this is obviously
06:09.888 --> 06:13.546
different than typical marriage, or in theory it is, because it almost
06:13.608 --> 06:17.314
always ends in divorce. Right. That's the whole goal is that you come together to
06:17.352 --> 06:20.400
develop this beautiful product and then you kind of split up at the end.
06:20.970 --> 06:23.770
But I also have a few angular experiences, of course,
06:23.880 --> 06:27.540
Kristen and Dave feel free to jump into if you think of anything.
06:29.410 --> 06:32.810
So in the single line for companies, I think the biggest thing
06:32.860 --> 06:36.230
is that you want to reduce your disclosure risk, of course,
06:36.280 --> 06:39.626
includes getting nondisposure agreements before you talk with anyone.
06:39.808 --> 06:42.078
Of course, this is going to have been flow a little bit with who you're
06:42.114 --> 06:45.614
talking with, investors and whatnot won't necessarily sign
06:45.652 --> 06:48.998
NDAs, but engineering firms should be willing to sign
06:49.024 --> 06:52.382
the NDA. Just make sure that the NDA and
06:52.396 --> 06:54.794
I think I touch on this later, but make sure that NDA does not have
06:54.832 --> 06:58.790
contract language in it. Some companies like to spill
06:59.410 --> 07:03.042
other contract language into an NDA. Just make sure NDA is a pure NDA.
07:03.066 --> 07:05.150
That's all it needs to be at this point. It doesn't need to be anything
07:05.200 --> 07:08.678
more in vendorship and ownership, making sure
07:08.704 --> 07:12.674
you get as much IP on file as soon as possible before you
07:12.712 --> 07:16.058
start talking with different firms or establishing relationships with
07:16.084 --> 07:19.240
them. This is where the value of a provisional comes in.
07:21.010 --> 07:24.422
It comes into play and has high value. It will
07:24.436 --> 07:28.130
establish, obviously, your clients IP
07:28.450 --> 07:31.622
and your ownership of that idea versus whatever the
07:31.636 --> 07:35.174
engineering firm is bringing to the table. And so I think
07:35.212 --> 07:38.822
that's probably the biggest important piece of this is just you
07:38.836 --> 07:41.702
want that clear line before you start any partnership, and a provisional is a good
07:41.716 --> 07:42.700
way to do that.
07:44.950 --> 07:48.266
I agree. I think part of the technique there
07:48.328 --> 07:51.974
is to get your ideas on file and some sort of provisional even fits cover
07:52.012 --> 07:55.442
sheet, right. And then as you work with
07:55.456 --> 07:58.538
that engineering firm, if they come to some novel ways of
07:58.564 --> 08:02.020
solving some of the problems that you have either
08:02.650 --> 08:06.794
created by creating the product or just
08:06.832 --> 08:10.370
ran into and needed fixing, it serves a
08:10.420 --> 08:14.418
really good way of filing two applications.
08:14.574 --> 08:18.506
One on your original idea with many bells and whistles that
08:18.568 --> 08:21.858
aren't related to whatever problem this engineering firm
08:21.894 --> 08:25.130
solved, and they can file something with you on
08:25.180 --> 08:30.146
a second application. And dividing those usually
08:30.208 --> 08:33.998
isn't a problem because usually even if you tie it back to the date,
08:34.144 --> 08:37.022
as long as you're not getting restriction requirements and things that are going to have
08:37.036 --> 08:38.690
to be a problem in the divorce.
08:40.570 --> 08:43.802
It's usually okay to tie it back to the
08:43.816 --> 08:47.738
date of the parent provisional, but you may not
08:47.824 --> 08:51.654
actually follow through with that tie back in the end because those claims
08:51.702 --> 08:55.406
may have actually been created later. It's something
08:55.468 --> 08:59.030
where, by procedure, we usually tie it back and we
08:59.140 --> 09:02.582
pull them off the original provisional. But in practice, if you
09:02.596 --> 09:06.038
ever had to uphold those claims, it's unlikely that they
09:06.064 --> 09:09.158
would hold up for the new claims of the engineering firm because of when they
09:09.184 --> 09:12.280
came into the process time wise. Right.
09:13.150 --> 09:16.430
So even if you strategically tie it just
09:16.480 --> 09:19.754
because it happens to be related and it happens to share some
09:19.792 --> 09:22.934
inventorship, it's possible that that wouldn't hold
09:22.972 --> 09:26.258
up anyway. Yes. I think the other interesting part.
09:26.284 --> 09:30.014
Too. That I've seen. Not necessarily from an engagement with an engineering firm. But even
09:30.052 --> 09:33.578
when you're working with universities. If you're using
09:33.664 --> 09:38.138
expertise from a university. We've seen it where we
09:38.224 --> 09:42.102
do a provisional with the stuff that was fully conceived
09:42.126 --> 09:45.818
of. Adjust the client. And then a separate provisional of
09:45.844 --> 09:49.634
it. The material that was conceived of in partnership with the
09:49.672 --> 09:53.246
university people. So then there's also clear ownership lines there
09:53.308 --> 09:56.810
of universities tend to take
09:56.860 --> 10:00.422
everything that's been developed kind of under their
10:00.616 --> 10:04.146
umbrella. There are some exceptions, like undergrads
10:04.158 --> 10:07.766
and things like that, those are paying for their education. But I
10:07.768 --> 10:11.654
think the same way here kind of what you were saying, Kristin, is if
10:11.692 --> 10:15.062
that one, you have very clear delineation between what
10:15.076 --> 10:18.386
the company did versus what the third party did in collaboration with the company.
10:18.568 --> 10:21.758
But then you also if for some reason something
10:21.844 --> 10:26.118
happens with the engineering firm, that IP
10:26.154 --> 10:29.822
that's related to that engineering firm is completely separate as well.
10:30.016 --> 10:33.770
Right. If they become difficult to work with or something
10:33.820 --> 10:37.610
like that, that IP hasn't infiltrated
10:37.930 --> 10:42.038
other aspects of the portfolio, you've kind of segmented it
10:42.064 --> 10:45.374
off. Yeah. And that's a really
10:45.412 --> 10:49.182
good example because universities are always trying to license what they've
10:49.206 --> 10:52.278
got. So rather than Joe Blow,
10:52.314 --> 10:54.770
engineer one and engineering firm too,
10:54.940 --> 10:58.358
who may license something, but they're really
10:58.444 --> 11:01.722
probably trying to block others from doing what they're doing and selling what they're
11:01.746 --> 11:05.582
doing, they're not likely going to license it unless they're up
11:05.596 --> 11:09.354
for selling it at some point or it's brilliant.
11:09.402 --> 11:13.554
Right. So many patents don't get licensed, but it's
11:13.602 --> 11:17.514
more likely that they would when you have somebody actively searching for a licensee,
11:17.622 --> 11:21.194
which is most universities. So that's a really
11:21.232 --> 11:24.100
good situation to divide that up as soon as you can.
11:24.430 --> 11:28.034
Yeah, that was going to echo the exact same thing. And especially in these
11:28.072 --> 11:31.922
situations where you have, I guess, a primary company
11:32.056 --> 11:36.062
who's trying to outsource something. So it's like different than a
11:36.256 --> 11:39.678
joint development agreement between two sort of equal
11:39.714 --> 11:43.562
partners. This is one where it's like one company is trying to outsource something,
11:43.636 --> 11:47.474
but the company is the driver we would always tell
11:47.512 --> 11:51.926
people to file all your ideas in a provisional and even maybe think ahead
11:52.108 --> 11:55.614
if you're going to engage with this other firm and they're going to be developing
11:55.662 --> 11:59.330
products, put all of your ideas for that product down
11:59.380 --> 12:02.678
before you engage with them. Have a record of that. So then, like you are
12:02.704 --> 12:05.562
both saying, it's so much cleaner, clearer,
12:05.706 --> 12:09.386
there's documentation about
12:09.448 --> 12:13.170
what exactly you did have possession of before you engage.
12:13.230 --> 12:15.614
And then I think you're going to get to it. But then of course,
12:15.652 --> 12:19.482
the next step is the agreement of okay, if something is jointly
12:19.506 --> 12:22.370
developed and who owns that, right? Yeah,
12:22.420 --> 12:25.598
exactly 100%. And yeah, we'll talk about that in more
12:25.624 --> 12:29.438
detail for sure, because it can be credited any way you want it to
12:29.464 --> 12:32.922
be, but there are probably some ways where you more likely
12:32.946 --> 12:34.600
than not want it to be.
12:36.890 --> 12:40.254
So just for obviously anybody who doesn't know non disclosure, I know you both do,
12:40.292 --> 12:43.366
but obviously non disclosure insures
12:43.438 --> 12:47.218
full confidentiality of all IP assets, limits third party
12:47.254 --> 12:50.782
disclosure without permission, ideally signed
12:50.806 --> 12:54.222
by the giver of the information and the receiver of
12:54.236 --> 12:57.958
the information. But again, like I said, it shouldn't include Statement of Worker IP
12:57.994 --> 13:01.906
agreement language. Now, a Statement of Worker IP agreement might have non
13:01.918 --> 13:05.218
disclosure language in it, but it's not typical for an NDA
13:05.254 --> 13:08.562
to have Statement of Worker IP language in there because you're kind of
13:08.576 --> 13:11.660
jumping the gun a little bit then by putting that in there.
13:12.350 --> 13:16.182
There's a quick comment on NDA because it's very related to what we're talking
13:16.196 --> 13:20.062
about. But I feel like a mistake that some people I've
13:20.086 --> 13:23.960
seen make is they try to rely too much on an NDA and
13:24.470 --> 13:28.314
thinking about like what we're just talking about the NDA is great. Of course,
13:28.412 --> 13:31.698
we always recommend that some people take them
13:31.724 --> 13:35.262
more seriously than others. So there is risk there. But in the
13:35.276 --> 13:38.610
NDA, it's not going to say specifically the technology
13:38.720 --> 13:42.030
that you are in possession of earlier or the other company
13:42.080 --> 13:46.162
was in. And that's where all these filings, the provisionals before you engage
13:46.306 --> 13:49.818
comes in together with the NDA, right? Yeah,
13:49.844 --> 13:53.074
that's a good point because in a vacuum,
13:53.122 --> 13:57.200
an NDA doesn't say a whole lot. Right. Just as of this date,
13:57.650 --> 14:01.410
anything that we've discussed, but who knows
14:02.090 --> 14:05.178
other people in that room or any documentation that was created, who knows what was
14:05.204 --> 14:08.458
discussed, right. Whereas having a final application on file
14:08.554 --> 14:12.958
really clearly spells it out, what was clearly
14:12.994 --> 14:16.630
known before that meeting happened. Right. Really clearly
14:16.690 --> 14:18.920
says this is what we had.
14:19.970 --> 14:24.020
And that maybe just goes towards documentation as well. Just in general from
14:24.530 --> 14:27.762
NDA meeting perspective, just really having good documentation too.
14:27.836 --> 14:30.270
So if you are relying on the NDA,
14:30.710 --> 14:34.518
you have the documentation to prove what was in that meeting, then at
14:34.544 --> 14:36.560
minimum, right? Yeah.
14:38.450 --> 14:43.210
All right. So then you're going to start vetting partners, the dating aspect
14:43.390 --> 14:46.602
and kind of tinder, although I
14:46.676 --> 14:49.242
don't think I've ever used that app. I couldn't even tell you. All they know
14:49.256 --> 14:51.786
is you had to swipe left. So we're going to talk about swiping left a
14:51.788 --> 14:55.318
few times. You want to consider several
14:55.354 --> 14:58.578
things when you're dating different engineering firms or embedding them.
14:58.724 --> 15:02.614
Obviously, geography and jurisdiction, the biggest
15:02.722 --> 15:06.226
asset comes in terms of time zone differences.
15:06.298 --> 15:09.946
And if you can work well with different time zones
15:10.018 --> 15:14.206
right. If that's going to work okay. Within the workflow that you have established,
15:14.398 --> 15:16.590
but also legal jurisdiction,
15:18.410 --> 15:21.450
is that if something goes awry,
15:22.070 --> 15:25.542
having part of the different teams and different legal jurisdictions, is that going
15:25.556 --> 15:28.878
to cause a problem for enforcing anything that you've set up,
15:28.904 --> 15:32.300
whether it be an NDA or some kind of agreement that you set out?
15:32.750 --> 15:35.866
Remember, the IP law is very strictly territorial.
15:35.938 --> 15:39.882
So again, if that territory that
15:40.016 --> 15:43.654
you're doing business with maybe has more permissive IP laws,
15:43.762 --> 15:47.830
is that going to be problematic? So just thinking about geography
15:48.010 --> 15:51.630
a little bit and how knowing that
15:51.680 --> 15:55.434
the people you talk with from a sales perspective may be different than the people
15:55.472 --> 15:58.798
that you are going to be working with from an RND perspective.
15:58.954 --> 16:02.658
And so just because the people you talk with are in
16:02.684 --> 16:05.934
Europe, for example, but then the people that you're actually working with,
16:05.972 --> 16:10.138
maybe in Singapore, and so do those different time zones and jurisdictions
16:10.234 --> 16:13.414
across all the different parts of the company, are those conducive
16:13.462 --> 16:15.560
to the work that you want to do with that company?
16:17.090 --> 16:20.190
Thinking about security and conference of interest management,
16:21.650 --> 16:25.182
obviously, especially with app development, medical device and
16:25.196 --> 16:28.326
things like that, might be a little bit, I guess Catheters could get kind of
16:28.328 --> 16:31.878
sticky, but more unique medical devices and
16:31.904 --> 16:35.734
things like that. I feel like conflict of interest is easier
16:35.782 --> 16:39.502
to manage, but we start getting into app development and maybe even like capitals
16:39.526 --> 16:43.542
and things like that. I can see there
16:43.556 --> 16:46.938
are companies that specialize in doing certain kinds of things. They're probably going to have
16:46.964 --> 16:50.578
multiple clients at the same time where they're developing
16:50.614 --> 16:54.606
similar technologies for the different clients. So how do you manage and
16:54.728 --> 16:58.078
how do you vet that third party to make sure that they're managing potential conflicts
16:58.114 --> 17:02.338
of interest? Right? Do they have separate floors for a separate,
17:02.374 --> 17:05.626
like personnel and entry
17:05.698 --> 17:09.318
and data management systems for all these different clients that might be a conflict so
17:09.344 --> 17:12.882
that one person who's working on your project can't see the other stuff,
17:12.956 --> 17:16.446
or another client, how do they manage that?
17:16.508 --> 17:20.334
Right. Because you don't want somebody working on your Catheter who's also
17:20.372 --> 17:22.880
working on Bars catheter right.
17:23.990 --> 17:27.750
Making sure that they have relevant experience and expertise.
17:28.070 --> 17:31.870
If you need an FDA compliant
17:32.050 --> 17:35.874
device, they have FDA experience. If you
17:35.912 --> 17:39.306
are working on medical devices, do they understand the requirements that
17:39.428 --> 17:42.822
medical devices have? If it's some kind of wearable, there's obviously
17:42.956 --> 17:46.318
battery life and charging and different attributes
17:46.354 --> 17:49.878
of wearables that are more known in the art. Are they familiar with
17:49.904 --> 17:53.682
that. So it's an app development. If you want react native, do they
17:53.696 --> 17:57.102
know how to develop react native apps? If you want native to particular
17:57.176 --> 18:00.162
platform? So they know how to do that, essentially making sure that they have the
18:00.176 --> 18:03.498
relevant experience, make sure that you
18:03.524 --> 18:07.618
know what kind of working model that they have. Is it time based fixed
18:07.654 --> 18:10.854
rates? Is it feature base and making sure
18:10.892 --> 18:14.442
that works with you and your budget? Of course. And then I think the
18:14.456 --> 18:17.190
other aspect is cashguine contractors.
18:18.230 --> 18:21.342
Is all the expertise in house? And are you going to be able
18:21.356 --> 18:24.502
to touch base with any of those contractors or people you're
18:24.526 --> 18:27.750
working with? Or are they using additional contractors on their
18:27.800 --> 18:31.134
back end to accomplish work? And how much do you care about
18:31.172 --> 18:34.846
oversight into those other people? Do you care that they're using maybe additional
18:34.918 --> 18:38.046
contractors to execute? Or do you want to have more insight? But I think you
18:38.048 --> 18:41.922
have to be careful with in general is that if
18:41.936 --> 18:45.414
you have so many different groups or if there's different groups within one
18:45.452 --> 18:48.562
company working on the product, how do you make sure that they're
18:48.586 --> 18:51.870
all coming together in a harmonious way to
18:51.920 --> 18:55.174
deliver the product that you ultimately want? We had a client
18:55.222 --> 18:58.566
that was using different contractors to
18:58.568 --> 19:02.046
build different parts of their device. And when it finally all came together, they started
19:02.108 --> 19:05.638
having different technical problems that they just didn't foresee
19:05.674 --> 19:08.562
until it was all kind of put together because nobody was talking together. They were
19:08.576 --> 19:11.838
all kind of siloed. And so then they had this product where
19:11.864 --> 19:15.462
it was like, okay, this is a great, maybe MVP, but we have
19:15.476 --> 19:18.534
a lot of things to fix for it to be an actual viable product.
19:18.632 --> 19:21.498
Because all these things were kind of developed in a vacuum and kind of put
19:21.524 --> 19:24.762
together at the last point. So just how do you manage that workflow to make
19:24.776 --> 19:27.920
sure that doesn't happen? Yeah,
19:28.310 --> 19:30.630
it's so important. I think this phase,
19:31.430 --> 19:35.302
one of the slightly different example about where this becomes
19:35.326 --> 19:39.042
so important and I've seen so many times is
19:39.236 --> 19:43.510
for more in like a manufacturing space for a brick and mortar manufacturing
19:43.570 --> 19:47.046
company almost, or at least it's very common
19:47.168 --> 19:51.082
for people to outsource the equipment manufacturing
19:51.166 --> 19:54.274
to these big equipment manufacturers.
19:54.382 --> 19:57.934
And when people have unique processes,
19:58.042 --> 20:00.860
materials, unique products,
20:01.250 --> 20:04.890
often the manufacturing equipment has to be tailored to make that product.
20:04.940 --> 20:08.686
Of course. And then the company who has this unique IP
20:08.818 --> 20:13.162
needs to teach all of that in great detail to this equipment manufacturer
20:13.186 --> 20:16.302
so that the equipment manufacturer can make the right tool
20:16.376 --> 20:20.058
to actually produce this novel thing right.
20:20.144 --> 20:24.606
And that is such a difficult relationship
20:24.728 --> 20:28.590
because the equipment manufacturers have huge
20:28.700 --> 20:31.938
motivation to take everything that you've just talked to them about how to make these
20:31.964 --> 20:34.710
things great and tell all of their other clients.
20:38.550 --> 20:42.970
The motivation is there. So picking a good partner
20:44.190 --> 20:47.674
and shoring up your own IP, making things
20:47.712 --> 20:50.940
really clear, working out the agreements all up ahead of time.
20:51.750 --> 20:55.982
It's just so important, like in the dating phase,
20:56.126 --> 20:59.758
to get all that stuff thought about out
20:59.784 --> 21:03.482
on the table, discussed, cleared up before you actually engaged
21:03.506 --> 21:07.318
and get into the work phase. Yes. You really
21:07.344 --> 21:09.674
want to make sure it's going to be conducive and you can have full oversight,
21:09.722 --> 21:12.060
right? Yes.
21:12.930 --> 21:19.778
Is it a good partner? Do you trust them? And is
21:19.804 --> 21:23.414
it going to be something that will work
21:23.452 --> 21:26.678
out the pros, outweigh the cons, if you will?
21:26.764 --> 21:30.578
Because it's very difficult. You can't do everything in
21:30.604 --> 21:33.582
house. You have to engage in outside firms.
21:33.666 --> 21:36.890
Oftentimes it's much more efficient. And so there are risks,
21:37.270 --> 21:40.842
but there are ways to mitigate those risks, right? By finding
21:40.866 --> 21:44.714
the right partner, having the right agreements, and then doing
21:44.752 --> 21:48.062
all that. We've been talking about filing your provisional, making sure
21:48.076 --> 21:51.100
it's really clear what you own and all that.
21:52.030 --> 21:55.334
Yeah, absolutely. Okay,
21:55.372 --> 21:59.102
so you have dated and vetted hopefully the right partner at least narrowed it down.
21:59.236 --> 22:02.070
So kind of moving into the engagement or prenuptial period.
22:02.190 --> 22:05.090
So again, the whole goal of this is that you're going to come together.
22:05.260 --> 22:08.882
You have your NDA, maybe some patent pending, they have all
22:08.896 --> 22:12.594
their tools are going to come together, create beautiful IP,
22:12.762 --> 22:16.574
beautiful products. At the end you're going to separate. Right. You're going to have more
22:16.612 --> 22:19.958
IP, ideally, and they're going to be less filled with their core things
22:19.984 --> 22:23.390
that they brought to the table. And so in thinking
22:23.440 --> 22:26.642
of pre natural contracts before you kind of engage the
22:26.656 --> 22:30.506
engineering firms, really think about a contract is I
22:30.508 --> 22:33.062
hate to think about it this way, but it has to be almost like the
22:33.076 --> 22:37.250
worst case scenario for how a relationship
22:37.360 --> 22:41.214
could end up in building provisions around that worst case scenario.
22:41.262 --> 22:45.160
Because honestly, contracts only matter when things blow up.
22:45.790 --> 22:49.190
They don't really matter if everything goes smoothly. Right. So you kind of want to
22:49.300 --> 22:53.370
think about your scope of work and make sure it's super clear. Non disclosure agreement,
22:53.430 --> 22:56.802
language, intellectual property ownership language, termination clauses,
22:56.826 --> 23:00.722
and other legal clauses. So thinking of scope of work,
23:00.856 --> 23:04.478
you want to think of expectations, deliverables time
23:04.504 --> 23:07.958
frames and guarantees. And this is super important. The image I
23:07.984 --> 23:11.246
have up on the screen is one person thinking of a
23:11.248 --> 23:14.970
square, one person thinking of a circle, and one person thinking of a triangle,
23:15.090 --> 23:19.286
and they're all thinking they're in agreement. How many conversations have we had with
23:19.468 --> 23:23.102
clients or other people where everybody thinks they're all on
23:23.116 --> 23:26.630
the same page and then something
23:26.680 --> 23:29.858
is created or there's a claim that's created and they're like, oh, that's not what
23:29.884 --> 23:33.642
I thought that was going to be. And so it's just so critical
23:33.726 --> 23:37.610
to really map out what the work is going to look like. So again,
23:37.780 --> 23:41.810
expectations, for example, for software, can they
23:41.860 --> 23:45.518
use open source software? Or if It's devices, can they use off the
23:45.544 --> 23:49.190
shelf components? Is it an MVP? Is it actually like an FDA running
23:49.300 --> 23:52.734
product? What are they creating? You want to outline
23:52.782 --> 23:56.790
all the deliverables. Do you want paperwork for the FDA?
23:56.910 --> 23:58.540
Start putting it through that process.
24:00.670 --> 24:04.398
They can be using some kind of framework, agile framework that you're familiar
24:04.434 --> 24:07.862
with or what they are used to in house. You also want
24:07.876 --> 24:11.874
to consider what kind of time frames
24:11.922 --> 24:16.286
there are, what kind of contracts you have in terms of feature based or
24:16.348 --> 24:20.114
time based ones. And so if it's feature based, that's great because
24:20.152 --> 24:22.862
you can then agree to all these different features and you lean on them for
24:22.876 --> 24:26.858
their expertise, for how much time these features might take, or the cost for
24:26.884 --> 24:30.426
them versus time based. Sometimes it's a little dangerous
24:30.498 --> 24:34.286
just because, as we know, you always end up
24:34.468 --> 24:38.198
with encountering problems in development and you don't want them
24:38.224 --> 24:41.990
taking shortcuts to meet a deadline. A time based
24:42.040 --> 24:45.710
deadline would ultimately you just want that feature. And so just really thinking
24:45.760 --> 24:49.190
about what really matters and also making sure it's an appropriate scope of work
24:49.240 --> 24:52.590
right for the engagement. What is your MVP
24:52.650 --> 24:55.480
like? What's your FDA product, whatever the case may be.
24:56.290 --> 24:59.030
Guarantees for software,
24:59.350 --> 25:02.438
I think this is more common, where you could have code guarantees that it should
25:02.464 --> 25:05.906
behave well for X period of time without
25:05.968 --> 25:09.398
any bugs. And then maybe you have some kind of maintenance contract with them that
25:09.424 --> 25:12.806
says after this time frame, if bugs are found, they'll fix them at whatever
25:12.868 --> 25:16.214
rate for you. For devices, I don't believe there's really any
25:16.252 --> 25:19.850
guarantees outside of just the guarantee that it's going to work, right?
25:19.900 --> 25:23.222
That we've created this capital for you and we said that we
25:23.236 --> 25:25.262
were going to create it so it would work. And so we're going to get
25:25.276 --> 25:28.562
you something that works. But I don't think there's going to be any kind of
25:28.576 --> 25:31.970
guarantee of customer success, market success, or anything
25:32.020 --> 25:35.522
like that. So I think guarantees are going
25:35.536 --> 25:39.160
to be light, but there does need to be clear
25:39.790 --> 25:42.470
lines around expectations, deliverables, and timeframes.
25:45.170 --> 25:48.942
Go ahead, Christine. Go ahead. Oh, that's okay. Mine was a little bit
25:48.956 --> 25:52.160
tangential, so go ahead on. The guaranteed thing
25:53.510 --> 25:57.500
in a product or a tool oftentimes are going to have
25:59.390 --> 26:03.006
a specification. It needs to
26:03.128 --> 26:06.870
ramp up to temperature and X amount of time or the device
26:07.730 --> 26:10.878
this needs to fit in there or have this strength or
26:10.904 --> 26:14.878
this whatever. Oftentimes you would have specifications,
26:14.914 --> 26:18.270
maybe guarantees a strong word, but you'd have specifications that they
26:18.320 --> 26:21.920
are designing around, you know what I mean? And that can be
26:22.550 --> 26:26.854
important, I think, in certain cases,
26:27.022 --> 26:30.714
right? Maybe. I think it's where the feedback loop comes to that they
26:30.752 --> 26:34.042
can't from like expectations or guarantees,
26:34.066 --> 26:37.834
whatever. If you've set some sort of deliverable
26:37.882 --> 26:41.960
or some kind of suspicion that is impossible to reach given other
26:42.410 --> 26:46.318
device constraints. Then again, like a good opendoor
26:46.354 --> 26:49.926
feedback loop between the company and the
26:49.988 --> 26:53.398
third party to make sure that those things are communicated
26:53.554 --> 26:57.138
so that then specifications can be revised. Right. Because I
26:57.164 --> 27:00.858
think I know that kind of stuff happens. They start developing and
27:00.884 --> 27:04.342
there's like there's no way I can make this drone fly
27:04.426 --> 27:07.698
in the way that you thought it would, given the propeller arrangement that we all
27:07.724 --> 27:11.406
agree to. So how are we now going to make it
27:11.468 --> 27:14.874
behave like you want to. But then change the design that's still
27:15.032 --> 27:20.382
within whatever other parameters that we have now.
27:20.396 --> 27:23.842
I know we're talking about the scope of work and design documents
27:23.926 --> 27:27.402
and expectations of delivery and what you're going to get.
27:27.536 --> 27:31.266
But something subtle and software is
27:31.328 --> 27:35.286
that you've got these people the one thought of the square. The one thought of
27:35.288 --> 27:38.898
the circle. And the one thought of the triangle. Let's look at those as
27:38.984 --> 27:42.534
three pieces that are being implemented in a product as
27:42.572 --> 27:46.158
software. Whoever is implementing that and
27:46.184 --> 27:49.750
I mean coding that up, generating the actual software
27:49.810 --> 27:52.640
code, making that actually function,
27:53.210 --> 27:56.814
those people are not considered the inventors. Those people should not
27:56.852 --> 28:00.574
be listed on the inventorship. If you're filing your provisional,
28:00.622 --> 28:04.762
if you're filing any of that along the way, those are just implementations
28:04.846 --> 28:07.878
of the original scope of the design document and the
28:07.904 --> 28:11.382
original algorithm, if you will. So something
28:11.456 --> 28:15.322
subtle when you're working with engineering firms in that way, remember, just because they created
28:15.346 --> 28:19.650
your code doesn't mean they created the idea or had any piece
28:19.760 --> 28:22.940
of the original idea.
28:23.330 --> 28:26.838
There are situations where it's different than that and they should be
28:26.864 --> 28:30.042
involved. But it comes into, did they
28:30.176 --> 28:33.510
solve a piece of the problem that you actually are trying to claim?
28:33.950 --> 28:37.434
Right. That is a little bit different than just implementing your
28:37.472 --> 28:41.070
code, your algorithm in code, right? No,
28:41.120 --> 28:46.342
absolutely. That's 100% because it's
28:46.366 --> 28:50.046
like the difference between handing an engineering firm a completely
28:50.228 --> 28:53.780
spec out CAD file of building a part,
28:54.110 --> 28:57.402
right, and saying, here, create this part for me and then set it back,
28:57.596 --> 29:01.230
versus basically saying, here kind of pie in the sky.
29:01.610 --> 29:05.718
I want a device that has A, B and C attributes that
29:05.744 --> 29:08.000
then functions in such a way as D.
29:09.290 --> 29:12.966
In that second scenario, there's likely going to be some inventing going
29:13.028 --> 29:16.302
on. In the first scenario, there's no inventing by the
29:16.316 --> 29:20.600
third party firm. And same with software. If it's like you're basically
29:20.990 --> 29:24.442
very clearly this is all the things it needs to do and now you're
29:24.466 --> 29:28.650
just going to code it up versus a little bit more open
29:28.700 --> 29:32.046
ended. I just want it to be
29:32.108 --> 29:34.926
behave like this and figure out how it's going to do it. And they might
29:34.988 --> 29:37.760
be inventors in that regard. Right,
29:40.110 --> 29:43.606
go ahead. Yeah, I guess the corollary I make there is maybe
29:43.728 --> 29:47.230
a mechanical engineer who is working at the engineering firm thing.
29:47.280 --> 29:50.834
Well, in order to do this requirement
29:50.882 --> 29:54.374
from your document, I need three notches in the Widget.
29:54.482 --> 29:58.022
Right. And that would be the software guy at the. Software engineering
29:58.046 --> 30:01.906
firm saying, well, in order to make this function and work
30:02.028 --> 30:05.506
like you slated it to work, we have to use
30:05.568 --> 30:08.280
artificial intelligence and we have to use the machine learning,
30:08.970 --> 30:12.394
right. Those sorts of things, those were not initially thought
30:12.432 --> 30:16.082
of, those were not initially proposed or generated
30:16.166 --> 30:19.742
by the actual IP originator.
30:19.886 --> 30:23.254
Right. So then those people should be part of
30:23.292 --> 30:26.998
the invented entity. And I said those people,
30:27.024 --> 30:29.650
I mean the engineering firms in those examples.
30:31.510 --> 30:35.150
Yes, that was a perfect TM because yes, ownership.
30:35.590 --> 30:39.074
So after first inventorship is the person who has contributed to the
30:39.112 --> 30:42.614
conception of the invention to the point that their idea
30:42.652 --> 30:45.642
is clear enough to be able to be reduced to practice,
30:45.726 --> 30:49.262
right? It doesn't have to be reduced, at least actually reduced to practice. It could
30:49.276 --> 30:52.250
be just constructively, just written in reduction of practice.
30:53.950 --> 30:57.114
Whereas ownership is the entity that has the authority
30:57.162 --> 31:00.602
to file the patent applications and enjoys all the rights and benefits
31:00.796 --> 31:04.790
if the patent is assigned to the entity. So from just inventors,
31:05.710 --> 31:09.962
if you're the inventor and there's no entity that it's assigned to,
31:10.156 --> 31:14.140
you're also the owner, right? Inventor equals owner. But if you are
31:14.470 --> 31:18.578
an employee who has signed assignments to the company
31:18.664 --> 31:22.526
or has assignment provisions in your contract and
31:22.588 --> 31:26.402
work for higher provisions, then those rights are going to flow to the company
31:26.476 --> 31:30.062
that you work for. And similarly. I think we'll get
31:30.076 --> 31:34.110
to this later. But if you have an engineering contract.
31:34.170 --> 31:37.854
A contract with the engineering firm. There should be IP
31:37.902 --> 31:41.238
provisions in there that basically say that your company owns
31:41.274 --> 31:44.810
the IP and not the engineering firm. Unless you have
31:44.860 --> 31:48.738
created some kind of unique arrangement. Right. Where the engineering
31:48.774 --> 31:52.360
firm gets some kind of equity or something like that.
31:53.650 --> 31:57.494
If they have part ownership or something like that. But otherwise your company should own
31:57.532 --> 31:58.120
it.
32:00.970 --> 32:04.382
Yeah, continuing on the It ownership piece,
32:04.576 --> 32:08.574
remembering that the creator is the owner, unless the contract says otherwise,
32:08.622 --> 32:13.638
that the engineering firm creates it like fully conceived
32:13.674 --> 32:17.742
of it, then they're going to be the IP owner. Unless it's
32:17.766 --> 32:21.398
in your contract that your company owns it. You want to include work for
32:21.424 --> 32:24.974
higher provisions, especially for software that again, just because their
32:25.012 --> 32:29.042
people code it still means that you would own any copyright or
32:29.056 --> 32:31.420
IP resulting from that work.
32:33.250 --> 32:36.954
And then if you need to require the permanent employee to participate in It requirements.
32:37.002 --> 32:40.614
So that means making sure that you're
32:40.662 --> 32:44.440
getting contact information for anybody who participated in
32:44.770 --> 32:47.946
ideation and whatnot, because you will need paperwork
32:48.018 --> 32:51.470
from them for a long time, overtime for
32:51.520 --> 32:53.570
any IP that was created.
32:54.970 --> 32:58.370
Then other termination clauses and other legalities
32:58.750 --> 33:03.026
of course you're going to have some kind of course of action in there.
33:03.208 --> 33:06.522
What causes termination or what's the course of action
33:06.546 --> 33:10.394
for termination? Where's the jurisdiction for any resolution of any issues?
33:10.492 --> 33:13.754
A lot of times it's in the state of the company,
33:13.912 --> 33:17.018
the contracting company, not the third party. But again, that's usually out for
33:17.044 --> 33:20.570
debate, sometimes through arbitration or litigation.
33:21.130 --> 33:24.518
You might want to have some right to audit clause as well for
33:24.544 --> 33:27.870
some of these in terms of what triggers some kind of termination.
33:27.930 --> 33:31.542
And maybe you have regular audits to make sure that they are complying
33:31.566 --> 33:34.778
with the contract. And of course if they fail to audit, then that's a right
33:34.804 --> 33:38.222
to terminate the relationship. Some kind of
33:38.236 --> 33:43.118
indemnity clause. Who pays for litigation or arbitration and
33:43.144 --> 33:47.118
any kind of joint or agreement? Who can they join in if they're using Cascading
33:47.154 --> 33:51.230
contractors? Are those contractors part of
33:51.340 --> 33:54.050
the dispute? Should there be a dispute?
33:55.390 --> 33:58.478
Just thinking through all those different things? Again, a contract is for
33:58.504 --> 34:02.320
when things don't work out appropriately, right? Not for when they go right?
34:03.790 --> 34:07.238
So the actual product development, when things actually get the
34:07.264 --> 34:11.322
marriage, when things actually get developed, I think the biggest thing is don't
34:11.346 --> 34:14.462
let yourself go. Because this is actually the point
34:14.476 --> 34:17.910
where you need to be the most engaged and understand what's happening, what they're
34:17.970 --> 34:21.482
developing, and have an active type feedback loop. You want to understand
34:21.556 --> 34:25.060
the sources of innovation. Again, who's owning the code,
34:26.110 --> 34:29.046
making sure that you have access to different repositories,
34:29.238 --> 34:33.722
making sure that you understand the impact of agile development and
34:33.736 --> 34:37.590
how they impact your IP. You want to keep on assessing patentability
34:37.650 --> 34:40.780
and freedom to operate. That is your responsibility. As we'll discuss,
34:41.590 --> 34:44.994
consider open source considerations and then various device
34:45.042 --> 34:48.714
considerations and then joke, you want to wear pants occasionally.
34:48.822 --> 34:55.626
Just because it's marriage doesn't mean anyway.
34:55.688 --> 34:59.670
Sources of innovation. So obviously the vendor has
34:59.780 --> 35:03.090
their own code, right? They might have code bases that they're working
35:03.140 --> 35:06.606
from our libraries, they might have test pictures that they're using.
35:06.728 --> 35:09.690
They may have some base devices for different things.
35:09.860 --> 35:13.698
So they're going to have their own IP, right? That's their own base stuff
35:13.724 --> 35:19.518
that they bring to the relationship. There are also outside sources that
35:19.544 --> 35:22.918
contribute to the innovation, right? There's open source software, there might be off the shelf
35:22.954 --> 35:26.118
component if it's an MVP, they might be using and
35:26.144 --> 35:29.526
harvesting pieces of devices from other things to kind of
35:29.528 --> 35:33.114
make something work and has a proof of concept. But of course, as you move
35:33.152 --> 35:36.990
more towards an actual commercially viable product, you move away from
35:37.100 --> 35:40.266
off the shelf components some more custom things
35:40.328 --> 35:44.134
as needed, right? You're not going to reinvent battery technology or PCB
35:44.182 --> 35:48.102
technology to develop a product, but you
35:48.116 --> 35:50.922
might want to move away from some of those technologies as you get more to
35:50.936 --> 35:54.618
a commercial ready one. There also might be compliance constraints that
35:54.644 --> 35:57.982
cause innovation to occur. Obviously the FDA
35:58.066 --> 36:01.470
is going to put constraints on different innovation
36:03.770 --> 36:07.158
or maybe just the app store. There's different countries that they
36:07.184 --> 36:10.842
put on from a software development perspective. So just thinking through that and
36:10.856 --> 36:14.838
if that's going to lead into innovation as well. And then
36:14.864 --> 36:17.826
lastly, obviously as part of all of this, there's going to be new code and
36:17.828 --> 36:20.982
new devices that are created. That's of course where innovation is going to
36:20.996 --> 36:24.270
come into play, but some of these other things may feed into it. So again,
36:24.320 --> 36:27.286
code ownership, you don't want to wait for project completion,
36:27.478 --> 36:30.750
get admin access to the code repositories.
36:32.030 --> 36:35.060
If you don't have access to the repositories, you don't own the code.
36:35.630 --> 36:39.560
Go ahead. A quick comment on that. Last thing is
36:40.010 --> 36:43.098
just the difference and this is getting in the weeds a little bit,
36:43.124 --> 36:46.546
but I think it's relevant to that is like when you're
36:46.678 --> 36:50.070
thinking about patenting some invention, you've got
36:50.180 --> 36:53.850
the inventorship which really goes on the claims and
36:53.900 --> 36:57.234
what is novel, not only just the claims, but what
36:57.272 --> 37:00.286
actually is novel and inventive in the claims.
37:00.418 --> 37:04.354
So you might have something off the shelf or something that's known
37:04.402 --> 37:08.074
or something even not very well known, but outside of your invention
37:08.182 --> 37:12.138
that's described in the spec that may have been contributed from this
37:12.164 --> 37:15.142
third party, but they still may not be an inventor on invention.
37:15.226 --> 37:19.482
If your key inventive concept that you're claiming does not include that
37:19.616 --> 37:20.600
piece right,
37:26.190 --> 37:31.262
especially when it codes involved understanding
37:31.286 --> 37:34.642
what their code base is contributing because you
37:34.656 --> 37:37.570
don't want the inventive piece lying in their code base,
37:37.620 --> 37:39.600
there's no way they're going to let you own that,
37:41.190 --> 37:43.860
right? I mean, I know how that would come out to be,
37:45.210 --> 37:48.382
but if their code base somehow lies as part of
37:48.396 --> 37:52.174
the inventive concept or something, that could be huge problems.
37:52.272 --> 37:55.706
And so just and I honestly don't know how you would tease that apart.
37:55.778 --> 37:57.790
I think it's just going to be again, let me type you back moving,
37:57.840 --> 38:01.438
understanding what there are
38:01.464 --> 38:05.062
two ways to do that. You force the coders to comment in
38:05.076 --> 38:08.350
a certain fashion and to uphold a standard of
38:08.400 --> 38:11.220
implementing their comments across the code. It's a pain.
38:11.610 --> 38:15.586
It's not something everybody has really got a
38:15.588 --> 38:18.938
good grip on or want to do. It really good coders
38:18.974 --> 38:22.222
do really good coders who get stuff implemented met ed, but get
38:22.236 --> 38:26.014
it done fast, don't often continually comment their code.
38:26.172 --> 38:29.858
So if you put that as part of a contract that I'm requiring
38:29.894 --> 38:33.670
that you've either got to extremely comment this or
38:33.840 --> 38:37.918
get my selected third party review
38:38.064 --> 38:41.782
to do code reviews at x amount of days. And so
38:41.796 --> 38:46.162
then you would have a third party who would attend these code reviews and
38:46.296 --> 38:49.378
they would look over best practices of what's going on in the code. They would
38:49.404 --> 38:53.374
know what's going on in the code and that would be kind of an
38:53.412 --> 38:56.594
outside expert that you as the owner
38:56.762 --> 39:00.540
of the IP or of the company asking the engineering firm to
39:00.990 --> 39:04.522
do some work, that would be your way to oversee some of
39:04.536 --> 39:08.280
that without having to dig into the technical nitty gritty code.
39:10.230 --> 39:13.790
If you're okay looking through code, you still want really reasonable
39:13.850 --> 39:19.298
commenting and you want them to do it for
39:19.324 --> 39:23.034
yourself, but also for transportability if that engineering
39:23.082 --> 39:26.826
firm goes away or you find a new, better engineering firm you'd
39:26.838 --> 39:30.734
like to work with to change that code. And it's so much better
39:30.772 --> 39:34.454
if somebody's actively commented the code in
39:34.552 --> 39:37.718
a useful way. You can do it the other
39:37.744 --> 39:40.838
way, but it takes twice as long to sift through all of the
39:40.864 --> 39:43.060
code. Exactly.
39:46.450 --> 39:49.994
Code commenting or whatever. Annotations so you know what things do
39:50.032 --> 39:52.300
what and yeah, that's a great point.
39:53.290 --> 39:57.110
Even the portability, like you said, being able to use somebody else later
39:57.280 --> 40:00.854
or make changes later, you don't have to figure out what step does what
40:00.892 --> 40:04.250
when there's clear distinction.
40:04.690 --> 40:08.102
Yeah, I mean, it's hard enough to pick up a new product with new code.
40:08.296 --> 40:12.470
Having done sustaining engineering in my career before, it's hard enough to just
40:12.640 --> 40:16.226
fall into that role and pick it up. But if somebody has done something
40:16.288 --> 40:19.682
logically in the code and commented why they've done it,
40:19.876 --> 40:23.462
it's so much easier than spending two days trying to figure out why they
40:23.476 --> 40:27.662
did this this way to
40:27.676 --> 40:31.358
do that. Right. And for most of the first day,
40:31.384 --> 40:34.970
you're like, what the hell, right? Guess I'll get another
40:35.020 --> 40:37.900
cup of coffee because I can't figure this out.
40:38.590 --> 40:42.350
It's just something you can put in your contracts to say,
40:42.400 --> 40:45.302
if you're going to do code for me, I need it to be up to
40:45.316 --> 40:48.842
snuff. Right. It needs to work, but I also need
40:48.856 --> 40:52.082
to know reasonably what's going on. And that
40:52.096 --> 40:55.730
doesn't mean every line but every function or
40:55.780 --> 40:59.390
every five page chunk of code that does
40:59.440 --> 41:02.694
something specific. I want to know why or I want it marked.
41:02.862 --> 41:06.962
Yeah, it's like you really need to do your homework even before if
41:06.976 --> 41:10.382
you're a person or company that has no software experience at all,
41:10.576 --> 41:14.054
almost consulting with somebody before you even vet partners around,
41:14.092 --> 41:17.800
what questions to ask. Right. Because I feel like if you're new
41:18.130 --> 41:21.722
to the product development or like FDA, what makes
41:21.796 --> 41:25.060
you even ask a potential partner? If you've never been down
41:25.390 --> 41:28.610
that road before? Recommendations can be good,
41:28.660 --> 41:32.526
right? If somebody's had time tested relationships
41:32.538 --> 41:36.926
with engineering firms that they know are good for FDA or code or whatever,
41:37.108 --> 41:40.682
that's one thing. But I don't know. Just thinking through it now, if I
41:40.696 --> 41:43.418
were to do this, I don't know if I would know the right questions to
41:43.444 --> 41:47.958
ask. Some of these groups, you'd almost want some kind of consultant
41:47.994 --> 41:52.046
upfront to say, here's all the things that you should ask before
41:52.168 --> 41:56.042
if you're looking for different kinds of firms. Yes. And there
41:56.056 --> 41:59.406
are people, there are a lot of good coders who work on contracts because that's
41:59.418 --> 42:02.138
how they want to work. If you can find a good one of those who
42:02.164 --> 42:05.666
will do this kind of review for you every once in a while,
42:05.788 --> 42:09.506
even once every three years, if you can get somebody to do 40 hours
42:09.568 --> 42:12.926
of code review and analysis to help you in the future,
42:13.048 --> 42:14.980
it's worth the money. Yeah,
42:16.450 --> 42:20.150
long term, yeah. I mean, the only time that doesn't make sense,
42:20.200 --> 42:22.310
if it's like graphical user interfaces,
42:23.290 --> 42:26.800
you're just generating objects on the screen, that's not as important.
42:28.630 --> 42:32.618
You're going to own the end guise. You're going to own if
42:32.644 --> 42:36.138
you try to claim or design the end of Gui's.
42:36.294 --> 42:40.082
And you of course include the appropriate inventors if you happen to
42:40.096 --> 42:44.082
have somebody on the engineering site as an inventor. But that's
42:44.106 --> 42:47.294
not as important to get your comments and whatever correctly. But if you were talking
42:47.332 --> 42:50.790
about firmware, device firmware that runs the guts of your device,
42:50.850 --> 42:53.920
it's hugely important that you do that.
42:54.910 --> 42:58.058
That you make sure that the comments are there,
42:58.144 --> 43:02.094
that your algorithms are laid out appropriately
43:02.142 --> 43:05.570
so that you could say, okay, this is the algorithm that I patented in this
43:05.620 --> 43:09.122
patent application. And it's even more important if you go
43:09.136 --> 43:13.058
to sell that end product as a whole. And I don't mean
43:13.084 --> 43:16.262
like retail, I mean get rid of the IP, get rid of the company and
43:16.276 --> 43:19.850
you're selling everything. People are going to want that. They're going to want that
43:19.900 --> 43:23.018
mapped to say, hey, do you really own it and
43:23.044 --> 43:25.598
who implement it and where do I go if I need to update it?
43:25.624 --> 43:29.510
Right? Yeah. Pretty bulletproof.
43:30.430 --> 43:32.630
And then thinking about agile methodology,
43:33.010 --> 43:36.858
traditionally from a waterfall practice, feature sets
43:36.894 --> 43:40.538
and products were basically fully specified and then kind of thrown over
43:40.564 --> 43:43.850
to developers to then build it. Now it's a much tighter timeline, right,
43:43.900 --> 43:47.800
of developing X features and then pushing them out and then
43:48.250 --> 43:51.782
iterating on them or adding new features and pushing them out. And so you just
43:51.796 --> 43:55.702
want to make sure that you're
43:55.726 --> 43:58.938
accounting for what they're pushing out and making sure you're getting protection on that
43:58.964 --> 44:02.698
before they push it out if you need to. And so capture inventions
44:02.734 --> 44:06.438
as quickly as possible, matching that fast pace of Agile. And this goes
44:06.464 --> 44:10.158
for devices and for software, right, where devices are
44:10.184 --> 44:13.678
changing rapidly over time. Maybe the specs that they give you originally
44:13.714 --> 44:16.878
for an IP disclosure aren't the specs that end up being
44:16.904 --> 44:20.974
the commercially viable ones. And so just before they go to design freeze,
44:21.022 --> 44:24.078
making sure that you're getting those. And so with that,
44:24.164 --> 44:28.258
as well as managing patentability and freedom to operate newly developed
44:28.294 --> 44:31.738
products, there is no guarantees in this world and most engineering
44:31.774 --> 44:35.406
firms do not participate. At least they're not going to be the ones
44:35.528 --> 44:39.090
instituting patentability searches and freedom to operate searches, right?
44:39.200 --> 44:42.330
They may look through some patent art, they may look through some of the field
44:42.380 --> 44:45.718
and kind of understand what's out there, but they are not going to be responsible
44:45.754 --> 44:49.174
for patentability and freedom to operate. That is fully you and your IP
44:49.222 --> 44:53.058
council's responsibility. And so just
44:53.084 --> 44:57.114
making sure that you're doing, searching and sharing those
44:57.152 --> 45:00.522
results with the engineering firm and talking
45:00.596 --> 45:05.782
through what they're developing relative to the art and making sure that your designing
45:05.806 --> 45:09.058
around were necessary or having really good arguments
45:09.094 --> 45:13.134
for when something has to be a certain way. And so just making
45:13.172 --> 45:16.770
sure there's that bond between your IP council, you and your engineering firm, to walk
45:16.820 --> 45:20.098
through things. We've had a couple of clients that worked with engineering
45:20.134 --> 45:23.278
firms over time, and we've just had meetings with them where we do searches,
45:23.314 --> 45:26.694
we walk through the art and we can talk around how
45:26.732 --> 45:30.298
things are different, where the development
45:30.334 --> 45:33.678
is going relative to what we're finding and stuff like that. So it would be
45:33.704 --> 45:37.662
highly valuable. And again, just from an understanding, patentability and
45:37.676 --> 45:41.310
freedom to operate. Patentability is your
45:41.360 --> 45:45.502
technology is new and inventive, and that's over all of the material that's
45:45.526 --> 45:49.650
currently out there, including publications, website patents, journal articles,
45:50.570 --> 45:54.042
similar things. Freedom to operate is that there is not
45:54.116 --> 45:57.750
an issued patent that prevents you from making, using,
45:57.800 --> 46:01.486
selling, or importing your invention into the US. But just because you get a patent
46:01.558 --> 46:04.794
on your technology doesn't mean you can actually practice your
46:04.832 --> 46:08.178
technology. You basically have to have patent ability to have
46:08.204 --> 46:10.914
a patent, and you need to have freedom to operate, to actually make and use
46:10.952 --> 46:14.790
and sell your invention. So you need kind of searches on both those fronts
46:15.530 --> 46:17.970
so quickly. Open source considerations,
46:18.290 --> 46:21.738
just making sure that it's very clear and understood what kind of
46:21.764 --> 46:25.400
licenses are okay. You obviously don't want any
46:26.210 --> 46:29.670
licenses that require your code to be shared
46:31.430 --> 46:35.262
openly, right? So more like the copy left kind of
46:35.456 --> 46:39.202
software licenses. You want to make sure that the engineering firm
46:39.226 --> 46:42.774
is not using those. Again, making sure you understand what code
46:42.812 --> 46:46.362
is being used, when and how, and that they understand you're okay with
46:46.376 --> 46:49.942
and what you're not okay with. You want to take an active role.
46:50.026 --> 46:52.770
You want, again, establish their expectations.
46:53.330 --> 46:57.034
And this kind of goes towards Kristen's commenting
46:57.082 --> 47:00.754
and things in the code base. Make sure they clearly list all the software
47:00.802 --> 47:04.026
packages that they use, all the open source software packages they use, and maybe even
47:04.088 --> 47:07.230
where they did in the code base so that you can be sure
47:07.280 --> 47:11.002
that they used ones that were good open source
47:11.026 --> 47:14.130
software and not more viral open source software.
47:14.870 --> 47:18.594
Yeah. And remember, you can still get that claim if you're just
47:18.632 --> 47:21.862
receiving something from an open source output.
47:21.946 --> 47:26.022
Right. You can still use that open source receipt of
47:26.096 --> 47:29.614
information, but you have to do something inventive with it in your claims.
47:29.782 --> 47:33.946
Absolutely. And then you're thinking of FCA compliance.
47:34.138 --> 47:36.450
There are rules with the FDA.
47:39.030 --> 47:41.710
I know. I've never even watched this movie.
47:43.050 --> 47:46.838
Get a bottle of wine, sit down and watch it, you'll die laughing.
47:46.934 --> 47:49.980
It's Big Lebowski, right? Yes.
47:50.310 --> 47:53.438
So the thing is, smoky, this is the FDA,
47:53.474 --> 47:55.642
and there are rules. Of course, you can't do the time with the FDA at
47:55.656 --> 47:59.098
that time. So, again, considering where
47:59.184 --> 48:02.390
innovation might be coming from and how you engage with engineering firms,
48:02.510 --> 48:06.310
just making sure that they're going to help you prepare things for FDA administration,
48:07.230 --> 48:10.810
drug Administration, that's any documentation, test,
48:10.860 --> 48:14.750
data, whatever, making sure they're using the right materials.
48:14.930 --> 48:18.326
And again, some of these things may impact the innovation,
48:18.398 --> 48:21.780
right, depending on what constraints there are.
48:22.110 --> 48:25.598
And then always keep the angle in mind if you're prototyping proof of concept
48:25.634 --> 48:29.666
and user ready because that will also impact patentability
48:29.738 --> 48:33.182
and making sure that you're not patenting things that aren't
48:33.206 --> 48:36.866
going to be in the final product either, right, just because they're in your prototype
48:37.058 --> 48:40.980
and it's inventive is actually going to be in your consumer product
48:42.330 --> 48:44.040
because those might be different things.
48:46.230 --> 48:50.218
So lastly, obviously divorce is inevitable after you develop the
48:50.244 --> 48:53.734
product. So just walk to the exit plan that you developed ahead
48:53.772 --> 48:57.014
of time, making sure you're getting assignments and declarations
48:57.182 --> 49:00.694
for the intellectual property before you fully disengage. But again,
49:00.732 --> 49:03.922
remembering that there will be this requirement for a long time,
49:03.996 --> 49:08.098
for upwards of 15 to 20 years potentially. So the
49:08.124 --> 49:11.494
more you can create a good relationship and keep that good relationship, the better because
49:11.532 --> 49:14.878
you will need them here and there throughout time.
49:15.024 --> 49:18.442
Make sure you provide adequate notes per your contract. If the
49:18.456 --> 49:21.742
contract says 30 day notice of termination, be nice and give them
49:21.756 --> 49:25.846
30 day notice. Make sure you transition the ownership of the infrastructure code
49:25.908 --> 49:29.746
devices, whoever's going to be taking it over, whether it's your company moving
49:29.808 --> 49:33.134
things in house or with another new third party,
49:33.302 --> 49:36.720
you want to cut up access to network systems, assets and data.
49:37.110 --> 49:41.030
Make sure you destroy any vendor data. Of course, pay your bills
49:41.150 --> 49:45.000
and then continue third party monitoring too. I would keep it for
49:45.330 --> 49:48.778
some kind of time period, maybe a year or so, kind of monitor that
49:48.804 --> 49:52.030
third party's activity, what's coming out, and making sure
49:52.080 --> 49:55.462
that they are complying with the terms of that
49:55.476 --> 49:59.222
agreement, whether with some kind of nondisclosure IP, make sure they're
49:59.246 --> 50:03.266
not developing something similar for somebody else right after you disengage.
50:03.338 --> 50:06.670
So some kind of level of pretty monitoring probably won't hurt.
50:07.110 --> 50:10.178
And lastly, some agile experiences that I've
50:10.214 --> 50:14.858
had is that we've
50:14.894 --> 50:18.850
seen where a product was
50:18.900 --> 50:22.738
developed without a development agreement in place and in this
50:22.764 --> 50:26.690
case it was a software product. And then once that new product was created,
50:26.810 --> 50:30.960
there was a disagreement around who owned the product because there was
50:32.010 --> 50:35.446
code base from the third party in the product,
50:35.628 --> 50:38.902
but yet the client had paid for the product. And so there
50:38.916 --> 50:43.786
was a huge disagreement, lots of phone calls and then we finally
50:43.848 --> 50:47.170
agreed to co ownership of some of the
50:47.220 --> 50:50.734
product because of the base code that was
50:50.772 --> 50:54.514
used by that code base. So one
50:54.552 --> 50:57.590
of the products was fully owned by the client and one was the co ownership.
50:57.650 --> 51:01.378
It wasn't the worst case scenario because that third party had
51:01.404 --> 51:04.980
also invested in the client. So they did pay for it, but they also did
51:05.790 --> 51:09.082
give the engineering firm some portion of
51:09.096 --> 51:12.194
equity or something. So it wasn't the worst case there, but still not ideal.
51:12.242 --> 51:16.042
Because if you think of investors and things like that, when you
51:16.056 --> 51:19.270
go to sell the IP or license it, now you have co ownership and everybody
51:19.320 --> 51:22.882
has to agree to that selling of the IP or the other company.
51:22.956 --> 51:26.674
So it's just not ideal. And a reminder from the
51:26.712 --> 51:30.334
IP perspective, if you have filed something and you have not
51:30.372 --> 51:34.258
gotten the inventive entity right, you have not credited your
51:34.404 --> 51:37.778
engineering firm, for example, they can challenge your patent
51:37.814 --> 51:42.674
and your patent can be invalidated because you didn't put the correct inventorship
51:42.722 --> 51:46.318
on file. And actually, we've seen that as
51:46.344 --> 51:50.914
well, where or at least having discussions where because
51:51.012 --> 51:54.362
a company is paying for development,
51:54.446 --> 51:58.198
they want to say that they are
51:58.224 --> 52:01.462
the inventors. Right? But that's not a
52:01.476 --> 52:04.978
false equivalency. Just because you pay for it doesn't make you the
52:05.004 --> 52:08.338
inventor. It makes you the owner, if your agreement says so,
52:08.484 --> 52:11.842
but it doesn't make you the inventor. And so I always say
52:11.856 --> 52:15.418
this is better to be over inclusive than under inclusive. Nobody throws a fit,
52:15.564 --> 52:18.982
or at least generally nobody throws a fit for being included on
52:18.996 --> 52:22.550
a pen, but they sure do throw a fit if they're not included,
52:22.670 --> 52:26.158
right? So if you have an engineer, something that finds that
52:26.184 --> 52:29.834
they were left off, especially with intentionally,
52:30.002 --> 52:33.540
that's just a recipe for disaster and invalidation 100%.
52:34.050 --> 52:37.438
Yeah. And you can fix it. You can fix it at any time. But if
52:37.464 --> 52:40.778
you refuse and they prove that they are part of the inventorship,
52:40.814 --> 52:44.614
you're really in trouble. Shame on you.
52:44.772 --> 52:46.980
Finger shook at you.
52:47.970 --> 52:51.322
So, yeah, I guess overall key takeaways protect as much as possible before
52:51.396 --> 52:54.854
disclosure, using provisionals, carefully vet potential
52:54.902 --> 52:57.960
partners, and maybe even figure out what questions to ask.
52:58.290 --> 53:01.802
Getting good contracts. Contracts only matter when things fall apart,
53:01.826 --> 53:05.026
so you want good contracts. Maintain access
53:05.088 --> 53:08.170
to your physical and digital assets at all times.
53:08.280 --> 53:11.230
Make sure that it's in your name and not theirs.
53:11.910 --> 53:15.970
Match iterative it approach with the development workflow,
53:16.350 --> 53:18.900
know what's getting baked into your product, into your code,
53:19.410 --> 53:22.140
and then execute a well thought exit plan.
53:23.910 --> 53:27.178
So, of course, never go to bed angry. Which is
53:27.204 --> 53:30.850
true engineering firms, because again, you need to make them happy for a long time.
53:30.960 --> 53:34.522
You'll be partners well beyond the termination. Yeah. And if you
53:34.536 --> 53:37.078
ever need anything, a favor to fix, code,
53:37.164 --> 53:41.486
update, something, questions, if they're
53:41.558 --> 53:45.386
still in good shape and you're still colleagues,
53:45.458 --> 53:48.718
that's a really nice thing. And they're more willing to do stuff for
53:48.744 --> 53:51.300
free for you, especially if it's one off questions.
53:51.870 --> 53:56.878
Yeah, exactly. Good talk. That was really
53:56.904 --> 54:00.960
good, Ashley. Super interesting. Thanks, Ashley. Yeah, happy to share.
54:01.710 --> 54:05.410
Yeah, thanks for participating and have a good rest of your day then.
54:05.580 --> 54:08.926
Yes, thank you. Absolutely. Thank you both you guys.
54:08.988 --> 54:12.946
Thanks. Bye. Bye. All right, that's all for today,
54:13.008 --> 54:16.762
folks. Thanks for listening and remember to check us out@aurorapatins.com for
54:16.776 --> 54:20.798
more great podcasts, blogs, and videos covering all things patent strategy.
54:20.894 --> 54:23.278
And if you're an agent or attorney and would like to be part of the
54:23.304 --> 54:26.974
discussion or an inventor with a topic you'd like here discussed, email us
54:27.012 --> 54:30.818
at podcast@aurorapatins.com. Do remember that this podcast
54:30.854 --> 54:33.898
does not constitute legal advice. And until next time, keep calm and
54:33.924 --> 54:35.330
patent on bye.
