May 112013
 

In disputes involving computer-related patents, obviously the plaintiff needs to establish that the defendant is infringing at least one of the patented claims.  But when can the plaintiff peer into the defendant’s source code during discovery for purposes of lending support to infringement.  What if the defendant moves for summary judgment even before the plaintiff determines the meaning of the claim terms?  These questions are addressed in the above Federal Circuit case decided May 7, 2013.

Background

Baron’s patent (‘525) relates to reporting and forecasting real-time weather information. Baron sued MWI alleging infringement of the ‘525 patent.  Two months later, Baron served MWI with a request to produce MWI’s source code in their allegedly infringing technology.  MWI moved for a protective order asserting that Baron’s asserted patent claims do not recite a computer-code based invention.  Claim 1 is representative:

Baron responded by arguing that the “logic” (i.e., of claim 1) is the source code and thus MWI’s source code was relevant to show infringement since MWI implemented their technology on a computer with its source code.  The district court granted MWI’s protective order “without prejudice” so Baron could seek the information at a more appropriate time in the litigation.  Discovery continued with MWI serving Baron with discovery requests on how MWI allegedly infringed the asserted patent.  In response, Baron moved for a Markman hearing and objected to the discovery requests as premature.   Baron then served its Disclosure of Asserted Claims and Preliminary Infringement Contentions, detailing how Baron believed MWI infringed its patent. Importantly, Baron renewed its request to peer into the source code.  Then, MWI filed a motion for Summary Judgment of noninfringement, arguing that its technology merely forwards National Weather Service warnings to subscribers.  MWI’s motion for Summary Judgment included an affidavit in which the affiant explained why the accused products did not satisfy the limitations of the claim terms given her understanding of the claim terms.  In response, Baron argued that Summary Judgment was premature because the claims had not yet been construed and it had not yet had the opportunity to review MWI’s source code.  Baron then filed a motion to compel production of MWI’s source code, arguing that without the source code, “[it] and the court would simply have to rely on MWI’s word as to how its products function.”  The district court granted MWI’s motion for Summary Judgment, holding that claim construction was unnecessary because the court only had to construe “disputed” claim terms.  Was the district court’s grant of Summary Judgment proper? Should Baron have been given a chance to look at MWI’s source code?

Majority

The majority opinion held that the district court should have allowed the claims to be construed and should have allowed Baron to look at MWI’s source code.  Thus, the district court erred in granting Summary Judgment.  Baron adequately showed how the additional discovery was relevant and essential for its opposition to Summary Judgment.  Thus, the Federal Circuit held that it was improper for the district court to have refused Baron’s request to delay ruling on Summary Judgment.

Dissent

The dissent disagrees that the additional discovery was necessary, looking at the plain language of claim 1.  Judge Reyna argues that since MWI’s technology disseminates unmanipulated NWS warnings to subscribers, it cannot infringe “logic configured to make a determination . . . said logic further configured to transmit, if said logic determines . . . that said one contact identifier identifies a remote unit located within said geographic region,” as recited in claim 1.  The dissent stresses that since MWI’s affidavits attest that MWI’s source code does not analyze or manipulate the weather information, that’s the end of the story.

My thoughts

This case brings up an interesting point about the difference of reciting “configured to [some function]” versus “performs [some function]” in claims.  “Configured to” can be used to denote that the claim object is capable of doing, or allowed to do, some function.  For example, a ball can be configured to bounce, to throw, to deflate – all of these things are dependent on how the object is used, not on what functions the object performs.  With regard to infringement of software, without looking at the source code, it is difficult to say that a particular software is, or is not, configured to do something.  You may be able to determine that the software does not perform a particular function, but to say that the software is not configured to perform the function is a different analysis.  In the dissent, Judge Reyna states the functions of MWI’s program (i.e., merely disseminates to users) and states that the program does not perform other functions (i.e., determine or analyze).  The dissent then concludes that as a matter of law, MWI’s program does not infringe claim 1.  But when I look at the plain language of the representative claim (Judge Reyna’s own words), the inquiry is not whether MWI’s program performs these functions.  Instead, the inquiry is whether the program is “configured to” perform the functions.  So my question is this: without looking at the source code, can you state so confidently that MWI’s program is not “configured to make a determination” or “configured to transmit, if said logic determines . . .”?

 

 Posted by at 9:57 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
Apr 152011
 

The B.P.A.I. recently decided an interesting case, Ex Parte Dwight Williams, 2009-010882, 2011 WL 1131340 (B.P.A.I. Mar. 28, 2011). The patent application at issue involved a system performing certain methods. The examiner had rejected certain claims as non-statutory subject matter because by combining two types of classes (systems and processes) the invention does not fall in any of the statutory classes. The question for the Board became whether the invention was a system or whether it was a method and if you can combine a system with a method. A representative claim is as follows:

1. A fire fighting system comprising:
pumping at least 2000 gpm water from a large water reservoir toward an industrial hazard using a standard pump having a water manifold inlet but no special approximately 2 1/2 inch inlet; and
adding, in an around-the-pump system, at least one water additive from a water additive source to the pumped water through a fitting at least initially separate from the standard pump, the fitting established on a suction side of the pump upstream of the pump water manifold inlet and in fluid communication between a reservoir outlet and the suction side.

The Board used a dictionary definition of system, which included a method: procedure. Because claims 1, 2, 5-8, 13, 16, and 17 only recited method steps, no structure was claimed. Accordingly, claims 1, 2, 5-8, 13, 16, and 17 were not improper hybrid claims. The Board stressed that a system can have methods as long as structure is not claimed. Therefore, it was “clear that these claims are method claims directed to one of the enumerated statutory classes.”

To me, this case highlights that 101 rejections at the PTO appear to be growing in number and scope. I appreciate that the Board set this point straight. The argument that the examiner made with regards to subject matter made little sense to me. If there were two or more statutory classes in one claim, the rejection should have been based on indefiniteness alone. See IPXL Holdings, LLC v. Amazon.com, Inc., 430 F.3d 1377, 1384 (Fed. Cir. 2005) (“Because [the claim] recites both a system and the method for using that system, it does not apprise a person of ordinary skill in the art of its scope, and it is invalid under section 112, paragraph 2.”). But 101 should be used to disqualify subject matter when the subject matter does not fit within any class. See In re Nuijten, 515 F.3d 1361 (Fed. Cir. 2008).

 Posted by at 4:38 am