|
Authored by: lnuss on Thursday, January 31 2013 @ 03:27 PM EST |
...
---
Larry N.[ Reply to This | # ]
|
- "multiple software functions then applied to the same input" then->when [N/T] - Authored by: bugstomper on Thursday, January 31 2013 @ 03:39 PM EST
- draw the shape a three-dimensional -> draw the shape of a three-dimensional [N/T] - Authored by: bugstomper on Thursday, January 31 2013 @ 03:42 PM EST
- will result into the same problem -> will result in the same problem [N/T] - Authored by: bugstomper on Thursday, January 31 2013 @ 03:45 PM EST
- Add a space between " character and the footnote 8 superscript for better readability [N/T] - Authored by: bugstomper on Thursday, January 31 2013 @ 03:57 PM EST
- "A complex software" -> "A complex software function" - Authored by: myNym on Thursday, January 31 2013 @ 11:01 PM EST
- "mirrors for telescope" -> "mirrors for telescopes" (n/t) - Authored by: myNym on Thursday, January 31 2013 @ 11:04 PM EST
- "Each of these ideas may be the subject matter of one or more patents." - Authored by: myNym on Thursday, January 31 2013 @ 11:09 PM EST
- "free and open source (FOSS)" -> "free and open source software (FOSS)" (n/t) - Authored by: myNym on Thursday, January 31 2013 @ 11:13 PM EST
- "keeps contributing and keep" -> "keeps contributing and keeps" (n/t) - Authored by: myNym on Thursday, January 31 2013 @ 11:14 PM EST
- "What is the point for a programmer in reading patents?" - suggestion - Authored by: myNym on Thursday, January 31 2013 @ 11:21 PM EST
- "and most of the time he doesn't learn" - suggestion - Authored by: myNym on Thursday, January 31 2013 @ 11:24 PM EST
- Footnotes 1 and 2 are missing closing periods. - Authored by: myNym on Thursday, January 31 2013 @ 11:27 PM EST
- USTPO -> USPTO - Authored by: Anonymous on Friday, February 01 2013 @ 12:59 AM EST
- Subordinate clause - Authored by: Anonymous on Friday, February 01 2013 @ 01:22 AM EST
- third -> fourth - Authored by: Anonymous on Friday, February 01 2013 @ 01:44 PM EST
|
Authored by: lnuss on Thursday, January 31 2013 @ 03:28 PM EST |
...
---
Larry N.[ Reply to This | # ]
|
|
Authored by: lnuss on Thursday, January 31 2013 @ 03:29 PM EST |
...
---
Larry N.[ Reply to This | # ]
|
|
Authored by: lnuss on Thursday, January 31 2013 @ 03:30 PM EST |
...
---
Larry N.[ Reply to This | # ]
|
|
Authored by: drodio on Thursday, January 31 2013 @ 03:36 PM EST |
Hi all, I'm a tech CEO in San Francisco and I'll be attending the
Stanford USPTO
roundtable event.
I have a convo going w/ other members
of the tech community on my
personal
blog, in a post titled
Wh
at are the Deadliest Sins of Software Patents?
If you'd like to
leave your comments over on that post, I'll represent them in
person at the
roundtable.
I'll also bring a copy of Groklaw's response with me and
interject that as
appropriate into the
discussion.
Regards,
DROdio
Daniel R. Odio
CEO,
Socialize, Inc.
[ Reply to This | # ]
|
|
Authored by: swmcd on Thursday, January 31 2013 @ 04:01 PM EST |
1. Typo
Sometimes the exact same algorithm implements multiple software
functions when applied to the same input.
2. What is the
point for a programmer in reading patents?
Consider avoiding rhetorical
questions in formal writing.
3. but how about similar claims
Consider
recasting in more formal language, like
but there could be similar
claims
[ Reply to This | # ]
|
|
Authored by: swmcd on Thursday, January 31 2013 @ 04:17 PM EST |
You write
Whether the claim reads on a new, yet to be discovered
algorithm or on an obvious use of an old algorithm, it reads on an invention the
patentee has not invented.
but it seems to me that there is yet
another problem with functional claiming, which is that the patentee may not
have any working algorithm in hand.
There are functions that are
easily specified, but not easily computed.
There are functions that are
easily specified, but for which there is provably no algorithm (e.g. the halting
problem).
If the PTO is going to allow functional claiming, then they are
going to need some principle for discerning which functions may be implemented
within the existing art, and which may not. [ Reply to This | # ]
|
|
Authored by: bugstomper on Thursday, January 31 2013 @ 04:18 PM EST |
I'm uncomfortable with how this document introduces into the suggestion for
using source code for disclosure the rulings in Fonar Corporation v. General
Electric Corporation and in Northern Telecom v. Datapoint Corporation.
The problem I have with it is that it brings up court rulings that specifically
are in opposition to the suggestion, it seems to argue that the courts got it
wrong, but it does not tell the PTO under what authority or by what rationale
they should set aside the decisions of the courts. Is it really enough to say in
effect "The courts have interpreted current patent law as saying that
production of source code is a merely clerical function given the type of
disclosure that is the common standard in patents. Software developers disagree,
saying that the non-obvious part is the production of the code not the
specification of the functions."? I don't have the legal background to know
what to put here, but it seems that there has to be something that does need to
go here that says to the PTO: "These court rulings specifically state that
source code is not required for disclosure for these reasons. Software
developers would disagree [explanation how and why]. The PTO should [something I
am not qualified to come up with that gives them a path to require or at least
prefer source code in patents despite the court rulings]"[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 31 2013 @ 04:20 PM EST |
UML is not just for graphical notation. UML can provide formal documentation of
a system that can be serialized to a standardized XML interchange format (see http://en.wikipedia
.org/wiki/XML_Metadata_Interchange
) can be used to generate code and can
be reverse engineered from code. The graphical diagrams are nice, but UML goes
way beyond that. [ Reply to This | # ]
|
|
Authored by: swmcd on Thursday, January 31 2013 @ 04:45 PM EST |
In the past, the courts have set an extremely high bar for an obviousness
defense.
For a while, they just about defined it out of existence.
Recent
Supreme Court decisions have relaxed this a bit, but the bar is still very
high.
The most trivial patents are held to be non-obvious.
A programmer
couldn't have done that; we needed the special creativity of the
inventor.
But when it comes to disclosure, the courts are entirely
dismissive of the work done by programmers.
(See the citations to Fonar and
Northern Telecom.)
No need to say how anything is done.
Given the function,
writing the code is a mere clerical task.
I find this maddening.
I
desperately want to construct an argument saying that they can't have it both
ways.
Either it is easy, and most of these patents are obvious, or it is hard,
and we need disclosure of source code.
It is difficult to construct this
argument, because the courts can assert an internally consistent position that
all the invention and value is in the function, and none is in the
implementation.
BTW, I suspect the plantiffs in many patent lawsuits would
slink away with their tails between their legs if challenged to produce a
working implementation of their invention. [ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 31 2013 @ 05:01 PM EST |
"Sometimes the exact same algorithm implements multiple software functions
then applied to the same input"
then -> when?
"An example may be a routine to draw the shape a three-dimensional
parabolic surface."
+ of?
The intro is a little repetitious. [ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 31 2013 @ 05:46 PM EST |
Am I being tautological if I ask that the Addendum title reference
that it is -Software- developers we are talking about?
[ Reply to This | # ]
|
- I don't think so - Authored by: Ian Al on Friday, February 01 2013 @ 07:44 AM EST
- Thanks - Authored by: Anonymous on Friday, February 01 2013 @ 01:52 PM EST
|
Authored by: gibus on Thursday, January 31 2013 @ 06:03 PM EST |
Section C) is indeed the most important!
I'm quite worry with the current hype around Lemley's proposal. Yes, it would be
going in the right direction if it was not based on a false assumption: that
some software can be patented. Reducing the number of granted software patents
and the unclear boundaries thereof by forcing to disclose algorithm implementing
the claimed function is not THE solution to the software patents problem,
contrary to what Mark Lemley voices in his paper. There are software patents
with clear boundaries and disclosed algorithm which nevertheless impede
innovation and economy. Just think about infamous GIF/LZW patents. They actually
included quite defined algorithms, IMHO with enough details to pass Section
112(f). Nevertheless, there is no need to recall harms caused by these patents.
This is really worrying because, we've already had these discussions in Europe
in the beginning of the century. We have identified that disclosure of algorithm
was only a partial solution which don't really help with the bigger problem of
software patents.
Indeed, I'm worried that the momentum in US could be wasted by bad partial
solutions. Just read 2011 Federal Register notice
(https://www.federalregister.gov/articles/2011/02/09/2011-2841/supplementary-exa
mination-guidelines-for-determining-compliance-with-35-usc-112-and-for-treatment
-of)) on "Computer-Implemented Means-Plus-Function Limitations". They
are advising disclosure of algorithm "in any understandable terms including
as a mathematical formula […]". Hey, don't you have a Supreme Court having
ruled that mathematical formula cannot be patented, as being an abstract idea?
I think this is the way to go: exclude software patent for the inherent
abstractness of software. This is the way that was debated and chosen in Europe
(with "non-technical" as European counterpart for
"abstract").
[ Reply to This | # ]
|
|
Authored by: BitOBear on Thursday, January 31 2013 @ 06:17 PM EST |
I would suggest a disambiguation: "(in software) The algorithm is the
process by which the function achieves its result. Absent the algorithm, the
functional patent fails to disclose the means and/or method comprising the
invention itself."
The point that without the algorithm the functional language doesn't actually
detail what it claims needs a "catch phrase" that pivots on the whole
"business methods" keyword that got us in to this mess. The closer it
matches a "breakfast (minus) orange juice == day (minus) sun shine"
simplicity the better. Only in this case it is patent minus algorithm equals
function minus method and process.[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 31 2013 @ 07:31 PM EST |
github? [ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 31 2013 @ 08:32 PM EST |
I see a problem with using pseudo-code to disclose. I have reviewed pseudo-code
that cannot possibly be implemented. That was in part why we initiated
"code" reviews of pseudo-code before actual coding started. While
pseudo-code may be useful in communicating amongst programmers, analysts and end
users I fear it would give trolls too much of an opportunity to be vague and
obscure while not actually disclosing anything. I could write pseudo-code for an
NC mill that defined a box who's inside dimensions are greater than its outside
dimensions. However the NC programmer would not be able to actually program the
mill to fabricate such a box.
In order to disclose anything useful the code must be working code. Otherwise
it simply discloses nothing more than what the author wishes it to do or more
likely what the troll claims it does.
In order for the USPTO to do its job it should be able to observe the "code
that discloses" actually working. If it doesn't work nothing has been
invented.
If the code need not be disclosed because the coding would merely be a clerical
function, then the the claim is obvious to anyone skilled in the art.
cc[ Reply to This | # ]
|
|
Authored by: Anonymous on Thursday, January 31 2013 @ 09:44 PM EST |
If source code is included in a patent, the "owner" will claim that it
is also covered by copyright and therefore will have an effective 100 year term
on their patent.
Source code that is part of a patent must automatically come into the public
domain at the end of the patent term, or the expiration of the patent has no
meaning.[ Reply to This | # ]
|
|
Authored by: ailuromancy on Friday, February 01 2013 @ 12:24 AM EST |
Start by understanding the definition of a mathematical
function. Next identify the
input set, output set and relation in
computing:
The first byte of memory can have any integer value
from 0 to
255 inclusive. So can the second byte. If we
only have two bytes of memory,
then the input set has
65536 elements: {[0,0], [0, 1], ... [0, 255], [1, 0],
[1, 1], ... [255, 255]}. A modern computer might have
2147483648 bytes of
memory, so the input set has
at least 2562147483648 elements.
Computers also have CPU registers which are a type of
memory and increase the
size of the set. They also have
IO devices. To include a keyboard, you need a
sequence
of numbers representing times, and a sequence of numbers
that
represent a particular key being pressed or released.
An input set that
includes a keyboard needs elements
for each possible sequence of key presses
combined
with each possible content for memory and CPU
registers.
The
biggest possible output set has similar
elements to the input set.
Memory and
CPU registers contribute to the size of
the set in exactly the same way. Output
devices can
be included in the set as a sequence of times, and the
number that
was sent to the output port at each
time.
Most of the initial memory
state is ignored and
not modified by practical computer functions, so
a subset
of the input and output sets described above
is sufficient. Given one element
from the input set,
a computing function provides one element of the output
set. In mathematical terms, this is a binary
relation.
Any function used in computing meets the
mathematical
definition of a function.
[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, February 01 2013 @ 04:12 AM EST |
> 6) This is assuming the code is well-written. Obfuscated code is useless.
So when patents are written in obfuscated (legal) code, this means that ...[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, February 01 2013 @ 06:45 AM EST |
Can I suggest using sorting as a running example, as it helps illustrate several
points.
"Sort" is a function: it takes a list in arbitrary order and returns
it in ascending order.
"Sort" can be implemented by many different algorithms; bubble sort,
heap sort, quick sort, radix sort etc.
These algorithms are not obvious from the specification of the function. Sorting
algorithms have been the subject of a great deal of research. Bubble sort was
first described in 1956, and a new algorithm "library sort" was
published in 2006. Knuth published a huge book on the topic: "Sorting and
Searching".[ Reply to This | # ]
|
|
Authored by: Ian Al on Friday, February 01 2013 @ 08:04 AM EST |
There have been one or two useful changes proposed.
Apart from that I think that the piece is excellent, on-point, well argued and
supported with really appropriate quotations and citations.
I hope that anyone else who is of the same mind will add their endorsements and
encouragement to publish it on our behalf.
---
Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid![ Reply to This | # ]
|
|
Authored by: reiisi on Friday, February 01 2013 @ 08:44 AM EST |
The rulings you provide as bad examples in your addendum, I should not
express the disrespect I have for the judges, the lawyers who argued for the
rulings, the expert witnesses that were relied on, and the opposing counsel who
evidently failed to present the abundant evidence against.
Anyway,
please note explicitly that very few programmers would agree with their honors'
assertion that there is nothing inventive or creative about what they
do.
Other comments, I would strongly argue for
- source
code required to patent;
- no patent on source code itself, rather on
the abstract machine as expressed in the source code;
- the source code
being interpreted to limit, never extend, the claims;
(I ranted
on this subject back in November, my opinions haven't
changed.)
- much shorter term for software patents -- five years --
although that would have to be pushed through Congress rather than the patent
office/li>
But, yes, this proposal is progress, if we can get the
USPTO and Congressmembers to look at it seriously. [ Reply to This | # ]
|
- Creativity - Authored by: Wol on Friday, February 01 2013 @ 10:09 AM EST
|
Authored by: leopardi on Friday, February 01 2013 @ 08:45 AM EST |
Should the Addendum explicitly mention FOSS as Prior Art?
Or is this beyond
the scope of the question form the USPTO?
I can give an example of FOSS
as prior art. In an Australian Peer-to-Patent trial, I submitted a contention
that GMP 2.0.2 was prior art for a patent application by Hewlett Packard.
At that time, the Peer-to-Patent trial was supposed set up to allow prior
art to be uploaded, but it could not cope with the upload of a source code
archive. So I suspect there was an assumption about what was supposed to
constitute prior art.
A similar patent issued in the USA in 2010, with no reference to GMP as
prior art.
It is my contention that if FOSS code both pre-dates a patent
application, and is significantly similar to an implementation of the algorithm
embodied in the claims of the application, it should count as prior art, not
just in principle, but in fact, to the extent that a patent is prevented from
issuing.
Thoughts?
[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, February 01 2013 @ 08:57 AM EST |
The "absolutely no benefit" phrase seems to conflict with preceding sentences?
If "Many Groklaw members" aren't allowed to read patents then the
remainder are allowed to read them, and while "most of the time he doesn't
learn anything" then the remainder of the time he does learn something. [ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, February 01 2013 @ 02:37 PM EST |
IMO, The addendum would be stronger if there was a statement to the effect of
"Since the programmer is the one who is ordinarily skilled in the art, how
the programmer experiences the process is highly relevant."
MSS2[ Reply to This | # ]
|
|
Authored by: Anonymous on Friday, February 01 2013 @ 04:42 PM EST |
I think the argument about
Fonar Corporation v. General Electric Corporation:
need to be made much tighter.
If this case should be referenced there need to be plausible acknowledgement
about what part of judgement was good so you can build the case about where it
went wrong. If done rightly it will further support the main argument. In the
absence of such argument the answer to the topic can be rejected as only
mentioning Fonar by lip service and not "understanding the finer points of
this good case law".
For instance I am certain there are plenty of cases when an ordinary person
skilled in the art can write the implementation directly from the formal
language only. The key question is if these cases are separate from the cases
that should be rejected on the basis of being trivial and not anything new.
Another important aspect is that Fonar is bad case law to build on because it
state that there are cases when real disclosure is not needed, but it does not
give support for it being always true. This can followed up by a reference to
some hard problem where there is a mathematical/computer science proof about it
being hopeless to implement based only on the formal language.
Neither does Fonar include any tool/analysis the patent examiner can use to tell
if the particular patent require additional disclosure for it being possible to
be repeated.
This all can be tied back into a argument about formal language not being enough
for disclosure because it is impossible from the formal language itself to tell
if it is enough disclosure without actually implementing the code. The only way
it can be possible to say from the formal language if a problem is possible to
solve is if it is either can be recognized as only using referenced known art in
a new way (this imply full disclosure of algoritm) or if there is logical fault
in the specification that can be used to prove it impossible to solve the
problem.
Finally I think the argument about treble damages is counter productive. It
might be true in the real world, but this type of objection can always be
twisted into the software developer is misguided and would be even more
productive if he looked at patents. A more useful way of argument is to point
out that software programmers find no value in the formal language used in
patents because literature in computer science covers every field known to man
and use formal language combined with enough disclosure for be useful. Patents
should not be written in formal language without source code disclosure it is
give no benefit that is not already included in literature that constitute prior
art.[ Reply to This | # ]
|
|
Authored by: rsteinmetz70112 on Friday, February 01 2013 @ 11:23 PM EST |
I think the references to patent trolls and Non Practicing Entities (NPEs)
distract from the essential points on patent eligibility.
I would like to see those references stricken since the point of the article is
directed at eligibility in general.
Courts have taken some steps toward reining in Trolls and NPEs by limiting
access to "patent friendly" jurisdictions.
But major corporations have stepped into the gap. Apple and Microsoft cannot be
labeled a troll or NPE, yet they seem to be driving the major litigation.
The recommendations in the article apply universally and highlighting one
particular class of litigant seems arbitrary to me.
---
Rsteinmetz - IANAL therefore my opinions are illegal.
"I could be wrong now, but I don't think so."
Randy Newman - The Title Theme from Monk
[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, February 02 2013 @ 01:57 AM EST |
I don't know if there's any way to do this. It would be good if thousands of
programmers wrote in support of this, which is an *extremely* good summary.
Nathanael Nerode
Open Source Programmer (notable credits: work on GCC, Simutrans)[ Reply to This | # ]
|
|
Authored by: Anonymous on Saturday, February 02 2013 @ 02:54 AM EST |
Thankyou very much for this article.
Sometimes the posts on this website come far too close to
religious dogma on the 'software=mathematics' debate without
any real care for how the legal world perceives the subject
matter. I found this article to be insightful, clear and
more importantly realistic about limiting the scope of
overly abstract patents without removing them entirely.
In particular, the section 'from a developer' is very close
to how I perceive the issue - myself being a developer at a
company that highly prizes its patent portfolio. Pointing
out that developers are actively forbidden by their
companies to read patents, and that reading the claims
within the patent doesn't actually serve any useful purpose
to a developer, is very important. The sentence 'the mere
description of the problem teaches a skilled developer how
to solve it' was quite pertinent.
So thankyou, PJ and Groklaw, for a relatively sane and
reasonable response to this issue.[ Reply to This | # ]
|
- Religious dogma? - Authored by: Wol on Saturday, February 02 2013 @ 09:40 AM EST
- Facts aren't dogma. - Authored by: Anonymous on Tuesday, February 05 2013 @ 06:31 PM EST
- Re:Dogma - Authored by: Anonymous on Sunday, February 10 2013 @ 03:05 AM EST
|
Authored by: Anonymous on Monday, February 04 2013 @ 01:42 PM EST |
Consider clarifying "It seems that the only real purpose of patents
currently is for litigation purposes." to "It seems that the only real
purpose of software patents currently is for litigation purposes."
i.e. Change "patents" to "software patents" in this
sentence.[ Reply to This | # ]
|
|
Authored by: Anonymous on Wednesday, February 06 2013 @ 08:35 PM EST |
You need to remember them why blocking employees from seeing patents at all is
such a problem.
The purpose of patents is to foster innovation, in other words, to bring into
reality that which is only an idea in as many variants as possible. Not to
protect what has already been put into practice.
When designing something, there are always plenty of tradeoffs. Different
alternatives may be better for different cases or maybe even only a matter of
taste. Usually the market will sort its favorite in ways defying the usual
definitions of better (this and market manipulation/marketing). Either way, as
many alternatives as possible must be put into practice for the markets to sort
them out and in order to foster more innovation, as even for those alternatives
that end up being failures something can be learned from them.
This is the reasoning behind early disclosure and exclusive rights. So those
seeing them would look at alternatives, alternatives meaning, it is important to
emphasize, either different things altogether for the same or similar purposes,
or even different ways at doing the same thing. This is why that is better left
out to copyright when dealing with software, as there are plenty different ways
pretty much everything can be implemented, even on the same language.
Patents blocking more than one way in which to implement something are a
travesty to their original purpose and the need to go as far as outright banning
workers from even looking at them is proof of how inverted the priorities have
become.
Today Edison would be paying royalties to Joseph Swan if not to Humphrey.[ Reply to This | # ]
|
|
|
|
|