Typically software patents describe the invention through a series of flow-charts and other symbolic representation of operations. Usually, the software code itself is not included in the application. Rather, the code is often kept as trade secret. From a practical standpoint, practitioners may want to rethink their approach based on these two associated cases:
- TouchCom v. Dresser, 427 F.Supp.2d 730 (E.D.Tx. 2005) (holding that the software code should have been present to provide structure for means-plus-function claims).
- TouchCom v. Bereskin & Parr (D.D.C) (TouchCom has filed suit against the Canadian IP firm, charging that the firm committed malpractice by failing to submit the software code).
Now, one seemingly important issue in this case is that TouchCom’s patent says that the code is included in “Schedule A” — while in actuality much of the software code was omitted from the Schedule. In addition, TouchCom did not appear to provide any non-code structure either.
“The law firm is Canadian. They’re toast the minute the Plaintiff’s laywer tells the Judge and Jury the defendants are foreigners.”
Both parties are Canadian. You think they would settle this in a hockey rink fight with some brew afterwords. As for the means plus function claim, that was written in 1987 when means plus function was good. And I agree that a software patent needs to disclose the software code itself to get over the full disclosure rules. If the software patent holder has nothing to hide, then they should disclose or at least the patent prosecution attorney should get the inventors to sign a document protecting the patent prosecution attorney from non disclosure.
1) Some of the legal reasoning in the case is odd, but the prudential moral seems clear: the safe level of disclosure in software cases is rising.
2) I would agree that a means claim should never be Claim 1 – but what if the Supreme Court revisits Pennwalt? Then we might see 112(6) returned to its plain meaning.
“My question is can you agree to dismiss your case with out actually losing and then sue your patent attorney because you lost?”
The law firm is Canadian. They’re toast the minute the Plaintiff’s laywer tells the Judge and Jury the defendants are foreigners.
Aug 06, 1987 Canadian priority, then PCT filed, then entered into US. U.S. Patent No. 5,027,282 is 686 pages and there are 16 claims, and only 1 independent claim (an apparatus claim for the software that controls a friendly gas station pump). There are no method claims to cover the software process steps.
The E.D.Tex. trial court first determined that “display and input task means” and the “application task means” limitations of claim 1 were Sec. 112 para. 6 because “Each uses the word ‘means,’ and cardinal rules of claim construction support Dresser’s position that Sec. 112 para. 6 presumptively applies.” That’s it! That is the entire 112 para. 6 analysis by the court. How’s that for analysis! Quick, simple, and to the point. It’s wrong, but its quick, simple and to the point.
The E.D.Tex. trial court next determine whether the patent discloses corresponding structure. The parties agree that, as software limitations, the structure for performing the function is the algorithm identified in the specification and equivalents. I always thought that as apparatus limitations, the structure for performing the function is the apparatus parts e.g., a viewer screen with touch screen options (display and input task means) and wires leading to computer chips (application task means). If the claim were a method claim, yea, look to the algorithm. But an apparatus claim? Come on folks. Get with it!
The E.D.Tex. trial court opinion won’t be cited by legal scholars any time soon. Now, let see the Federal Circuit tear the E.D.Tex. trial court an new one. Here’s what happen on May 24, 2006 at the Federal Circuit “The parties having so agreed, it is ORDERED that the proceeding is DISMISSED under Fed. R.App. P. 42(b).” There you go! Your legal system in action.
OK. So now why sue the patent attorney who prepared the patent application? At trial, the court determined that the portions needed to determine whether the patent discloses corresponding “software structure” was missing from the 686 page patent. As the court put it “the relevant portion in the actual code section of the patent, at column 1341, the source code ends part of the way through the “P” or “pump” section. Thus, a portion of the “P” section, all of the “S” section (for switches) and the “T” section (for touch) are missing.”
So some of the pages of the application may not have been copied by the minimum wage law clerk. My question is can you agree to dismiss your case with out actually losing and then sue your patent attorney because you lost?
Two points:
Including code in a software application is a pointless exercise. Usually the invention is embodied in thousands of lines of code scattered over millions of other lines of code. I’ve worked as a software engineer and drafted lots of software patents. If a person is truly skilled in the art, then they can typically implement their own software solution to embody anything described in a software patent in a fraction of the time they would spend trying to discern meaning from millions of lines of code.
And I completely disagree with those who suggest means-plus-function claims have no use in software patents. 112p6 claims are interpreted totally differently than ordinary claims after Festo. There is plenty of good reason to include 112p6 claims in addition to good method claims and other good apparatus claims. More claims of different types is always good. I would put some multicellular living organism claims in my software patents if I could figure out how to do it. Discounting 112p6 claims out-of-hand doesn’t seem to make any sense to me.
This case was *not* decided on enablement nor on written description.
The issue was indefiniteness for failure to disclose corresponding structure for a means-plus-function element. See Touchcom, 427 F.Supp.2d at 735-37.
The court asserted that, because the particular function in the means-plus-function element was implemented in software, the corresponding structure would be an algorithm in the patent that performed the function. See id. at 735.
Unfortunately for the patentee, no such algorithm was present in the patent in *any* form.
The defendant argued “that the patentee did not provide flow charts, mathematical formulas, or other detailed descriptions of the algorithms at issue” and consequently that the patentee was “stuck with” the source code that was appended to the specification. Id. at 735.
After reviewing the contents of the source code and other portions of the specification, the court found that the patent did not disclose any detailed algorithm for performing the functions in the mean-plus-function elements and thus held that those elements rendered the claim indefinite. See id. at 735-37.
Since flowcharts or other symbolic representation of operations could have been sufficient in this case if they had only been included, I think Dennis’s comment overstates the relevance of source code. Moreover, if you really wanted to use a means-plus-function, flowcharts presumably would be at some level of abstraction higher than source code and thus would allow one to have broader (albeit still narrow) patent scope.
> In these cases, are flowcharts really be all that illustrative?
There are flowcharts, and there are flowcharts. You can flowchart at a module level (the boxes say “scan file for key”, “compile list of matching keys”, etc.) or one which is essentially the same as high-level code (the boxes say, “read record”, “extract key from positions 1-9”, “compare…”, etc.) or even at the level of symbolic assembler code (“read block address”, “position read head”, …).
As with any drawing providing enablement for any invention lies in choosing the appropriate level of flowchart so that the invention as claimed is enabled sufficiently. This is no different than the analysis you need to go through in deciding if your mechanical application can get away with a block diagram, or do you need a detailed cutaway drawing of that “linkage” or “feeder”.
I have never provided source code in a patent application, in favor of sufficiently detailed flowcharts and step-by-step explanations of what is behind the flowchart. I feel that supplying the present code is likely to (a) lead to arguments that the invention is limited to PL/1 release 6.0 and the potential infringer’s C++ code is therefore inherently different; and (b) be absolutely useless in five to ten years when the programming language has been forgotten.
Flowcharting is forever, if you do it right, while computer languages come and go with electronic rapidity. At one time or another I had programmed in 25 languages or dialects, by actual count when I stopped programming professionally about 25 years ago – and maybe three of these still exist in some form or other.
How “enabling” is a disclosure of specific code in AUTOCODER, SNOBOL, APL, WATFOR, or Z80 symbolic assembler, when any computer which could run those languages is obsolete, and (in many cases) even the documentation has long since been discarded?
Letter to client regarding disadvantages and advantages of including source code in given case (tylically do not include-only method flow charts and structural block diagrams as detailed as the case warrants). Best mode is a bit more concerning than enablement.
No need for software apparatus claims to include any means language. It is lazy claim drafting. An element of a claim written in means-plus-function is narrower as a matter of law than the same element written without any means language. Section 112 is a limitation on the claim. End of story.
The utility of code in a specification is questionable.
However, it is not difficult to imagine circumstances where simply including a flowchart and diagrams would not be sufficient to show that the inventor is in actual possession of the claimed invention. The path along an arrow from A to B might actually be impossible to practice for a PHOSITA without the associated code (or pseudocode).
Frankly, I’m torn. On the one hand, software development is almost always a “I’m here, and I want to be there” path. Is “there” the invention or is the path to there the invention? As a former programmer, I’d say the “path to there” is usually the most creative/inventive part. In lots of software cases, many people have a conception of “there” (think “one-click,” “shopping cart,” “cascading stylesheets”, “compressed sound files”,and “hyperlink”), but few are (or at the time, were) able to make the software actually get “there”. In these cases, are flowcharts really be all that illustrative? I think the answer is “maybe.”
On the other hand, there may, in fact, be “theres” that are trully inventive but relatively simple path. In this case, a flowchart is probably sufficient because it is trully novel and nothing about the problem is “difficult.”
That’s a lot of rambling.
Seems a bit pointless really – the code itself is covered by copyright – it is what the code does or to put it another way the underlying idea that is important to the patent.
Even the recently abortive attempt at a European Directive did not want to inlcude the code.
What policy justifies the conclusion that software is not sufficient corresponding structure for a means-plus-function clause?
There may be thousands of ways to code the software that performs the function. But breadth is hardly a reason for concluding that an enabled claim is indefinite. For example, what if a patent discloses a fastener and a claim recites a “means for fastening”? Just like there are thousands of coding possibilities, there are thousands of fasteners (bolts and nuts with thousands of sizes and threads, screws of thousands of sizes and threads, rivets, nails, etc.). Does this mean a fastener would be insufficient structure also?
And it’s not like that reciting software as a corresponding structure allows one to assert that software (basically ones and zeros) is somehow the equivalent of all possible means for performing the function. Would an Etch-A-Sketch be the equivalent of software? Probably not. Would hardware be the equivalent? Maybe.
But the point is that software *has* structural features (the ones and zeros that are loadable into memory, etc.) and I have yet to hear any good reason why a specific algorithm should be necessary given software’s inherent structural features.
If the flow charts and symbolic representation (pseudocode) have completely described the invention it is hard to understand why you need to include source code demonstrating an implementation of the algorithm. The implementation is no more than a translation of one expression of the algorithm to another. Its like requiring that a patent applicant in the US include a French translation.
Crouch’s summary of the case is slightly misleading. The only mention in the patent-in-suit of the structure corresponding to the claimed means was in its summary, and only in passing. The patent’s detailed description was entirely silent regarding the required structure.
In contrast, most practitioners today provide a full written description of all code elements (or their functions) in the detailed description, and provide source code only as a secondary source. The two cited Touchcom cases do not imply that source code should be submitted in all cases, but rather that a full description of all claim elements should be provided in the specification and not in appendixes that may be inadvertently lost or omitted.
Isn’t that the equivalent of providing a detailed schematic of every aspect of a mechanical device? You don’t need that level of detail for means-plus-function normally, do you?
“What is the “structural” equivalent of disclosed code, anyway?”
Seems to me it could be:
1. Different programming language
2. Refactored code
3. object oriented implementation of same functions
4. distributed execution (e.g. client-server) if relevant
5. similar but not identical code that performs the same function in the same way with the same result (b + a instead of a + b)
Now, proving it in court may be a more difficult story.
Wow, interesting. What is the “structural” equivalent of disclosed code, anyway?
I have not done many software applications. I have submitted a code appendix in most of them (particularly a neural net application where I didn’t want to violate 112 and the client was unconcerned with the code (graduate student work)).
Means-plus-function is a pretty lazy way to draft apparatus claims for a method patent, I try to avoid it. If it is about the only way to do it, I would reconsider apparatus claims altogether.
Comments are closed.