Bilski has two “prongs.” One is the “general purpose computer” prong. The other is the “tied to process or transformation” prong. Both need a bit of strengthening.

In respect of the “general purpose computer” prong, it is reasonable to insist that even if the patent recites dedicated hardware for processing information, the patentee should have the burden of showing that his algorithm is “computationally infeasible” on a general purpose computer. A working definition might be a computational complexity of, say, ten to the hundredth power. In other words, a circuit built out of quantum qubit registers would be eligible for a patent, but an ordinary circuit which processed audio (say, 50 Khertz) or video (say 6 Mhertz) would not be. I don’t think there would be very many intermediate cases. Problems either “go to infinity” or they don’t, as the case may be.

I gather that a lot of the MPEG patents recite low-speed dedicated computing apparatus, which may have made economic sense twenty years ago, but which no longer makes sense.

In respect of the “tied to process or transformation” prong, the patent should either 1) recite novel and non-obvious “tied hardware,” or 2) some novel and non-obvious method of connecting the hardware to a computer, or 3) cause the hardware to act in some novel and non-obvious fashion for some purpose other than conveying information to a human user.

For example, if Lonnie E. Holder wants to build a computer-controlled tractor transmission which behaves in different ways according to how muddy the ground is, according to directions from a computer program, the third clause would put the system within the scope of patentability, subject to novelty and nonobviousness. However, it should not be possible to patent the idea of plugging a standard radio or tape recorder’s speaker output into a desktop computer’s stereo input or microphone ports, using a standard cable, and running some possibly novel software which does something with the resulting data.

Similarly, the USB specification (class library) for video covers all the usual controls of a VCR or video camera. One might, for example, write a program which tells a USB compatible VCR to advance one frame, records and stores the frame, and then directs the VCR to advance to the next frame. The VCR is synchronized to the computer in much the same way as a disk drive. Thus, data does not arrive until the computer is ready to handle it, and such software ceases to be “real time.” This sort of thing should not be patentable. “Freeze-Frame” buttons have been present on VCR’s for at least twenty years, being anticipated by similar buttons on moving film projectors.

Well, my intent was to draw a line between user interfaces and bona fide embedded systems, to say that no matter what images you put up on the computer screen, that does not overcome the software-ness of the software. My basic standard of reference in thinking about patent language would be video file formats. My language is provisional, and I invite better phrasings.

Suppose you have a computer controlling a phased-array radio set. At one level, you have the controlling the actual array phasing, steering a radio beam around. You might be testing the thing by getting in your car and driving around to find out what the reception was like at different points. In electrical engineering, there is a distinction between “signal-type” people, or old-time radio engineers, who worry about that kind of stuff, and “computer-science-type” people. My concern is that someone who is doing pure applications software, say a database to keep track of telephone numbers, should not be able to recite some “magic words,” and call himself a radio engineer when he is nothing of the kind, and doesn’t know the first principles of electromagnetics. The idea is, insofar as possible, to keep the two spheres separate, and let them go their separate ways.