Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[LivingItUp]

Has anyone noticed that most software patents do not enable a reader of the patent to actually make the software?

Instead, software patents disclose what the software would look like or do, if you could make it. The mystery sauce algorithms that accomplish the patentable feature(s) are not disclosed.

I see older software patents that included large code listings, and very descriptive detail of low level events about what is going
on in the program. Yet, It seems like the modern way of patenting software is not to disclose to the patent reader how to build it. Keep your secrets -- secret.

Yet, nobody is challenging these patents in court on enablement?  No one questions whether USPTO is getting a quid pro quo for these patents?

[Isaac]

Has anyone noticed that most software patents do not enable a reader of the patent to actually make the software?

Instead, software patents disclose what the software would look like or do, if you could make it. The mystery sauce algorithms that accomplish the patentable feature(s) are not disclosed.

I believe you are applying an improper standard for enablement.  In many cases a skilled artisan can implement write the software based on a description of functionality.  Fed Circuit case law says that that is enough for enablement.   The federal circuit has invalidated means plus function style claims where an algorithm is not provided, and the BPAI has invalidated claims where a programmer could not implement the described functionality because the objectives are not specified in terms one of skill can understand.

But not every reader is skilled.  Failing to enable every reader does not mean that the claims are not enabled.

Yet, nobody is challenging these patents in court on enablement?  No one questions whether USPTO is getting a quid pro quo for these patents?

The quid pro quo belongs to the public, and not to the PTO.

[Sudhir Kumar]

In context of countries other than US, where Software inventions are not allowed per se, the invention is always decribed/claimed in form of system with method limitations and mehtods with system limitations (both having hardware features). therefore we always avoid mentioning algorithm and even when objection is raised we counter it by suggesting that no where we are claiming the algorithm.

[LivingItUp]

 In many cases a skilled artisan can implement write the software based on a description of functionality.  Fed Circuit case law says that that is enough for enablement. 

thanks.

I am not so sure that a skilled artisan writing software based on a descriptive functionality could duplicate most software inventions. I guess if we assume that given enough money + enough time (perhaps years) + enough software developers + trial and error in development then a software invention can be duplicated.

What if someone invents a cure for AIDS, and in the patent filing, the inventor does not disclose how to make the cure, but instead, discloses what the cure does (i.e., says "it cures AIDS"), and shows drawings of what the end result molecular structure of the cure looks like. It seems like leaving out the "how to make" part of the invention would be non-enabling. I guess if we assume infinite money + infinite time + infinite chemists + trial and error then it can be duplicated (even if the chemical process uses a mystery sauce to make it).

[DogDayPM 9er9er9er]

What if someone [claims to have invented] invents a cure for AIDS, and in the patent filing, the inventor does not disclose how to make the cure, but instead, discloses what the cure does (i.e., says "it cures AIDS"), and shows drawings of what the end result molecular structure of the cure looks like. It seems like leaving out the "how to make" part of the invention would be non-enabling. I guess if we assume infinite money + infinite time + infinite chemists + trial and error then it can be duplicated (even if the chemical process uses a mystery sauce to make it).

This tracks a recent discussion with some of my inventors, and I was thinking about software patents in the same fashion - that they often seem to claim (once boiled down) not really more than a recitation of the results to be achieved.  This was during a discussion in which we were hashing out claims that included a ""mystery sauce" that the inventors didn't want to disclose, and they were wanting instead for that portion of the claim to use results-based language.

When I brought up enablement and undue experimentation, one of them said, "well, we can say in the spec to go to an XYZ type vendor skilled in this art, and tell the XYZ type vendor what the final product parameters are.  Given that, any skilled XYZ vendor could figure out a workable mystery sauce".

While I have some time to mull this over, I don't think a spec/claims set written as proposed fulfills our end of the bargain.

Thoughts?

[JimIvey]

Being a (former) software engineer, I'll go ahead and weigh in on this topic....

For my own work, I write my applications so as to enable me to make and use the technology -- assuming I had time to read up on some well-known development tools/environments.

As for the work of others, I'd say most of it is enabling -- not that it doesn't make me roll my eyes and think, "well, I know what you meant to say."  Note that the application is not required to teach a lay person of ordinary skill in nothing how to develop software; the intended audience (for meeting the legal requirements) is one of skill, albeit ordinary skill, in the technology/ies of the invention.

However, there are some patents/applications I see that confuse the heck out of me.  I won't go so far as to say they're not enabling as I'm not really one of ordinary skill in the art -- I'm of rudimentary skill as I still try to dabble in development.

From time to time, I hear practitioners say that it doesn't take any special knowledge of software to write software applications.  I respectfully disagree with them.  While there are some simple software innovations, not all software innovations are simple and software is no less a technical discipline that any other.

Regards.

[khazzah]

[software patents] often seem to claim (once boiled down) not really more than a recitation of the results to be achieved. 
...
I don't think a spec/claims set written as proposed fulfills our end of the bargain.

I agree with this characterization of many sw patents. But, speaking as a former sw developer now practicing as a patent attorney, I see nothing wrong with that.

That is, I think claiming sw in terms of function does fulfill the enablement bargain, precisely because you can give a sw guy a functional description and he can go off and implement it.

To give an extreme example -- one which I only spent the last 5 seconds thinking about -- here's a sw claim that comes close to being self-enabling:

A method comprising:
receiving an email message; and
if a sender field of the email message matches a predetermined string, playing a particular sound.

A sw developer could go off and implement this on, e.g., Unix or Mac or Windows, without any (here come the magic words) "undue experimentation". I don't have to tell him anything about mail protocols like SMTP or POP3. I don't have to describe a GUI. I don't have to tell him what language to write it in, or what platform it runs on. There are many different ways to do it, and him can figure all this out by himself.

It seems like leaving out the "how to make" part of the invention would be non-enabling. I guess if we assume infinite money + infinite time + infinite chemists + trial and error then it can be duplicated (even if the chemical process uses a mystery sauce to make it).

I think most software is just fundamentally different than research-focused areas like biology and chemistry. For software, you can just throw bodies on the project and give them enough time, and they'll be able to produce the specified function. It's not even "experimentation", much less "undue experimentation".

Instead, software patents disclose what the software would look like or do, if you could make it. The mystery sauce algorithms that accomplish the patentable feature(s) are not disclosed.

In my mind, by choosing to describe the algorithm as "mystery sauce", you're stipulating that a POSITA would not know how to implement it. In such a case, you do need to disclose further details.

But to me, the results described by most software patents are not in fact a "mystery", but are doable. The claim to an email feature that I wrote above being a perfect example.

Comments?

[JimIvey]

To give an extreme example -- one which I only spent the last 5 seconds thinking about -- here's a sw claim that comes close to being self-enabling:

A method comprising:
receiving an email message; and
if a sender field of the email message matches a predetermined string, playing a particular sound.

For what it's worth, I could do that, so I agree that it's self-enabling.  I would never write it as if it were self-enabling, but I think that example is.  Well, I could make the sound play on the server (using procmail), so it might depend on more context.  But, the sender field of an e-mail message is well-known and well-defined, text pattern matching is well-known, and how to play a sound on a computer is well-known.  So is the if-then-else logic required to glue it all together.  No "secret sauce" needed.

Of course, if it's self-enabling, you probably have a heightened likelihood of obviousness.

Regards.

[LivingItUp]

That is, I think claiming sw in terms of function does fulfill the enablement bargain, precisely because you can give a sw guy a functional description and he can go off and implement it.

Tell someone of ordinary skill in the art to build you a 3rd virtual world that performs like the top game physics engines of 2010, and see what that person tells you.

There is a reason why leaders in the game industry are leaders. There is a reason why top talent in software gets paid more than ordinary talent. Yet, people seem to assume that any software person is enabled to produce anything in software.

Using game systems as an example. Why the top physics engines are innovative over the ordinary physics engines is the mystery.

If all that is in the patent says functional descriptive claims that say "A 3d physics engine that appears realistic and achieves velocities and accelerations within range X ", and range X is the innovation, then one of ordinary skill in the art will never know how they do it.

[Isaac]

If all that is in the patent says functional descriptive claims that say "A 3d physics engine that appears realistic and achieves velocities and accelerations within range X ", and range X is the innovation, then one of ordinary skill in the art will never know how they do it.

Your example claim is probably indefinite under 112, 2nd paragraph and probably is not self enabled.   But whatever is lacking in the disclosure could likely be cured without providing code listings.   I don't believe your example is representative of most software patents.

[JimIvey]

Tell someone of ordinary skill in the art to build you a 3rd virtual world that performs like the top game physics engines of 2010, and see what that person tells you.

Hmmm....  Here's a patent that might be on-topic: 7,209,139
(at the USPTO search engine, search "an/(electronic and arts) and lrep/ivey")

My guess is that you might be interpreting "the art" too broadly -- as in the ordinary software engineer.  If the art is 3D virtual world interactive game development, you don't have to describe conventional systems (i.e., systems that exist and are understood as of the time the invention was made).  In fact, if you can just use a conventional physics engine, you can simply write, "In one embodiment, physics engine 100 is the XYZ physics engine available from Pixar of Emeryville, California."  However, you do have to describe how to get from conventional systems to the one that implements the invention claimed such that your average game developer could get there -- without undue experimentation.

Regards.

[khazzah]

To give an extreme example -- one which I only spent the last 5 seconds thinking about -- here's a sw claim that comes close to being self-enabling:

A method comprising:
receiving an email message; and
if a sender field of the email message matches a predetermined string, playing a particular sound.

For what it's worth, I could do that, so I agree that it's self-enabling.  I would never write it as if it were self-enabling, but I think that example is. 
Of course, if it's self-enabling, you probably have a heightened likelihood of obviousness.

Sure, I wouldn't actually file a spec that copied the claims into the detailed description with nothing more. But I don't think this particular example needs more than 3 diagrams: a client+server+network; a flow chart; and a block diagram of a computer.

Tell someone of ordinary skill in the art to build you a 3rd virtual world that performs like the top game physics engines of 2010, and see what that person tells you.
Yet, people seem to assume that any software person is enabled to produce anything in software.

Nah, I don't assume that. Enablement is measured by a person-of-ordinary-skill-in-the-art, which varies from case to case. The POSITA for an application dealing with a manual razor is different than the POSITA for an app dealing with jet engines -- even though both are "mechanical cases". Similarly, the POSITA for an app dealing with email-client-gui-features is different than the POSITA for an app dealing with the physical interaction of objects in 3D games - even though both are "software cases".