PART IV: SPECIFICITY: PINPOINTING, FACTS, AND MEANING

[TODO: intro to Part IV; “meaning” refers to specific meaning of terms from claim construction]

What specifically is meant by “specificity” in claim charts

When the Local Patent Rules (LPRs) require a chart identifying “specifically where” each limitation is found in an accused product, or in each item of prior art (see Part I), this is not a call for a great amount of specifics.

Taking a dozen, or twenty, or even (as the author has seen) fifty, pages of material from a manual and juxtaposing them with a single limitation, might be viewed as providing specifics (lots of them), but it is hardly a case of being specific. This goes not only for verbatim dumping of those pages into the chart, but also for citations pointing to large amounts of material, in which the reader is presumably expected to go hunting. See e.g. Intellectual Ventures v. JP Morgan (“Some assertions cite manuals hundreds of pages long without providing a pincite”), Droplets v. Amazon (“each claim limitation is followed by approximately 15-20 pages of screen shots. Most of the screen shots are duplicative”), Iris Corp v. US (“citing entire user guides and manuals …, requiring Defendants to comb through voluminous pages to identify specific alleged elements”); but also see cases in which the court appeared impressed with the size of claim charts, e.g. Robert Bosch v. Snap-On (“Having reviewed the two claim charts, which total almost 150 pages, the court finds that Bosch’s infringement contentions” provide sufficient notice).

The LPR “specifically where” requirement means almost the opposite from dumping in (or referencing) a large amount of material. It requires careful selection of what material “goes with” each limitation. Contrast the following, which is a realistic example of everyday claim-chart practice, not some caricature:

Limitation 1	12 pages of material…
Limitation 2	Same 12 pages of material…
Limitation 3	Same 12 pages of material…
Limitation 4	Same 12 pages of material…

with the following, unfortunately less common, preferred example:

Limitation 1	3 pages from the material…
Limitation 2	A different 2 pages from the material…
Limitation 3	A somewhat different 5 pages from the material…
Limitation 4	A somewhat different 4 pages from the material…

Yes, 3+2+5+4 adds up to more than 12. There is still some overlap in the second (preferred) example. Clearly it will often be difficult or impossible to achieve a set of “super-pinpoint” citations, in which each limitation is juxtaposed with distinct material that precisely pertains to a given limitation, and nothing more. Neither the other side’s product or materials, nor prior-art references, are organized in the same way as the patent claims. See super-pointing at xxx below. But the LPR requirements of “A chart identifying specifically where each limitation of each asserted claim is found within each Accused Instrumentality”, and “A chart identifying where specifically in each alleged item of prior art each limitation of each asserted claim is found”, will not be met if the party does not think through, and take seriously, what “specifically where” means (i.e. striving for a certain level of precision and specificity).

Recall from Part I that an ultimate goal of claim charts is to help narrow issues, not help leave them loosey-goosey until the last possible minute when the two sides figure out what they really want to say (the “shifting sands” or “musical chairs” approach which claims charts were specifically designed to deter, see e.g. O2 Micro v. Monolithic Power). Turning the RHC of each row of the claim chart into a wishing well, or what has been in another context (non-pinpointed legal citations) referred to as a game of “hunt the peanut,” is inconsistent with the purpose of claim charts.

It should be noted that the degree of specificity required depends on the stage of the litigation. See for example the two examples which begin this book, where a fairly unspecific (albeit brief) preliminary chart was in AVG v. EA acceptable, but a more specific non-preliminary chart, from a later stage of litigation, was in Sutton v. Nokia unacceptable.

Pinpointing, “location where”, names for locations, and level of detail

Claim chart cases often refer to the need for “pinpoint” citations. See e.g., UltimatePointer v. Nintendo (giving P one month in which it “SHALL amend its infringement contentions for claims requiring software instructions to include pinpoint citations to source code”), Theranos v. Fuisz Pharma (“It is not enough that Fuisz has provided some ‘relevant’ information, as they claim to have done. Their obligation is to pinpoint their contentions ‘as specific[ally] as possible'”), Tyco Healthcare v. E-Z-EM (P argues that D’s invalidity contentions are too voluminous, and asks court to strike, as it did in Saffran; however, here D has provided pinpoint citations, whereas in Saffran there was 800 pages of nothing but citations without explanation).

In this context, “pinpoint” refers, not to pinpoint legal citations (since claim charts are unlikely to cite legal materials), but rather to pinpoint factual citations.

Generally the courts do not require these in PICs, as the requirement (or desire) is most easily met with materials learned in discovery. The requirement frequently (but not always) arises in software patent cases involving source code. It is not always a strict requirement, e.g. Oracle v. Google (“Google’s heavy reliance on a nonbinding decision requiring ‘pinpoint citations’ to source code files is misplaced”).

The difference between pinpointing and its opposite (dumping) is shown below:

Limitation 1	Presence of this limitation is shown in defendant’s technical manual <TITLE> at page 123: <SHOW PARAGRAPH>
Limitation 2	See defendant’s technical manual <TITLE> pages 1-250, herein incorporated by reference.
Limitation 3	See defendant’s technical manual <TITLE> pages 110-160: <FOLLOWED BY 50 PAGES FROM MANUAL>
Limitation 4, with subparts (a), (b), and (c)	Presence of this limitation is shown in defendant’s technical manual <TITLE> at pages 121-124: <SHOW PAGES, WITH RELEVANT PORTIONS CIRCLED AND WITH ARROWS FROM THE CIRCLED PORTIONS POINTING TO SUBPARTS (a), (b), AND (c) IN THE LEFT-HAND COLUMN>

Limitations 1 and 4 above present examples of pinpointing, while limitations 2 and 3 present examples of dumping.

The seemingly-small difference between limitations 1 and 2 above – citing to one page vs. citing to 250 pages – is important. In the first case, the reader knows what the claim chart is relying upon for its assertion that the limitation is present. In the second case, the reader really has no idea what specifically the chart is relying upon among the 250 pages. The difference is the same as that in legal pinpoint citations. [TODO: once this draft is using pinpoint citations to cases, use an example.]

However, pinpoint factual citations are not primarily important as a time-saving device for the reader or user of the claim chart on the other side, nor even for the convenience as such of the court.

Rather, the author of the claim chart is expected to isolate or extract the essential factual components of its theory, from what is likely a much larger mass of material. A patent owner for example should be able to look at a product it has accused of infringement, and see, and point to an actual place (or actual places) where each element or step of its invention is embodied or practiced. See e.g. Sun v. Network Appliance (Sun’s selection of 300 lines of source code, out of 20 million produced, made a difference in refusal to grant SJ). In an imperfect analogy, a personal property owner should be able to see what it says is its boosted stuff in someone else’s pile. [TODO: hmm, what about those tricky personal property cases involving commingling, accession (Wetherbee v. Green), attachment, alteration, and tracing?]

The good this does, apart from making the claim-chart author work harder, so that the claim-chart reader need not, is this: A shorter row in a claim chart, or a more specific page reference, narrows down the party’s theory. By stating, “this very fact, or this very page (or small set of pages), is what corresponds to this claim limitation,” the claim-chart author is in effect also stating, “So you need not worry about other facts, or other pages, for this limitation.”

That is the problem, of course. Many if not most parties would prefer to not lock themselves down in that way. This is why even quite precise pinpoint citations are often joined to “See e.g.” or “See for example” or “Including but not necessarily limited to” clauses. [TODO: more acknowledgement that the reader precisely does NOT want to lock themselves in. Fear of commitment. What is proposed here is scary, as it means committing to one thing, and not another. The reader can point to section XXX as an example of what comes of over-commitment e.g. to literal infringement, then later can’t amend to include DoE. But…]

However, the other side is arguably entitled to know, not only what you specifically regard as infringing or invalidating, but also, at least by implication, what you are not maintaining is evidence of infringement or invalidation. [TODO: any support for that in cases?; it is a natural consequence of other goals, e.g. no shifting sands, amendment only for good cause, need for party to rely on other’s theories.]

The frequent practice of dumping large amounts of undigested matter into claim charts, with isolation or extraction of material assertedly corresponding to particular limitations or subparts, sometimes provokes requests for what have been called “super-pinpoint” citations. An example request of this sort comes from Vasudevan v. IBM, where the court granted IBM’s request to order Vasudevan to provide a claim chart with:

“only those lines of source code for each limitation that are necessary to allegedly meet each such limitation”

It has been explained at xxx and at xxx why this can be difficult to achieve. Briefly, neither the other side’s manuals, nor prior-art references, have been conveniently organized in the same way as the claim limitations. Further, products and references will often have one element or step taking the place of multiple claim limitations in the patent, or conversely multiple elements or steps corresponding to the single claim limitation; see e.g. MobileMedia v. Apple; Patent law has no requirement of one-to-one mapping of elements/steps in the RHC to limitations in the LHC. See e.g. Linear Technology v. ITC (limitations need not be entirely distinct from one another).

Still, there is a difference between trying to provide pinpoint factual citations, and not entirely succeeding on the one hand, and not even trying on the other hand. Two partial examples were provided at xxx in Part II. [TODO: xref to MPEP 2214 example, with quotes spanning multiple rows of chart, and xref to color-coded chart.]

It is worth remembering that “less is more.” A large claim chart, like a monster truck, suggests a feeling of inadequacy. Too much detail suggests, “I think he doth protest too much.” [TODO: this very book should follow this advice.]

[TODO: remind the reader that pinpoint is more likely REQUIRED post-discovery than in initial PIC (pre-discovery), but that this section is about a goal, not just about the strict requirement. Try to make clearer why the goal is good even for the claim chart drafter who fears commitment.]

Which instrumentalities are being accused, or references being asserted?

Another type of LPR requirement of specificity relates not to individual rows of a claim chart, but to the accused instrumentality. For example:

“Separately for each asserted claim, each accused apparatus, product, device, process, method, act, or other instrumentality (“Accused Instrumentality”) of each opposing party of which the party is aware. This identification shall be as specific as possible. Each product, device, and apparatus shall be identified by name or model number, if known. Each method or process shall be identified by name, if known, or by any product, device, or apparatus which, when used, allegedly results in the practice of the claimed method or process…”

Part I at xxx has walked through each component of this rule. The point here, which also applies to prior-art references (e.g. specifically listing prior-art combinations for obviousness), is the need for specificity is naming what appears in the LHC of a claim chart.

This sounds like it should be simple enough. For example, the sample chart in Part III gave “Defendant’s product X123” and the like as the product name. But a moment’s thought indicates that this likely falls below the level of specificity called for in the LPRs. What version of X123? Is there a specific part number or model number? Since this mythical example product is apparently software, were there variants for different platforms such as Windows, Mac, iPhone, or Android? Even if all known versions or variants are alleged to infringe, it’s easy to say that. Likely only some versions or variants will have been tested, and it is not always safe to assume that the untested versions behave in the same relevant way.

[TODO: more on version problems in claim charts, e.g. Ameranth v. Pizza Hut; Smartphone v. HTC; Bedrock or Droplets case involving claim chart with Windows version; Android versions; sometimes D demands separate charts for each version – makework, busywork; see xxx on representative instrumentalities.]

An important reason for the LPR requirement for specificity in product naming is not simply to get litigants to dot their i’s and cross their t’s. It is, as with pinpointing factual citations above, to lock down the case earlier rather than later. It is a lot easier to lock P into a case against a specific set of products when P’s contentions refer to some particular set of versions of some particular named product, than it is when P generally accuses “Defendant’s products,” or even “Defendant’s product X123,” or even “Defendant’s product Microsoft Word” (which has numerous versions, for numerous platforms).

The LPRs typically required, as quoted above, that “Each product, device, and apparatus shall be identified by name or model number, if known,” prompting the question how the plaintiff could not know. There are numerous cases in which P does not know all to-be-accused instrumentalities at the time of filing its case, roughly the time of its PICs, and the question later arises of whether P can add additional accused products to the case.

Courts appear to disfavor adding additional accused products, even more than it disfavors adding additional theories of infringement (see xxx). P’s ability to later accuse more products typically comes down to whether P should have known of the products at the time it filed the case. See e.g. Digital Reg of Texas v. Adobe (P failed to show existing claim charts were representative of newly accused products which have different software platforms from originally-accused products), Acer v. Technology Partners (P was not diligent in investigating D’s product line to identify the new products it seeks to accuse with amended contentions); but see Cap v. McAfee (improper for P to add 8 new products, but denying it leave to amend at this early stage in the litigation would likely just lead to another suit, so as a one-time exception P is permitted to amend).

The types of products which P might legitimately not known of, or not know of in sufficient detail to chart, or not know of in sufficient detail to determine coverage or non-coverage by an existing chart (i.e., does an existing claim chart of one product turn out to be “representative” of new products?), include: products in development (including alpha and beta tests); one-off custom products; bids; demos; limited editions; working models; and proofs of concept (POC). Some of these will be made or used or offered, even if not sold. Some beta tests of “forthcoming” products are widespread and well-known, possibly making a plaintiff’s lack of knowledge of the forthcoming product inexcusable (in the sense of closing off good cause for an amendment to include the “new” product).

More information about such products will often become available in discovery, either prompting an assertion that the product is essentially already covered under an existing claim chart that presents a “representative instrumentality” (see xxx), or prompting an amendment request to include the “new” product. A court will often ask whether sufficient product details could with diligence have been earlier learned; that P has only later learned them in discovery will not in itself make the information “new” in the sense that constitutes good cause for an amendment.

Speculative accusations against unnamed future products are of course frowned upon. See Intertrust v. Microsoft cited at PICs in Part II (“InterTrust asserts that past, present and as yet unmade future versions of Microsoft’s products do and will infringe its patents”).

The LPRs also state that “Each method or process shall be identified by name, if known…”. Inaccessible processes and methods, whose operation has been inferred at the time of filing and/or the time of PICs, may later become better known in discovery. Here too, the court could ask whether P, despite only later gaining information in discovery, could have earlier found out more. To take a software/internet example, even server processes located behind a firewall are often sufficiently “chatty” to reveal publicly-accessible names or identifiers for otherwise-hidden processes (e.g., xxx). However, a court may be more likely to give P a pass here.

As an aside, that methods/processes can be inaccessible, in a manner that products/devices are not, is even accepted so far as to shift the burden of proof in 35 USC 295 (“if the court finds — (1) that a substantial likelihood exists that the product was made by the patented process, and (2) that the plaintiff has made a reasonable effort to determine the process actually used in the production of the product and was unable so to determine, the product shall be presumed to have been so made, and the burden of establishing that the product was not made by the process shall be on the party asserting that it was not so made”). [TODO: somewhere need more on method claims, product-by-process, and 35 USC 295, but not here.]

Most of the above discussion focuses on accused products. Some of the same issues arise with newly-discovered prior art references. Note however that late amendment with “new” prior-art references should be more difficult than for “new” accused products. Not only are newly-disclosed prior-art references clearly not new, but their new discovery is arguably less excusable, as prior art by definition should have been publicly accessible at the time of filing. However, a once-accessible prior-art reference (such as a briefly-displayed conference presentation, see In re Klopfenstein) can later become inaccessible. [TODO: more on newly-discovered prior art, e.g. GeoTag v. Frontier; Best Medical v. Accuray; Streak Products v. Antec; Sybase v. Vertica]

[TODO: contrast 11^th hour delays in disclosing one’s own products (working/practicing), e.g. MediaTek v. Freescale Semiconductor (late disclosure of own product to bolster argument for injunction).]

Which dates are relevant?

When preparing a claim chart, it is useful to include (as least as temporary scaffolding while building the chart) dates in the column headers representing the patent claims and the accused instrumentality and/or prior-art reference. The date in the patent-claim column is either when the patent was granted (for infringement or non-infringement) or its priority date (for invalidity or validity). For example:

US 7,472,398 Granted Dec. 30, 2008	Defendant XYZ’s AppServer for Windows version 1.23 Released Jan. 2011
[1pre] A computer system comprising…	While the preamble is not limiting, …

or:

US 7,472,398 Filed Nov. 17, 2003	Prior-art reference: Jennings 6,717,593 Filed Sept. 12, 2000 Published/granted April 6, 2004
[1pre] A computer system comprising…	While the preamble is not limiting, …

The infringement example above appears unproblematic: the patent was granted before the stated release date of Jan. 2011. However, this is version 1.23 of the product. Consider whether an earlier version 1.0 or beta version (0.9) could predate the filing date of the patent, and whether that earlier version might have included the same technology that will be shown in the RHC of the claim chart. It is unlikely in this case (the product would need to have reached only version 1.23 in 8 years), but the draft claim chart is a good place in which to consider such possibilities.

In the invalidity example above, the prior-art reference was not published until it was granted, after the filing date of the ‘398 patent. Generally only published material is eligible as prior art. However, unpublished patents that eventually publish are a category of “secret prior art” under 35 USC 102(e), as of their filing date, not their publication date. Drafting the claim chart is a good time to consider whether your prior-art references truly are prior art. Note that priority dates often precede the filing date, to include earlier filings, including provisional patent applications, and that priority dates may differ on a claim-by-claim basis for continuations-in-part (CIP); see xxx.

When the information is available, dates for accused instrumentalities should consider the type of infringement being accused. The date for making a product should be older than the date for its sale. However, the date at which a product was offered for sale may predate the date the product was made, and not only in case of so-called “vaporware.” Use of a method may occur in early planning stages of a product, once all limitations have been practiced.

As noted in the infringement example above, it is important when accusing a current product to consider whether the current product has a history, possibly pre-dating the patent’s filing, which arguably includes practice of the patented invention. A defendant with full knowledge of its product line – fuller knowledge than plaintiff likely has (see “Who Knows More?” in Part I) – may possibly practice patent jujitsu on the plaintiff, by taking precisely what P has pointed to in the RHC of its infringement claim chart, noting that its history antedates the asserted patent claims, and turning P’s RHC into the RHC of an invalidity chart. “That which infringes if after, anticipates if before.” (Though anticipation and infringement are not exact mirror images, because the presumption of patent validity means that D’s proof must be by clear and convincing evidence, whereas P’s need only be by a preponderance of the evidence.)

Another such “gotcha” concerns the patent-owner’s own activities. Under the statutory on-sale and public-use bars, the inventor/owner has a one-year “grace period” in which it can publicly make, use, sell, or offer the invention before applying for a patent. Apart from the well-known risks of engineers and scientists giving conference presentations and papers more than one year before the patent has been filed (see e.g. xxx), working/practicing claim charts can present a related risk. In a working/practicing chart (see Part II), P makes a claim-by-claim, limitation-by-limitation presentation of its own practice of its patented invention. This treads very closely to what might be called a “statutory bar chart.” The date of practice is all that is keeping the nice working/practicing chart from becoming an invalidating chart demonstrating public use or sale. Thus, when drafting a working/practicing chart, ensure that the touted limitations were not also present in older versions of the same product. Given a choice between multiple instances of working/practicing the patent, it is advisable to pick an example that stays furthest away from the one-year grace period.

Dates of particular documents describing accused instrumentalities must also be considered. Particularly post-discovery, P may have a nice collection of D’s internal documents (such as presentations, requirements and specification docments, and emails) describing D’s product in ways that are helpful to P’s case. Such internal documents have a nice “straight from the horse’s mouth” quality. On the other hand, unlike the product itself, such documents may also be forward-looking and speculative, or conversely, outdated, with respect to the specifically accused versions of the products. D might glance at such documents and say, with some amount of truth, “We never did that” (or, if coached by an attorney, “That never came to fruition”), or “We no longer do that” or “We stopped doing that in version 1.1.”

As a final point about dates, there is a 6-year limit on recovery for patent infringement, e.g. no damages past the 6 years before filing suit (35 USC 286). Further, if P waits too long to bring its case, D may invoke the equitable defense of laches, in response to which P must provide a reasonable basis for delay, which may pose the question of whether P should have earlier known of D’s alleged infringement. The issues are analogous to those in adverse possession in property law. [TODO: open/notorious and method claims?; need to tie this to claim charts in some way, or to ability to learn of infringement via reverse engineering.]

[TODO: sometimes have referred to PHOSITA’s knowledge “at the relevant time”; what is that relevant time?; usually the time patent was filed; rarely some earlier date of invention; almost never date of infringement, and almost never the present date. Also see issues with 112(f) equivalence at date of filing, vs. DoE equivalence at date of infringement?]

Types of facts used in claim charts

While Part III covered the contents of the right-hand column (RHC) of a claim chart, little was said about what types of content are typically used. Some suggestion of the various types of factual material that can be employed is provided in some Local Patent Rules (LPRs) concerning, not the chart itself, but rather the mandatory disclosures that typically accompany claim charts. For example requires that the defendant (D) in a patent infringement case, at the same time that it provides its invalidity charts, also make available, for the plaintiff’s (P) inspection and copyright, material that will aid P in making out its infringement case:

“Source code, specifications, schematics, flow charts, artwork, formulas, or other documentation sufficient to show the operation of any aspects or elements of an Accused Instrumentality identified by the patent claimant in its Patent L.R. 3-1(c) chart” (N.D. Cal. LPR 3-4(a))

Similarly, P must provide, at the same time as its infringement charts, material that will aid D in making out its invalidity case:

“(a) Documents (e.g., contracts, purchase orders, invoices, advertisements, marketing materials, offer letters, beta site testing agreements, and third party or joint development agreements) sufficient to evidence each discussion with, disclosure to, or other manner of providing to a third party, or sale of or offer to sell, or any public use of, the claimed invention prior to the date of application for the patent in suit. A party’s production of a document as required herein shall not constitute an admission that such document evidences or is prior art under 35 U.S.C. ç 102;

“(b) All documents evidencing the conception, reduction to practice, design, and development of each claimed invention, which were created on or before the date of application for the patent in suit or the priority date identified pursuant to Patent L.R. 3-1(f), whichever is earlier; …

“(e) If a party identifies instrumentalities pursuant to Patent L.R. 3-1(g), documents sufficient to show the operation of any aspects or elements of such instrumentalities the patent claimant relies upon as embodying any asserted claims.” (N.D. Cal. LPR 3-2)

P and D will have already filed initial infringement and invalidity charts, and the document productions described above (which are mandatory disclosures, not requiring a discovery request) will come after those initial charts. Thus, the mandatory document productions are likely to prompt a second round of charts containing the sort of information specified above.

What then is in the earliest-filed PICs? This book has been referring to these as being filed pre-discovery, which is not quite correct, as they are really pre the mandatory disclosures set forth e.g. in LPR 3-2 and 3-4, but at any rate these initial charts are unlikely to contain internal or confidential material from the other side, and are more likely based on public sources such as manuals, web sites, perhaps open source (rather than proprietary source code), and so on. At any rate these early charts are expected to use factual material with details or level of granularity sufficient to show “where” (per the LPRs) each limitation is found in the other side’s product. As shown at PICs in Part II, this amount of level generally corresponds to a “reverse engineering or its equivalent” standard, but if P diligently mines all sources of information its pre-discovery charts will more likely find favor. Several types of evidence typically used in pre-discovery claim charts include:

• Marketing materials: These are typically frowned upon as lacking the detail or reliability necessary to generate limitations-level details; see e.g. Vasudevan v. IBM; View Eng. v. Robotic. See xxx. At the same time, some vendor statements, if they can be tied to specific limitations, may help avoid more complex proof; e.g. “We support X,” where X is a limitation or subpart.
• Standards documents: As discussed at xxx, these can be very important in showing the operation of a product, but only if the product’s adherence to the relevant portion of the standard can be shown. This is a somewhat circular undertaking; see e.g. xxx.
• Photographs of products: Photographs of products are often included in PICs, with arrows pointing to, or circles enclosing, key features. However, the photographs are often not at a sufficient level of detail, or capture only some externally visible aspect of the product. See e.g. the example from H-W v. Apple at “deficiency charts” in Part II, where attractive photographs were not used effectively. [TODO: possibly also see Droplets v. Amazon (chart screen shots and arrows, but missing labels to tie to claim limitations).]
• Screen shots, web site images: Screenshots have been provided in many cases, with mixed results, as often they are used as substitute for text. See e.g. Grecia v. Apple (xxx), Intellectual Ventures v. JP Morgan (“Much ‘evidence’ is simply cut-and-pasted screen shots from various manuals or websites shorn of context or plain English explanation”), Finjan v. Proofpoint (“generic marketing literature and screenshots of the type routinely rejected by courts”, “high-level generalities that do not specifically relate to the claim elements identified in each Claim”), Digital Reg v. Adobe (“Plaintiff improperly incorporates screen shots in lieu of explanatory text”). Clearly, if screenshots are to be used, they must – as with every other type of fact – be explained, and tied to a specific limitation (or even subpart of a limitation).
• Software Development Kits (SDKs) and Application Programming Interfaces (APIs) often have documentation that in some way reflects the internal operation of software-related products, or otherwise suggests the product’s operation.
• Third-party materials, if not relied upon to show indirect infringement by inducement, can be useful, as someone else has often already done a teardown or inspection of a product, and then written about it. [TODO: given an example of third-party books at the right level of detail, e.g. early Xbox or cable-modem reverse engineering books. Explain why user manuals often not at the right level.]
• Reports from commercial reverse engineering labs: Labs such as teardown.com appear especially useful for gleaning hardware rather than software related details of products.

After or during the parties’ disclosures of internal/confidential material, material such as the following will often be used in post-discovery claim charts, in addition of course to the types of material listed above from LPRs 3-2 and 3-4 (specifications, schematics, etc.):

• Forward-looking documents & emails: See the point made above at XXX about checking forward-looking documents (e.g. requirements specifications or emails) for purely speculative statements which may not have come to fruition.
• Source code: See the next section, which uses source code as an example of facts used in claim charts.
• Deposition transcripts can help avoid complex proof (“yes, we do X”), if it is clear that the deponent was referring to the relevant limitation, product, and/or feature; a deponent is not always speaking to the same thing that the attorney thinks he is asking about. As noted at XXX, deponents can even be asked to provide (even if it raises a “calls for legal conclusion” objection) a claim chart or its textual or drawn equivalent.
• Results of experiments, tests, reverse engineering: As a case proceeds, reverse engineering, experiments, and tests of the product may continue, even as internal documentation is provided. Whereas the reverse engineering that took place during a pre-filing investigation will generally remain undisclosed, absent a rare Rule 11 challenge, later product tests yielding information for a non-initial claim chart should likely be memorialized in a report that is attached to the claim chart. See e.g. xxx. Such testing will often be conducted by an expert witness or non-testifying expert consult; see below.
• Expert-supplied material for the claim chart: In addition to the expert’s own claim charts (or chart-like material) in the expert report, an expert may provide material, often in the form of a sworn declarative or affidavit, which will be referenced in a party’s claim chart. For example, an expert may provide necessary statements for an obviousness chart, regarding PHOSITA knowledge at the relevant time; or for a rebuttal (e.g. non-infringement or validity) chart, point out omissions or errors in the other side’s chart (the party can’t effectively do this without an expert); or for an invalidity chart, point out inherency. See xxx. The expert’s affidavit or declaration should be attached to the claim chart.

With all this information, perhaps the most important point is to actually USE it in the claim chart. It is not helpful to place the information in the chart, without doing something with it, i.e., explaining the information and using it to make an assertion, as discussed in detail in Part III. Simply including the information in chart is not using the information. See e.g. the case examples above where litigants merely dropped in screenshots without explanation, and without tying them to the limitation, e.g. one court’s complaint, “Plaintiff improperly incorporates screen shots in lieu of explanatory text.” Instead, using information includes parsing it to highlight the presence of limitations and subparts. This in turn means aiming for shorter, rather than longer, quotations from materials. See XXX.

Computer software code: A detailed example of one important type of evidence, including useful substitutes for source code

The following section presents as an example of what is simply one type, albeit an important one, of factual material used in claim charts.

Patent litigation involving computer code is not confined to software patent cases. Increasingly, cases involving medical devices, biotechnology, or industrial technology, at least partially involve software. See e.g. xxx.

In such litigation, each party’s “source code” (i.e., the code as written by programmers in languages such as C, C++ or Java) is tightly held at proprietary, confidential information, even when the software-based product itself, built from this source code, is widely available. For example, even though there are hundreds of millions of copies of Microsoft Windows available on the planet, there is a much smaller number of copies of the source code for Windows.

The defendant’s source code for its accused product is generally not available to the plaintiff until after P files its initial infringement contentions (PICs; see Part II). Thus, these PICs must be based on something other than the source code. This generally does NOT present a so-called “chicken and egg problem” or “Catch-22,” as the courts have sometimes characterized it (see e.g. xxx and xxx). That is because, while the source code is an excellent source of information about a product built from that source code, it is not the exclusive source of such information. Much can be learned about software-based products from the products themselves. If there is a difficulty in extracting information from software products, the difficulty is often more in acquiring the product to begin with (because, for example, it is only sold to known buyers and is not provided on the open market).

As initial substitutes for the source code, P can rely upon, for example:

• Open source code often used as a basis, perhaps with less-accessible vendor modifications, for some products. The product will typically openly acknowledge its use of open source, as this is required under the GPL.
• SDKs and APIs (see about at xxx)
• Static reverse engineering: Extracting textual information from software products, in the absence of source code: strings, dependencies and other metadata, disassembly, and (feasible for Java code) decompilation.
• Dynamic reverse engineering: Running products with instrumentation to log dynamic activity, e.g. “packet sniffers” such as Wireshark and Fiddler.

See the fuller discussion at PICs and pre-filing investigation in Part II.

Once source code is available, its use in a claim chart requires some care. First, not all the source code produced in a case necessarily corresponds to the accused product. A source-code repository often contains code that “ended up on the cutting-room floor” is is otherwise not included in all versions of a relevant product. For this reason, source-code citations in infringement claim charts should often be checked against the product itself (by, for example, seeing if the product contains pathnames of source-code files, as it often does, even when it does not contain the source code itself).

Similarly, not everything that did make its way into the product is necessarily ever executed. The extent to which code is actually run does not affect infringement of apparatus/device claims. However, it does affect infringement of method claims (and may affect damages for apparatus/device claims). See xxx on the problem of “latent code.”

Second, source-code citations should typically include complete pathnames, especially when these include product names (or product codenames) and version numbers. For example, not merely “located 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”.

Third, the temptation should be avoided of trying to provide pinpoint source-code citations using mere line numbers. Instead, use as much of the other side’s naming as possible, including names of functions, structures, methods, messages, etc. For example, not “…storage.c lines 1000-1020” but: “…storage.c function foo() at lines 1000-1020.” This is important because the other side’s names are vital in avoiding merely-conclusory claim charts that merely ape or mimic the claim language (see xxx), and because the other side’s names are a better way of showing the location where infringement occurs.

While source-code line numbers appear to provide a precise location, thereby honoring the LPR requirement that claim charts specify a location where infringement occurs, the line numbers are to files which, as noted earlier, have only an indirect relationship to the actual infringing product. Yes, the source code is the “source” for the accused product, but not everything in the source necessarily made its way into the product.

Depending upon how the parties have arranged source-code printing (typically under a court protective order), Bates numbers may be available and should be used in the claim chart, again so long as it is understood that these have only an indirect relationship to the actual accused product.

Quotation from proprietary source code in claim charts is often restricted under court protective orders forbidden verbatim copying of the source code. To quote a single entire line of the source code may be viewed as making a copy. The claim chart should then use the function, structure, and variable naming from the code, but without “logic” (e.g., something with an equals sign). [TODO: show example; already covered this at xxx?] When based in part on proprietary source code, the claim chart itself may need to be maintained at a secure location. The party’s own personnel may be restricted from seeing the chart, as it contains references to the other side’s source code; such charts will have an “attorneys-eyes-only” designation, or perhaps there will be a second redacted version.

Source code may also be employed in an invalidity chart, but because source code is generally proprietary material which was not publicly accessible at the relevant time, the source code itself is generally not prior art. Rather, such source code is evidence of what a publicly-accessible product or method did, or evidence of what was on sale or in public use. See also the point below regarding source-code comments, which are particularly unlikely to constitute prior art. [TODO: case involving proprietary source code + public product?]

When examining source code, and/or while reverse engineering software, an expert or consultant will generally rely on the text of the claim limitation to help locate potentially relevant code in the accused or prior-art software. However, there are “gotchas” involved with keyword searching or “token matching” of code.

On the one hand, given a claim limitation for A+B+C, code that embodies and/or practices that claim limitation might use entirely different language, X+Y+Z. It is possible that when looking not only for A+B+C but also for known synonyms and examples, one might never find elements or steps X, Y, and Z in the code.

Conversely, and the danger which appears to be more frequently encountered, is that elements or steps named A, B, and C are found, but that they do not relate to the A, B, and C in the (properly construed) claim limitations. As one example, the same term “communityList” in code might refer to social media, or to a network router. It is often necessary to “drill down” below the name to see that the name is an accurate description matching terminology as used in the patent claim.

When X+Y+Z are found as a match for claim limitation A+B+C, the different naming does not in itself invoke the doctrine of equivalents (DoE). Even with entirely different naming, and indeed different code, one can have literal infringement. See “Structuring the Comparison” in Part III, including the point that this is not a “ipsissimis verbis” test.

Somewhat like names of functions or structures, comments in code can be essential to locating potentially relevant code. The comments themselves can often be extremely useful in short-circuiting what might otherwise be a complicated analysis of a piece of code. For example, if the comment states, “The following function is where we do A, B, and C,” this arguably may eliminate the need to carefully examine the following function. Such a comment might be perfect material for inclusion in the RHC of a claim chart, juxtaposed to claim limitations A, B, and C.

However, the comment might be outdated, incorrect, or referring to a somewhat different A, B, and C. Further, comments are one part of the source code which will definitely be removed when compiling the actual software product, and hence make poor evidence of publicly-accessible prior art.

When using source code in a claim chart, care should be taken that the “direction” of the source code matches the direction of the claim limitation. For example, don’t use a DoSend() function to meet a limitation which reads a message, unless one can show why reading a message is a reasonable inference from sending. Presumably due to copy and paste from one claim to another, claim charts often confuse client/send/write with server/receive/read.

For further information, see a forthcoming book by the same author: Schulman, Source Code in Patent Litigation. In addition to the above topics, this also covers source-code discovery, spoliation, the source-code examination, printing, POs, expert reports, and other topics.

[TODO: is there some way to generalize from the points above re: source code, to e.g. schematics?; make the point that claims are sometimes generated starting with materials like source code or schematics?]

Using claim construction in claim charts

Claim construction is the legal issue in patent litigation, but this book is concerned largely with factual issues in patent litigation, and thus discusses claim construction less than one might expect. At the same time, clearly there are important intersections between claim construction and claim charts, and these are noted below.

Claim charts often explicitly incorporate claim construction, including the court’s claim construction (in later charts), the party’s desired claim construction (in earlier charts), or a set of alternative claim constructions (perhaps to show that the facts selected for the RHC of the chart match the limitation in the LHC, under a variety of constructions). See xxx and xxx in Part II. Having duly included claim construction (using bullets in the LHC, or in a middle column), many charts nonetheless neglect to use the claim construction in the RHC, with facts being presented in terms of the literal unconstrued claim language, rather than the language as construed; see e.g. xxx. This is particularly unfortunate, as claim construction can often help structure the comparison between the LHC and RHC of the chart, because claim construction often calls out features not explicit in the unconstrued claim language; see xxx in Part III.

Claim charts always employ some claim construction, even if it is merely implied by the choice of what factual material to juxtapose with a given claim limitation. That is, a party chooses and reveals at least an implicit claim construction, simply by what it chooses to put into its claim charts. Even in the earliest PIC, a claim chart needs to employ a reasonable claim construction; see e.g. Eon-Net v. Flagstar (reading “hard copy” onto web page was not simply wrong, but reflected an unreasonable claim construction). In the process of creating an early claim chart, a litigant will often discover what claim constructions it desires, and one purpose of early claim charts is to to “tee up” the case for a Markman claim-construction hearing (see xxx on Markman).

In preparation for a Markman hearing, litigants will typically prepare claim-construction charts, and the two sides will collaborate on a “Joint Claim Construction Chart.” The differences between these documents on the one hand, and claim charts on the other, are discussed at xxx and xxx in Part II.

Litigants will often desire to amend charts following a Markman ruling (just as there is often a difference between pre- and post-discovery charts). However, one of the underlying goals of claim charts is to avoid the “shifting sands” approach to claim construction, e.g. radically changing theories of infringement/invalidity after an unfavorable Markman ruling; see xxx on the policies behind claim charts and xxx on amending claim charts. Allowance of post-Markman claim chart amendment often requires some element of “surprise” in the claim construction rule, the point being that if the party could have anticipated the possibility of a given claim construction, it ought to have been built into the chart in the first place. Ways of doing this were shown at xxx in Part II, “Contentions employing explicit or alternative claim constructions.”

Claim construction often employs a set of “canons,” basic presumptions which can be rebutted (it is said “for each canon of claim construction, there is an equal and opposite canon of claim construction”) but which serve at the very least as useful starting points. Some of these canons are discussed below, as they might relate to the use of claim construction in claim charts. The following canons would affect what to put in the RHC of a claim chart to align with the limitations in the LHC, and could be used in crafting explanations for why the RHC matches (or does not) the LHC; see explanations at xxx in Part III.

The following may also serve as a brief introduction to claim construction for the non-attorney experts and consultants who are often tasked with drafting claim charts.

Plain and ordinary meaning (P&OM): The words in a patent claim are presumed to mean what they ordinarily and customarily mean, to someone skilled in the relevant technical field, unless something rebuts this presumption. In interpreting a patent claim, one usually will start out with, and end up at, the P&OM.

However, for one or more claim terms, one side will generally desire a broader or narrower reading than seems ordinary. Good examples of such “stretching” are the Markman case itself, with an attempt to read a dry-cleaning “inventory” claim term onto money (as opposed to articles of clothing), and conversely an attempt to stretch “value” to include non-monetary items in Bid for Position v. AOL.

In a claim chart, the P&OM rule can help caution the claim chart drafter from trying to stretch too far in cleverly but unnaturally reading the LHC claim limitation onto things in the accused product or prior-art reference which are poor fits. Also note “Claim scope: broad is not always better” below.

P&OM will not work (i.e., the presumption will be rebutted) when the inventor is acting as their “own lexicographer”; see below.

Inventor as “own lexicographer,” specification as dictionary: While the ordinary meaning of a word, to a person skilled in the field, usually applies (see P&OM above), the inventor however can invent terms, and/or use terms in ways that differ from their ordinary meaning. This is referred to as the inventor “acting as their own lexicographer” (see e.g. Desper v. QSound). This requires that the inventor intentionally do so in the patent specification, for example by using words such as “is a” or “defined is” or “refers to”, by putting a word to be defined inside quotation marks, and so on. Such intentional definition in the specification beats out plain and ordinary meaning.

Using dependent claims to understand independent claims: Recall the example of a vehicle-speed patent in “Filling out the left hand column” in Part III, where a dependent claim 5, “A method as recited in claim 1, wherein the first protocol comprises amplitude shift key” was shown to reveal something about independent claim 1 – that claim 1 could (though need not) be “read on” (i.e. be made a basis for an infringement assertion against) an amplitude shift key protocol.

In addition to providing (non-limiting) examples of independent claims, dependent claims also, somewhat non-intuitively, show that an independent claim must be broader than what is specified in its dependents; this flows from the rule of “claim differentiation,” which states that different claims are presumed to have different scope.

Claim differentiation is a presumption which can be rebutted by a more explicit statement of claim scope, such as use of means-plus-function (see below).

Using adjectives to understand claim terms: Somewhat similarly to how a dependent claim can broaden (or, rather, show the breadth of) an independent claim, likewise the use of an adjective can show the breadth of a noun. For example, the term “steel baffles” (from Phillips v. AWH) shows not only that baffles can be steel, but equally shows that baffles need not be steel (otherwise, the adjective would be redundant, thus violating a rule of claim construction which views all words in a claim as significant).

Using small differences between claims, or between claim limitations: It follows from the presumption of claim differentiation that small differences between claims must mean something. Likewise between two otherwise-identical instances of a limitation.

For example, given two claims that differ only by the use of the phrases “X resting on Y” vs. “X supported by Y,” the presumption would be that there is a difference between resting on, and supported by. If identical material were presented in the RHC of a chart for these two claims, or if the RHC for one claim merely cross-referenced the other, without any accounting for the subtle but likely significant difference, this might at the very least suggest that one of the two claims is superfluous. [TODO: more (here or Part III) on this problem of identicality in RHC implying identicality in LHC.]

The presumption of consistency: Each claim limitation has certain capabilities or attributes which should be consistent throughout the claim, in that any limitation or element appearing multiple places in a claim will pick up attributes from each of its occurrences. For example, if “a framis” is connected to a widget and later “said framis” 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. See e.g. Oak Tech v. ITC (antecedent basis within claim; “said x” carries with it previous attributes of x). In fact, this should carry across an entire set of claims, an entire patent, and related patents (e.g. CVI/Beta Ventures v. Tura).

However, and perhaps surprisingly, this is merely a presumption, and therefore rebuttable. See e.g. Aventis v. Amino, where claim language itself overcame the presumption of consistency, with “substantially pure” referring in one claim to an intermediate product, and the same “substantially pure” term having a different meaning in a claim to an end product. Similarly, see Bell Atlantic v. Covad (“channel” refers to bidirectional communications when referencing prior art, but unidirectional when referencing claimed invention). [TODO: perhaps explain why this doesn’t violate the “nose of wax” rule below.]

Using examples and embodiments in the specification: Examples and “embodiments,” given in the patent specification to describe claim terms, can affect the reading of a claim and its limitations. A claim term generally should not be limited to the examples given of it in the spec, even if there is only a single example (see Comark v. Harris), because this would constitute impermissible “importing” of the spec into the claims. When the inventor lists some examples and then states that “these do not in any way limit the scope of the invention,” this boilerplate can actually make a difference in not limiting scope (see Aria Diagnostics v. Sequenom).

However, a larger range of more disparate examples will often lead to a broader scope for the corresponding claim term. For example, where a claim refers to use of a “standard,” and the spec lists as examples, a range of 10 different standards from different types of organizations, this is more likely to support reading the term “standard” onto some eleventh non-listed standard, than if the spec had merely listed two IEEE standards. As one book on patent drafting states, “You get what you disclose.”

Pay attention to small, non-technical words: Technical experts working on claim charts have a natural tendency to ignore common, seemingly non-technical “filler,” words such as “therein” or “distinct.” However, the word “therein” played a key role in a patent case involving the location of a water chamber in the Supersoaker toy (Larami v. Amron), and the word “distinct” was important to a case involving XML (i4i v. Microsoft). Consider a claim term “X or Y”: is that an inclusive-or or an exclusive-or? If the accused product includes both X and Y, the case could turn on the meaning of “or”.

The following is a list of common articles, pronouns, and modifiers that have been the subject of litigation with divergent outcomes: a/an; about; abut; adapted to; adjacent; at least; attached to; between; connected to; corresponding; coupled with; different; directly; each; easily; first/second…; generally; improved; near; obtainable by; one; portion; predefined; predetermined; regardless; said, the; substantially; such that; therein; without requiring (see Manzo et al., Patent Claim Construction in the Federal Circuit).

Pay close attention to seemingly-vague connectives, e.g. “in association with”, “correlated to”, “based upon”, and so on. If nothing else, such a term can serve as a “wildcard,” supporting almost anything, so long as it supports something. For example, if the claim requires “X is based upon Y”, the RHC of the claim chart must show some relationship between X and Y, and it is a mistake to neglect to show this, but the relationship can be fairly tenuous.

Pay attention to word endings: Technical experts tend to ignore word differences such as that among “programmed”, “programmable”, and “programming.” However, the -ed vs. -able vs. -ing distinction is crucial (and proved so in Intel v. ITC). “Programmable” means merely capable of being programming; it’s a mere capability, and need not have occurred. “Programmed” means it occurred – but not necessarily at the time of, or as part of, infringement; it is a mere precondition (see xxx) that needs to have been done at some point by someone (not necessarily the accused infringer). “Programming” likely means actual occurrence as part of infringement. Thus, it is easier for a plaintiff to show -able than -ed, and easier to show -ed than -ing. This is a general point, not limited to these particular three word endings.

Broad claim scope is not always good for the patent owner: When drafting an infringement claim chart, it is tempting to interpret claim terms broadly to cover the accused product, like using an “inventory” claim term to read on cash, as in the Markman case. However, such broad readings can hurt the client when it comes time to argue invalidity. If a claim is made to read on accused X, then this implies a claim construction under which the claim is also anticipated by prior-art X. “That which infringes, if after, anticipates, if before” (an old patent law adage which is not quite true because of the higher burden of proof for invalidity, but close enough). There is one single claim construction for both infringement and invalidity. The claim construction is not a “nose of wax” to be twisted this way and that for the convenience of the patent owner. Contrast so-called “split systems,” with bifurcated infringement and invalidity hearings, featuring the “Angora Cat problem” (http://www.ipglossary.com/glossary/split-system-patent).

The same point applies to the defendant’s invalidity assertions. If D states that prior-art X anticipates the patent claim, or that some portion of X matches a particular claim limitation, then D’s own later practice of X would infringe. What’s sauce for the goose is sauce for the gander. At the same time, whereas P must find a single claim construction that supports both infringement and validity (AND), D on the other hand can live with one that supports either non-infringement or invalidity (OR), though naturally it would prefer both.

Means-plus-function claims/limitations: Parts II and III have already covered handling of “means for” limitations. Sometimes it is not clear whether a claim employs means-plus-function, covered under 112(f). “Means for…” is a sure signal, but how otherwise can one know that a limitation is purely functional? The cases state that one must search the entire claim (not merely the limitation) to see if it “recites function without reciting sufficient structure for performing that function” (CCS Fitness v. Brunswick).

Having found a means-plus-function limitation, understanding its scope requires finding corresponding structure in the specification, and this structure must exhibit “clear linking” to the functional claim language, or else fail for indefiniteness (Med. Instrum. V. Elekta AB). [TODO: make sure means+function in Parts II and III include looking in entire claim for sufficient structure, and include need for “clear linking” from structure in spec to functional claim language.]

Preambles: It has been noted that the preamble to a claim is generally not limiting, when it merely sets forth a purpose/use of the invention, rather than being necessary to describe the boundaries of the invention itself. This illustrates a more general rule of patent law in which structure/implementation/what-it-is matters more than function/use/purpose/what-it’s-for/how-it’s-used. This same point also applies to “whereby” clauses (see xxx), but not “wherein” clauses.

However, a preamble is a limitation when, for example, it “breathes life and meaning into the claims” (see e.g. Catalina Marketing v. CoolSavings.com), a phrase which does not immediately seem useful. If a claim already recites an entire complete structure, without need of supplementation from the preamble, then the preamble is likely not a limitation, and is perhaps merely setting forth a use (akin to a “serving suggestion” on food packaging) for the claim itself. If there is structure, it is more likely to be a limitation. At the same time, a preamble could be a limitation for other non-structural reasons, e.g. if it was relied upon at the PTO to distinguish prior art (Marrin v. Griffin). [TODO: maybe note parallel, that means+function arises when there is no means, i.e. no structure; and that preamble is a limitation when it is needed to provide structure.]

The role of prior art and claim validity: It is sometimes said that prior art helps define claim scope, and indeed the scope of a valid claim cannot include the prior art. There must be some addition, at least non-obvious even if not novel, over the prior art. Therefore, the prior art can help clarify the claim’s scope.

However, the prior art should not be used to redefine the claim’s scope. The distinction is important: were the claim’s scope narrowed, merely to avoid the prior art, this would constitute a claim construction whose goal was preserving the claim’s validity, when the claim should instead be found invalid. [TODO: but e.g. Apple v. Articulate Sys., reading claim in a way that avoids the prior art?]

Conclusion to Part IV

[TODO: quickly summarize what has just been discussed: what “specificity”, “pinpointing”, and “location where” mean; instrumentality details; dates; types of facts used in charts (including extended example of source code); and using claim construction in charts. Is there anything that ties all this together?]