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.

Transcript

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.