decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Fonar and 'normally'. | 202 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
The point about court rulings that source code is not required for disclosure
Authored by: PolR on Thursday, January 31 2013 @ 06:56 PM EST
The proposed response touched on that with the first two sentences of the
addendum:

> The USPTO should pay attention to how patent disclosure is
> actually used by developers. This should help the USPTO
> understand to what extent the practical consequences of
> patent law match how it should work according to theory.

Then the conclusion of the addendum reminds them of that:

> In conclusion, the USPTO should pay attention to how
> disclosure actually works in practice and compare this
> information with how case law says it should work. The
> ability of the patent system to actually promote
> innovation depends on it.

The legal theory justifying patents is that it is a quid pro quo: society grants
exclusive patent rights for a limited time in exchange for disclosure. But if
the the disclosure doesn't work as intended then patent law doesn't fulfill its
purpose in practice.

I agree that this addendum is letting the USPTO know the courts have it wrong.
The consequence of these rulings is that patent can't promote innovation anymore
because the quid pro quo is neutered. They need to do something to restore the
quid pro quo. What should they do? I don't know. But at least this response
ensures they are aware of the issue.

This quid pro quo is something the USPTO knows very well. They are the experts
on patent law. What else need to be said?

[ Reply to This | Parent | # ]

Court rulings parroting merketing hype?
Authored by: reiisi on Friday, February 01 2013 @ 07:36 AM EST
I would personally want a note with those quotes to the effect that there are
legions of programmers who would beg strongly to disagree with the assertions.

If programs could be mechanically derived from functional specs, where would be
the need for any human hands at all? The very fact that humans are needed to
implement the functional description is undeniable evidence that it is not a
mechanical process.

There is no best mode without context. Even with context, there is rarely a
single best mode. "Normally", "for such software", well,
such software is restricted to the domain of problems that have been solved
already, multiple times.

If the problem has been solved, the functional description of the problem is
already within the existing art.

(Not sure what the purpose in saying "skill of the art" is; I might
suspect it's an attempt to obscure the fact that this ruling flies in the face
of logic, common sense, experience, and mathematical truth.)

If flowcharts could be provided, they ought to be required, since a required
part of the purpose of a patent is to disclose.

If flowcharts can't be provided, that fact alone should be considered strong
evidence that the would-be patent holder either has no idea what he is trying to
claim, or is deliberately avoiding making his claims specific.

Making an excuse for failing to require disclosure in a patent seems like
evidence of undue influence to me.

And this talk about black art?

Pipe dreams.

There is no existing software that is better than 80% solution. Microsoft used
to claim the wonders of the 80% solution (while providing no better than 20% in
most cases).

They don't claim that any more because every time they try to extend their
product line into some place they get kicked in the face by the failings of
their algorithms in the new context.

Black art, white art, it's art, not engineering. As long as there are
differences from one person to the next, there is no universal solution. And,
unless this judge is talking about clerics, not clerks, when he talks about
clerical function, he might as well be admitting to adherence to the religion of
bureaucracy.

So, I want to know on what authority these judges decided to rule against
reality.

[ Reply to This | Parent | # ]

Fonar and 'normally'.
Authored by: Ian Al on Friday, February 01 2013 @ 07:37 AM EST
Fonar says
This is because, normally, writing code for such software is within the skill of the art, not requiring undue experimentation, once its functions have been disclosed.
PolR says that when writing code for such software is not 'within the skill of the art', then the functional claim is not enough and every function not within the skill of the art must be provided with the invented algorithm.

I think that PolR needs to revise the comment:
From a programmer's point of view, these cases are incorrect'.
What he needs to draw out is that the Fonar opinion does not propose the disclosure of just the functions when the algorithm is not clearly 'within the skill of the art'.

In addition, the Northern Telecom v. Datapoint Corporation deals only with the case where writing the algorithm is 'a mere clerical function to a skilled programmer'. Again, when it is not 'a mere clerical function', then the algorithm for computing the function must be given in the disclosures.

In fact, both of these cases are a strong endorsement of PolR's point about function and the associated algorithm.

BTW, I hope you noticed other very interesting points made by PolR. If a function is within the existing skill of the art, it does not need the statement of the computing algorithm because that is deemed to already exist within the skill of the art. Any claimed function without the associated algorithm can only be prior art.

The only inventive concept in software is expressed in functional claims with the associated algorithm.

PolR says:
The same algorithm may be used to compute multiple functions. For example, an algorithm for multiplication may double, triple or quadruple a number. Several well-known algorithms in computer science are routinely used in such a versatile manner. An example is an algorithm for recognizing regular expressions, which may be used for a wide range of text processing functions. Therefore it is possible that a software function in a claim is actually an obvious use of an old algorithm. This circumstance will be easier to identify if we require that a software function is accompanied with the corresponding algorithm.
I don't know about you, but I cannot think of many software algorithms that would not have been used countless times before and would be demonstrable prior art to be found in FOSS code.

That's the thing about code fragments: it's hard to tell what they are for unless someone tells you. How much code would you have to put into the patent to show that it was not just some general code fragment that was being re-used in an obvious way for the purposes of the invention function?

Also, if the algorithm enacted a math function for compression, decompression or signal processing, then an alternative algorithm will not infringe on the claim. Just how different would the programming have to be? How do you convince the jury that it is your patented algorithm?

Finally, I am reminded of the Benson case that PolR introduced to me in years gone by. The Supreme Court said:
The mathematical formula involved here has no substantial practical application except in connection with a digital computer, which means that if the judgment below is affirmed, the patent would wholly pre-empt the mathematical formula and in practical effect would be a patent on the algorithm itself.
I know it was a computer algorithm to convert BCD to binary, but what digital computer algorithms do you know of that have any substantial practical applications except in connection with a digital computer?

---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid!

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )