Source code ch.26: Claim charts

Source Code & Software Patents: A Guide to Software & Internet Patent Litigation for Attorneys & Experts
by Andrew Schulman (http://www.SoftwareLitigationConsulting.com)
Detailed outline for forthcoming book

Chapter 26: Claim charts

26.1 Introduction

  • Also known as claims tables, or infringement contentions (ICs)
  • A claim chart is a table, generally two columns wide, with one row for each limitation of each patent claim asserted in litigation; a “limitation” of course is an element/part of a device/apparatus, or a step in a method.
  • The left-hand column reproduces the text of the claim limitation, and the right-hand column presents evidence (e.g. from source code, technical manuals, screen shots of web sites, or deposition transcripts) assertedly matching the claim limitation shown in the left-hand column.
  • Importantly, the right-hand column not only presents evidence, but also explicitly makes some assertion regarding infringement or invalidity, and should explain how the evidence relates to the claim limitation in the left-hand column
  • For example, see http://multiplayerblog.mtv.com/wp-content/uploads/2008/03/activisiongibsoncomplaint25.jpg [but this is a PIC; substitute a post-discovery IC (likely with redactions) relying on source code; use one from major litigation, to indicate the importance and potential $ value of a properly-constructed claim chart]
  • Claim charts are essential to patent litigation, but creating claim charts is a largely un-codified practice, picked up informally; treatises and articles on patent law, even those focused on patent litigation, tend to gloss over factual aspects of infringement and invalidity as “unproblematic” (concentrating instead on thorny legal issues at the margins, e.g. the intersection of the Doctrine of Equivalents with “dedication to the public”).
  • Chapter 7 has already discussed initial or preliminary infringement contentions (PICs), i.e. those generated without the benefit of discovery of the other side’s confidential information (such as source code), and therefore typically based on a party’s pre-filing investigation using public information, including that derived from reverse engineering (as discussed in chapter 6); Chapter 7 covered:
    • 7.1 PICs are not actually all that preliminary; they are still “nit picky”; PIC should “exhaust” “all reasonably-available public information” (PICs of course are pre-discovery), based on a reasonable pre-filing investigation, which in turn is based on “reverse engineering or its equivalent” (chapter 6 covers case law regarding which investigative methods are deemed “equivalent” to reverse engineering).
    • 7.2 Claim chart basics: showing infringement or invalidity is element-by-element, not “holistic” (see xxx on parsing claims into limitations)
    • 7.3 Claim chart left-hand side (LHS) with claim limitations, and right-hand side (RHS) with facts re: accused or anticipatory product
    • 7.4 Level of detail necessary for PICs: don’t be “conclusory”, don’t “mimic” claim language, etc.
    • 7.5 Omissions & repetition: don’t over-rely on “information & belief”; don’t hedge with “see” or “for example”; don’t infer the presence of limitations (the “inventor’s fallacy”); how to avoid copy & paste repetition in a claim chart; etc.
    • 7.6 Reducing repetitiveness with Limitations Tables
    • 7.7 Representative instrumentalities
    • 7.8 Small but important words, e.g. “distinct” in i4i, “therein” in Supersoaker case
    • 7.9 Special cases: “means for…” limitations under 112(6); doctrine of equivalents (DoE) and function/way/result (F/W/R) analysis; showing inducement, contribution
    • 7.10 PIC as admission ticket to discovery (or to mandatory disclosures under Local Patent Rules)
    • 7.11 Other types of charts: Markman claim construction charts, invalidity, non-infringement, practicing/working charts
    • 7.12 Supplementing & amending PICs
  • In this chapter, non-preliminary claim charts (ICs) are covered in greater detail, and differences between initial and non-initial claims tables are highlighted:
    • Because confidential information (CBI) such as source code has at this stage been made available, it should be referenced in the chart, to replace or supplement earlier PIC reliance on publicly-available (non-source) information
    • Pinpointing: source-code references in the post-discovery claims table should “pinpoint” the location where each limitation is found in the accused/anticipating product; see xxx below
    • Any hedging or generality in the PIC should be replaced with a firm commitment to a theory of infringement: no more “See, e.g.,” or “for example but not necessarily limited to…”
  • Apart from its immediate application to software patent litigation, an in-depth look at claim charts is also useful as a case study in:
    • Aligning tech with law: how can a piece of technology be described to facilitate testing whether a law or legal criteria (here, a patent claim) applies or doesn’t apply to the technology?
    • Somewhat more narrowly, aligning code with text: how can a piece of software be compared to a possibly related piece of prose/text (which may be a specification or a patent claim)?
    • Constructing patent claims tables as a case study in “forensic classification” (matching an item found “in the field” to a category; the category is possibly, but not necessarily, represented by exemplars)

26.2 Claims table requirements from Local Patent Rules for infringement contentions, responses, invalidity contentions

  • In addition to Local Patent Rules, pending legislation also addresses infringement contentions, i.e. claims tables; see e.g. Rep. Goodlatte’s Innovation Act 2015 (see  summary re: “Heightened Pleading Requirements,” though this concerns initial ICs as covered in ch. 7, whereas this chapter addresses non-preliminary ICs)
  • See handy tables at localpatentrules.com, e.g. http://www.localpatentrules.com/compare-rules/infringement-contentions/
  • Each x 3: “A chart identifying specifically and in detail where each element of each asserted claim is found within each accused instrumentality…” (e.g., ED TX LPR 3-1(a)(3)); “instrumentality” here may be a product, service, method, and/or system
  • Use the other side’s names, rather than mimic language of one’s own claims: e.g., “Each method or process must be identified by name, if known, or by any product, device, or apparatus that, when used, allegedly results in the practice of the claimed method or process” (e.g. ED TX LPR 3-1(a)(2))
  • Specify location of limitation with name of corresponding element or step
  • Case law on claim charts, interpreting LPRs; e.g. xxx

26.2B Results of inadequate claim charts

  • Strike PIC/IC under FRCP 16(f); failure to obey order
  • See H-W v. Apple; Comp. Accel. v. Microsoft; Davis-Lynch v. Weaterford
  • Summary judgment (SJ) in patent infringement litigation is generally on a per-claim basis
  • “Failure of proof” (Celotex: SJ of an entire claim is appropriate if there is “a complete failure of proof concerning an essential element of the nonmoving party’s case,” because such an omission “necessarily renders all other facts immaterial”)
  • If inadequecy afflicts all asserted claims, the inadequate claim chart can end P’s case with “death penalty”
  • But courts, for better or worse, tend to give party with inadequate claim chart multiple brief (e.g. two week) extensions to correct the deficiency
  • But to survive SJ, on the other hand, the adequate claim chart need not itself prove the party’s case: IC should present assertions and evidence such that a reasonable jury could agree

26.3 Sample claims tables

  • Unfortunately, even case law directly concerning claims charts often does not show the claim chart at issue, or even an excerpt; however, some examples of acceptable and unacceptable PICs and ICs are available.
  • See claim chart which is unacceptable (even though it cites to specific function names in specific source-code modules) in Michael S. Sutton v. Nokia [cite]
  • See claim chart which is acceptable (but note this is a PIC, created before discovery access to source code) in Amer. Video Graphics v. Electronic Arts (359 F.Supp.2d 558, ED TX, 2005)
  • See table of alleged claim chart deficiencies in H-W Technology v. Apple (2012 WL 3650597, ND TX)
  • Claims tables can be found attached to or quoted in party motions with Lexis or Google searches for phrases which commonly appear in claims tables, e.g. “The accused instrumentality meets this limitation…”, “This element is present…”, “… meets this element of …”, “… are performed in the following source code …”, “While the preamble is not a limitation…”, “to the extent the preamble is a limitation,” etc.
  • [Insert contrived claim chart e.g. for HP “facade server” patent (7,472,398) and CGI-based accused infringement]

26.4 Purpose of claims tables

  • Since the purpose of PICs is to “streamline discovery” (Linex Tech., citing STMicro) and as an entrance ticket to litigation (including to discovery and/or mandatory disclosures), not to require proof of infringement nor to provide a forum for litigation of substantive issues (see H-W Technology v. Apple, citing Balsam Coffee v. Folgers), therefore clearly there must be other purposes to post-discovery ICs.
  • Notice (to defendant of plaintiff’s theory of infringement, to plaintiff of defendant’s theory of invalidity, etc.)
  • Notice not merely of the claims being asserted (see Computer Acceleration v. Microsoft), but specifically of what allegedly constitutes infringement or invalidity
  • “Mere notice,” old Form 18, heightened pleading (Iqbal, Twombly)
  • By the post-discovery, non-preliminary IC stage, is D entitled to notice, not only of what P regards as infringing, but also at least by implication of what P regards as non-infringing?; i.e., is D entitled to know what P regards as the boundaries of its property, as opposed to notice merely that D’s x or y trespasses within those boundaries?; see the “including but not limited to” problem at xxx
  • While ICs should provide more than mere notice (Comp. Accel. v. Microsoft), on the other hand ICs are not proof (though deficient ICs can result in “failure of proof”; see xxx); ICs are something between notice and proof; IC should be sufficient to pass summary judgment, such that a reasonable jury could agree
  • To narrow issues, force proponent to crystallize theories, commit: at least PICs (and likely ICs too) are “designed specifically to require parties to crystallize their theories of the case early in the litigation so as to prevent the shifting sands approach to claim construction” (O2 Micro v. Monolithic Power, cited in H-W v. Apple; see N.D. Illinois local patent rules: “the purpose of these provisions is to require the parties to identify the likely issues in the case, to enable them to focus and narrow their discovery requests”)
  • Narrowing issues, and crystallizing theories, not only for the start of the case, but ongoing; ICs as part of the litigation “funnel”
  • To guide court in comparison of every claim with accused device (see e.g. Nazomi v. ARM Holdings: court wants table, not thousands of lines of code)
  • ICs are not proof, but inadequate ICs can lead to failure of proof, SJ (see xxx above re: Celotex)
  • Are ICs as such (as opposed to materials cited in the IC) ever evidence? [xxx MORE; PICs may be evidence in Rule 11 satellite litigation]
  • Party uses PICs and ICs as “wishing well,” containing something (“hooks”) to support any possible theory it might later need

26.5 Types of claims tables

  • 26.5.1 Preliminary/initial infringement contentions (PICs), before discovery, reflecting, and as part of, pre-filing investigation: see ch. 7
  • 26.5.2 Non-preliminary infringement contentions (ICs), following discovery: main subject of this chapter
  • 26.5.3 Non-infringement contentions (“response charts”)
    • Response to IC, showing absence of one or more elements/steps necessary for infringement
    • For non-infringement, D of course need only find that a single limitation is missing, but it generally will not stop there in its non-infringement chart
    • Sometimes, D is required to provide a chart showing whether it agrees/disagrees with P, for each and every element (e.g. ND GA LPR)
    • Disproving infringement is not the same as proving non-infringement: D need only rebut P’s asserted (examples of) infringement; but must a party seeking declaratory judgment of non-infringement ever affirmatively prove absence of infringement?
    • See Local Patent Rules: http://www.localpatentrules.com/compare-rules/non-infringement-contentions/
    • See e.g. O2 Micro v. Monolithic Power; McKesson v. Epic Systems
  • 26.5.4 Invalidity contentions
    • Show anticipation, obviousness, on-sale bar, public-use bar
    • Show prior art disclosed (and enabled) each claim limitation
    • Combining multiple references as part of showing obviousness: here, need to show a single structure/method (see “no bag of parts” at xxx) is replaced by need to show that PHOSITA at relevant time would have thought to combine (T/S/M, etc.)
    • ND CA LPR: “Whether each item of prior art anticipates each asserted claim or renders it obvious. If obviousness is alleged, an explanation of why the prior art renders the asserted claim obvious, including an identification of any combinations of prior art showing obviousness…”
    • Motivation to combine, and expert’s opinion on PHOSITA’s knowledge at the relevant time
    • Proprietary source code may not be the best evidence, as showing anticipation typically requires pointing to something publicly available at the relevant time (e.g. commercial product on the market, rather than the source code used to build it); however proprietary source code could be used as evidence of what was on sale
    • See e.g. Pixion v. Citrix re: CuSeeMe source code
    • Make sure to consult file wrapper, and likely use that as starting point for prior-art research
    • See Local Patent Rules: http://www.localpatentrules.com/compare-rules/invalidity-contentions/
    • See PTAB rules re: claim charts in petition for IPR
  • 26.5.5 Practicing/working charts
    • No “working requirement” in US patent law, but need to show working/practicing for:
      • To show domestic industry (DI) in ITC importation action; see details below
      • To show commercial success of embodiment of patent, as secondary consideration for non-obviousness; P must show, on limitation-by-limitation basis, that product embodies at least one claim of patent (as well as showing “nexus” of commercial success to patented feature)
      • To show technical ability to meet demand, for lost profits calculations
      • To show non-troll/non-NPE status, when requesting injunction or other equitable relief under eBay v. MercExchange
    • Technical prong of domestic industry (DI) in ITC importation case; only need 1 example, can even be from non-asserted claim (?)
    • http://www.usitc.gov/secretary/fed_reg_notices/rules/itcrules409.pdf: “A showing that an industry in the United States, relating to the articles protected by the patent exists or is in the process of being established. The complainant shall make such showing by appropriate allegations, and when practicable, by a chart that applies an exemplary claim of each involved U.S. patent to a representative involved domestic article or to the process under which such article was produced…”; contrast this “exemplary” claim chart to show domestic industry, with charting every claim for which infringement is asserted.
    • Domestic industry can be shown with licensee working/practicing, even an unwilling licensee from earlier litigation.
    • At least for ITC domestic-industry chart, make sure chart shows currently practicing
    • Practicing/working charts in Local Patent Rules, e.g. ND CA 3-1(g): “If a party claiming patent infringement wishes to preserve the right to rely, for any purpose, on the assertion that its own apparatus, product, device, process, method, act, or other instrumentality practices the claimed invention, the party shall identify, separately for each asserted claim, each such apparatus, product, device, process, method, act, or other instrumentality that incorporates or reflects that particular claim.”
  • 26.5.6 Expert’s claims tables vs. party’s claims table
    • Party’s ICs covered under Local Patent Rules, Rule 11, etc.; expert claim charts are not (see MPT v. Apple)
    • But expert’s claim charts covered under FRE, Daubert (and party’s are not?); see ch.xxx
    • Expert can establish linkages (D’s code x matches P’s claim limitation a) for which party itself would otherwise need written evidence; but no mere expert ipse dixit
    • Expert generally should provide more WHY (specific reason why this claim limitation reads on this particular piece of code) than party’s ICs are typically expected to provide
    • Expert can assume some claim construction based on expert’s opinion of what PHOSITA would have understood term to mean at the relevant time
    • Don’t try to use expert to “backdoor” theories or evidence which party failed to present in timely fashion in its ICs; see xxx below on deadlines and scheduling
    • Expert report which merely attaches (or “incorporates by reference”) the party’s ICs, while putting forward theories/evidence different from that in the attached IC
  • 26.5.7 Injunction/contempt-related chart
    • Is D, already found to infringe, and already subject to an injunction, now violating the injunction (and therefore in contempt of court) by continuing to practice the same technology as was enjoined?; see Tivo v. EchoStar and “colorably different” standard in ch. 30
    • This chart may be more akin to a copyright-infringement chart than to a patent-infringement chart because, rather than showing that code x2 infringes patent claim y, it may be sufficient merely to show that x2 is not “colorably different” from enjoined code x1 which was  already found to infringe y.
    • Much earlier, claim chart accompanying a TRO or preliminary injunction (PI) request, to show “likelihood of success on the merits”
  • 26.5.8 Claim construction charts
    • These are different from the subject of this chapter; see ch.xxx
    • Unlike Markman claim construction tables, in this chapter, we are comparing the claims (as construed) to some external reality (here, a software product and/or source code)
    • Markman charts are largely legal (but may contain facts re: PHOSITA’s understanding of a term at a given time); ICs are largely factual (but will at least imply some claim construction, by virtue of which facts it chooses to align with each claim limitation, and may contain explicit claim construction and/or show infringement under a variety of alternate constructions; see xxx)
  • 26.5.9 Charts showing dependent-claim trees
    • These too are totally different from the subject of this chapter
  • 26.5.10 Claim charts in petitions to PTAB for IPR, PGR, or CBM review
    • Only show prior art disclosing limitations; no argument (VMWare v. E&TRI)
  • 26.5.11 Claim charts employed in licensing negotiations
    • Cases in which presentation of claim charts does or does not cause reasonable apprehension of impending litigation, for declaratory judgment (DJ) action
  • 26.5.12 Claim charts in jury verdict forms
  • 26.5.13 Claim charts employed by PTO examiners

26.6 Basics of creating a claims table

  • Chapter 7  has already shown the creation of a PIC or initial IC, before discovery; now this is being turned into a non-initial, post-discovery IC; see xxx for cautions in turning PICs into ICs
  • Showing patent infringement/invalidity is of course not a “holistic” exercise
  • Individual claims are infringed or invalidated, not the patent as a whole (even though a patent, with all its claims, represents a single invention; see xxx)
  • Further, showing infringement/invalidity of a single claim is also not holistic: the showing is limitation-by-limitation, not claim-by-claim
  • Split claim into limitations, show presence of each and every limitation (or, for non-infringement, absence of at least one limitation)
  • Each limitation of each asserted claim will have a separate row in the claims table
  • See xxx below on identifying the limitations within each claim: generally start by separating claim along semicolons, but don’t assume that semicolon-parsing is sufficient to isolate limitations
  • If (as is usually the case) limitations are not assigned letters or numbers within the claim (e.g. steps (a), (b), (c) of a method), these can be assigned via square brackets along with the claim number, e.g. [1.1], [1.2], [1.3] (with the premable perhaps designated as [1.0]) or [1a], [1b], [1c].
  • Claims table generally has two columns: left-hand side (LHS) shows language of claim limitation; right-hand side (RHS) shows evidence for presence/absence of that limitation in product being charted
  • Importantly, RHS not only includes facts, but also weaves these facts with language from LHS as part of explicit assertions regarding infringement or invalidity, e.g. “the doFoobar() function (implemented in source-code file foob.c) in the accused instrumentality embodies/practices the ‘wherein the bar is connected to a foo’ limitation, because the doFoobar() function has two parameters, representing a bar and a foo, and the function, among other tasks, connects these two parameters by copying pointers to them into a data structure, named Baz, to which the function returns a pointer”.
  • Thus, table is 2 columns x number of rows necessary to show each limitation of each asserted claim
  • Rows for claims (e.g. dependent claims) containing some of the same limitations can refer back to earlier rows, so long as the back-reference still makes an assertion, and is not a mere “see”; the problem of cross-references in claims tables, and why copy & paste repetition is the wrong solution to the problem, is discussed at xxx
  • See xxx on 3-column tables also incorporating claim construction
  • Landscape mode is generally used, with more wider column for RHS than for LHS
  • When rows cover multiple pages, it is helpful to provide a header indicating the claim/limitation (e.g. [1.3] or [1c]) and product (if more than one) for each page; of course, as this is helper to the chart’s reader as well as the chart’s preparer, litigants often omit see (see xxx on “games litigants play”)
  • RHS may incorporate screen shots, diagrams, etc., for simple limitations such as the presence of a network, CPU, etc., or are more likely to appear in pre-discovery PICs than in final ICs based on source code
  • RHS may incorporate deposition testimony, rog responses, etc., but make sure that dep or rog answer used for one limitation is really referring to the same overall apparatus/device/process/system as the source-code citations

26.7 Identifying limitations within claims, and sub-limitations within limitations

  • Some claims may already be naturally split along limitations, e.g. a method claim with explicitly-designated steps (a), (b), (c), etc.
  • How to split claims along limitations: start with semicolons; possibly also split along “and” and other connectors
  • When to do or not do further splitting beyond mechanical use of semicolons:
    • For infringement, P will want fewer rows/limitations, D will want more; though note case xxx with P seeking more limitations to contain effect of PHE?
    • But this stance reversed for invalidity (infringement/invalidity near-mirror image helps keep parties honest)
    • When is it useful to isolate a sub-limitation into its own row?
    • Some limitations may already be naturally split along sublimitations, e.g. nested “wherein” or “comprising” clauses; see cases xxx
    • If a semicolon-delimited limitation within a claim contains multiple adjectives, such that the limitation could have been written with a nested “wherein” clause, those adjectives are candidates for consideration as sublimitations; e.g., “said widget coupled to a large green furious framis” could have been rendered as “said widget coupled to a framis, wherein the framis is (a) large; (b) green; and (c) furious”?
  • If individual limitations are not already identified within the claim with (a), (b), (c), etc., then using square brackets to add [a], [b], [c], etc. tags will facilitate later cross-referencing (see xxx on pros & cons of cross-references vs. repetition in claim charts)
  • Claim can be seen as a “parts list”; but careful, not a disconnected “bag of parts” or “laundry list” (Intertrust v. Microsoft)
  • Pay attention to connections/links between parts/elements/steps; xxx
  • Preamble is generally not a limitation (preambles generally state a use/purpose for the invention, but patent infringement is more about structure than about use/purpose); however, preambles are generally charted just in case; see xxx
  • Preamble does include claim type (apparatus/device, method, system), and this must be consistent with the type of infringement alleged (making, using, selling, offering, importing); see xxx below
  • Negative limitations “without x”, “free of noise” (Mallinckrodt v. Masimo), etc.; difficulty of conclusively showing absence of x in infringing product; easier for other side to find one exception to show presence within accused instrumentality
  • What looks like a limitation may merely be a precondition: must be present, but need not be carried out by infringer; e.g. -ed (past tense), “such that”, “in which”, “whereby”, etc.; see xxx

26.8 Claims tables & claim construction

  • Claims table must adopt some claim construction, which must be reasonable (see e.g. Eon-Net v. Flagstar, in which attorney conducted reasonable pre-filing investigation of accused web site, but PIC and case failed, because of unreasonable implied claim construction that “hard copy” claim limitation read on web site); straight-face test; don’t be too “clever”
  • In some cases, table will be 3 columns, with middle column showing claim construction of LHS
  • Or, claim construction being employed in the chart may be shown in LHS, below language of claim, and set off with e.g. bulleted list
  • Claim construction will be party’s own if Markman ruling has not yet been issued; see xxx below on IC deadlines and scheduling
  • Chart might contain multiple alternate constructions, showing e.g. that infringement/invalidity is unaffected by different possible constructions; though this can risk sounding implausible (“yes, we have fought tooth and nail against this other construction, but even under that other construction, we still don’t infringe, because even under the DoE…”).
  • Party’s claim construction may come from e.g. dependent claims (claim differentiation), spec, etc.; see below
  • If claim construction is provided, the RHS should then explicitly use this claim construction, where different from the language shown in LHS; having presented claim construction, don’t in the RHS then simply use the un-constructed claim language
  • A quick introduction to claim construction as it relates to claim tables (see more complete coverage of claim construction at xxx):
    • Usually start, and end up with, “plain and ordinary meaning”
    • “Canons of claim construction”
    • Hierarchy of sources: claims trump spec; spec and file wrapper are “intrinsic,” and trump extrinsic sources such as dictionaries, treatises, and expert testimony; expert can opine on what PHOSITA’s understanding of term would have been at the relevant time, but courts suspicious of expert bias (see xxx)
    • Stay within claims before looking elsewhere for meaning of a term; contrast frequent engineer approach of immediately consulting one’s own mind for the meaning of a term
    • Why not dictionaries: seem like a perfect unbiased source, but dictionary definitions are often compiled for a more general purpose (Phillips v. AWH)
    • Claim differentiation
    • Dependent claims (whether or not asserted in this litigation) provide (non-limiting) examples of independent claims
    • Dependent claims at the same time indicate that independent claim MUST be broader than what is specified in its dependents; this is a crucial but somewhat non-intuitive point
    • Oddly, however, the spec can trump claim differentiation
    • Dependent claims, used only for their broadening effect upon independent claims, but still be valid (e.g. enabled) to be used in this way
    • Preamble generally not limiting,when it merely sets forth purpose/use of invention, rather than being necessary to describing the boundaries of the invention itself; this illustrates the more general rule that, in patent law, structure/implementation/what-it-is trumps function/use/how-it’s-used
    • “Comprising” vs. “consisting”
    • “Plurality” requires two or more [is 1 ever “equivalent” to a plurality?]
    • Patent claims are perfect illustrations of “less is more”: fewer limitations, and limitations using more generic or common words, are broader (i.e., claim more “real estate”) than claims with more limitations and/or employing more-specific terms
    • If an independent claim is not infringed, then its dependents cannot be infringed; but if an independent claim is invalid, its dependents may be valid
    • Some terms which appear to be limitations are really mere preconditions (see xxx)
    • Pay attention to little words, e.g. xxx
    • Pay attention to seemingly-vague connectives, e.g. “in association with”, “correlated to”
    • Pay attention to word endings, e.g. “programmable” merely means capable of (“-able”) being programmed, not that the thing so described must actually be programmed to meet the limitation (see case xxx)
    • Whether a claim limitation is covered under 112(6) “means plus function” is not necessary clear from the wording of the limitation; see Williamson v. Citrix on functional claiming
    • Each limitation has certain capabilities or attributes which should be consistent throughout the claim: any limitation or element appearing multiple places in a claim should behave consistently in all those places; e.g. if “a framis” is connected to a widget and later “said gizmo” is connected to a gizmo, in reading the initial “a framis,” it should at least be connectable to a gizmo as well as to the framis.
  • When is it claim construction (law) vs. when is it code interpretation (fact), and what are implications for each party at a given stage in the litigation for making legal vs. factual assertions?
  • Good examples of claim construction in software cases include disputed terms such as “compiling” (does it include turning Java into byte codes?); “programmable” (does -able, in contrast to “programmed,” provide any limitation at all?); “instruction” (is a byte code an instruction?; how about a SQL statement?; how about XML data with a one-to-one correlation to some code which acts on a particular XML tag?; must an instruction be in assembly/machine language?);

26.9 Source-code citations in claims tables

  • Don’t forget non-source evidence, at least to fill in straight-forward limitations which one might otherwise overlook, e.g. limitations merely (but tangibly) requiring the presence of “memory”, “CPU”, “storage”, “network”, etc.; see xxx
  • For each limitation, chart must identify on RHS at least a “single structure, process, algorithm, feature or function of any accused product” (Connectel v. Cisco, quoted e.g. in Bedrock v. Softlayer); note this is somewhat different from more specific requirement for 112(6) means-plus-function limitations (see xxx below)
  • In a software patent case, structure, process, algorithm, feature, or function of accused product in RHS of IC will usually be identified with citations to source code
  • Usually show citations to source code (names of files/modules, functions; line numbers; etc.), rather than quotations from source code itself (actual “logic”), as the latter are usually attorney-eyes only under PO (see ch.xxx)
  • Alternatively, if proponent needs to actually quote (rather than merely cite) other side’s source code, claims table can be generated in both redacted and non-redacted versions
  • Cases in which even mere citation to source-code file names or module names, function names, data structures, variables, even without quoting code itself (“logic”), was still regarded as generating attorneys-eyes-only material under the PO?
  • Pinpointing: source-code citations should “pinpoint” the specific location where the limitation is found in the corresponding product, as shown e.g. with source-code version, filename, function name, line numbers
  • This will be the location of a structure, process, algorithm, feature, function, etc. [xxx MORE]
  • “Specific location where”: remember that infringement is concrete, tangible; NOT “they stole our concept” or similar layman’s vagueness; rather, infringement takes place in some specific place or location, or as part of a process that actually runs/executes; perhaps it is in a network packet or a signal, but it is still a tangible place you could point to with a sufficiently-tiny finger; note however this is somewhat less true of invalidity, which can be more conceptual than infringement?
  • Super-pinpointing: rarely, a “super-pinpoint” citation is required, pointing precisely to the minimum block of code which embodies/performs a limitation, or to “the code which does x and does nothing else” (see Vasudevan v. IBM, and various D discovery requests for P to identify “the minimum source code which P alleges satisfies claim limitation x” xxx)
    • The super-pinpoint request, while sometimes unreasonable, has generally been provoked by the habit of dumping many pages of material in the chart RHS for a given row in a chart (limitation), and then repeating (copy & pasting) the same material for other limitations
    • If the same material is applicable to multiple limitations, then rather than the habit of simply copy & pasting the material into multiple rows of the table, the chart should at least bold or underline the portion corresponding to a given limitation
  • While filenames and line numbers are widely recognized as specifying “where” a limitation is allegedly located, location/where in code is often better shown by using the other side’s own naming (function names, structure names, etc.)
  • Specifying location where infringement occurs will often require providing a complete source-code path, version number, product name, and/or platform, e.g. not merely “in storage.c function foo() at lines 1000-1020”, but: “in /product_name/source/2.5/mac_osx/storage.c function foo() at lines 1000-1020”.
  • Depending on how the parties have arranged source-code printing (see ch.xxx) as part of the examination, Bates numbers may be available, and should be used.
  • Remember that a single claim limitation may be met by more than one element/step in the infringing/invalidating product, and conversely that a single element/step may meet more than one claim limitation (this is one reason why claim charts, without proper use of cross-referencing, tend to be repetitive) [xxx more on how this is reflected in the chart]
  • For those using this book but not involved in software patent litigation, the role played by source code in software patent litigation is analogously played in non-software patent litigation by blueprints, schematics, photos with arrows pointing to parts, and so on; see xxx cases.

26.9B Non-source-code citations in claims tables

  • In addition to source code produced in discovery, don’t forget open source, SDK samples, etc. (see chapter 6 on public information gathered during pre-filing investigation)
  • Don’t get lost in the weeds: sometimes an involved source-code walk-through, showing that the product does or does not do X, Y, and Z, can be short-circuited with the vendor’s statement “we do X, Y, and Z”
  • Of course, the vendor statement may be in marketing material written for a non-technical audience by someone relatively ignorant of what the product actually does; the vendor statement may be forward- or backward-looking, and not apply to the current product; the “X” “Y” and “Z” may only resemble in name the patent claim limitations, and so on.
  • In addition to source code, don’t forget information gleaned from reverse engineering the relevant product or service; see chapter 6; in some instances it will be important to couple source-code citations with reverse-engineered information showing that the source code accurately reflects the infringing/anticipatory product (see xxx on “latent code”)
  • Experiments, testing, and/or reverse engineering used as the basis for material in the IC should generally yield output listings, scripts, packet traces, etc. to be included in an appendix to the IC; see case xxx
  • Limitations such as presence of memory, storage, network, CPU, etc. can often be filled-in with non-source evidence, such as screen shots of web sites
  • Technical manuals
  • Diagrams, flowcharts, screen shots
  • Courts sometimes frown on the use of marketing materials, including from web sites, in ICs (see xxx)
  • Deposition transcripts and interrogatory responses: but make sure the deponent is talking about the same thing as appears in the LHS of the claim chart, and make sure that dep or rog answer used for one limitation is really referring to the same overall apparatus/device/process/system as the source-code citations

26.10 Connecting the claims table right-hand and left-hand sides

  • Often, claims table RHS will contain a “dump” of evidence corresponding to the claim language in the LHS, without explaining how or why the material in the RHS embodies the LHS, and often without even asserting that it does
  • It is inadequate to simply “juxtapose” (see Network Caching v. Novell) code in RHS alongside claim limitation in LHS; but note one exception: PTAB petition claim charts only contain evidence, no argument
  • It is inadequate to simply state that the materials in the RHS “correspond to” (see Fleming v. Escort) the claim limitations in LHS
  • It is inadequate to simply show seven pages of source code in the RHS, as satisfying the requirement of the claim limitations in LHS (see Sutton v. Nokia)
  • Only rarely is an explanation unnecessary, e.g. if a limitation specified the use of “storage,” and the RHS evidence was a source-code comment stating “// we use storage”
  • More basic than the need to explain is the need to assert: “The ‘x’ limitation of the claim is practiced by and/or embodied in the accused instrumentality, which includes in file foo.c lines 100-200 a function named ‘a’ which, when invoked, will carry out the ‘x’ method…” (followed, of course, by an explanation of how and why “a” is “x”; but the key thing is to first explicitly make the assertion that code “a” satisfies the “x” claim limitation)
  • [Insert list of useful assertions, considering the type of claim (method vs. device vs. medium) and the type of accused infringement (making vs. selling, etc.); a device’s or medium’s limitations/elements are “embodied” or “included,” whereas a method’s steps are “practiced” or “carried out”]
  • Almost always, the RHS must be explicitly connected to the LHS:
    • This is similar to the need, in 1L law-school essays, to “weave” the facts with the law
    • In claims charts, the LHS with claim limitations represents the “law,” and the RHS with e.g. source-code evidence contains the facts
    • As in 1L law-school essays, weaving/tying facts to claims is often shown with the word “because”
  • Example: “D’s function named StoreDataInMemory(), located in storage.c at lines 100-350, embodies the ‘random access memory’ limitation, because as shown for example at line 124 the structure is copied to global variable gKeep, which resides in RAM.”
  • Often, phrases such as “see” or “reference is made to” (Sutton v. Nokia) or “for example” are used in claims tables to avoid connecting/tying/weaving the RHS with the LHS, and to avoid commitment to a particular theory of infringement; this is generally unacceptable
  • Often, a LHS limitation will be matched with a RHS stating merely e.g. “See storage.c, lines 100-350”; this is generally unacceptable
  • Phrases such as “see” do not make assertions; they merely tell the reader to go look somewhere for themselves; claims tables should make explicit assertions of the presence/absence of each limitation
  • Example: “The ‘random access memory’ limitation is embodied in, and/or carried out by, the StoreDataInMemory() function located in storage.c at lines 100-350, because as its name states, it stores into memory; this is specifically ‘random-access’ memory (RAM), as called for by the claim limitation, because for example at line 90 in storage.c, the stored-in global variable named gStorage is allocated with the C++ keyword ‘static’, which…”
  • In other words, explicitly state even what seems blindingly obvious, because the other side is highly motivated to not make the same hidden assumptions you might, e.g. the assumption that a function named StoreDataInMemory(), from the name alone, must be storing into RAM, rather than into a file system on disk, or Flash memory, etc.
  • Don’t merely repeat or “mimic” (case xxx) the language of the LHS over on the RHS, e.g. given a “framis” limitation, don’t simply assert that “D’s product includes a framis” when D’s code uses the term “widget”; see “the mere language of claim itself” in STMicro v. Motorola
  • Parties often try to avoid using the other side’s proper nouns (“widget”), preferring to simply repeat the claim terminology (“framis”), out of fear that they are locking themselves into saying that the other side’s widget — and only the other side’s widget — is its instantiation of one’s own framis; but the ICs require commitment to a specific theory of infringement
  • Pros & cons of using the other side’s terminology
  • [How to show that D’s code “a” matches P’s limitation “x”: even for literal infringement, it is useful to think in terms of the function/way/result (F/W/R) test used to determine equivalence: what function/role/purpose does “x” serve, and does “a” have that same function/role/purpose?; how about way/implementation?; how about result/output?; MORE xxx]
  • [Another way to show that D’s code “a” matches P’s limitation “x” is to consider any attributes or sub-elements of “x”, and to consider whether code “a” has those; almost anything has such sub-elements; MORE xxx]

26.11 Analyzing claim charts

  • Analyzing not only the other side’s charts, but also one’s own draft charts
  • Think through whether each row makes sense, and whether the rows fit together into a coherent whole
  • WHO is carrying out all the steps of a method claim, or WHOSE product embodies all the elements of an apparatus/device claim?
    • Remember, there is no divided or “joint” infringement; a single actor must carry out or embody all limitations (though can perhaps show agent/direction/control)
    • Even when showing inducement/contribution, there still must be some direct infringer (perhaps the product’s end-user) carrying out or embodying all steps
  • WHERE is infringement occurring?: apart from export or ITC importation actions (see xxx), it must all occur in the US
  • WHERE: does infringement evidence for all limitations face in the same direction for e.g. server- or client-based claims?
    • Similarly, careful when using “write” evidence to satisfy a read limitation, or “send” evidence to satisfy a receive limitation, etc.
    • Don’t assume, if there’s a client/writer/sender, that there must also be in the same product, a server/reader/receiver; see xxx
  • WHERE: are all elements/steps at least arguably part of a single product?
    • In an infringement chart, while avoiding a failed attempt to show infringement “holistically” (i.e. without sufficient attention to the individual limitations of the patent claim), beware of the opposite sin of treating the claim as a mere “parts list,” by failing to ensure that the parts fit together as part of a unified product or service which has been made, sold, used, etc.; see xxx on the “bag of parts” problem
    • But in an invalidity chart, while anticipation must be shown using a single reference, obviousness will be shown with multiple references for which, however, some contemporaneous motivation to combine the references must be shown; see xxx
  • WHEN: note that steps of a method claim need not be carried out in the same order as shown in the claim, unless the claim language explicitly requires this (see e.g. Creative Internet Advertising v. Yahoo: claim does not recite steps/processes that must occur in a particular order)
    • Similarly, one element/step of product can satisfy multiple limitations (see e.g. MobileMedia v. Apple: can steps be combined, with intermediary results within a step?)
    • Similarly, multiple elements/steps of product can satisfy a single limitation; see xxx
  • WHEN: is the evidence cited in claim chart’s RHS from the correct date to satisfy the chart’s LHS?
    • “That which infringes if after, invalidates if before”
    • After for infringement: see xxx on supplying relevant dates for code; see ch. 30 on damages for possible use of pre-grant dates
    • Before for invalidity
    • At least one year before for statutory bars
    • To show domestic industry for ITC action, is the invention currently being worked/practiced?
  • WHY: unless it will be blindingly obvious to the reader, explain why (“…because…”) the code in the RHS matches the claim limitation in the LHS
    • Even if the code in the RHS uses the same terminology as the claim limitation in the LHS, are they necessarily referring to the same thing? (e.g. case with “engine”)
    • It may be necessary to drill down several levels in the code to show that a function named XYZ() really is doing the same X, Y, or Z as required by the limitation
    • If the code in the RHS does not use the same terminology as the claim limitation in the LHS, then it will almost always be necessary to show that the function XYZ() matches limitations A, B, or C
    • To show that function XYZ() in code matches A, B, or C in claim limitation, as part of showing literal infringement or anticipation, it is often helpful to use the same function/way/result (F/W/R) framework used for analyzing equivalence (it may sound wrong to use F/W/R to establish literal infringement but, after all, if something literally infringes it must necessarily also be equivalent; therefore, F/W/R can be used to show that code called X literally infringes a claim limitation called A)
      • Does code X have substantially the same function/role/purpose, within the overall product or feature, as claim limitation A?
      • Is X implemented (“way”) substantially the same as A?
      • Does X produce substantially the same result/output as A?
  • WHICH level?: pay attention to levels of granularity, caller vs. callee, etc. [xxx MORE]
  • WHICH product?
    • When multiple products are accused, make sure that each product separately includes each limitation; don’t locate some limitations in one product, and other limitations only in another product
    • This also applies to invalidity charts, except that references of course are combined when showing obviousness
  • HOW do the parts/elements/steps fit together?; do their interconnections match those in the claim?
    • [Give examples of connectives in claims, vs. connectives in code; MORE xxx]
    • Make sure the parts do fit together in a single product/service/method: see xxx on no “bag of parts” or “laundry list”; see xxx on using the product/service/method’s proper name (including version numbers, platform, etc.)
    • Even if the chart covers multiple infringing products, there must be at least one single “representative instrumentality”; see xxx
  • Does the type of infringement asserted (making, using, selling, offering, importing) match the type of claim as reflected in the preamble (method, device, system, etc.)?; e.g., it is unlikely one can import a method
  • When referring to functions in code, think through whether it is the function implementation (function definition) itself, and/or calls to the function, which fulfill the limitation
  • While infringement and anticipation are not “holistic” exercises (see xxx above), at the same time, all the elements/steps matching limitations of a claim must fit into a single device/apparatus, method, or system: no “bag of parts”, “parts list”, or “laundry list” (see e.g. Intertrust v. MS); however, obviousness will of course be based on a combination of multiple separate references
  • Consistent mapping of code to claims: if code X() matches limitation A in one row or one claim, the same code X() ought to match references to the same limitation A elsewhere
  • Consistency of limitations: if limitation A has some attribute early in the claim, and is later re-used in the claim (“said A”) with another attribute, make sure that, when A is mapped to element/step X in a product, X is consistent (or at least not inconsistent) with every attribute A takes on in the claim [MORE; example xxx]
  • Has every limitation been satisfied?; see xxx on “vitiation” of limitations by attempting to turn them into NOPs
  • Is P relying on D’s product’s mere ability to infringe, without showing actual infringement?; see xxx on “latent code” and apparatus v. method claims; see xxx on “capability” preconditions which may be satisfied with mere ability
  • After analyzing other side’s claim chart, see xxx below on responding to chart

26.12 Repetition, copy & paste, voluminous claim charts, and “representative instrumentalities”

  • Claims tables for “the quantity case” (large number of products x multiple versions x multiple patents/claims)
  • P is master of its case, and can’t complain if overwhelmed by too many products to chart (Vasudevan v. IBM)
  • Multiple accused products: some defendants insist on one chart per accused product (Linex Tech v. Belkin); expensive busywork; a Full Employment Act for tech experts?
  • This can lead to hugely repetitive charts produced with copy & paste, with little difference between charts
  • Parties can instead chart “representative instrumentalities,” but must show WHY a given charted product is representative of the other, non-charted, products; e.g. because of product families (see e.g. Renesas v. NanyaBender v. Maxim, Implicit Networks v. HPIntertrust v. MS; P has burden to show why representative: Vigilos v. Sling Media)
  • Even within a single chart, the same evidence is often applicable to multiple claims, and rather than use cross-references and risk the “see” problem (e.g. “reference is made to” in Sutton v. Nokia), the party or expert will simply repeat the same information over and over
  • Such huge charts are less informative than small ones, and courts are seldom fooled (e.g. Connectel v. Cisco: “six hundred footnotes simply refer back to the same handful of string cites” to a document)
  • Boilerplate claim charts are a sufficient problem that the N.D. Illinois local patent rules explicitly state that to accomplish the purpose of ICs (see xxx above re: purpose), “the parties’ disclosures must be meaningful – as opposed to boilerplate …”
  • Engineer’s perspective: large claims tables produced by copy & paste present the same problem as code in which one function has been copy-and-pasted to create other, only slightly different variants, rather than having a single function, implemented in one place, whose variations are specified with parameters; one problem with copy & paste is that, when a change must be made, it will likely not be made to all copied instances
  • How to pick apart the other side’s massive copy & paste charts: e.g. create a Word “un-merge” macro, to reverse effect of using copy & paste (or Word merge) to create massive repetitive claim charts; you can then look for slight inconsistencies between copy & pasted paragraphs and, conversely, look for instances in which the claim language requires a slight variation but the creator of the table has used blind copy & paste to stamp out a duplicate paragraph without regard for different claim requirements; example xxx
  • The reader of a claim chart is far better off having a cross-reference (in claim 6 limit X, say “see claim 1 limit X”); but the very fact that it is far better for the recipient of the claim chart suggests one reason why this is often not done (“it’s good enough for ’em”); and there is case law indicating that such cross-reference may be misconstrued as not satisfying requirement of proof, because they look like an improper “see xxx” which fails to explicitly assert infringement
  • Sometimes a party D will demand that its opponent P generate “complete” claims tables, devoid of space-saving cross-references, with the ostensible purpose of insisting that P prove up each and every claim limitation, but actually with the mere gamesmanship desire to bury P in work; D should not then complain when it must wade through unhelpful repetitive thousand-page charts [this book unfortunately needs a section on “gamesmanship,” why it seems to appeal particularly to young male associate attorneys, why it merely gives the appearance of helping the client, etc.]
  • Some parties use copy & paste to generate huge charts because they think the charts will appear impressive, and complete
  • Other times, the party genuinely fears that showing information only once, and cross-referencing to it elsewhere, will result in chart which is (because of the “see” problem) unacceptable to the court
  • Formulations which solve the cross-reference problem, e.g. xxx [MORE]
  • Another solution, especially given multiple asserted patents, is to use “Limitation Charts”: a set of limitations, common to all asserted claims in all asserted patents, is charted once, and these common limitations are then referenced in separate charts for each asserted patent; “parts is parts”
  • Problem with such limitation charts: Easy to overlook the subtle different ways in which limitations combine in different claims, e.g. in method vs. apparatus claim, in server- vs. client-based claim, etc.; see xxx noting that a claim is not a disconnected “bag of parts”, “parts list”, or “laundry list”
  • If, to streamline its source-code discovery burden (see ch. 9), D insists that a single produced source-code tree is representative of all accused products, it may thereby forfeit the ability to assert that P’s single claims chart does not adequately represent all accused products
  • See Bedrock v. Softlayer re: implications of “for example” in claim chart, and of using a single chart v. multiple charts
  • Other cases with claim charts & representative instrumentalities, product families, version issues: Bedrock v. Softlayer; Computer Acceleration v. Microsoft; Apple v. Samsung

26.13 Omissions, vagueness, and assumptions

  • Despite the massive size of many claims tables, these monuments to busywork nonetheless often fail to meet basic requirements: overkill and underwhelming in the same chart
  • Silly omissions: forgetting to supply a “trivial” limitation such as presence of memory, storage, network, CPU, etc.; these can often be filled-in with non-source evidence, such as screen shots of web sites, deposition transcripts, etc.; see xxx
  • Less trivially, limitations sometimes appear to have been met, but the evidence provided, were it taken seriously, would vitiate the limitation; see e.g., for an XOR claim limitation, the assertion that the code has in essence performed an XOR with zero.
  • P often uses its own claim language to point to corresponding elements in D’s product, rather than using D’s own naming; often such “mimicking” is an attempt to defer committing to a specific mapping between a P limitation and a D element/step
  • “Information and belief” often used as unthinking talisman (though this is more likely in PICs than in ICs)
  • “For example but not necessarily limited to…” [MORE xxx]
  • P often assumes that, if claim limitation x was found in D’s source code, it must therefore be in the accused instrumentality; but presence in source code does not necessarily mean presence in a commercial product built from the source code (see ch. 22 on “latent code” and “dead code”), and presence in the product does not necessarily mean that it is ever executed (such “latent code” may be sufficient to infringe an apparatus claim, but likely not a method claim; see chapter xxx); see e.g. MetLife v. Bancorp (easy capability insufficient when claim requires actual doing); contrast e.g. Intel v. ITC, Broadcom v. ITC/Qualcomm (claim required mere capability, not doing); Telemac v. Topp (source code ability to infringe insufficient, when device must be modified to infringe, unless some inducement argument re: components); see Lucent v. Gateway re: run-time behavior of Windows Media Player (WMP); run-time question couldn’t be answered merely by examining source-code
  • Assumptions, e.g. “it must be there” because of result/output y, and “you can’t get y without our x” (inventor’s fallacy); see e.g. Bender v. Maxim; CSR v. Freescale (requirement to pinpoint location of infringement not satisfied with “it must exist somewhere” inference from device’s overall output)
  • Inferring presence of element x from element y; inherency; but note e.g. Whitserv v. Computer Packages (jury entitled to credit expert testimony that it is impossible to do B without also doing A, and jury may infer from expert’s testimony that party’s evidence that opponent does B is sufficient to satisfy claim limitation A)
  • Standards — be careful:
    • Claim charts can use standards to avoid full-blown source-code analysis, but don’t simply assume, from party’s marketing literature touting the standard, that the product adheres to the relevant part of standard; this must be shown
    • The product may merely be emulating, or employing a given standard, whereas limitation requires implementing specific part of standard
    • See 802.11 cases: Fujitsu v. Netgear, Linex v. Belkin
    • If standard is used to short-circuit code analysis, explain WHY the product adheres to the relevant portion of the standard (analogous to explanation needed for representative instrumentality)
  • Inferring product’s operation from names in code — be careful:
    • Probably okay when the part name suggests a well-known function, e.g. sqrt() for square root
    • But sometimes the function’s name cannot be taken at face value, and the source-code examiner should drill down into what the function does, to be sure that the name is sufficiently accurate
    • Of course, the source code’s owner will have a hard time denying that a function named DoXYZ() really does X, Y, and Z (see e.g. Westerngeco v. ION Geophysical, party disputing accuracy of term “prediction” in its own code)
    • See also the 112(6) means-plus-function issue of when a claim limitation is mere functional language, such that it is only infringed by products that match the specific means disclosed in the patent spec; “means for…” claim language is not the only trigger for 112(6) means-plus-function analysis (see xxx below).
  • Assuming that name in code “xyz” matches claim limitation “xyz”; “xyz” may have particular construction; code may not do what its name implies (name inaccurate, or find out inaccurate only if drill down further in the code); or code may not do “xyz” in the sense meant even by the plain language of the claim limitation; however, party’s denials that comments or function names in its own code really mean what they say will sound implausible (see e.g. “prediction” in case xxx)
  • Claims charts are often “conclusory” because the party wants to keep loose/flexible (especially pre-Markman; see claim construction above, and timing/scheduling below)
  • Insufficient attention paid to small or seemingly non-technical words:
    • For example: “coupled” (H-W v. Apple); “in accordance with” (IGT v. Bally Gaming); “responsive to”
    • This is often where fight will be, sometimes precisely because they have been glossed over; had party’s chart said something, anything about “coupled” it would have been sufficient, but having failed to say anything about it, opponent is now motivated to turn it into a cause celebre
  • Insufficient attention paid to slight variations in words e.g. “programmable” vs. “programmed” in Intel v. ITC (-able is much weaker requirement than -ed; and note that even -ed may imply a mere precondition rather than an actual limitation; see xxx)

26.14 Showing means-plus-function 35 USC 112(6) infringement

  • Post-AIA 112(f)
  • Patent law generally cares more about structure than about purpose; this is one reason why preambles are generally not limiting: so long as the accused instrumentality does X, we typically don’t care if D is doing X to implement a floor wax, even if P’s patent claim says that X’s purpose is to provide a dessert topping [perhaps better explain SNL floor wax/dessert topping skit?]
  • At the same time, US patent law also allows claim language which focuses on purpose/results/function rather than on way/implementation/means — but only so long as the functional claims language is backed-up by specific means disclosed in the spec
  • The important point for patent litigation (as opposed to prosecution) is that infringement (and anticipation) will only be found when the specifically-disclosed means are present, not merely when the claim’s function/purpose is present
  • Functional language under 112(6) usually is marked by “means for…”, but functional language can be anything which specifies what result is to be achieved, without specifying in the claim how it is to be achieved; see Williamson v. Citrix
  • There are limits, of course, to what is seen as functional language under 112(6): for example, “square root” specifies the result/output to be achieved, with no indication of how to go about doing so, but this function/part/element/step is so well known that a specific means/implementation need not appear in the spec, and likely any implementation in the accused instrumentality will be seen as meeting the claim limitation
  • Often one speaks of “claims” under 112(6), but really it is limitations which are or aren’t functional, and which therefore are or aren’t limited in scope by disclosure of “means” (implementation) in the patent spec
  • Functional claiming is not limited to method claims [MORE xxx give example from apparatus claim]
  • Local patent rules, e.g. ED TX LPR 3-1(c), requires that claim chart include “for each element that such party contends is governed by 35 U.S.C. § 112(6), the identity of the structure(s), act(s), or material(s) in the Accused Instrumentality that performs the claimed function”
  • This need to identify structure/act/material [SAM] is somewhat different from general requirement that, for each limitation, one show at least one “structure, process, algorithm, feature or function [SPAFF] of any accused product” (Connectel v. Cisco)
  • The key difference is that the infringing product must match, not merely the functional claim language, but also the specific means/implementation (or equivalent) disclosed in the spec, or its equivalent (also true of invalidating prior art)
  • The difference between functional and non-functional claim language implicates how far the code examiner must “drill down” in the code to determine whether code to do X satisfies a claim limitation of X that is covered under 112(6)
  • Insufficiency proving infringement/anticipation of functional claim language, by focusing only on the function in the claim and not also on the means in the spec, resembles the “inventor’s fallacy,” discussed at xxx, in which from a product’s output of X the inference is made that the product “must” use the inventor’s means Y to achieve X, without adequate consideration that there may be other ways than Y to achieve X
  • Under the Aristocrat and WMS Gaming lines of cases, a patent spec need not supply source code as the “means” for a software patent’s “means plus function” claim, but the spec must provide specifics (and an infringing/anticipatory instrumentality must match those specifics)
  • One can plead 112(6) in the alternative, but by the time of ICs party should have committed; see Intertrust v. Microsoft on “premature” 112(6) [?]
  • N.D. Ill. LPR 2.2(d) requires an F/W/R explanation for each DoE assertion; also W.D. Pa. 3.2 and Utah 2.3(d)

26.15 Showing infringement by doctrine of equivalents (DoE)

  • Claims tables often, following an assertion of literal infringement, will include an obligatory boilerplate “or, in the absence of literal infringement, D’s X satisfies the Y limitation of this claim, because X has the same or similar function as Y, uses substantially similar means as Y, and has the same or similar result to Y”
  • In other words, Function/Way/Result (F/W/R) is recited as a mantra
  • This shows that the claims table drafter likely has not thought through what Function, Way, and Result actually mean
  • Function = role, purpose
  • Way = implementation, means
  • Result = output
  • If claims chart drafter has merely recited F/W/R as a mantra, without truly parsing out its components, this should also cast serious doubt on their assertions of literal infringement
  • If something literally infringes, it would at least also infringe under the DoE; therefore, F/W/R can be used as a framework to think through whether there is literal infringement; alternatively, consider other attributes (apart from the three attributes of function, way, and result) along which the limitation and the code can be compared (see xxx)
  • In PIC, one need only indicate whether asserting DoE (see e.g. ED TX LPR 3-1(d): “Whether each element of each asserted claim is claimed to be literally present or present under the doctrine of equivalents in the Accused Instrumentality”), but a non-initial IC must spell out F/W/R
  • Other ways of showing DoE, apart from F/W/R [MORE xxx on DoE “factors” from Graver Tank and Warner-Jenkinson: known interchangeability, evidence of copying vs. design-around, etc.]
  • Interaction of DoE with 112(6) means-plus-function, where equivalence to disclosed means is considered part of literal infringement
  • One can plead DoE in the alternative; but by the time of IC, one should have committed (and again, if do plead DoE in the alternative, don’t just repeat F/W/R as mantra)

26.16 Showing inducement and contributory infringement

  • Still need a single direct infringer
  • Method claims: infringer may be end-user, consumer
  • Who carries out process?
  • If P can show that third party is acting directly under D’s control or direction, then the issue is direct infringement rather than inducement or contribution
  • [MORE: discuss legal elements of inducement, contribution, how these might be located in source code or other evidence]

26.17 Showing invalidity

  • TODO xxx
  • Showing anticipation by comparing patent claims to disclosures in prior-art patents or patent applications (comparing patent to patent, rather than patent to product)
  • Show obviousness using multiple references, or single reference combined with expert’s testimony as to PHOSITA’s knowledge at the relevant time
  • Rebutting obviousness in part with secondary consideration of commercial success, requiring showing that product embodies or practices the patent
  • Showing on-sale (including offer to sell), by showing that patent claim was embodied in and/or practiced by product

26.18 Responding to, and offensively using, the other side’s claim charts

  • TODO xxx
  • See xxx above on analyzing other side’s claim charts
  • When to complain or not complain about inadequate charts from the other side; it may be preferable to hold the other side to its inadequate charts, rather than seek improvements
  • Rebuttal charts
  • Expert reports, declarations, and affidavits noting omissions and errors in charts (see case xxx)
  • Utilizing assertions in the other side’s charts as party acknowledgements, implied claim construction, etc.; e.g. what the other side accuses as infringing suggests claim scope for assessing prior art
  • Mining multiple charts for inconsistencies; e.g., party’s domestic industry (DI) chart in ITC action maps claim limitation to very different embodiment from what the same party’s infringement chart maps to in accused product

26.19 Scheduling of ICs, deadline, supplementing, and amending ICs; extensions

  • Don’t wait for Markman claim-construction ruling to do IC; see e.g. Townshend v. Broadcom
  • Get to work on IC using at least provisional claim construction (but claim construction must be reasonable: see Eon-Net v. Flagstar)
  • Need for “diligence” in producing non-preliminary IC soon after get source-code access; see e.g. Diagnostic Sys. v. Symantec
  • Better to produce an incomplete IC, noting omissions in source code production, than to hold off on the IC until opponent’s source-code production is complete
  • The IC can be used to show omissions in source-code production, e.g. xxx
  • Supplementing or amending requires “good cause” [MORE xxx; see Informatics v. BODI (?)]
  • Potentially dire results of missing IC deadlines, including failure to fix inadequate ICs by deadline; see e.g. H-W v. AppleComputer Acceleration v. Microsoft
  • Don’t use expert report or declaration to “backdoor” material omitted from party’s claim chart; see e.g. Oracle v. Google re: DVMDex.h
  • Supplementing ICs in response to other side’s additional source code production; claim charts while discovery ongoing
  • An inadequate claim chart will be struck, but party is usually given e.g. two weeks to fix; at least in source-code cases, courts appear to give multiple chances to parties with inadequate ICs; see xxx re: ICs and “death penalty”
  • Timing of when 112(6) means-plus-function claims/limitations can be identified; may require claim construction

 

Print Friendly, PDF & Email