|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
|
|
|