decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books


Groklaw Gear

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

You won't find me on Facebook


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

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

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:


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

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” 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.


A Proposed Response to the USPTO's Topic 1 Question on Functional Language ~pj Updated | 202 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread Here...
Authored by: lnuss on Thursday, January 31 2013 @ 03:27 PM EST

Larry N.

[ Reply to This | # ]

Off Topic Thread Here...
Authored by: lnuss on Thursday, January 31 2013 @ 03:28 PM EST

Larry N.

[ Reply to This | # ]

Newspicks Thread Here...
Authored by: lnuss on Thursday, January 31 2013 @ 03:29 PM EST

Larry N.

[ Reply to This | # ]

COMES Thread Here...
Authored by: lnuss on Thursday, January 31 2013 @ 03:30 PM EST

Larry N.

[ Reply to This | # ]

A Proposed Response to the USTPO's Topic 1 Question on Functional Language ~pj
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.


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

The point about court rulings that source code is not required for disclosure
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 | # ]

Disclosure vs. Obviousness
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 | # ]

A Proposed Response to the USTPO's Topic 1 Question on Functional Language ~pj
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
Providing sufficient structure for functional is not a substitute to section 101 subject matter
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
-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

[ Reply to This | # ]

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

A Proposed Response to the USTPO's Topic 1 Question on Functional Language ~pj
Authored by: Anonymous on Thursday, January 31 2013 @ 07:31 PM EST

[ 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

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.


[ Reply to This | # ]

One Hundred Year Patent Terms
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

[ Reply to This | # ]

Computer functions are mathematical functions
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 | # ]

A Proposed Response to the USTPO's Topic 1 Question on Functional Language ~pj
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 | # ]

Sorting as a running example
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

"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

[ 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.

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

[ Reply to This | # ]

A few comments
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

  1. source code required to patent;
  2. no patent on source code itself, rather on the abstract machine as expressed in the source code;
  3. the source code being interpreted to limit, never extend, the claims;
  4. (I ranted on this subject back in November, my opinions haven't changed.)

  5. 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
Open source as prior art?
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.


[ Reply to This | # ]

A Proposed Response to the USPTO's Topic 1 Question on Functional Language ~pj
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 | # ]

The addendum
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."


[ Reply to This | # ]

A Proposed Response to the USPTO's Topic 1 Question on Functional Language ~pj
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

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

[ Reply to This | # ]

Patent Trolls and NPEs
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 | # ]

I would like to endorse Groklaw's submission as a co-signer.
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 | # ]

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

[ Reply to This | # ]

Purpose of pattents
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

Today Edison would be paying royalties to Joseph Swan if not to Humphrey.

[ Reply to This | # ]

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 )