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
The CPU is a concrete invention. | 364 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
The HDL created the CPU? I think not
Authored by: Anonymous on Wednesday, January 09 2013 @ 10:16 AM EST

The software HDL definition of a CPU creates a physical thing in the same way that a software procedural program creates an executable program.
Sorry, I disagree. While you can use the HDL to simulate the CPU, it does not create the physical thing. The processes, such as the ones that create wafer, are responsible for creating the CPU.
[snip] the software HDL that serves as its construction blueprint is the normal means of designing it.
No dispute there - blueprints are used in many fields as a set of instructions to create the physical inventions.
the HDL representation is NOT the CPU and hence not patentable is true - but only in the sense that the machine drawings for an invention are not patented, the patent only applies to the thing that is constructed from the drawings
Bingo!!! We have a winner!!! It's the computer that is patentable not the abstract thing we call software that we use to "instruct" the computer in the form of a pattern of electrical signals!
Asserting that Software is abstract and hence not the means of defining the sorts of inventions that patents should protect is naive when Software is the means of defining all high-density integrated circuits, almost all PCBs, buildings, planes and etcetera.
Now the conflation begins: You're basically stating:
    Since the physical invention is patentable, the blueprint on the physical invention is patentable!
But you've already said "drawings for an invention are not patentable"! You have a conundrum in your logic to resolve. Drawings can not both logically be patentable and not patentable - pick one!

RAS

[ Reply to This | Parent | # ]

Patents vs Copyright
Authored by: Anonymous on Wednesday, January 09 2013 @ 10:22 AM EST

it is not an argument that patent law should never apply to this industry.
We're not saying patents shouldn't apply - depending of course on what you mean by "industry"! If you're talking "computing industry" - absolutely we are not saying patents should not apply. If you are talking "software industry" - absolutely I (and others) are saying patents should not apply.

We keep saying the physical invention (cpu, fpga, computer, monitor, etc) is patentable. We keep saying the abstract (the blueprint) is not patentable!

There is no reason that both forms of protection could not be applied to the same work by the inventor
Actually, there is.
    Copyrights are supposed to protect the specific "expression" of an idea. Releasing the idea itself to the public.
To quote section 102(a) of the Copyright Act:
Copyright protection subsists, in accordance with this title, in original works of authorship fixed in any tangible medium of expression [snip] from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device.
Copyright protects the specific abstract expression!
    Patents are supposed to protect the specific physical implementation of an idea!
And that is where - in my humble opinion - we lost our way. Why "physical implentation"? Because abstract concepts - like communication - are supposed to be excluded.
Software is patentable because, IIRC, the Supremes have ruled that software running on a computer can create a machine for the purposes of section ii above.
In my humble opinion this is because the Supremes haven't quite yet figured out that software never has a physical form and all people are actually patenting are the particular pattern of electrical current flowing through the computer which humans interpret to mean something more then just electrical current.

But that's why this challenge: an attempt to educate through asking a different question.

Specific expression vs specific implementation. If you can patent the abstract expression, why can't you copyright the physical implementation? Copyrights are supposed to apply to the blueprints while patents are supposed to apply to the physical creation!

RAS

[ Reply to This | Parent | # ]

The CPU is a concrete invention.
Authored by: dio gratia on Wednesday, January 09 2013 @ 05:41 PM EST

Quoting you:

Software is patentable because, IIRC, the Supremes have ruled that software running on a computer can create a machine for the purposes of section ii above. It a bit strange to refer to it in this discussion without acknowledging that your interpretation of it does not agree with the authoritative one.
Perhaps you'd like to reference your authoritative case? See As Supreme Court Software Patent Ban Turns 40, It's Time To Stop Ignoring It:
Beginning in 1989, the Federal Circuit began handing down a series of decisions that made it easier to get software patents. By the end of the 1990s, all practical limits to patents on software had been dismantled, sparking the software patent arms race that continues to this day.
It was the CAFC that declared software creates a new machine. It has never been tested at the Supreme Court. This was Gottschalk v. Benson. And the next paragraph:
Yet theoretically, the Supreme Court’s 1972 ruling is still a binding precedent. The Supreme Court re-iterated its rule against patenting software in 1978. The Supreme Court did uphold a patent on a software-controlled rubber-curing machine in 1981, but its ruling emphasized that this was because the patent covered a physical machine that happened to have a software component, rather than claiming a software technique by itself.
This was Diamond v. Diehr. You could note that it's no patentee's interest to appeal an affirmation from the CAFC that there patent is held valid by that court. The CAFC is backing off their position of support, fof Beauregard claims which came about because the then head of the Patent Office withdrew the patent office's printed matter objection allowing patentability of software on a substrate (53 F.3d 1583, 35 U.S.P.Q.2d (BNA) 1383 (Fed. Cir. 1995)). Further the CAFC as noted earlier in this exchange disallows second by disallowing Beauregard claims (Again see Federal Circuit Rules Beauregard Claims are Unpatentable and Cybersource Corp. v. Retail Decisions, Inc., PDF, 129 KB). Also see Digital-Vending Services International, LLC v. The University of Phoenix, Inc. (PDF, 143KB), Disavowal of Claim Scope and Beauregard Method Claims, wherein the important thing being Beauregard claims are method claims (software providing means) putting such patent claims at the mercy of The Four Categories of Statutory Subject Matter (i. Process – an act, or a series of acts or steps. See Gottschalk v. Benson, 409 U.S. 63, 70, 175 USPQ 673, ___ (1972) ("A process is a mode of treatment of certain materials to produce a given result. It is an act, or a series of acts, performed upon the subject-matter to be transformed and reduced to a different state or thing."). Your software as a process needs to treat something material transforming it to a different state or thing. When promoting claims as both process claims and apparatus claims (Beauregard claims) both are now interpreted as process claims. Note this has Supreme Court support dating back over 140 years ( Cochrane v. Deener, 94 U. S. 780, 787-788 (1877)) as noted in Diamond v. Diehr. Something has to be transformed.

Further support for software patents is a CAFC invention, although in Bilski you can find Justice Breyers and Roberts parroting CAFC support in Bilski (for the minority, see Supremes wrestle with business method, software patents, whereupon:

But Justice Breyer objected that this reasoning would undermine the government's goal of limiting business method patents. "All you do is you get somebody who knows computers, and you turn every business patent into a setting of switches on the machine because there are no businesses that don't use those machines."

Justice Roberts asked about another hypothetical software case: whether you could patent the process of using a calculator to compute "the historical averages of oil consumption over a certain period and divide it by 2." Stewart responded by drawing a distinction between a calculator with "preexisting functionality" to "crunch numbers" and a computer that "will be programmed with new software" and "given functionality it didn't have before." We'll let readers judge for themselves whether this distinction makes any sense.

Bilski was narrowed to avoid the issue, something called first principles, which in this case is §101 and statutory patent subject matter along with the judicial exceptions.

The heart of the CAFC support for software making a new machine still requires a machine in the first place, see In Re Alappat (33 F.3d 1526, 31 USPQ2d 1545 (1994). Note there is a distinction you can make between general purpose computers and embedded computing which your CPU programming of an FPGA embraces. It still boils down to the software itself not being protected by patent, and you could note reading up on Bilski that Justice Breyer was arguing against slapping down Bilski because of (as Richard Stallman says) clever patent practitioners simply restating things as new machines without physical change - which doesn't occur on a general purpose computer and in cloud computing the particular machine may not be identifiable.

Personally I find it takes to much effort to try to dissuade you from using self reinforcing argumento. You could note your argument has aligned with mine, you've switched from software having patent protection of itself to new machine.

Your statement:

As I said, abstractions are powerful things. Requiring all patents to be expressed in concrete terms is an interesting, but I fear flawed, way of handicapping patent lawyers.
Smearing the distinction between the name of a process (method) and it's results is the issue. It lends it self to considering abstracts as concrete while software in and of itself isn't concrete, nor is the 'document' being bounced in Apple's '381 patent, comprised solely of transitory signals on a touch screen display.

See Some New Ideas About Law Zechariah Chafee, Jr., Professor of Law at Harvard Law School, delivered before the Indiana State Bar Association at Lake Wawasee, Indiana, July 10, 1936 (PDF, 1.2 MB) at 13:

On the basis of Piaget's Studies in Child Psychology, Mr. Frank gives us other parallels between lawyers and children. Children are egocentric, wishful thinkers, and believe in word magic. The name is the thing, for lawyers as for Plato, who also had a childish mind.

In reality there is no certainty about law, the judges merely decide as they want.

The basic issue is removing whimsey as perpetual support through case law citations and getting back to first principles. Software of itself is not patent subject matter (per se). It can be used as a component to create a new machine when it doesn't conflict with §101 as Justice Breyer pointed out, caused by accepting abstract results (the process of which we call algorithms), also demonstrated by business patents.

BTW, you said:

A software engineering team that is building a flight simulator for windows will not apply the same level of testing as a software team that is developing the software for micro-controllers in a fighter jet. In particular, mathematical models of software correctness were applied to the avionics field a long time ago... This seems to be another way in which HDL design of digital circuits is analogous to the development of procedural software to run on computers.
I've worked in both fields (Silicon Graphics and Loral Rolm). VHDL for instance is used to support formal proofs of surety, though there are likely limits on the language constructs used. We generally avoid formal proofs whenever possible as being too expensive, counting on equivalence instead - using agreed upon results as proof. The practice can avoid billions of dollars in cost for instance when implementing replacements for obsolete computers used in the command and control of nuclear weapons. Now done on PC's by the way, the camel's nose being described as accepting equivalence to the discrete event level for the CPU to known behaviors captured from a certified machine through 100% coverage diagnostics. Once we can certify the results by passing the diagnostics (test vectors and results) we can prove equivalence with a virtual machine, too. Now the question is, do those PCs require ECC memory? What about host operating system issues conflicting with accurate execution of the virtual machine?

An HDL description is a program that runs on a virtual machine (a simulator), or from time to time specialized hardware as a particular machine. It's software and when combined with a virtual machine doesn't result in something patentable lacking transformation of something physical, which can be accomplished when embedded in an FPGA that transforms something physical or creates an effect necessary to a process. These things don't occur in a simulation.

Your HDL description is translated to a physical layer description, which in the case of an FPGA is typically a list of switch settings and look up table contents. There are two classes of FPGA devices, volatile and non-volatile, the distinction being whether or not they need to be reconfigured after power has been removed and reapplied. Some of those switch settings apply signals to and from particular device pins allowing real world effect, which could be simulated. There is a requirement the HDL behavior or structural simulation match the physical implementation (the programmed FPGA) tested through equivalence.

Conveying the analogy to software, a simulation would be what happens on a general purpose computer, where no specific I/O provides unique transformation causing real world effect, versus embedded computing applications when your say programmed FPGA is for instance a vocoder, where it is used to remove redundancy in speech communications.

The problem arises that general purpose computers also routinely contain the I/O hardware to perform identically. The question then arises as to how many particular machines can be present in the same CPU of the general purpose computer at the same time? After all there's something like Skype, Google's Voice and Video Chat, Apple's iChat, ... These all perform both voice and video compression and decompression simultaneously through preemptive multitasking, general purpose computers also typically supporting video cameras. When is a computer a particular enough machine? Accepting multitasking it to accept they are virtual machines and you are actually again dealing with processes in the manner of Cybersource v. Retail Decisions. General purpose computers as particular machines is bound to fall sooner or latter. It's likely you FPGA as a CPU won't unless we see programmed hardware strongly embrace virtual hardware in the manner of reconfigurable computing allowing multitasking.

[ Reply to This | Parent | # ]

But software per se isn't a concrete invention.
Authored by: dio gratia on Wednesday, January 09 2013 @ 05:52 PM EST
You said:
Patents are a device constructed to reduce the need for trade-secrets; as trade secrets do not efficiently contribute to the benefit of society as a whole. The need for trade-secrets to protect HDL software is a strong argument that patent law is incorrectly formulated for this industry; it is not an argument that patent law should never apply to this industry.
Consider IEEE 1076-2008, 24.1 Protect tool directives:
Protect tool directives14 allow exchange of VHDL descriptions in which portions are encrypted. This allows an author of a VHDL description to provide the description to one or more users in such a way that the users’ tools can process the description, but the text of the description is not disclosed to the users.
If a VHDL description (software) could be protected in and of itself by patent there would be no requirement to treat it as a trade secret.

The issue isn't the lack of patent protection for abstracts, rather that software is abstract. Circular argument doesn't aid your case.

[ Reply to This | Parent | # ]

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 )