|
A Proposed Response to the USPTO's Topic 1 Question on Functional Language ~pj Updated |
|
Thursday, January 31 2013 @ 03:22 PM EST
|
In response to the USPTO's call for comments on how to enhance software patent quality, Groklaw has a draft of a response to the USPTO's Topic 1 question, on "how to improve clarity of claim boundaries that define the scope of patent protection for claims that use functional language". We'd like your input before we finalize our comment. Do you see a way to improve it? Make it clearer and more accessible to non-programmers? Any further references you think would be useful? We are going to respond to the USPTO's Topic 2 question as well, but the deadline for Topic 1 looms, so we'll start with Topic 1 for now and I'll post the Topic 2 draft later. The first roundtable panel will be February 12th, so I'd like to submit by that date.
Update: I wanted to let you know that we incorporated your ideas and suggestions, and I sent it in just now, Sunday, Feb. 10th. The final version as PDF is here. In the cover email, I said:
Gentlemen:
Thank you for expressing a desire to work more closely with the
software community. Groklaw represents a large chunk of the software
community, being a membership-produced journalistic website, one
that covers legal events of particular interest to the technical
community, especially to Free Software and Open Source software
developers.
We are applying open-source principles to research and journalism to
the extent that they apply. Our community us predominantly made up of
software developers, but our membership includes those with a
technical background in other fields, including mathematicians and
physicists, CEOs of startups, developers of apps for mobiles, others
with legal and paralegal training, as well as journalists, educators,
and many end users who care enough about operating systems to want
to volunteer to make Groklaw able to report effectively on patents,
which we have been doing for a decade.
So, when we saw your request for comments on Topic 1, on how to
improve clarity of claim boundaries that define the scope of patent
protection for claims that use functional language, naturally we
wanted to respond. I attach a copy of our comment, which was written
by many members as a group work, and then opening up the draft to the
world for their comments. By incorporating all the suggestions and
comments from both sources, I believe it now adequately reflects
widely held beliefs in the software developer community about means
plus function claiming and some ways to improve them. We hope you
find it helpful.
Pamela Jones
Founder and Co-Editor, Groklaw
http://www.groklaw.net
Next, we'll start working on Topic 2. If you see a better way to do a cover letter, save it for that draft, please. I can't read one more word on this topic at the moment. By that I mean not that I can't stand it, but that I've read it now so many times, my brain can't absorb things or notice things as it will be able to later. Thank you everyone for your fine input. I hope we've made a dent in the universe.
**************************
Groklaw's Response to the USPTO on the First Topic
Establishing Clear Boundaries for Claims That Use Functional Language
The USPTO has launched a Software Partnership initiative to enhance the quality of patents. It has invited the public to comment on three topics. This is Groklaw's response to Topic 1, “Establishing Clear Boundaries for Claims That Use Functional Language”.
Summary of the response
Claims on the functions of software without an accompanying algorithm result in granting rights to inventions the patentee has not invented.
This view is similar to a legal analysis by Mark
Lemley.1 Lemley argues based on legal considerations; Groklaw reaches this conclusion on technical grounds.
The functions of software should always be explicitly accompanied by a corresponding algorithm unless the algorithm is known from the prior art. Similarly, algorithms should be detailed up to the point where there is prior art for the implementation of all elements used to describe the individual steps. This rule should be applicable to all forms of claiming because the problems of functional claiming without an accompanying algorithm occur no matter how the claim is drafted.
We disagree with Lemley when he says functional claiming is the source of most of the ills of software patents. We believe that patents on abstract ideas are also problematic. It is possible to write claims on abstract ideas using very specific terms, so invalidating vague or overly broad patents will not solve the problems caused by claims on abstract ideas.
This response is divided in three parts followed by an addendum providing a supplementary comment: -
A. Permitting recitations of software functions without specifying their accompanying algorithms leads to grants of rights to inventions the patentee has not invented.
-
B. Algorithms should be detailed up to the point where all functional elements have corresponding algorithms which are either explicitly disclosed or known in the computer programming art.
-
C. Providing sufficient structure for functional language will reduce needless litigation but is not a substitute to section 101 subject matter analysis.
-
Addendum. From a developer's perspective, source code for working programs is the preferred form of disclosure.
A. Permitting recitations of software functions without specifying their accompanying algorithms leads to grants of rights to inventions the patentee has not invented.
This response documents this issue from the point of view of the mathematical theory underlying computer science. It shows why the problems of functional claiming occur no matter which form of claim language is used.
The key concept is the distinction mathematicians draw between a function and an algorithm. Hartley Rogers explains:2 (emphasis in the original):
It is, of course, important to distinguish between the notion of algorithm, i.e., procedure, and the notion of function computable by algorithm, i.e., mapping yielded by procedure. The same function may have several different algorithms.
A mathematical function is a correspondence between one or more input values and a corresponding output value. For example the function of doubling a number associates 1 with 2, 2 with 4, 3 with 6 etc. Non-numerical functions also exist.
A function is not a process. There is no requirement that the function must be computed in a specific manner. All methods of computation which produce the same output from the same input compute the same function.
A method for computing the function is called an “algorithm”. There is a series of steps to be executed starting with the input and ending when the output is produced. The ordinary procedures of arithmetic for adding and multiplying numbers using pencil and paper are examples of algorithms. In mathematics, nonnumerical algorithms for processing nonnumerical data also exist.
Despite the similarly sounding words, a software function is not the same thing as a mathematical function. However the two concepts are closely related. If we look at the underlying principles of mathematics which are at the foundations of computer science the functions of software are described with mathematical functions.3 The methods used to perform the functions of software are implemented using mathematical algorithms.
As indicated by Hartley Rogers, the same function may have several algorithms. For example we may double a number by multiplying it by 2, or we may add it to itself. Both ways the number is doubled.
When the algorithm for a software function is not provided, the claim will read on all algorithms for this function. This implies the claim may read on methods the patentee has not invented. This shows the mathematical principles underlying computer science are supporting Lemley's description of the problems caused by functional claiming.4:
While experienced patent lawyers today generally avoid writing their patent claims in means-plus-function format, software patentees have increasingly been claiming to own the function of their program itself, not merely the particular way they achieved that goal. Both because of the nature of computer programming and because of the way the means-plus-function claim rules have been interpreted by the Federal Circuit, those patentees have been able to write those broad functional claims without being subject to the limitations of section 112(f). They have regained the ability to claim ownership not of what they built, but of what it does. They claim to own the function itself.
There is another problem with functional claiming that Lemley has not identified. 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.
And there is still another problem with functional claiming. Sometimes the exact same algorithm implements multiple software functions when applied to the
same input. An example may be a routine to draw the shape of a three-dimensional parabolic surface. This routine may be mentioned in a claim as a method for drawing the form of different physical devices, like radio-frequency antennas, mirrors for telescope or directional microphones. The mention of the object will make each of these claims sound like they are reciting different functions, but in reality the objects may have the same shape and dimensions. Then exactly the same code is used on the same numeric data. Nothing new has been invented. Once again this circumstance will be easier to identify if we require that a software function is accompanied with the corresponding algorithm.
There is a third problem with functional claiming. The knowledge of the
functions of the software is not a guarantee that the patentee has a working
algorithm in hand. Some functions are notoriously hard to program. For example
cryptography relies heavily on the difficulty of finding algorithms for large
integer factorization
that
are fast enough to be used in practice. The extreme cases are the
undecidable problems.
These are functions for which we have a mathematical proof that no corresponding
algorithm can possibly exist. A patent may in theory recite a function like
these, but its disclosure doesn't enable anyone to implement a corresponding
algorithm. In fact, without disclosure of a specific algorithm, one has
reasonable grounds to doubt the patentee has a practical way to implement the
function claimed as his possession.
Whether the claim reads on a non-existant, 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. In all cases, this is a problem.
The cause of these problems resides in part in the mathematical principles underlying computer programming. As Lemley points out, they occur no matter which form of claim language is used. It should not matter whether or not the claim is written in traditional 112(f) means-plus-function format. Either way, a claim element described in functional language without the corresponding algorithm will result in the same problem.
B. Algorithms should be detailed up to the point where all functional elements have
corresponding algorithms which are either explicitly disclosed or known in the computer programming art.
This section addresses the degree of detail which should be required to meet the sufficient description requirement.
For example, if a claim recites the function of adding numbers, there is no requirement to describe a method for addition, because this method is well-known in the computer programming art. But when a claim recites a function for which no algorithm is known in the prior art, an algorithm must be explicitly disclosed.
An algorithm is usually described by elaborating it with an increasing degree of detail in a hierarchical manner. The rule for sufficient description should be applied at all levels of the hierarchy.
Here is how it would work: An algorithm is made of steps. Each step is itself described in functional terms. Therefore each step is itself a functional element for which an algorithm must be provided. This more granular algorithm is also made of steps described in functional terms. Algorithms for the more granular steps must also be provided. This elaboration of steps into more granular algorithms must continue until it is known from the prior art how to implement all individual steps. Then the algorithms for all functional elements are either explicitly disclosed or already known.
This rule for what is sufficient structure should be applied for both purposes of enablement and defining the boundaries of claims. Anything less permits incomplete disclosure. Also, if some steps are allowed to be described in functional terms without disclosing a corresponding algorithm, we just move the problems of functional claiming from the main functions of software to the functions of individual steps. This doesn't accomplish much. Functional claiming will persist because applicants will cleverly write patent language that uses this loophole.
C. Providing sufficient structure for functional language will reduce needless litigation but is not a substitute to section 101 subject matter analysis.
Providing this degree of detail in the structure for functional elements will help reject vague or overly broad patents. The approach proposed by Groklaw has an additional benefit. It should create a presumption that any functional language recited without a corresponding algorithm is within the prior art, otherwise the claim is invalid as indefinite. This presumption may help curtail baseless litigation with summary judgment motions on invalidity under sections 101, 102 or 103 because there will be fewer material issues of fact that could be disputed.
This is a highly desirable result but this doesn't resolve all the problems with software patents. In
particular, Section 101 analysis is still required to determine whether a claim is drawn to an abstract idea. For example consider a claim on a computer programmed to compute the location of points on a non-vertical straight line in plane geometry according to the well-known formula y=mx+b. This claim is on a method to compute the y-coordinate of a point when the x-coordinate is known.
A computer programmed for computing the y-coordinate using a method comprising: 1. a step of identifying the value x of the x-coordinate, and; 2. a step of multiplying the x-coordinate with the slope of the line m to obtain an
intermediate result mx, and; 3. a step of adding the intermediate result mx with the value b of the y-coordinate at
the origin to obtain the value y of the y-coordinate.
This is clearly a claim on an abstract mathematical algorithm. This claim is not vague and it is not overly broad. It doesn't use functional claiming. It is invalid because it is abstract. It is also invalid because the formula is old, but how about similar claims where the formula is new and nonobvious? They can only be invalidated using section 101.
This observation is typical. In mathematics an algorithm must be given at a great degree of specificity, otherwise it is not an algorithm in the sense mathematicians give to this term. Boolos, Burgess and Jeffrey explain:5:
The instruction must be completely definite and explicit. They should tell you at each step what to do, not tell you to go ask someone else what to do, or to figure out for yourself what to do: the instructions should require no external source of information, and should require no ingenuity to execute, so that one might hope to automate the process of applying the rules, and have it performed by some mechanical device.
Any attempt to equate the abstract idea exception with a prohibition of vague or overly broad claims is inconsistent with the notion that mathematical algorithms *are* abstract ideas. Also we believe that many non-mathematical abstract ideas may be described in specific terms.
Software development is an incremental activity. A complex software may use thousands of ideas. Each of these ideas is a basic building block which could be used in a large number of different pieces of software. Each of these ideas may be the subject matter of one or more patents. Patents on abstract ideas are as damaging as patents on vague or overly broad claims.
If the patent system successfully curtails the use of vague and overbroad claims, patent trolls may shift their activity to claims drawn to abstract ideas. A patent on an idea which may potentially be widely used may be well-suited to patent trolling. Please recall that non-practicing entities may be profitable even when their targets don't infringe on claims. They only need to threaten litigation to extract settlements. Their business model doesn't require vagueness and breadth of claiming.
Patents on abstract ideas may also be used for other forms of abuse of the patent system, like building patent thickets that impede innovation for anti-competitive purposes.
Addendum. From a software developer's perspective, source code for
working programs is the preferred form of disclosure.
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. In
particular patent law depends on a quid pro quo to promote innovation. Patentees
are granted exclusive rights for a limited time in exchange for the disclosure
of the invention. It would be important to assess whether the quid pro quo works
in practice according to theory. If not, there is no reason to believe patent
law actually promotes innovation.
Most developers are not good at reading legal language. For best results, disclosure should be
written in a language developers can read. Software programmers would welcome a greater use of textual and graphical notation systems known in the art, such as C-like pseudo-code or XML-like schemas for textual notation and Unified Modeling Language (UML) for graphical notation. We see the request for comments on topic 3 as a positive development.
For developers the preferred form of disclosure is source code for working programs.6 Please note that the patent system is not the only incentive for disclosure available in the market. Parties skilled in managing a relationship with a community of developers will use an open development model where information is freely shared. One example is the free and open source (FOSS) development model. Another example is the IETF standard development model.
In the FOSS development model, disclosure of the source of working programs is mandatory. Programmers need to read, use, modify and distribute the software in order to contribute modifications. For many businesses this is R&D available at no monetary costs. The only requirement is to keep a good relationship with the community to ensure it keeps contributing and keep releasing the improvements to the software in source code form. From the point of view of programmers, this incentive leads to a superior form of disclosure when compared to the patent system. In fact, the patent system is toxic to the FOSS development model, and hence works against innovation, in that the purpose of patents is exclusion.
Examples of software inventions developed and disclosed in this manner are the Perl and Python programming languages, the Linux operating system kernel, and the Coq proof assistant.
The IETF standard development process is different. They write detailed specification documents called RFCs (Requests for Comments). These documents are shared and updated until the participants generally agree these specifications are proven to work with actual implementations.7 This process has been summarized with the phrase “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.”8 All the core communication protocols of the Internet are developed and disclosed in this manner. Although this development process doesn't explicitly require the disclosure of source code the publication of reference implementations is a common practice.9 It is required that a proposed standard must have two independent interoperable working implementations in order to be adopted.10
Other inventions which have been disclosed in source code form are the web browser and the web server.11
Please compare this quality of disclosure with Fonar Corporation v. General Electric Corporation: As a general rule, where software constitutes part of a best mode of carrying out an
invention, description of such a best mode is satisfied by a disclosure of the functions of the software. 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. It is well established that what is within the skill of the art need not be disclosed to satisfy the best mode requirement as long as that mode is described. Stating the functions of the best mode software satisfies that description test. We have so held previously and we so hold today. Thus, flow charts or source code listings are not a requirement for adequately disclosing the functions of software.
See also Northern Telecom v. Datapoint Corporation:
The computer language is not a conjuration of some black art, it is simply a highly structured language . . . . The conversion of a complete thought (as expressed in English and mathematics, i.e. the known input, the desired output, the mathematical expressions needed and the methods of using those expressions) into a language a machine understands is necessarily a mere clerical function to a skilled programmer.
From a programmer's point of view, these cases are incorrect. Sometimes the
algorithm can be easily derived from the disclosure of the functions and
sometimes it can't.12 When the disclosure of the functions suffice to
enable to algorithm, the invention should be considered obvious because the mere
statement of the problem to be solved suffices to teach the programmer how to
solve it. This is definitely how a programmer would see this sort of thing.
Also, from the perspective of a programmer these cases eviscerate the usefulness
of disclosure.
The functions of most software inventions can be defined after a few brainstorming sessions. Turning these functions into a working implementation is still a lot of hard work. When only the functions are known, the programmer is still required to do the bulk of this work. But this obligation does not follow from the disclosure, which is commonly available from collaborative development processes. In the case of FOSS, the programmer has access to the source code of a working program he can immediately use. In the case of IETF the programmer can usually refer to a reference implementation. This is why the FOSS and IETF development models lead to a superior form of disclosure.
The functions of existing software can usually be seen just by watching the program in action. Developers may watch over the shoulder of a user, or they may inspect the computer internals with debugging tools. Disclosing the functions of software without source doesn't disclose any trade secret or, in fact, anything useful.
For a programmer reading patents is usually pointless and it is dangerous. He risks
becoming liable for treble damages for willful infringement and most of the time
he doesn't learn anything that wouldn't otherwise be known to him. Many Groklaw members report that their employers forbid their developers from reading patents precisely because the risks are high, and there are no benefits. It seems that the only real purpose of patents currently is for litigation purposes. This kind of "disclosure" does not and cannot promote innovation because the patent quid pro quo is not working in practice according to theory.
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.
1 See Mark Lemley, Software Patents and the Return of Functional Claiming
2 See Rogers, Hartley Jr., Theory of Recursive Functions and Effective Computability, The MIT
Press, 1987 pp. 1-2
3 See for instance textbooks on denotational semantics for one method of writing such descriptions. An example of such textbook is Stoy, Joseph E., Denotational Semantics: The Scott-Strachey Approach to Programming Language Theory, MIT Press, First Paperback Edition.
4 See Lemley supra, pp.2-3.
5 See Boolos George S., Burgess, John P., Jeffrey, Richard C., Computability and Logic, Fifth Edition, Cambridge University Press, 2007, page 23.
6 This is assuming the code is well-written. Obfuscated code is useless.
7 See RFC 2026 for the current version of the RFC development process. RFC2555 is an historic
account describing how the RFC process has been used to invent and disclose the core Internet
protocols.
8 See Andrew L. Russell, Rough Consensus and Running Code and the Internet-OSI Standards
War (PDF).
9 An example of a reference implementation is found in RFC1321 Appendix A. Reference
implementations may also be incorporated by reference. For example, RFC 5905 includes the reference, “This document includes material from [ref9], which contains flow charts and equations unsuited for RFC format. There is much additional information in [ref7], including an extensive technical analysis and performance assessment of the protocol and algorithms in this document. The reference implementation is available at www.ntp.org.” This same RFC 5905 also includes a skeleton program with code segments in appendix A.
10 See RFC 2026 supra, section 4.1.2: A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level.
11 The W3C consortium hosts the first web page ever published. It includes instruction on how to obtain the source code for web browsers and web servers.
12 See the discussion of large integer factorization and undecidable
problems above.
|
|
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 | # ]
|
|
|
|
|