Nov 222011
 

The Manual of Patent Examining Procedure is the reference for patent agents and patent attorneys. In the MPEP, the PTO outlines established patent law and guidelines into this one reference, the result of which is a manual of literally thousands of pages. The MPEP also importantly provides guidance for PTO employees and applicants in areas of patent law that are somewhat in flux. Since the first edition in 1949, new editions to the MPEP have been relatively slow going.

First Edition, November 1949
Second Edition, November 1953
Third Edition, November 1961
Fourth Edition, June 1979
Fifth Edition, August 1983
Sixth Edition, January 1995
Seventh Edition, July 1998
Eighth Edition, August 2001

However, since 2001, the PTO has accelerated updates through revisions on almost a yearly basis. 

Revision 1, February 2003
Revision 2, May 2004
Revision 3, August 2005
Revision 4, October 2005
Revision 5, August 2006
Revision 6, September 2007
Revision 7, July 2008
Revision 8, July 2010

Not too long ago, I passed the PTO registration examination. Studying for the exam involved me becoming very familiar with the MPEP. I found that the MPEP needs some updating. You see, the latest revision of the 8th edition of the MPEP was released July 2010. However, since that time a lot has changed that warrants another revision, or even edition. Besides the most obvious updates including the post-KSR guidelines, the America Invents Act additions, and additional pilot programs, it appears as if Section 2106 needs a complete revamp.

Section 2106 includes the 2005 interim guidelines of Subject Matter Eligibility. Since this time, we’ve seen a lot of activity with regards to § 101. For instance, the 2009 Guidelines in light of In re Bilski, Bilski v. Kappos, and the 2010 Guidelines. As you’ll see, this section focuses a lot on utility.

In section I.A., the guidance is to: “Identify and Understand Any Utility . . .”

However, isn’t the utility section of 101 another inquiry than subject matter eligibility?

The section continues: “The claimed invention as a whole must be useful and accomplish a practical application. That is, it must produce a “useful, concrete and tangible result.” State Street Bank & Trust Co. v. Signature Financial Group Inc.

But In re Bilski pretty decisively took care of this State Street doctrine, which Bilski v. Kappos did not overturn.

Next, “USPTO personnel should review the application to identify any asserted use. The applicant is in the best position to explain why an invention is believed useful.”

Again, utility is an inquiry in a different section 2107.

Finally, section III.C.2. refers to the “Useful Result, Tangible Result, Concrete Result.”

This entire section is State Street, which was overturned by In re Bilski. Outdated.

It is perhaps only a matter of time before outdated sections like 2106 become updated. However, it is too early to tell when this will happen. Part of me wants to predict that it will take quite some time. A lot of the America Invents Act provisions (some of which don’t become law until a couple years later) are still being planned and thought-through, which means that it may be a while before we actually see an update with these new provisions.

 

 

 Posted by at 1:27 pm
Nov 082011
 

Marty Goetz’s recent piece on reframing the software patent debate may be the best way to go forward. He asks, “Is an invention that is patentable in hardware, equally patentable if implemented in software?” This inquiry takes into consideration the machine-or-transformation test and the judicial statutory exceptions. For instance, if an invention is a patentable piece of hardware then the software that does the same thing should not be deemed an abstract idea or a mental process.

Goetz continued to compare software to a manufactured product. Both life cycles, he argues, have similar characteristics. The definition phase describes functionality, specifications, the environment in which it must operate, and its operating characteristics. In the design phase, they develop and define all the interfaces, break down the functionality into modules, and do all the engineering so that the product can be properly implemented. During the implementation phase the software is debugged, tested, and goes through quality assurance. During the delivery phase there is alpha and beta testing, documentation, installation, and training. Companies can sell the product to other companies where the product becomes a component of a larger system and is repackaged. During the maintenance phase the company warrants its workmanship, and guarantees the correction of errors and defects. Finally, during the enhancement phase the product is improved, enhanced, upgraded, and new models, or releases, are announced.

Notwithstanding all the similarities between computer programs and manufactures, to me the patentability inquiry should come down to how the invention is claimed. Thinking about a computer program as what it actually does and performs just like a hardware counterpart is useful in determining its patentability. It also helps to alleviate confusion among critics that claim that you can’t patent code. I think that the original Beauregard claim was claimed in a way that meets the Goetz standard, but since then there are many claims that don’t.

Consider this claim from Beauregard, patent number 5,710,578:

Claim 22. An article of manufacture comprising:
a computer usable medium having computer readable program code means embodied therein for causing a polygon having a boundary definable by a plurality of selectable pels on a graphics display to be filled, the computer readable program code means in said article of manufacture comprising:
computer readable program code means for causing a computer to effect, with respect to one boundary line at a time, a sequential traverse of said plurality of selectable pels of each respective said boundary line;
computer readable program code means for causing the computer to store in an array during said traverse a value of an outer pel of said boundary of said plurality of selectable pels for each one of a plurality of scan lines of said polygon; and
computer readable program code means for causing the computer to draw a fill line, after said traverse, between said outer pels having said stored values, for each said one of said scan lines.

Importantly, this claim as written specifies that the computer program code must be used to cause certain things to happen. For instance, “for causing a polygon . . . to be filled” and “for causing a computer to effect . . . a sequential traverse.” In other words, the inventor is not claiming the code, but rather the code to have the computer actually do something. This is much like a machine that has certain switches hard-coded into it, this claim is drafted to resemble it very nicely. Another example in simpler language is here:

A computer-readable medium storing instructions that, when executed by a computer, cause the computer to:

calculate a set of occluding shields in a voxel dataset using …;

designate a voxel whose effective opacity exceeds a specified …;

apply the occluding shields to identify the regions of the voxel data …; and

render the voxel dataset, ….

In my research, I have run into many Beauregard-style claims that do not claim the instructions causing the computer to do certain things. Instead, these overbroad claims claim a computer medium with instructions. This may not meet the Goetz standard. Consider this claim, for instance:

A computer-readable storage medium encoded with a set of instructions for a computer, said instructions including:

a display routine configured to display a plurality of two-dimensional (“2D”) images representative of cross-sections of a three-dimensional (“3D”) volume in a plurality of viewports, wherein the plurality of viewports includes a first viewport, a second viewport and a third viewport each configured to display one of the 2D images; and
an angle of cross-section modifying routine configured to :
(1) alter an angle of the 2D image displayed in the second viewport based on and simultaneous with a movement of a control line in the first viewport,
(2) alter an angle of the 2D image displayed in the third viewport based on and simultaneous with a movement of a control line in the second viewport, and
(3) not alter an angle of the 2D image displayed in the first viewport based on the movement of the control line in the second viewport.

Here the claim of a computer program product comprises a medium that has instructions. From the claim, the invention does not claim something like a manufacture, what the invention can concretely do. Instead, the claim is to a set of instructions. Other alternative language I have seen is medium that “bears” certain instructions, or is “operable” or “capable” of making the computer perform certain steps. Claiming a computer medium that has instructions operable to do certain things doesn’t mean a whole lot, however. The inquiry should be whether it does it or not. In fact, it is possible of having instructions on the medium that never make an effect on the invention itself.

Here the important distinction that supports the fact that software patents are deserved just as hardware patents are. If hardware and software are interchangeable, then features that are built into the product but never utilized are still part of code, but not part of the invention. Consider this snippet of imaginary code.
if(true){
first set of instructions
}
else{
second set of instructions
}
Here the invention never performs the second set of instructions. The computer program will perform only the first set of instructions because the statement is set to always be true. Just like if this was a piece of hardware and a switch was turned on, so this piece of software is always set to perform the first set of instructions. Yet the second set of instructions are on the machine-readable medium.

I think that the courts and PTO are struggling with how to classify software inventions. Like Goetz, I believe that in many instances they resemble real-manufactures quite remarkably. In order for them to be treated as such in the patent arena, their patent claims must likewise resemble what the claimed code is actually doing.

 Posted by at 9:46 am