decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Why Software is Abstract, by PolR
Thursday, October 07 2010 @ 03:40 AM EDT

Why Software Is Abstract
by PolR

[This article is licensed under
a Creative Commons License.]


Following the ruling of the Supreme Court in Bilski, the USPTO asked, in substance, how to tell an abstract idea from an application of the idea. In this article I propose an answer to the question of what makes software abstract. It is a follow up to the previous article, Physical Aspects of Mathematics.

The logic is to look at why a mathematical calculation is abstract and then see if the same logic applies to software. It happens that it does. It is possible to show that software is abstract with references to the underlying mathematical aspects. This is not, however, the topic for this article. The argument is presented without any assumption as to whether or not software is mathematics. I work from the observation that a mathematical calculation solving a mathematical problem is abstract. Then I look at what makes it abstract. Then I observe that the exact same logic is applicable to all software whether or not the law sees it as an algorithm as defined by Benson. This is not surprising. Software is mathematics and this makes it abstract, but I don't use or rely on this fact in making the arguments in this article.




Abstraction Is Self-Containment

Let's start with experts, who can define for us what makes mathematics abstract, in some writings on the psychology of learning. See Mitchelmore, Michael and White, PaulAbstraction in Mathematics and Mathematical Learning (where you can download the article as PDF)

We claim that the essence of abstraction in mathematics is that mathematics is self-contained: An abstract mathematical object takes its meaning only from the system within which it is defined. Certainly abstraction in mathematics at all levels includes ignoring certain features and highlighting others, as Sierpinska emphasises. But it is crucial that the new objects be related to each other in a consistent system which can be operated on without reference to their previous meaning. Thus, self-containment is paramount.

These authors are university researchers specializing in the psychology of learning mathematics with a focus on the role of abstraction. They are authorities on the issue of what is an abstract idea when the psychology of learning mathematics is concerned.

Consider a calculation written down on paper. Let's say you have 128 boxes each containing 48 cans of peas. How many cans do you have? It is 128 × 48 = 6144 cans.

This is an arithmetical computation. What is the difference between this and computing 128 × 48 in the abstract without referring to boxes, cans, and peas? Does the computation change if it is cans of mushrooms instead? The difference is purely semantic. The computation is not changed. The written numbers do not record such information. The arithmetic process, the physical manipulation of the digits, is the same no matter what the written symbols represent in the real world.

This is why arithmetic is abstract. Mathematical calculations are self-contained in the sense that they are defined entirely within mathematics, independent of the real-world meaning of the numbers. This independence is the abstraction that makes mathematics an abstract idea.

This same idea of self-containment applies to computers for all type of computations, not only the ones restricted to computations about numbers. During the actual computation the real world meaning of the bits is not stored with the bits. Some mathematical meaning is hardwired in the computer. Boolean and numerical interpretations of bits are understood by the computer instruction sets. This is all the meaning computers can understand. When the computer carries out the computation any information about real-world meaning is unused and physically absent from the computer. Only the raw bits are present.

Abstractions may come in layers, each one being located at its own self-contained level. For example a particular program may be written in a programming language with an elaborate type structure that retains some information about real-world usage. For example, numbers may be tagged with the unit like inches and kilograms so we know what the number is used for. This source language layer of abstraction is self-contained. The information the program is able to understand is defined in terms of the capabilities of the programming language.

Then there is a layer closer to the hardware where the operations must be the machine implemented instructions. Unless the hardware has been designed especially for this purpose the elaborate types of the programming language are not recognized at this level. This degree of abstraction is also self-contained.

The activity of the computer is self-contained, then, in the sense given by Mitchelmore and White. The activity on the bits is entirely defined within the architecture of the computer with no reference to the real-world meaning. This means all computations made by the computer are abstract in the same manner that mathematical calculations are abstract.

To confirm that this is true, please examine the list of instructions from reference material like The Art of Assembly Language Programming. All the instructions a CPU is physically capable of are described in such reference material. None of the instructions ascribe or require any real-world meaning. The computer neither knows nor needs to know whether it adds oranges or apples. A requirement to understand the real-world interpretation of the bits will prevent computer execution because no computer has such capability1.

An anonymous user replying to the previous article mentioned a related issue which is worth repeating here.

This leads to my second point, that of severability and intent - which was triggered by your analysis of Alappat. The four circuits in that case _were_ severed, as you pointed out. As such, they were a general purpose computing device; general in the sense that they could be used for any purpose where the mathematical operation they embodied was useful. On the other hand, a mechanical analogue fire control computer is very limited -- it's pretty hard to think of another use, other than fire-control, for such a device. When someone tries to assert claims under various tests by tying a program to a GP computer, these parts are clearly severable.

Self-containment is not the ability to think of another use for the same abstraction or the same device. It is not being general purpose as opposed to being specific purpose in the sense of this comment. Imagine for example a complex mathematical model for climatology. It will be very hard to think of another use of these specialized mathematical formulas2. But they are still mathematical formulas and abstract in the self-containment sense. If we build a special purpose computer to carry this computation it would still be self-contained, even though this computer might have no other use than climatology.


The Irrelevance of Real-World Meaning

I understand that case law pays attention to the real-world meaning of symbols. I am not a lawyer, obviously, but from what I've read, patent law seems to care when the patent covers a real-world application, because this is one of the factors that help determine when the claimed subject matter is patentable. But failure to factor into the analysis the irrelevance of real-world meaning to the execution of an algorithm will bring inconsistencies. For an example, see In re Alappat where the meaning of the numbers was used to determine that the contested patent passed the useful, concrete and tangible result test.

As another example, this article on Patently O discussed Ex Parte Gutta, at a test to determine whether a machine that involves a mathematical algorithm is patentable subject matter:

The BPAI's test for a claimed machine (or article of manufacture) involving a mathematical algorithm asks two questions. If the a claim fails either part of the two-prong inquiry, then the claim is unpatentable as not directed to patent eligible subject matter.
  1. Is the claim limited to a tangible practical application, in which the mathematical algorithm is applied, that results in a real-world use (e.g., “not a mere field-of-use label having no significance”)?

  2. Is the claim limited so as to not encompass substantially all practical applications of the mathematical algorithm either “in all fields” of use of the algorithm or even in “only one field?”

I don't know whether this test is still in use in the post-Bilski world. But still its analysis is instructive and relevant to this discussion.

Both prongs of the inquiry look at the purpose of the claim in terms of practical applications. In a scenario where the claimed machine does nothing but execute a computer program, this test depends exclusively on information that is both unused during the actual execution of the program and absent from the machine as it carries out the computation. There are scenarios, then, where the same machine can simultaneously be non-patentable subject matter and subject to several independent patents because this test is based on information that is irrelevant to its intended purpose. The outcome of the test depends on the purpose of the user and not on the technology he is patenting. This outcome may and will vary from user to user.

This observation applies to special purpose computers where the computation is carried out by application specific circuits. It also applies to software to the extent the courts believe that loading software in memory makes a new potentially patentable machine. Finally, although the BPAI test is applicable to machine patents, the observation would also apply to a similar test for process patents where the process is defined by the step-by-step execution of the computation on the bits.

If the law uses an inquiry that looks at the purpose of the claim in terms of practical applications to determine whether or not the claim is patentable or not because it's an abstract idea, where the claimed machine does nothing but execute a computer program, this inquiry would depend on information that is both unused during the actual execution of the program and absent from the machine as it carries out the computation. Depending on how that actual test is defined, there could be scenarios where the same machine can be simultaneously non-patentable subject matter and subject to several independent patents because the inquiry is based on information that is irrelevant to the actual technology. In this hypothetical scenario the outcome of the inquiry depends on the purpose of the user and not on the technology he is patenting. This outcome may and will vary from user to user.

This observation applies to special purpose computers where the computation is carried out by application-specific circuits. It also applies to software to the extent the courts believe that loading software in memory makes a new potentially patentable machine. Finally the observation would also apply to a similar test for process patents where the process is defined by the step-by-step execution of the computation on the bits.

Let me give an example. Suppose someone patents a method to draw the shape of a parabolic antenna for radio applications and drafts it as a machine patent on the computer running the program.

This is a practical application. But the program nowhere uses the information that it is the shape of an antenna that is being drawn3. The program is drawing a tridimensional geometric shape that will be displayed on screen or printed on paper. The fact that this shape is the shape of an antenna is totally irrelevant to the execution of the algorithm and has no effect on the structure of the computer that executes it. It is only when the output is produced that the human viewers will interpret the shape as an antenna.

Then along comes an engineer in the field of acoustics that has a use for a parabolic object. He may patent a method to draw his object and draft it as a machine patent. This likewise is a practical application. But both objects have the same shape and are computed by the same method. The very same computer can be used for both purposes. The code will be identical if the programmer so desires. In such a scenario, would a second patent on the same software be granted because a different application is contemplated? In such case when a user uses the software the patent that will be applicable will depend on the user's purpose and not on the software itself.

Then here comes a mathematician in the field of solid geometry, looking for a program to draw parabolic 3D objects. The very same code will work just fine but solid geometry is theoretical mathematical work and not a tangible practical application that leads to real-world use. For the purposes of this mathematician, the same software is not patentable subject matter.

In all three scenarios the "invention" is exactly the same. It is the same computer running the same software implementing the same algorithm and executing the same machine instructions. But this kind of inquiry gives different answers in each scenario. This indefiniteness is what we get if we ignore the abstraction inherent in software and give undue consideration to the real-world meaning of the bits.

Consider Diamond v. Diehr. The patent in that case involved an algorithm for computing the time required to cure rubber. But the patented process isn't content to just print the answer. It actually cures the rubber. It is the actual curing that separates this industrial process from a mathematical process because there is a functional relationship with the actual rubber. Such a relationship wouldn't occur if the process were just printing an answer.

In Parker v. Flook, the patent uses a mathematical algorithm to determine conditions that require human attention. An alarm is sounded where these conditions occur. An audible alarm is output.4 Its purpose is to convey information. It means a condition occurred. It answers the question of whether or not something is worthy of attention. It doesn't act in the real world beyond communicating the information. The Flook patent covers a mathematical algorithm because the functional relationship with the required intervention is not being claimed.

In the antenna example, printing the shape of an antenna is output. The line between expressing and making a physical real-world use of the meaning is crossed when the antenna is built. Printing or displaying the shape of an antenna is a mathematical algorithm. Building an antenna is not.


Where Are the Boundaries of an Algorithm With the Real World?

So far we have gathered sufficient facts to answer two questions:

  1. Why is software abstract?

  2. In a process involving software, where are the boundaries of its abstract parts?

We know the answer to the first question. It is the independence of the bits from their real-world meaning that makes software abstract. Let's answer the second, looking again at a mathematical example.

Consider a practical example. Here is a two-step process to compute the circumference of a circle with a precision of four decimal places:

  1. Measure the diameter of the circle with a measuring instrument precise to four decimal places,

  2. Multiply the diameter by 3.1416. The result is the circumference.

This is abstract because there is no correlation with the real world at all. The calculation is self-contained. A circle is a geometric figure and the arithmetic operations work on numbers.

What if we alter the process to make it a process to compute the circumference of a bottle? Would it make it more concrete?

Step b) is certainly not more concrete. A mathematical computation doesn't depend on the real-world meaning of the numbers. The fact that the diameter is the diameter of a bottle doesn't change anything about this step. The difference is in step a) because the measurement is now limited to measuring a bottle.

When a computation is done, the answer may have practical applications. For instance, the diameter may be used to compute the quantity of paint needed to paint a line around the bottle. This will involve some more abstract mathematical calculations, but eventually you put the exact quantity of paint in your bottle painting machine for the quantity of bottles you have. When you reach this point your activity is no longer independent of the real-world meaning. You are back into the concrete world.

From this example I infer the answers to the second question. In a process involving mathematics, its abstract mathematical part starts at the initial input, when the real world is described in mathematical terms by measurement or otherwise. It stops after the final output where the answer is provided, at the point when its meaning is acted upon.

In the actual process there is a flow of information. This flow starts at the data gathering step where information about the real world is collected. This information is represented with a mathematical object like a number or a collection of bits. This is the input. Then some mathematical operations occur. An answer in the form of another mathematical object is produced and communicated. This is the output. The information flow stops when the information is received by a party, human or device, who interprets the information to act upon its meaning. Everything that happens between the data gathering and the acting upon the meaning is abstract.

This logic is stated in terms of mathematical calculations. It applies also to abstract bits independently of whether or not the problem being solved is a mathematical problem in the sense of Benson. At the initial input when the real world is represented with bits, the abstract part of software begins. When the answer is acted upon after the final output the abstract software part has ended.

Would this not tell us where to draw the line between an abstract algorithm and an application of one? A court would know where are the boundaries of the algorithm and why it is abstract. The court should be able to work out how the law applies to a specific patent from this knowledge.

This analysis correlates well with the printed matter doctrine, or more exactly the notion of a functional relationship between the information and the substrate. Here is how it goes:

  • When the real-world data is initially gathered it is input recorded on some media, be it a piece of paper, a USB key, a CD-ROM, a hard disk etc. Then it is printed matter with no functional relationship with the substrate.

  • When the real-world data isn't initially gathered at the computer it must be brought to it somehow. This could be for example by communication over a network, an input connection or insertion of the media in a reader device. Again the real-world data is printed matter with no relationship with the substrate.

  • When the data is processed by the computer the real-world meaning of the data has no functional relationship with the computer, because the computer never uses this meaning. This is why the computer program is abstract, and it is part of why the program is a mathematical algorithm.

  • When the answer is produced, it is bits recorded in memory. Again this is printed matter with no functional relationship with the substrate.

  • The answer may undergo some more steps. It may be communicated over a network or recorded on some storage device. If the answer is text or an image, it could be printed or displayed. If it is sound or video, it could be played back. In all scenarios, this is output. Again this is printed matter with no functional relationship with the substrate.

  • Once the answer is interpreted and the real-world meaning is acted upon (as opposed to mere communication) then a functional relationship with the real world is found.

This analysis focuses exclusively on the real-world meaning of the data, ignoring its mathematical meaning. The functional relationship between computers and the mathematical meaning of the raw bits depends on the mathematically exact definition of algorithm and how this definition relates to actual computers.

In the entire chain of events there is no point where the real-world meaning has a functional relationship with the underlying computer processing until the end when a functional relationship with the meaning occurs5. Therefore, we should ask: do we have in the claim a legally significant element outside of this chain? If there is none, the claim is abstract.

This view is putting the emphasis on the claimed subject matter. Activity which is not explicitly claimed does not change a mathematical algorithm into a non-mathematical process. The mere presence of a real-world problem does not suffice to make software patentable. We also need to ask how this problem is solved. Is the real-world solution actually claimed? Or is it information processing that will eventually lead to the solution?

Consider the anti-lock brake system in a car. There is an embedded computer controlling the brakes. The software by itself is abstract. The apparatus formed by loading the software on the embedded computer is also abstract because it is entirely enclosed within the boundaries that delimit the abstract portion of the invention. But if we look at the entire system then the brakes are outside these boundaries. The brake system taken as a whole is not abstract.

This analysis implies that when the real-world problem requires nothing but the production of information from already known information the resulting patent claim is always abstract. Computers work in such manner that software solutions to these problems are always abstract. For example consider a database of scientific research on the chemistry of rubber with a search function to help an engineer locate a scientific article. We may say this is a real-world problem in the field of chemical engineering. The computer will never use the real-world meaning of the database content because it can't. It is all pure database algorithms that rely only on the raw bits. Like the formula to compute the circumference of a bottle, the solution to this database problem is abstract, because the processing of the bits is self-contained.

An Observation On Business Processes

This analysis also brings a partial answer to a question asked by the USPTO in their request for comments.

The decision in Bilski suggested that it might be possible to "defin[e] a narrower category or class of patent applications that claim to instruct how business should be conducted," such that the category itself would be unpatentable as "an attempt to patent abstract ideas." Bilski slip op. at 12. Do any such "categories" exist? If so, how does the category itself represent an "attempt to patent abstract ideas?"

My answer would be this: Any process made entirely of information processing steps with no activity that acts upon the information is non-patentable because it is abstract. Communication of an answer is not enough to make a business process not abstract. A significant physical use of the real-world meaning of the information is required. This is true when all agents executing the process are human beings because then all steps are mental steps. If such a process is adapted to be implemented in whole or in part on computers or computer networks, then it remains non-patentable because no non-abstract element is introduced in the adaptation.

The Limitations of Self-Containment in Identifying Mathematical Algorithms

There is an implicit assumption that is pervasive in the whole article. It is that the meaning of the bits are external to the computer. What if the patent claim doesn't meet this assumption?

Suppose some computer engineer includes in the design of his CPU instructions to perform binary-to-BCD conversions using the Benson algorithm. Is this abstract? If the instructions are implemented in microcode this is software and I suppose the Benson Supreme Court precedent should be applicable. But what if the patent claims it as the making of a better CPU, calling it a method to set the bits to their right value in the registers? Can we say that the setting of the bits is a physical activity that acts on the bits instead of merely referring to their interpretation?

This question speaks directly to the issue that was the topic of the previous answer to the USPTO, Physical Aspects of Mathematics. Mathematical activity needs a physical representation in order to be carried out. Therefore the question as to whether a patent is on an abstract idea can be split into (at least) two separate questions.

  1. Whether the patent is on abstract information about a real-world application or about the real thing.

  2. Whether the patent is on a physical representation of mathematics.

This relates to the two directions of modeling that were discussed in Physical Aspects of Mathematics.

  1. Mathematics is used to provide a model of the physical reality. This is what happens, for example, when we use mathematics to describe the laws of physics.

  2. A physical device of process is used to carry out an abstract mathematical operation. This is what happens, for example, when we use a calculator to carry out a calculation.

Self-containment is good at identifying the first type of issues. It is effective at telling whether the patent is on an abstract computation on abstract bits used to represent the external world as opposed to the real thing. This approach has the merit to work without having to get into the complexities of defining and identifying the notion of mathematical algorithm.

Self-containment by itself does not suffice to answer the second type of issues because they require recognizing when a mathematical calculation is done by physical means. This is not an inquiry of whether the actual processing is done at a level of abstraction different from the real-world application.


References Cases

Bilski v. Kappos The Supreme Court decision

Diamond v. Diehr, 450 U.S. 175, 182 (1981)

Gottschalk v. Benson, 409 U.S. 63, 71-72 (1972)

In re Alappat, U.S. Court of Appeals Federal Circuit, 33 F.3d 1526 July 29, 1994

In re Bilski the Court of Appeals for the Federal Circuit decision

In re Gulak, 703 F.2d 1381

Parker v. Flook 437 U.S. 584 (1978)

Footnotes


1 This bit level degree of abstraction may also be independent from actual hardware references. It is frequent that the computer is emulated in software. In such case the instructions are executed on foreign hardware that has no native ability to execute them. The universe of reference that defines the software is not the actual hardware. It is its abstract specifications.

2 Perhaps someone with more imagination or a better understanding of climatology than I can find a way to reuse these mathematical equations. This is a feature of defining “abstract” as the inability to reuse. This is a definition that depends on the amount of knowledge and ability to imagine of human beings. It is always possible that some people will find creative reuse where others can't. This information may be present in descriptions of the algorithm like patent claims. But when writing the actual code this information does not translate into computer instructions. It has only documentation value. The instructions only depend on the abstract geometric properties of the antenna and not on the fact that it is an antenna.

3 This information may be present in descriptions of the algorithm like patent claims. But when writing the actual code this information does not translate into computer instructions. It has only documentation value. The instructions only depend on the abstract geometric properties of the antenna and not on the fact that it is an antenna.

4 In engineering the definition of symbols is recognizable physical states that can be used to represent information. A sound emitted vs no sound emitted is a pair of recognizable physical states. This is a pair of symbols able to convey a Yes/No type of information: whether or not something needs human attention.

5 This is applicable to analog information such as sound and video. When the inputs and outputs of a computer do nothing but a conversion between the analog and digital domains the boundaries of the abstract part of the process may extend across the analog portion until the points where the information is initially captured or eventually used. This is because even in analog format the information is self-contained, independent from the substrate carrier. I believe this too fits well with the printed matter doctrine because it is my understanding that this doctrine is applicable to analog information. For example the TV show that is aired is not patentable subject matter while equipment using radio-frequencies for television broadcasting is patentable.


  


Why Software is Abstract, by PolR | 557 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread
Authored by: bugstomper on Thursday, October 07 2010 @ 03:44 AM EDT
Please put a summary error->correction or s/error/correction/ in the Title
box for everyone's convenience scanning the thread

[ Reply to This | # ]

Off Topic threads
Authored by: bugstomper on Thursday, October 07 2010 @ 03:45 AM EDT
Please be off topic here. Use HTML mode to make your links clickable.

[ Reply to This | # ]

News Picks Thread
Authored by: bugstomper on Thursday, October 07 2010 @ 03:47 AM EDT
Pick your news here. Please put the title of the News Pick in the Title box and
include an HTML link to the article for when the article scrolls off the News
Picks column.

[ Reply to This | # ]

COMES goes here
Authored by: bugstomper on Thursday, October 07 2010 @ 03:49 AM EDT
Keep those Comes transcripts coming. Post using HTML markup posted as Plain Old
Text to make it easy for PJ to copy and paste.

[ Reply to This | # ]

Minor Quibble
Authored by: DaveJakeman on Thursday, October 07 2010 @ 04:43 AM EDT
This is all the meaning computers can understand.
The information the program is able to understand is defined in terms of the capabilities of the programming language.
Computers and computer programs don't understand; they simply execute. It is humans that do the understanding. By its very definition, understanding is abstract (meaning it occurs in the mind) and is not part of the computer or computer program.

It's easy to think in terms of computers "understanding things", but they don't. They just do what they are told and that's it. It's possible to write programs that give the impression the computer or computer program understands (Adventure anyone?), but the computer still just does what it is told.

[ Reply to This | # ]

Better Example?
Authored by: DaveJakeman on Thursday, October 07 2010 @ 04:48 AM EDT
2 A physical device of process is used to carry out an abstract mathematical operation. This is what happens, for example, when we use a calculator to carry out a calculation.
Would the following be a better example?
2 A physical device of process is used to carry out an abstract mathematical operation. This is what happens, for example, if we used a slide rule to carry out a calculation.
(Avoids possible confusion over what the abstract part of the operation is.)

[ Reply to This | # ]

Nice Article
Authored by: DaveJakeman on Thursday, October 07 2010 @ 04:50 AM EDT
Presents a very clear and easy-to-understand view of why software is abstract.
No mind-bending required.

[ Reply to This | # ]

Why Software is Abstract, by PolR
Authored by: Anonymous on Thursday, October 07 2010 @ 05:10 AM EDT
I feel there is something missing from your analysis. You correctly note that a
particular algorithm can be
applied in many situations, however what you fail to address (unless I've missed
it) is that a key step in software
is the abstraction of a physical problem to an abstract concept that can be
manipulated by mathematics. I.e. a
piece of software to design parabolic antennae is not simply an algorithm to
define the shape of the antennae but
also contains the knowledge that the antennae can be abstracted to the
mathematical formula. As such the use of a
particular algorithm in a new situation could indeed be novel and therefore
potentially patentable as what is
inventive is the recognition of the underlying mathematical truth for a given
situation.

To put it another way, it could be argued that advances are made in the physical
arts when a new way is found to
map the physical world to a mathematical abstraction. If as a virtue of this
mapping a new process is found that
is patentable why does it matter if it is implemented in software? The advance
is the new mapping to mathematics.
Now is that mapping abstract? Not really as it relies on the physical world as
one "end" of the mapping.

So what if there isn't a new mapping involved? In that case is there a novel
application of mathematics to an
existing abstraction? Is that abstract? Yes, as it is a different use of
mathematics. Patentable? I simply
haven't absorbed the rulings enough to tell.


NB I really should create an account one day...

[ Reply to This | # ]

curing rubber
Authored by: Anonymous on Thursday, October 07 2010 @ 05:14 AM EDT
Would not the mathematical formula that describes aspects of the process for
curing rubber only be part of a patent if actually used for curing rubber?
So you can use the formula and print an answer on any computer, but unless you
use it to make a machine that actually cures rubber, or if you use it to cure
rubber by hand, you do not infringe the patent.
So the process would have to be patentable wether it uses the mathematical
algorithm or not.

[ Reply to This | # ]

My, writing this on a smart phone doesnt make it smarter. The underlying hardware doesnt matter
Authored by: Anonymous on Thursday, October 07 2010 @ 05:22 AM EDT
Android is here.

[ Reply to This | # ]

Why Ideas are Patentable.
Authored by: Ian Al on Thursday, October 07 2010 @ 06:58 AM EDT
I want to explore the principle that Abstraction Is Self-Containment and use it
to show that transforming information within a computer file makes no real world
changes and is, therefore, the physical embodiment of self-contained and thus
abstract ideas. If you want mathematical proof, then you must revisit POiR's two
stories.

As usual, I whine on interminably and so my ramblings are given in a sibling
post. Just to keep you interested, it shows that you cannot patent software
processes.

---
Regards
Ian Al
SCOG, what ever happened to them? Whatever, it was less than they deserve.

[ Reply to This | # ]

Why Software is Abstract, by PolR
Authored by: Anonymous on Thursday, October 07 2010 @ 07:11 AM EDT
Here is a two-step process to compute the circumference of a circle with a precision of four decimal places:
  1. Measure the diameter of the circle with a measuring instrument precise to four decimal places,
  2. Multiply the diameter by 3.1416. The result is the circumference.

This is abstract because there is no correlation with the real world at all.

I'm pretty sure that it was discovered by practical experiment that the circumference of a round thing was a little over 3 times its diameter long before it was proved analytically to be πd. Fortunately, you can't patent the laws of nature any more than you can patent the laws of mathematics, so that doesn't make the process patentable.

Also, applying abstract logic to the problem would only tell you that the answer was πd and that you could never actually write it accurately as a number. You've "correlated" the process with the real world by observing that 4 decimal places is sufficient accuracy for your purposes. Fortunately, there's plenty of prior art on that "innovative step" (although, sadly, the USPTO would probably give you a patent for measuring circles to appropriate accuracy on a mobile phone :-) )

Software is mathematics and this makes it abstract, but I don't use or rely on this fact in making the arguments in this article.

I like what you're trying to do - but (even if your assertion above is logically correct) you've still used the m-word in every other paragraph and relied a lot on overtly mathematical examples. Perhaps if you'd focussed more on abstract procedures for sorting, searching or recommending books, rather than calculating the shape of the curve? Logically, it makes no difference, but strategically it makes the argument more convincing to non-mathematicians if you talk about processes which can be visualised without thinking about numbers or geometry.

[ Reply to This | # ]

What if you do the calculations in your head?
Authored by: Anonymous on Thursday, October 07 2010 @ 07:17 AM EDT
If a patent for a novel process of X describes the use of a
particular mathematical formula using a device, would you
infringe if you perform the same calculation in your head or
by hand?

[ Reply to This | # ]

Using the KISS principle: Take it as a hole.[sic]
Authored by: Anonymous on Thursday, October 07 2010 @ 07:32 AM EDT

For me there's too many math comparisons.
The problem is being over analyzed.

Let's take punched tape.

You can have a patent on the device that sticks some pins through the holes (if
there are any) and generates a signal

You can have a patent on the new improved whizzy super upgraded faster device
that uses light instead of pins to generate the signal.

You can have a patent on the device that does something with that signal.

You can have a patent on the device that makes the holes in the tape.

You can have a patent on the whatsit that spools the tape.

You can even have a patent on special types of tape.

You cannot have a patent on the arrangement of holes in the tape, any more than
you can have a patent on the arrangement of dots on a musical score.

Too much of a leap?

Have a look at the history of the Jacquard Loom. Yes, you can have a patent on
the device, but not on the holes in the card.

Freedictionary.com gives this definition of "hole"

9. Physics A vacant position in a crystal left by the absence of an electron,
especially a position in a semiconductor that acts as a carrier of positive
electric charge

thus....A vacant place defined by an absence

something empty as a result of something not there.

How mush more "abstract" does it need to be in legalese, mathematics
or any other language.

Despite the complexity, miniaturisation, improved functionality,storage mediums,
additional peripherals, complex input and output devices, GUIs, touch screens,
parallelism, connectivity, programming languages and a whole bunch more,
software is still the holes in the punched tape.


Discuss.

[ Reply to This | # ]

Why Software is Abstract, by PolR
Authored by: Anonymous on Thursday, October 07 2010 @ 08:23 AM EDT
If all "software is mathematics" please educate us all as to the
mathematics of something commonplace: creating a variable sized pop-up window
(MessageBoxW() in Windows), coupled with the user pushing the "ok"
button. Are there algorithms involved? Yes. Is this abstract? Probably. But
so is cursive script. Do I think that the original concept of having a GUI was
patentable? Yes. Remember that user interfaces (and some hardware) is
non-deterministic. Partly because people are non-deterministic, and have
non-deterministic response rates and unpredictable failure rates. Mathematics
is inherently deterministic. So claiming all software is mathematics is overly
simplistic.

[ Reply to This | # ]

Self-containment and Benson
Authored by: Ian Al on Thursday, October 07 2010 @ 09:33 AM EDT
Benson is self-contained and demonstrates an abstract idea as defined by the
Bilski opinion.

In Bilski the Supremes highlight claims 1 and 4 which are a written description
of how hedging is done (1) and the conversion of that to mathematics (4). They
called this an attempt to patent an abstract idea.

This is because neither the exercise of the ideas in (1) nor the exercise of the
math in (4) result in a real world outcome as a result of running the process.
It can be clearly seen that the ideas in (1) and the math in (4) are
self-contained.

If there had been a link between, say, doing the math and ending up with more
profitable and less risky hedged deals then it would not have been
self-contained and might have been upheld.

In Benson, the algorithm was self-contained. There were no process steps that
made an external or real world change. Thus the patent would have been on a
self-contained, algorithmic process expressed as a computer program and this
meets the Bilski definition of an abstract idea.

For a general purpose computer there is no escaping this situation. If the
conversion had been enshrined in a processor electronics it would no longer be a
process patent but a machine patent. Maths can only be used as a tool to make
the machine. The patentable invention can only be defined by the structure of
the components. Claiming a structure of components that executed an algorithm
fails in the same way as Alappat.

I think the rule is rock solid. If no real world change comes from the process
step or if the real world change of the whole process is not altered by the
process step then the process step is self-contained and is, by definition
(Bilski), an abstract idea.

---
Regards
Ian Al
SCOG, what ever happened to them? Whatever, it was less than they deserve.

[ Reply to This | # ]

  • Bingo. - Authored by: jesse on Thursday, October 07 2010 @ 10:43 AM EDT
    • Bingo. - Authored by: PolR on Thursday, October 07 2010 @ 11:23 AM EDT
      • How about this then - Authored by: jesse on Thursday, October 07 2010 @ 11:48 AM EDT
      • Bingo. - Authored by: Wol on Thursday, October 07 2010 @ 01:17 PM EDT
      • Bingo. - Authored by: Ian Al on Thursday, October 07 2010 @ 03:58 PM EDT
        • Bingo. - Authored by: PolR on Thursday, October 07 2010 @ 05:27 PM EDT
          • Bingo. - Authored by: Ian Al on Friday, October 08 2010 @ 06:59 AM EDT
      • Bingo. - Authored by: Anonymous on Friday, October 15 2010 @ 08:13 PM EDT
Why Software is Abstract, by PolR
Authored by: Anonymous on Thursday, October 07 2010 @ 11:27 AM EDT
Consider a thermostat that controls my central heating.

The one in my house currently consists of a bimetallic strip and spring
arrangement that switches an electrical switch on or off depending on the
temperature. Clearly a lump of patentable hardware.

Now I replace this with a micro controller that can read the temperature using a
thermocouple and a bit of A/D hardware, and can toggle an output on or off
depending on some preset threshold. This device contains a program. This is
clearly still patentable.

Some clever chappy thinks of a brand-new way of using this piece of hardware by
reprogramming it. Is this new device patentable?

[ Reply to This | # ]

Because you can
Authored by: Anonymous on Thursday, October 07 2010 @ 11:39 AM EDT
First impression after reading the article: software is "abstract",
because it is more useful when it is "abstract". Software that is not
"abstract", can usually easily be made "abstract".

It doesn't take much to write some program that does a particular thing on a
particular machine. As time moves on and the machine doesn't work anymore it
will occur to change the program to work on the new machine as well.

Of course, compilers help making software abstract, after all, they produce
machine code that is supposed to correspond to the programs they compile, on any
target machine that they support.

At the same time, computers as different as they are, do have commonalities so
that changes that the compiler cannot perform, can sometimes be easily applied
to the original program. See for example:
http://www.justlinux.com/forum/showthread.php?t=152322

Because of this, I got the impression the article went off in the wrong
direction.

[ Reply to This | # ]

'Abstract' is not correct for formulas.
Authored by: Anonymous on Thursday, October 07 2010 @ 11:44 AM EDT
Your definition of abstract is missing! Are you refering to just to numerical operations or more general operation on text, number etc?

In your example, you are using a formula without stating it and you are using it incorrectly because you are missing the units!

Consider a calculation written down on paper. Let's say you have 128 boxes each of boxes each containing 48 cans of peas. How many cans do you have? It is 128 × 48 = 6144 cans.

This is actually 128 boxes of pea cans * 48 peas cans per box = 144 pea cans.

This is an arithmetical computation. What is the difference between this and computing 128 × 48 in the abstract without referring to boxes, cans, and peas? Does the computation change if it is cans of mushrooms instead?
If you use the formula correctly then obviously, the answer is yes! But not if used incorrectly as units matter:
128 boxes of pea cans* 48 mushroom cans per box is not 144 mushroom cans.

So you can not be abstract with this example. It is worse when converting say mass into energy such as when if the mass is in tons or kgs). Furthermore, computer have their own rules so example 22 divided by 7 is an approximation for pi. But is it 3 or 3.14285714285714 or something else? Both are correct depending on whether or not you use a integer representation or a 64-bit floating point representation or some other precision.

The difference is purely semantic. The computation is not changed.

These are not true because all your education has taught you to automatically convert the problems into specific formulas. That is, you know that you have to multiple 128 by 48 rather than divide 128 by 48. Thus, the potential patent not that actually calculation but whether you have to multiple or add or subtract or divide or do some other operation on that specific combination.

While there is simple mathematics involved, there is critical non-abstractable process to get the correct inputs and perform the correct calculation.Thus, my quandary, at some point an idea eventually becomes an very specific set of operations that are patentable. Yet those operations are usually specific to say an application or operating system as just how a number is stored can vary.

[ Reply to This | # ]

Expert review
Authored by: Anonymous on Thursday, October 07 2010 @ 01:49 PM EDT
Thanks for the great article! It would be interesting to invite Mr. Mitchelmore
and Mr. White to review this and comment, since their work was pivotal in
writing this article.

[ Reply to This | # ]

Why Software is Abstract - a straightforward answer
Authored by: Anonymous on Thursday, October 07 2010 @ 02:49 PM EDT
Software is abstract because by looking at the code it is
not evident without a huge effort in reverse engineering, to
figure out what it is that is patentable in it, be that
methods, algorithms, data structures etc. - whatever it is
that is claimed to be patentable (which in most cases would
take a much greater amount of effort than the patenter put
into coming up with the idea in the first place). I would
challenge anybody who argues otherwise.

My response to anybody arguing otherwise would be to give a
piece of source code to a patent office patent assessor, and
ask him/her to write down all the patentable material in it
that he/she would check in order to check if it contained
prior art that may be used to challenge other patent
applications. I can guarantee that the USPTO patent examiner
would come up with a blank every time.

The problem with the abstractness of software patents is
even worse than that, because most code and therefore most
prior art is proprietary and therefore secret or at least
obfuscated further by translating it into machine code. So
the highly abstract code that the patent examiner is unable
to fathom is even more abstract when you consider that most
of the prior art that is present is secret, and therefore
unsearchable.

To summarize, software is abstract because the things that
are claimed to be patentable and for which patents are being
granted cannot be ascertained without extensive reverse
engineering of the concepts from the code. As a result, the
USPTO hasn't got a hope in hell of checking for prior art in
the existing art - the mass of code already produced, and
the USPTO is not therefore doing any sensible check for
prior art before granting patents. Indeed the only check at
all that is being carried out by the USPTO is to look at
software patents which are granted, which represent only a
tiny subset of the known art since it is only used for
patent trolling, patent defence, and exclusion of
competition. [Nobody in industry files a patent first and
then uses that to develop software. Instead software is
developed without looking or thinking about patents, and in
a separate process unconnected with development of software,
patent lawyers draw up patents that can be used against
competitors or to extort from others who have independently
come up with the same (and by the fact, obvious) idea].

I believe this is what was meant by "abstract" in patent
law, and a very sensible measure it was. Indeed it is the
only sensible meaning for the term "abstract" in the context
of patents. Basically it means you cannot patent something
that does not allow prior art to be readily checked because
it is too "abstract".

Dictionary.com also agrees by the way

ab·stract
–adjective
1. thought of apart from concrete realities, specific
objects, or actual instances: an abstract idea.
2. expressing a quality or characteristic apart from any
specific object or instance, as justice, poverty, and
speed.
3. theoretical; not applied or practical: abstract science.
4. difficult to understand; abstruse: abstract speculations.

[ Reply to This | # ]

Programs and data are numbers and why it matters
Authored by: Anonymous on Thursday, October 07 2010 @ 03:11 PM EDT
All computer data are just numbers, and binary numbers at that. Try stuffing a
real orange or apple into your computer. You can stuff counts of apples or
oranges into a computer, or pictures of them, or diagrams of their internal
structure, or their chemical compositions, or models of how they deform when
shot with a high powered rifle. All those inputs have to be expressed in binary
numbers, though, because that is all computers can work with. Mouse movements
are numbers relative to the upper left corner of the screen. Mouse clicks and
keyboard presses are expressed as numbers. We attach some meaning to those
numbers but to the computer they are simply more yummy, crunchable numbers to
process.

In fact, a computer program itself is simply a large binary number, as far as
the computer is concerned. How large? Big. Really big. Lets look at why that
is, and what it means.

A program that is 128 bytes long has 1024 bits and it is considered very small.
It is a binary number that is 1024 digits long and it can represent every base
10 value from 0 to
179,769,313,486,231,590,772,930,519,078,902,473,361,797,697,894,230,657,273,430,
081,157,732,675,805,500,963,132,708,477,322,407,536,021,120,113,879,871,393,357,
658,789,768,814,416,622,492,847,430,639,474,124,377,767,893,424,865,485,276,302,
219,601,246,094,119,453,082,952,085,005,768,838,150,682,342,462,881,473,913,110,
540,827,237,163,350,510,684,586,298,239,947,245,938,479,716,304,835,356,329,624,
224,137,216. And that is a small program. Many real-world programs are
hundreds of millions of binary digits long (or thousands of times that size). A
program that size could be one of an astronomically immense number of possible
values.

The same scale applies to data too, which is unsurprising because computer
programs themselves are just data as far as the computer is concerned.

(Donald Knuth and some of the other well known computer scientists considered
programming to be very advanced applied mathematics. What I am saying about the
scale of data and programs isn't new by any means.)

So programming is the art of creating just the right number to control the
computer as it processes input (a huge range of possible numbers) to produce
output (another huge range of possible numbers). Notice that all the mouse
clicks, webcam images, key presses, sensor inputs, and so on constitute a single
large number when considered all together. All the output is similarly just a
very large number. That output number may be displayed as windows, images, and
so on. Designers take serious advantage of that characteristic. It isn't a
mere byproduct, it is a fundamental principle that drives many complex
programming systems such as the web server on which you are viewing this page.

So data can be unimaginably large numbers and programs are data so they are
unimaginably large numbers too. Where does that lead us?

As an aside, this reveals the nature of “bugs” in software. If you don't have
exactly the right program (number) to produce the expected output based on the
input, then you need a slightly different program (number), one that generates
the correct output for that input. The problem is that we can't test most
programs against all possible inputs (numbers) for a variety of very practical
reasons, all related to the vastness of the sets of inputs and outputs
(numbers). So we try to choose as many inputs as we can reasonably hope to test
and hope that is mostly sufficient. Lots of hoping going on in the programming
world.

All the difficulties we have with programming computers come back to the fact
that all programs and input/output are enormously large numbers, each having an
astronomical set of possible values.

Oh, yes, sorry, I was going somewhere with this, wasn't I?

Every possible input, output, and program is a number of some length. Those
numbers simply have no intrinsic meaning to the computer. We may use our
knowledge of the problem at hand while we create the program (number), but that
is a strictly human endeavor with no meaning to the computer, even if the
program (number) we generate has embedded in it things that we would recognize,
such as inches or centimeters. Our intent, though, has no meaning to the
computer, only the numbers have meaning.

The size of the numbers we deal with makes computer programming an application
of mathematics bordering on the insane, but in the end it is all about dealing
with many mind boggling large numbers. Indeed the very nature of the word
“computer”, a device that does computations, points to the purely mathematical
nature of these devices. Patent law explicitly says that numbers and
mathematics can't be patented.

Do the math, it isn't that hard to arrive at the correct answer. ;)

[ Reply to This | # ]

Why Software is Abstract, by PolR
Authored by: Imaginos1892 on Thursday, October 07 2010 @ 06:01 PM EDT
You need to carry your argument one step further:

Even the bits inside the computer are abstractions! So a computer program consists of a series of
abstract operations performed on a bunch of abstract entities. We call them "bits" for convenience.
Where are the bits? Open up your computer and show me a bit.

The bits in your computer are implemented as tiny electrical circuits composed of monocrystalline
silicon with traces of other elements infused into it in microscopic patterns. This forms specific
arrangements of atoms which conduct electrical currents in predictable ways. These arrangements of
atoms are not changed by the currents passing through them (unless their Absolute Maximum Limits
are exceeded - then they emit Mysterious Blue Smoke, turn crispy, and cease to do anything at all).
They form the substrate, or medium, within which the abstractions we refer to as "bits" are expressed.
The circuits are not the bits, and the bits do not modify the circuits. Bits exist only as transient
electrical potentials. Even with the most powerful microscope, you can't tell whether one of those
circuits is expressing "1", or "0", or even if it's powered on.

The collection of circuits we call "CPU" detects the voltage levels present in some of the circuits
designated as "memory" and alters its internal voltages based on them. It then modulates signals
and alters some voltages in another part of the "memory". There is no structural difference between
the circuits it detected the initial voltages from, and the ones where it changed voltages. Indeed,
it is perfectly capable of changing the voltages in the circuits it's supposed to be using as a
reference, and has no idea that you'd prefer that it didn't do that.

That is what happens inside your computer. Any meaning you may attach to these goings-on is entirely
in your head. You and the programmers may choose to agree that it all represents a different set of
abstractions, but that is irrelevant to the computer's operations.
-----------------------
"Congratulations on our glorious victory! It... was a glorious victory, wasn't it?"
"No, but if we think fast we might live to lie about it!"

[ Reply to This | # ]

Affecting the real world--a question
Authored by: Anonymous on Thursday, October 07 2010 @ 07:34 PM EDT
In light of this discussion, I'm curious. Is device driver software patentable?
Diehr would seem to suggest "yes".

[ Reply to This | # ]

What kind of abstraction does software exhibit? Why does it matter?
Authored by: Anonymous on Thursday, October 07 2010 @ 08:18 PM EDT

I think the parent article somewhat misstates some of the key points which make up the thesis of the work by Mitchelmore and White (M&W). M&W were careful to distinguish between what they called abstract- apart from what they called abstract-general. Mathematics is abstract-apart because it is self-contained and unaffected by outside considerations.

To emphasise the special meaning of abstraction in mathematics, we shall say that mathematical objects are abstract-apart. Their meanings are defined within the world of mathematics, and they exist quite apart from any external reference.

But the M&W also identify another kind of abstraction, based on what they call empirical abstraction. Empirical abstraction is often derived from observations of similarities between real-world observations, which lead to certain recognitions of common underlying structures and the formation of empirical concepts. They quote Skemp as writing:

Abstracting is an activity by which we become aware of similarities ... among our experiences. Classifying means collecting together our experiences on the basis of these similarities. An abstraction is some kind of lasting change, the result of abstracting, which enables us to recognise new experiences as having the similarities of an already formed class. ... To distinguish between abstracting as an activity and abstraction as its end-product, we shall ... call the latter a concept. (p. 21, italics in original)

The important point is that M&W carefully distinguish abstract-apart from abstract-general.

We have already referred to mathematical objects as abstract-apart. To emphasise the distinction between abstraction in mathematics and mathematics learning, we shall call empirical concepts abstract-general: Each concept embodies that which is general to the objects from which the similarity is abstracted.

Another important observation is that new advancements in mathematics, in the abstract-apart context, is defined by a process they call theoretical abstraction.

The formation of new ideas within mathematics is well described by the Schwarz- Hershkowitz-Dreyfus Nested RBC Model of Abstraction. They define abstraction as “an activity of vertically reorganizing previously constructed mathematics into a new mathematical structure” [F121]. New mathematical objects are constructed by “the establishment of connections, such as inventing a mathematical generalization, proof, or a new strategy of solving a problem” [F121]. This abstraction process is quite different from empirical abstraction, and is best described as theoretical abstraction. Sierpinska’s ignoring/highlighting process is another example of theoretical abstraction.

These distinctions between various kinds of abstraction are relevant to this discussion. M&W include a valuable graph in their conclusion that shows the world divided into two blocks, one representing the abstract-apart realm of mathematics and the second representing the experience of the physical and social world. A subset of the mathematical world is labeled "fundamental mathematical objects", while a subset of the physical world is labeled mathematics related concepts. The two subsets are linked by an arrow representing the process of formalization, where empirical concepts are matched with corresponding mathematical objects. Outside of the empirical concepts that are linked with mathematical objects is shown an even larger subset in the physical world that represents other empirical concepts that have not been formalized with mathematics.

So why does this all matter? It means that there are different kinds of abstraction. Mathematical abstraction is only one of them. So when PoIR includes a subtitle that says "Abstraction Is Self-Containment", he is only really correct when talking about the abstract-apartness of mathematics.

In addition, this type of abstraction is almost certainly not the same meaning of abstraction that the courts have intended when they created the exceptions to patentability under section 101. These exceptions are not found in the statutes, but have arisen from precedent-setting rulings made by the courts. The Supreme Court in Diehr said this:

Our conclusion regarding respondents' claims is not altered by the fact that in several steps of the process a mathematical equation and a programmed digital computer are used. This Court has undoubtedly recognized limits to § 101 and every discovery is not embraced within the statutory terms. Excluded from such patent protection are laws of nature, natural phenomena, and abstract ideas. See Parker v. Flook, 437 U. S. 584 (1978); Gottschalk v. Benson, supra, at 67; Funk Bros. Seed Co. v. Kalo Inoculant Co., 333 U. S. 127, 130 (1948). "An idea of itself is not patentable," Rubber-Tip Pencil Co. v. Howard, 20 Wall. 498, 507 (1874). "A principle, in the abstract, is a fundamental truth; an original cause; a motive; these cannot be patented, as no one can claim in either of them an exclusive right." Le Roy v. Tatham, 14 How. 156, 175 (1853). Only last Term, we explained:
"[A] new mineral discovered in the earth or a new plant found in the wild is not patentable subject matter. Likewise, Einstein could not patent his celebrated law that E=mc[2]; nor could Newton have patented the law of gravity. Such discoveries are `manifestations of . . . nature, free to all men and reserved exclusively to none.'" Diamond v. Chakrabarty, 447 U. S., at 309, quoting Funk Bros. Seed Co. v. Kalo Inoculant Co., supra, at 130.

The three exceptions are laws of nature, natural phenomena, and abstract ideas. Exceptions must fall within one of these three categories. They have specifically not excluded all mathematics, so even claiming that all software is math is not sufficient to gain an exception to statutory patentability under Section 101. Mathematics may be excluded only so far as it falls under the category of abstract ideas. What PoIR has cited M&W for is the proposition that mathematics is abstract-apart, something that "exists quite apart from any external reference." This is clearly not the same level of abstraction as found in many software patent claims, since most software claims are grounded in specific external references tied to the real world. So while pure mathematics seems to qualify as a form of abstract- apart abstraction that is exempt from statutory patentability, many software patent claims are not.

That leaves the second form of abstraction discussed by M&W, empirical abstraction, to be considered. M&W showed in their illustration that there are at least two types of empirical abstraction, those that can be formalized with mathematics and those that have not. It might plausibly be argued that empirical abstractions that can also be formalized in abstract-apart mathematical terms belong under the umbrella of abstract ideas that should be exempted for patentability. That still leaves a large number of empirical abstractions that have not been formalized in mathematics but which people attempt to employ in real-world applications. These might include solutions to problems where finding optimum results cannot be done deterministically and heuristics must be employed, where outcomes are probabilistic or are the result of chaotic processes. These kinds of problems often require solutions where mathematical formulations are inadequate, and empirically based approaches are required.

This empirical-driven approach to deriving solutions is precisely the act of invention that the patent system is designed to protect. This aligns with the desire by the courts that patents not be granted for inventions that foreclose all other alternatives because the patent preempts a fundamental principle. Such patents could easily be seen to retard progress. However, patents for inventions that claimed only to cover a specific solution in a space of many possible solutions derived from empirical processes would not necessarily retard progress, but could in fact stimulate others to continue the search for even better solutions.

The article by M&W shows that it is important to not just question whether software patent claims are abstract, but also what kind of abstraction is being contemplated and whether it is the kind of abstraction that the courts have decided should be exempt from patentability.

--bystander1313

[ Reply to This | # ]

Even Easier - A Universal Turing Machine...
Authored by: Anonymous on Thursday, October 07 2010 @ 08:31 PM EDT
... is computationally as powerful as any modern computer
running software (Church-Turing Thesis) and a UTM can be shown
as an abstraction with any number of physical implementations,
e.g. a UTM can be modeled by a person placing rocks in
railroad squares (Computability and Logic - George Boolos).

[ Reply to This | # ]

Metamathematics?
Authored by: halfhuman on Friday, October 08 2010 @ 01:13 AM EDT
I have yet to read the article thoroughly, and I note the interesting
qualification referring to M+W's distinction between `abstract-apart' and
`abstract-general' but i want to throw in what may be an important point.

`self-contained' can never be an adequate definition of mathematics, firstly for
the obvious reason that in fact the practice of mathematics is done by in the
real world by real persons (and possibly by machines, which is the thorny issue
here), secondly for the more subtle reasons involved in the long-standing
debate in philosophy of mathematics on platonism. Are mathematical objects
entirely and completely ideal? if so, how can they possibly interact with the
real world, in particular, how can us gross real people grasp ideal objects with
our wet brains? But if not ideal, how can mathematical objects provide the basis
for the absolute and indubitable proofs that mathematicians claim? (Not that
they claim all proofs, but i suggest all mathematicians claim some proofs as
absolute).

Me, I don't think maths is ideal so I think the issue doesn't arise. PoIR, I
think, avoids the issue by taking maths as something rather narrower than usual.
For most people, mathematicians included, the usual meaning is across all orders
of logic and reference. However, if i am not mistaken, PoIR, invaluably careful
as always, uses a definition that steers clear of many pitfalls.

In particular, s/he takes as read that we need not enquire how this
self-contained world comes about. Invented or discovered? Created by humans or
pre-existent? Are sets or categories the true basis of mathematics? Irrelevant!
All we want is a simple basis for the abstractions of mathematics, or at least,
for all those abstractions that could possibly be relevant to software.

I hope I'm right!

However, the subtlety of saying: "For this argument, please take a narrow
view of mathematics, one that is just wide enough to furnish an explanation of
why computation is an abstract process. It is enough just to understand that, so
ignore all the issues about the nature of abstract objects, the mathematical
basis of physics, the problems of self-reference, and let's proceed." Might
be worth spelling it out.

[ Reply to This | # ]

I still think software is like a music composition
Authored by: alisonken1 on Friday, October 08 2010 @ 02:36 AM EDT

A composer (programmer) writes music notations (software).
A musician (compiler) interprets the notations (software).
An instrument (computer) produces the results (executes).

So far, only the musical instrument (computer) is patentable.


---
- Ken -
import std_disclaimer.py
Registered Linux user^W^WJohn Doe #296561
Slackin' since 1993
http://www.slackware.com

[ Reply to This | # ]

Ah, the missing link!
Authored by: Ian Al on Friday, October 08 2010 @ 06:02 AM EDT
Following the ruling of the Supreme Court in Bilski, the USPTO asked, in substance, how to tell an abstract idea from an application of the idea. In this article I propose an answer to the question of what makes software abstract.
I follow the threads of your argument fairly well and I don't see anything that strikes me as hard to accept. However, my irritating boss used to demand of me 'How does that pass the so what test?'. My next boss was even more irritating. When I had summarised my inescapable logic he would follow with the phrase 'Which means that?'.

It strikes me that 'software is abstract' is true, but is not an answer to 'how do you tell an abstract idea from an application of the idea?'. Not as a self-contained statement it isn't!

Looking at it from the judges viewpoint, an abstract idea can be changed to a non-abstract idea (when applied to a process or method) both by means of writing the process/method steps on a piece of paper and actioning them or by means of writing software such that it follows the process steps and automatically actions them without human intervention. Software makes computers work, ergo software that actions process steps is not by definition (as given by Bilski) an abstract idea.

All of your arguments refine the separation of information-processing software or processes implementing a Bilski abstract idea and software or processes implementing an idea made into statutory subject matter. The comment I made in the members-only predecessor still holds. Not all patentable processes are information processing processes. Some involve stirring a vat of bubbling natural rubber with a big stick.

You frazzle our brains by correctly pointing out that even the stirring of the rubber can me modelled mathematically and that the math can be usefully done with a computer with the added advantage of colourful and graphical results. The math works as an information flow and processing task even though the actual patented idea does not.

In a legal context, the statement 'software is abstract' does not pass the 'so what' test in the same way that 'ideas are abstract' also fails. If an idea is applied in a way which passes the legal rules of a patentable process or method then it can get a patent, ergo if software is applied in a way which passes the legal rules of a patentable process or method then it can get a patent.

We claim that the essence of abstraction in mathematics is that mathematics is self-contained: An abstract mathematical object takes its meaning only from the system within which it is defined.
I'm glad you put this first as I think it is key. I would suggest that it needs to be expanded somewhat in the following way.
In the Bilski opinion we find the same principle extended to the analysis of process patent claims. They found, in effect, that claims 1. and 4. were self-contained. There were no process steps or methods that took those claims and actioned a real world change. They were self-contained ideas that, when followed, merely communicated information on the idea of hedging.
Flook is another example of a self-contained idea that merely communicated an alarm indication. 'Peas' is a practical example of a self-contained process (a mathematical one, in this case) which is modelled with real world elements.

Benson is an example of the attempt to patent a self-contained program that did not even communicate information. It is just like the 'Peas' example except that the result of the math was not communicated by the terms of the patent. If the process in Benson were executed there would be no indication that the process had done anything. The results of the process would have to be inferred by some other feature of the computer. An abstract idea cannot be transformed into a non-abstract idea by using real world elements to model it. Neither can it be so changed by embodying it in a computer program.

A real-world, non-abstract idea does not remain so when modelled by math and/or by computer program. If the math or computer program is self-contained then it is an abstract idea as defined in Bilski. The 'parabolic' example is of a real-world, non-abstract idea (when actioned as an antenna or an audio component), but a model of the idea whether as a computer program or math on a sheet of paper that does not action the idea in the real world (self-contained) is an abstract idea. If running the program actioned the machining of an antenna then the software is no longer self-contained and the whole process is not an abstract idea.

Although the examples given are of information processing, the principle applies to all ideas whether expressed on paper or by computer program.

The legal boundary between abstract and non-abstract is the boundary between informing and actioning. The general test is that self-contained processes and methods that merely inform are abstract ideas. Processes that action an idea are not abstract ideas. Applying that to a computer program, if it is claimed as a process or method and merely informs (See, Flook) then it is self contained and is an abstract idea. If it is a computer program and the whole process actions the idea by means of the computer running the program (with additional, external process steps, if claimed) then it is a non-abstract idea.

I think the link between the arguments you make and the challenge that the courts and the USPTO face needs to be clear rather than implied. Otherwise, they are likely to ask 'So what?'.

---
Regards
Ian Al
SCOG, what ever happened to them? Whatever, it was less than they deserve.

[ Reply to This | # ]

Understanding the difference between syntax and semantics
Authored by: Anonymous on Friday, October 08 2010 @ 08:59 AM EDT

A second major point made by PoIR in his article seems to be the idea that software is unpatentable as an abstraction because the code that runs on a general purpose computer is devoid of much of the context which makes an invention patentable in the first place. This view suffers from a disconnect between what is actually being claimed for patent protection, versus details which are not considered as part of the patent process. In short, PoIR appears to confuse the irrelevant issue of patentability of software syntax versus the relevant issue of patentability of software semantics.

Software claims seldom include any specifications for how computers implement the details of the invention, concentrating instead on what is being done. That means that virtually all issues regarding syntax of an implementation are not relevant. This includes the particular programming language being used, the instruction set architecture of the processor the software might run on, the number of hardware registers in the physical processors, etc. While it may be true that these are abstract, that characteristic is irrelevant in the evaluation of the patentability of most claimed inventions.

It is important to note that software code representations are almost never the subject matter of patent claims. Source code can always be transformed into other forms, including textual forms that are directly runnable through an interpreter or virtual machine, intermediate binary forms that are created by compilers, or even circuits that are synthesized into custom hardware. Just as the code formats can vary, so can the hardware platforms on which the code executes. From the standpoint of patent claim evaluation, it doesn't matter whether the platform is a general-purpose processor or a custom configuration of hardware components. Those are all syntactical details which are unimportant.

PoIR also makes the claim that real-world meaning is irrelevant when considering the patentability of software. I contend just the opposite, that real-world meaning in the form of software semantics is a key factor (that the courts have acknowledged) in determining whether software is statutory or not.

The example given with the two-part test from Ex Parte Gutta is puzzling, because the argument does not easily follow from the example. PoIR says that:

In a scenario where the claimed machine does nothing but execute a computer program, this test depends exclusively on information that is both unused during the actual execution of the program and absent from the machine as it carries out the computation.

This is puzzling because the first rule is intended to prevent patents from being issued under this exact same scenario, where the claimed invention does not use any specific inputs nor produce any specific outputs directed to the claimed field of use. The rule holds that merely stating a field of use is insufficient, if the actual claims do not support how the invention is truly specific to the field. Under this rule, the hypothetical example PoIR gives of a software program for drawing 3d parabolic shapes would not be eligible for a patent by itself in more specific fields of use without limitations in the claims specifying attributes specific to those fields. The rule works to exclude the kind of scenario PoIR claims supports his argument.

PoIR writes about his scenario saying:

The outcome of the test depends on the purpose of the user and not on the technology he is patenting. This outcome may and will vary from user to user.

This is an incorrect reading of the rule. The outcome of the test depends on the limitations of the claims supporting any assertion about the intended field of use. It has nothing to do with an arbitrary purpose of a user of an invention, and everything to do with how the invention performs in its stated field of use. That a component, whether software or not, may be found in a variety of patented and unpatented inventions at the same time is nothing new. A simple gear can have many different uses, some of which may be in the operation of patented inventions. The potential multiplicity of roles does not prohibit the patentability of inventions utilizing that component. The first rule merely ensures that the patent scopes are properly limited to eligible fields of use.

The example cited, giving three alleged instances of patents being issued for different fields of use for the same invention, is unrealistic. It emphasizes the "practical application" aspect of the cited rule, but ignores the equally important second aspect of the rule which requires inventions in different fields of use to show actual significant limitations in their claims to demonstrate that the distinctions between claimed fields of use are real and not merely illusory. The example he cites simply doesn't pass the rule, and patents would not be issued for the three different inventions under the scenario given.

One problem with PoIR's analysis in general is that it overemphasizes one aspect of software, its abstract qualities, while failing to account for its equally important characteristic, how it enables computer-driven applications to affect the world around us. He states:

This indefiniteness is what we get if we ignore the abstraction inherent in software and give undue consideration to the real-world meaning of the bits.

This ignores the lesson given by M&W that tells us one of the great values of abstract-apart mathematics is its ability to enable relatively accurate predictions of real-world conditions, and from those predictions to make better real-world actions.

But calculational facility would be useless if the results did not predict reality. Predictions are successful to the extent that mathematics models appropriate aspects of reality, and whether they are appropriate can be validated by experience. In fact, one can go further and claim that the mathematics we know today has been developed (in preference to any other that might be imaginable) because it does model significant aspects of reality faithfully.

This is possible because the system of mathematics we are most familiar with has been consciously developed to closely align with many observable aspects of reality. Yes, mathematics is abstract, but it is also closely tied with empirical observations of the real world. In the same way, software shares many of the abstract qualities of mathematics, but is even more firmly grounded in the requirements and constraints of performing actions in a physical world. Just as scientists have discovered that many fundamental elements can exhibit a dual nature (such as photons behaving as both waves and particles), so too can software be said to have firm roots in both abstract and physical worlds. This dual nature means that simply claiming that software is abstract is insufficient to justify banning all software from being granted patents, as this would arbitrarily remove a legitimate technological field from patent protection in seeming contradiction to the tenets stated in our Constitution.

--bystander1313

[ Reply to This | # ]

Breaking News: the machine is broken!
Authored by: Ian Al on Saturday, October 09 2010 @ 05:59 AM EDT
The majority opinion in AT&T v. Microsoft has invalidated the AT&T v.
Microsoft majority opinion.

The effect of this is to eliminate software machine patents.

It is a large comment and, this time, I am not so frazzled that I cannot give it
to a child to deliver.

---
Regards
Ian Al
SCOG, what ever happened to them? Whatever, it was less than they deserve.

[ Reply to This | # ]

Educating lawyers and legislators in math
Authored by: reiisi on Saturday, October 09 2010 @ 10:32 PM EDT
Hopefully, I can make a little more sense this time.

Starting with a little motivation, it's always a little surprising to remember
that the old saw about the state that tried to legislate the value of pi to
something a little easier for the children to remember is not just a bit of
USian mythology. The problem with this as a starting point is that the instant
reaction is that math is just numbers, and that's not true, and we aren't
talking about just numbers, of course.

For what it's worth, the latin root of the words, "number", and
"numeral" are the same as the root of the word, "name".

Math is intimately related to human language, or, should we say, Chomsky pointed
out that our language is intimately related to our math, and it's hard to
imagine a functional society in which it would not be so. Maybe impossible.

Math is therefore an intimate part of everything we do, including law.

But it's not just language. One of the more fundamental branches of mathematics
is logic. (And I think the basics of logic should be taught in parallel with the
basics of arithmetic, starting with "true and true" not more than a
day later than we start with "one and one", and continuing in
parallel.)

Law is squishy, as PJ likes to point out, but without being able to handle
logic, lawyers are going to have a really, really hard time applying either the
squishy part or the hard part. Or telling the difference between them.

(One serious problem area is understanding -- and admitting -- the difference
between mathematical logic and rhetorical logic, and talking about the limits of
our understanding that require us to sometimes give the rhetorical logic
priority.)

But the connection between mathematics and law is even deeper. One of the
currently harder branches of math -- harder because we don't treat boolean math
as importantly as arithmetic -- is the mathematics of rules. Definition is math.
Rules are math. The interaction of rules is math.

Law itself is an advanced application of math. The fact that lawyers and
legislators seem unaware of this is one of the points where future history books
will say our society failed. (Or succeeded, if we can defeat the momentum and
correct this now.)

And this is the irony of the patent situation we are in.

The very field of math of which law is an advanced application is the same field
which is being incorrectly invoked in the arguments for making software somehow
patentable.

PoIR has been doing a much better job than I could of exposing the underlying
principles. I assume he is heading the same place as I. What I'm not sure of is
whether it would help to point out the end of the road at this point, but fools
jump in where angels fear to tread, so I will.

Abstract machines have nothing non-mathematical about them. Abstract machines
are collections of definitions and rules and the interactions thereof. (Speaking
a little loosely here, but I think in this context the description is okay.)

Not coincidentally, mathematical languages are also the same, collections of
definitions and rules and the interactions of them.

Programming languages are, by definition, mathematical languages. I don't think
we have any lawyers who will argue with that, although certain large
corporations seem to be doing exactly that in many of the patents they file.

The question that is before the courts now is whether software, which is
constructed of mathematical languages (plural, yes) can be non-abstract enough
to merit patent.

Mathematically, the only thing you can build with a mathematical language, or
even a collection of them, is more mathematical languages.

I find myself hesitating to make the final rhetorical step here. The
consequences of what I'm saying here, and the disaster that looms, not just for
industries, if the courts and legislatures get it wrong, should be obvious.

But if I take that final step here, I'll be labeled a wingnut of the left or
right variety, so I'll leave it implicit.

But that should be the end of the argument.

[ Reply to This | # ]

A Quick and Simple to Understand Rebuttal
Authored by: Anonymous on Monday, October 11 2010 @ 06:53 PM EDT
A database application is software. But is it abstract? No.

A database application takes a series of specific instructions (analogous to a
"Work Instruction" in the ISO world) to do one or more out of a very
limited set of possibilities (four possibilities):
A. Create "Records" by arranging very small physical objects called
atoms into a consistent, pre-determined pattern so as to make the resulting
"Record" easily recoverable (see item B.)
B. Retrieve "Records" by detecting how the very small physical objects
called atoms are arranged on the physical storage medium so as to make it
possible for the data user to determine if and how to modify the retrieved
dataset (see items C and D.)
C. Update "Records" by re-arranging very small physical objects called
atoms into different, yet still pre-determined, patterns according the data
user's desire
D. Delete "Records" by re-arranging very small physical objects called
atoms on the storage medium such that the "Records" are no longer
Retrievable nor editable (steps C. and D.)

In Software Design, the above is described as a "CRUD check" because
when all is said and done, all data operations fall within the CRUD. And every
database application works in exactly the same way - the hardware retrieves the
very physical manifestation of the application (by detecting how the physical
pits and/or electrons are arranged) on the storage media. .

The end result of data operations is that there are very physical changes done
at a very small microscopic scale. They may be minute changes invisible to the
human eye, but they are still concrete changes nonetheless.

So the instructions themselves are ultimately stored in a very concrete (not
abstract) manner and the data itself is stored in a very concrete (not abstract)
manner.

Notice, I didn't use even a single iota of what could be considered mathematical
in nature to post this - not a single digit, or numeral - even for the outline
of the CRUD process.

I know it's hard for some of you to stomach, but if you were taught that all
software is mathematics, you were taught incorrectly. It's high time for such
people to take the tack that Rene Descartes did when he first declared
"Cogito ergo sum".

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