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

**************************

Groklaw's Response to the USPTO on the First Topic
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.¹ 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.

The key concept is the distinction mathematicians draw between a function and an algorithm. Hartley Rogers explains:² (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 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.³ 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.⁴:

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.

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.

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.

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 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:⁵:

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.

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.

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.⁶ 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.⁷ This process has been summarized with the phrase “We reject: kings, presidents, and voting. We believe in: rough consensus and running code.”⁸ 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.⁹ It is required that a proposed standard must have two independent interoperable working implementations in order to be adopted.¹⁰

Other inventions which have been disclosed in source code form are the web browser and the web server.¹¹ 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.

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.

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.

¹ See Mark Lemley, Software Patents and the Return of Functional Claiming

² See Rogers, Hartley Jr., Theory of Recursive Functions and Effective Computability, The MIT Press, 1987 pp. 1-2

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

⁴ See Lemley supra, pp.2-3.

⁵ See Boolos George S., Burgess, John P., Jeffrey, Richard C., Computability and Logic, Fifth Edition, Cambridge University Press, 2007, page 23.

⁶ This is assuming the code is well-written. Obfuscated code is useless.

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

⁸ See Andrew L. Russell, Rough Consensus and Running Code and the Internet-OSI Standards War (PDF).

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

¹⁰ 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.

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

¹² See the discussion of large integer factorization and undecidable problems above.