The Software IP Report

Williamson v. Citrix Online, LLC, and Lessons for Patent Drafting

By Charles Bieneman

Categories: 35 U.S.C. § 112, Software Patents, The Software IP Report

Williamson v. Citrix Online, LLC, No. 11-CV-2409 (Fed. Cir. June 16, 2015), raises the specter that software patent claims, already oft-challenged in the wake of Alice Corp. v. CLS Bank, could face the additional challenge of being unexpectedly construed as “means-plus-function” claims under 35 U.S.C. § 112(f). (Or, prior to the America Invents Act, “Section 112, paragraph 6.”)  No drafting technique can produce a software patent claim that is impervious to challenge in today’s environment. However, a reading of Citrix Online does suggest some fairly straightforward guidelines for patent applicants, drafters, and prosecutors to consider.  These guidelines are offered below, after a summary of the Federal Circuit’s decision.

Summary of Citrix Online

In Citrix Online, the Federal Circuit, in an opinion by Judge Linn, affirmed the district court’s holding that claim language deemed functional was indefinite due to the failure of U.S. Patent No. 6,155,840 to enable the claimed function. The district court had construed independent claim 8 of the ’840 patent as including “means plus function” language in reciting a “distributed learning control module.” The Federal Circuit agreed.

The ’840 patent is directed to “methods and systems for distributed learning,” i.e., long-distance learning via computers and the Internet.  Independent claim 8 recited a system including “a distributed learning and control module for receiving communications transmitted between the presenter and the audience member computer systems.”

The Federal Circuit agreed with the district court that the recitation of the “learning and control module” invoked means-plus-function claiming under 35 U.S.C. § 112(f) even without a recitation of the phrase “means for.”  The court thus overruled (sitting en banc for this purpose) recent jurisprudence recognizing a presumption that claim language is non-functional absent the phrase “means for.”  The old presumption seemed immutable; the court had previously stated that it “is ‘strong and not readily overcome.’”  The court had “seldom held that a limitation without recitation of means is a means-plus-function limitation.”

Now, the court has “expressly overrule[d]” the requirement for a “heightened evidentiary showing” and “the characterization of [the] presumption as ‘strong’.”  The new rule is that, while claims are presumed not to invoke 35 U.S.C. § 112(f), the presumption can be “overcome and § 112[f] will apply if the challenger demonstrates that the claim term fails to ‘recite sufficiently definite structure’ or else recites ‘function without reciting sufficient structure for performing that function’.”  The court explained that the old rule had inappropriately “shifted the balance struck by Congress in passing § 112[f] and has resulted in a proliferation of functional claiming untethered to § 112[f] and free of the strictures set forth in the statute.”

Left undefined for the present is what constitutes, for enablement purposes, “a sufficiently definite meaning as the name for structure.” However, the present case does present some guidance. Specifically, “nonce words” such as module, mechanism, element, and device may describe structure-less functionality. In this case “module” was “simply a generic description for software or hardware that performs a specified function.” The term “module” provided no “indication of structure because it sets forth the same black box recitation of structure for providing the same specified function as if the term ‘means’ had been used.”

The “learning and control module” was associated with three functions, including “coordinating the operation of the streaming data module.” However, the Specification did not disclose any algorithm for this function. Figures and accompanying descriptions showing interfaces of the “presenter computer system under the direction of the ‘distributed learning control module’” did not, contrary to the patent-owner’s arguments, show such an algorithm.

(Judge Reyna’s concurring / dissenting opinion, and Judge Newman’s dissent, are not discussed in this post.)

Practice Tips: Avoiding Functional Claim Traps

Ranging from the obvious to the more subtle:

Tip 1: Even if you want to avoid application of 35 U.S.C. § 112(f), the first rule is to be prepared for a means-plus-function construction.  Include lots of flowcharts, and lard your specification with plenty of descriptions of “processes,” “sub-processes,” “steps,” etc.

Tip 2: Avoid “black boxes” in your specification and drawings.  For example, if your claims relate to a “playback device,” give concrete examples of what hardware may comprise the playback device. And then include flowcharts and, if appropriate, other diagrams, describing operation of the “playback device.”

Tip 3: Avoid the so-called “nonce” words in your specification and claims, e.g., means, module, etc. Avoid any term that abstractly refers to a concept, and not to a specific structural element. More broadly, this leads to the next tip:

Tip 4: If claiming functionality is unavoidable, as is often the case in a software patent, then claim only the functionality, and not any structure. Avoid the specter of a “means for” construction by omitting to recite anything that could be construed as a recitation of “means.” For example, instead of claiming “a module [or a device] for carrying out a calculation / providing some output / analyzing some data,” claim simply performing the processing. To take a more specific example, what if, instead of “a distributed learning and control module for receiving communications transmitted between the presenter and the audience member computer systems,” claim 8 of the ’840 patent had simply recited “receiving communications transmitted between the presenter and the audience member computer systems,” or even a computer programmed to receive such communications?  Your specification, of course, will explain that the processing is performed by a general purpose computer programmed to execute the process (algorithm) shown in your one or more flow charts.  (See Tip 2.)

Caveat to Tip 4: Some may say that claiming only functionality, and omitting or limiting any hardware or physical infrastructure, will hamper efforts to argue for patent-eligibility under Alice. My view is that the post-Alice patent-eligibility analysis really does exalt substance over form, and merely seeming to recite hardware or something tangible in a claim that otherwise fails the “abstract idea” test will not save the claim.  Moreover, avoiding abstract terms like “module,” or even “device,” could even avoid an Alice attack singling out purportedly abstract claim terms.  And a benefit of following the first three tips, if not this one, should be to provide additional arguments against a patent-ineligibility attack.

Tip 5: Consider including an explicit “means-plus-function” claim in addition to claims that are not intended to be construed under Section 112(f). Such a claim may accomplish at least three purposes. First, it will distinguish itself from non-functional claims. Second, it will force the drafter to consider how the claimed functions are supported in the specification. Third, explicit invocation of means-plus-function claiming forces claim construction to the Specification, which, disadvantages discussed above notwithstanding, can have advantages both with a patent examiner and in litigation.