Source code ch.27: Expert reports

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 27: Software expert reports and affidavits

Table of contents

  • 27.1 Goals & role of the expert report
  • 27.2 Bare-bones or comprehensive expert report?
  • 27.3 Required contents of the expert report under FRCP 26
    • 27.3.1 Facts or data “considered”: a broader category than “relied upon”
    • 27.3.2 Exhibits
    • 27.3.3 All publications for the past 10 years: why not merely a selection
    • 27.3.4 Compensation
    • 27.3.5 All cases for only the last 4 (as opposed to 10) years
  • 27.4 Potentially important non-FRCP expert report contents
  • 27.5 Software expert’s opinions
    • 27.5.1 Ways in which experts (consciously or unconsciously) avoid stating an opinion
    • 27.5.2 Be explicit: all asserted claims, all limitations, all accused products
    • 27.5.3 Terminology & wording: “red flag” words, characterizations, and “patent profanity”
    • 27.5.4 Degree of specificity: both broad & narrow
    • 27.5.5 “Reasonable degree of certainty”: what it means; not a mere mantra
  • 27.6 Bases & reasons for software expert’s opinions: facts, principles, and methods
    • 27.6.1 Facts: based on source-code exam and/or examiner, and non-source facts
    • 27.6.2 Principles: generalizations, background, assumptions (including claim construction), and expert’s experience/training
    • 27.6.3 Methodology: software inspection, source code review, reverse engineering, code/text comparison
    • 27.6.4 “Reasons” distinct from methodology
  • 27.7 “Teaching”: General principles & authorities in the expert report
  • 27.8 Exclusion, weight/strength, sufficiency & insufficiency of expert reports
  • 27.9 Supplemental reports, rebuttal reports, timing, and “backdooring”
  • 27.10 Drafts of expert reports and “ghostwriting”
  • 27.11 Impact of protective order (PO) on expert report
  • 27.12 Expert affidavits, especially their role in summary judgment (SJ)
  • 27.13 Deposition & expert report
  • 27.14 The other side’s expert report
  • 27.15 Excerpts from software patent expert reports

27.0 Introduction

  • A testifying technical expert in a software patent case will prepare an expert report covering infringement (literal or equivalence) and/or invalidity (anticipation, obviousness, lack of enablement, on-sale or prior-use bar).
  • Specific topics may also include the PHOSITA’s level of skill at a relevant time, the PHOSITA’s understanding of claim terms at the time the patent was filed, non-infringing alternatives, or the patentee’s practicing of its own invention. (PHOSITA = “person having ordinary skill in the art,” here an ordinary non-inventive software engineer who, however, knows all of the prior art, and who might have a Ph.D., x years in the industry, etc.)
  • This technical expert report is separate from an economics/accounting expert report focusing on damages, and likely provides important underpinning for the economics/damages report. (And there are technical aspects to damages, e.g. helping inform which categories or items to count or “monetize” in D’s spreadsheets of equipment inventory/sales/purchases, or of service subscribers.)
  • The Federal Rules of Civil Procedure (FRCP) require an expert report (Rule 26(a)(2)(B)). The FRCP Advisory Committee Notes explain that, in addition to the reasons provided for other required disclosures, such as helping make “an informed decision about settlement,” an expert report provides the opposing party with “a reasonable opportunity to prepare for effective cross examination and perhaps arrange for expert testimony from other witnesses” (1993 notes). See FRCP 26 with ACN notes.
  • The expert report “is intended to set forth the substance of the direct examination” and “should be written in a manner that reflects the testimony to be given by the witness” (1993 notes).
  • The report discloses not only the expert’s opinions, but the bases for these opinions: general principles or assumptions, facts, and the expert’s “thought process” in moving from raw facts to considered opinion (see chapter 8 on expert methodology in software patent cases).
  • See also chapter 8 on the role of experts in software patent litigation
  • This chapter focuses on expert reports in software patent litigation; for general guidance on writing expert reports, see especially David Malone, Expert Report Rules (2nd ed., NITA, 2013); Steven Babitsky & James Mangraviti, Writing and Defending Your Expert Report: The Step-by-Step Guide with Models (SEAK, 2012)
  • [Note ASTM E620-11 “Standard Practice for Reporting Opinions of Scientific or Technical Experts” for use in litigation; other widely-accepted templates/standards?]

27.1 Goals & role of the expert report

  • Newer experts may not understand the role of the expert report in the case: is the expert report evidence?; will the judge and jury see it?; is the report written for the expert’s clients or for the other side?; given that most cases settle before trial, what is significance of expert report as disclosure for (unlikely) trial testimony?; etc.
  • Expert report is intended primarily for the other side to facilitate deposition it takes from the expert witness
  • Expert’s conflict between natural obsessiveness on the one hand, and tight deadline and budget on the other hand, can partially be resolved by remembering the usually limited purpose of the expert report.
  • Thus, often no particular immediate benefit to expert’s clients to have a lengthy “comprehensive” report, BUT:
  • Expert can only testify at trial to opinions and topics sufficiently (“completely”) disclosed in the expert report; failure to timely disclose an expert opinion in a report may preclude an expert affidavit based on that opinion [case]
  • Unlike the party’s own contentions, expert reports can be cited re: summary judgment (SJ); see see also affidavits at 27.12 below
  • The report may help educate judge re: SJ, general background, etc. [cite cases where court found expert reports helpful in summarizing source code issues]
  • One expert’s report is often relied upon by other experts; especially economics/damages experts relying on (assuming truth of) technical expert report
  • While expert report is usually not admissible evidence (hearsay), nonetheless other experts may reasonably rely, and expert report may serve as evidence if e.g. summary of voluminous evidence under FRE 1006 (see e.g. Personal Audio v. Apple)
  • Attorneys on both sides often refer to the expert reports; a point not made in the expert report may simply get lost (or be constantly revisited, per Proverbs 26:11)
  • Role of expert reports in “framing” the technical issues in the case
  • Some experts view deposition preparation as their most important goal for the expert report, the thinking being that a properly-prepared report will allow the expert, in response to any question, to simply point to specific passages in the report; but see Soverain Software v. JC Penney, where expert barely skirted being viewed as non-responsive
  • With an eye towards settlement, the report may educate the other side to the problems in its case, and the strength of one’s own case, or as a demonstration of a party’s seriousness and resources
  • Report is unlikely to be viewed by the jury [but see cases]; hearsay status of expert reports
  • So is the expert report “evidence”?; at least a portion of the report may e.g. serve as a summary to prove the contents of voluminous materials under FRE 1006

27.2 Bare-bones or comprehensive expert report?

  • Expert report length is a result of competing motivations; bare-bones and comprehensive approaches each have benefits and disadvantages
  • The bottom line is that FRCP 26 (see below) requires “complete” report re: “all” opinions, bases, and reasons; see xxx below
  • FRCP ACN and case law on “complete” and “all”; can missing opinions/bases/reasons be “fixed” in deposition, without a supplemental report, and will a supplemental report even be allowed (or conversely, be required)?
  • Somewhat analogous to loading up a patent specification so that later amendments are not “new matter,” the desire to cover all bases in an expert report may lead to generic catch-all lists of topics; however, mere mention of topic, without a specific opinion on that topic, and stated basis for the opinion, may not preserve that topic for expert testimony
  • Attorneys can’t later fill-in or infer any missing essentials from the expert report [case]
  • Anticipate opposing expert’s likely responses, or keep in back-pocket for rebuttal?
  • Benefits of a “small target”; “when in doubt, leave it out”
  • Disadvantage of a small target: opponent has a more precise target on which to focus
  • Benefit of a comprehensive report: the expert’s need or desire to educate himself and his own side in any subtleties of his opinions and the bases for them. Something not recorded in the expert report may simply get lost.
  • Comprehensive expert report as deposition preparation: can the expert successfully navigate a deposition without a written report recording every reason why a particular basis leads to an opinion, why alternative opinions were rejected, and so on?
  • “Comprehensive” reports are sometimes produced with cut & paste; but court unlikely swayed by mere volume of pages or footnotes (note case in which court was clearly annoyed at same lengthy footnote repeated over and over in report), nor is mere repetitiousness likely to persuade the other side of one’s seriousness and resources to proceed to trial.
  • Highly-repetitive reports only superficially appear comprehensive (“look how many screenshots and footnotes!”), and make more work for everyone. But there is a somewhat legitimate fear that a more sensible arrangement (information appears only once in the report, with cross-references as appropriate) will be insufficient to meet the expert’s burden of making explicit complete statements about each and every product, claim, and limitation (see xxx below on exhaustiveness) [cite case in which party punished for efficient non-repetitive infringement contentions employing cross-references].
  • There should be a reason for the level of detail used in a report, beyond the fact that the expert has OCD
  • There should also be a reason for report length, beyond a misconception that “bigger is better”
  • Report length is affected by the desire to hold material in reserve for a rebuttal report, rather than prematurely educating the other side on weaknesses in its likely arguments; this is risky (see below on “supplemental” expert reports). Experts may lean towards a “preemptive strike,” but it is usually more effective to not respond to an argument until after the other side first makes the argument.
  • The expert’s desire to not prematurely commit to a particular claim/code mapping may lead to somewhat brief vague formulations, and a less fleshed-out report; however, this may lead to a report which mimicks or parrots the claim language (see ch.xxx) without sufficient grounding in the terminology used by the infringing/anticipatory technology.

27.3 Required contents of the expert report under FRCP 26

  • FRCP 26(a)(2)(B) states that the expert report — “except as stipulated” — “must contain” the following:
  • (i) a complete statement of: (a) all opinions the witness will express and (b)the basis and (c) reasons for them;
  • (ii) the facts or data considered by the witness in forming the opinions;
  • (iii) any exhibits that will be used to summarize or support them;
  • (iv) the witness’s qualifications, including a list of all publications authored in the previous 10 years;
  • (v) a list of all other cases in which, during the previous 4 years, the witness testified as an expert at trial or by deposition; and
  • (vi) a statement of the compensation to be paid for the study and testimony in the case.
  • Opinions, basis for opinions, and reasons for opinions are discussed in detail below at 27.5 and 27.6

27.3.1 Facts or data “considered”: a broader category than “relied upon”

  • The FRCP Advisory Committee Notes (ACN) explicitly state that “considered” is very broad: “The disclosure obligation extends to any facts or data ‘considered’ by the expert in forming the opinions to be expressed, not only those relied upon by the expert” (2010).
  • This means that the report must include a list of at least the Bates numbers of everything which the expert at least glanced at in (during the process/period of) forming his opinions.
  • All materials “considered” must be produced to the other side, if not otherwise readily available.
  • The expert has a duty to keep materials considered: this presumably would include output from test programs, intermediary results generated during product reverse engineering, etc.; this is perhaps true even if those tests were done on systems to which the other side has equal (or even superiod) access.
  • All Source Code Considered: every source-code file scanned by an indexing/search program presumably is NOT for that reason “considered” by the expert; however, were the expert to reply to a “what didn’t you look at?” deposition question with a proud “my program looked at everything,” that result might change.
  • [Should the expert simply list each top-level entry in each source-code production (each drive, CD, etc.) as having been “considered”?]
  • Of course, if the expert has considered the report of a non-testifying examiner, that too must be listed, even if the expert does not “rely” on the report.
  • Possible implications when a large amount has been “considered” but not relied upon

27.3.2 Exhibits

  • See “Demonstrative exhibits” in ch.28
  • While exhibits are to be attached to the report, the exhibits to be used at trial often won’t be known until just before trial
  • Exhibits may include FRE 1006 summaries of voluminous material, including summaries of source code
  • Generally preferable to have one exhibit per accused product, even if repetitious?

27.3.3 All publications for the past 10 years: why not merely a selection

  • Some experts believe they should only list those publications which are relevant to the case; however, opposing counsel should be told about, and given an opportunity to ask the expert about, the expert’s bizarre self-published work on the gold standard, Bretton Woods, and the phases of the moon.

27.3.4 Compensation

  • Generally not only rate per hour, but number of hours worked to date
  • Possibly including percentage of total income from non-litigation vs. litigated-related work
  • Oddly, some clients prefer as little detail as possible in invoices; however, expert report can use the compensation disclosure to also show diligence in source-code examination, which is often as issue in these cases (see chapter 14 on scheduling/timing)
  • See fees in chapter 8

27.3.5 All cases for only the last 4 (as opposed to 10) years

  • In a source-code case this information will be used to determine whether the expert/examiner has conflicts of interest which could preclude source-code access; this has presumably been addressed by the time of the expert report (see chapter 8 on conflicts of interest)
  • That the FRCP requires only four years of prior cases, in contrast to ten for publications, is perhaps based on courts’ interest in not overly restricting the pool of available qualified experts (see BIAX v. Brother).
  • The parties can stipulate to a longer period than 4 years.
  • An expert’s NDA with a previous client may state that the expert’s engagement is confidential. But using this as a rationale for not listing the engagement may be perjury (see Cardiac Pacemakers v. St. Jude Medical).

27.4 Potentially important non-FRCP expert report contents

  • Field of expertise, including any directly relevant industry experience; the expert’s specific field of expertise required to form the opinions: while attorneys often refer loosely to “computer science” (CS), the relevant field is more often “software engineering” (SE); within CS or SE, the expert will often have a particular expertise which should be noted, while not precluding his ability to opine on more general areas.
  • Consider whether, and how, the expert’s stated “field of expertise” will align with the party’s designation of the “art” in which the PHOSITA will have ordinary skill.
  • Especially if the expert will be pointing to experience as part of the basis for opinions, highlight any non-litigation experience (especially extensive code reading or analysis, as opposed to code writing) which closely resembles what the expert has done in this case.
  • Dates for the expert’s expertise, as frequently testimony will be required on the state of the PHOSITA’s skill or knowledge at a particular time, and expert should have contemporaneous knowledge to opine on this.
  • Scope of assignment: who retained the expert, and what expert was asked to do; what questions to which the expert was asked to provide answers; perhaps, what expert was asked not to do (because of e.g. division of labor with other experts); how expert is translating legal questions into narrow factual technical questions.
  • Describe writing of report itself, including any assistance from expert’s staff or from non-testifying consultant
  • Any other reports on which the expert is relying (including assuming the truth of)
  • Describe the source-code exam: number of hours, which source code examined, volume of code, etc.; see ch.xxx on the importance of establishing “diligent” source-code examination; see ch.xxx on note-taking at source-code exam
  • Describe out-of-court experiments, testing, or product reverse engineering (if the expert report refers only to source-code exam, without any product testing, this can raise the question of whether such testing might disconfirm conclusions drawn only from the source code)
  • Code which wasn’t produced in discovery: describe any public source code, datestamped code from archive.org, SDKs, publicly-available API documentation used as a basis for the report, etc. (generally also need to attach to report, if not already a Bates-stamped document in the case; there may be authentication issues; see ch.xxx)
  • Any assumptions the expert has made, either in response to a specific request, or as necessary to complete the work in the face of insufficient facts
  • The claim construction upon which the expert is relying; whether or not there has already been a Markman ruling at the time of the expert report, it is best for the expert to explicitly state the claim construction (including multiple alternative claim constructions) being employed
  • Any dates the expert upon which the expert is relying, such as the priority date used in patent validity analysis, and the date at which the PHOSITA’s knowledge is being discussed
  • Any authorities (learned treatises) on which the expert will rely; while this gives the other side an opportunity to question the expert on seeming contradictions between his positions and those stated in the learned treatise, this is something the expert ought to be carefully considering in any case; see ch.xxx on the “no learned treatises, just journals” gambit; expect any cited works (at least their first 20 pages, or relevant passages reachable from a hurried glance at an index) to be pored over for quotations that appear to contradict the expert.
  • Background needed to understand the field: as part of the expert’s role of “helping” the jury “understand” the evidence, the expert often will teach general points about the field; this must be disclosed beforehand, in sufficient detail, in the expert report (e.g., not just going to talk about DLLs, but more specifically what general points the expert plan to say about them).
  • Possibly, a glossary of terminology; experts and their clients may shy away from providing a clear glossary with definitions, as unduly pinning down the expert, especially on claim construction (which is, in any case, more a legal rather than technical question); however, recall from ch.xxx that one of the expert’s role is as a “translator”: here, to translate the meaning of “code words” into something meaningful to laypersons.
  • Table of contents (TOC) should “tell a story”: ideally, each opinion should appear as a complete sentence in the TOC
  • Section headings should make specific assertions (see “Opinions” below on this seemingly obvious but frequently-overlooked point), such that the TOC will present a series of statements.
  • The outline of the report should be dictated by the legal requirements, which in a patent case generally flow from the limitations of one or more patent claims; thus, the report (and its TOC) will generally follow the order of claim elements or steps.

27.5 Software expert’s opinions

  • See chapter 8 on expert role, especially 8.6.6 (“What is an opinion?”):
    • 8.6.6.1 Opinions vs. “I just let the facts speak for themselves” (faux naivete)
    • 8.6.6.2 Raw facts without an opinion may sometimes be appropriate
    • 8.6.6.3 Opinions should not be merely conclusory, e.g. employing “unexplored legal criteria”
    • 8.6.6.4 Weasel words, “is consistent with,” and other hedging opinions
    • 8.6.6.5 Reasonable degree of certainty: what it means
    • 8.6.6.6 Expert stretching and “wringing” (over-extrapolation); “fit” & “application” of specialized knowledge/experience to the case at hand
    • Here, specifically opinions in the context of expert report:
  • Most important content of report is of course the statement of opinions, with the bases and reasons for the opinions
  • FRCP requires a “complete” statement of “all” opinions, bases, and reasons (see xxx above)
  • “Complete” means at least sufficient for the other side to effectively depose and cross-examine the expert
  • Completeness of the report should be tested at the deposition, and indeed even insured at the deposition, by “sealing off” the expert’s testimony (e.g., “is there any other basis you have for this opinion?”; see chapter 14 on supplementing)
  • “Complete” is not a passive test of whether the report fully pre-disclosed everything to which the expert later testified; the report should act as an active control, limiting that to which the expert is later allowed to testify.
  • Every expert knows that opinions should not be given without some basis, and likely has heard the word “conclusory,” meaning a conclusion for which no (or insufficient) basis has been provided.
  • In patent litigation, it is especially easy to be conclusory by mimicking or parroting the patent claim language, without tying it to the relevant technology, e.g. “D’s source code embodies this limitation of the claim because source code file f.c lines 123-345 contain an image transform processing step,” where “image transform processing step” is the language used by the patent claim, NOT by the source code).
  • Expert reports are also often conclusory by adapting legal terminology without fully understanding that the legal term is likely comprised of multiple elements or factors which must be separately analyzed; see xxx on “unexplored legal criteria”.
  • For example, in patent litigation expert reports often merely assert that x is “equivalent” to y, without further analysis, or perhaps use the phrase “substantially similar function, way, and result” as a mantra, without separately/individually thinking through the code’s function (e.g. the role or purpose it serves as part of a larger whole), its way (implementation), and its result (output).
  • Similarly, “infringes” has sub-elements, including whether the alleged infringer makes, uses, sells, offers for sale, or imports the patented invention; a technical expert is likely better equipped to opine on making, using, selling, etc. than on “infringing”.
  • By thinking of lower-level terms (e.g. make/use/sell rather than “infringe”), the expert will automatically be directed to consider the particulars necessary to make the higher-level point, and the differences between these particulars:
    • is the infringer alleged to “use” the patented method?;
    • perhaps the method is only “used” when the software is executed by certain end-users;
    • perhaps something is made but not sold (because the infringing software is only employed internally);
    • perhaps something is purchased, but not necessarily deployed/used (while purchasing itself is not infringement, large purchases of the same item, over time, may be sufficient for the expert to infer deployment/use).
  • Another reason to avoid legal terms of art in the expert report is that experts may get the legal requirements wrong, e.g. drawing a conclusion of patent validity solely by exploring the prior art, and forgetting an issue of enablement; by picking the wrong date before which to consider prior art; or by opining on the PHOSITA’s level of skill at the time of expert report, rather than contemporaneously with the invention/filing date.
  • While FRE 704 generally permits experts to give an opinion which “embraces the ultimate issue to be decided by the trier of fact,” this is not a license for wholesale adoption of legal terminology, nor an invitation to use contrived pseudonyms for these terms (see xxx on “prissy” or evasive formulations).
  • In addition to conclusory opinions, the converse problem is also prevalent: experts often avoid providing an opinion; see 27.5.1 below
  • [List requirements of opinion: “falsifiable”/testable; specific; reasonable certainty; no unexplored legalese; relevant (“fit”, “application”); sufficient basis/reasons; etc.; with cites to xxx for each requirement]

27.5.1 Ways in which experts (consciously or unconsciously) avoid stating an opinion

  • [Very rough notes below]
  • Some experts believe (or profess to believe) that their job is to present the facts, period; “I just call ’em like I see ’em, and let others draw their own conclusions”; when a professor adopts the cracker-barrel language of the general store, it’s a sign that something is wrong.
  • See 8.6.1 Opinions vs. “I just let the facts speak for themselves” (faux naivete)
  • Opinions are drawn from the presence or absence of elements/factors (sub-opinions) necessary to support the opinion
  • For example, an opinion that D infringes P’s patent claim 1 requires further opining that D sells (or makes, uses, etc.) a specific product (or service or internal resource, etc.) which carries out each and every step (or contains each and every element) of the patented method (or device, system, etc.) in claim 1.
  • Language properly stating an opinion, together with its sub-opinions and their supporting factual bases, often seems (at least to newer experts) like “legal mumbo-jumbo”; they simply want to state that a given set of source code files does, or does not do, the same thing as what the patent claims; the source-code files and line numbers will be meticulously provided, but the expert will fail to address issues such as e.g. whether the type of claim requires that the steps actually be executed, whether the source code is reflected in a product on the market, etc. [confusing; rewrite]
  • When stating what looks like an opinion, together with some supporting facts, but without tying the facts to each and every element of the opinion, the expert has (probably unconsciously) avoided giving a complete opinion.
  • How else can an expert create a report without expressing opinions? It’s actually rather easy to do, and may be unconscious:
  • Frequent use of the word “see”. For example, “with regard to the thread’ limitation of claim 1, see source-code files thread.c and thread2.c.” It appears that the expert has said that there is code in these two files which satisfies, practices, carries out, or embodies the thread limitation, but really the expert has not said this. The expert has in effect merely said “you the reader of my report should go to these two source-code files and ‘see’ for yourself.” This is not an opinion. Note the problem is not only that there may be insufficient basis (which specific functions or lines of code in the files?; are they even called as part of the overall method or apparatus which comprises the claim?; are these lines represented in the commercial product?), but that any such basis isn’t supporting anything: the expert doesn’t state that the limitation is present, satisfied, embodied, nothing. “See” is not an opinion. [Cite cases where such language was insufficient to survive or support SJ; “Fleming v. Escort” “correspond to”; MetLife v. Bancorp?]
  • See above on use of legal rather than technical terms: “infringe” (or perhaps “satisfies”) really is a legal conclusion, whereas seemingly-same “carries out” or “embodies” or “contains” are not.
  • Frequent use of “could”, “possibly”, “may”. An experienced expert or academic knows that these words sound equivocal, wishy-washy and inconclusive, and so is more likely to use impressive-sounding words or phrases which mean exactly the same thing as “maybe”:
  • To avoid stating a conclusion, an expert would use the following impressive-sounding phrases (the following list comes from a brilliant article, “Understanding forensic science opinions” by Graham Jackson which dissects these and other common phrases): “suggests”; “is consistent with”; “cannot exclude”; “provides evidence of”; “points toward”; “indicates”; “there is an association between”; “supports an assertion that”. [Attorney may in argument even put extra emphasis on these words, as if saying something very profound; hopefully the fact-finder would see through this.]
  • [Case where court notes that “possibly” != probably; patent case where ability to calculate != calculated; SJ requires opinion of probability not mere possibility (see xxx below on “reasonable certainty”).]
  • [So, a statement is something which is “falsifiable”; attorneys hate & misunderstand this word (Rehnquist in Daubert said judges didn’t understand it), but it merely means a statement whose truth or falseness could be tested, i.e. potentially disprovable (another word attorneys will hate); it’s not a statement if there’s no way of testing its truth.]
  • [Failure of expert to actually give opinion, SAY something falsifiable, leads to disputes over whether expert report actually helps carry burden in SJ: REC v. Bamboo; Oracle v. Google (expert report re: 2 patents no longer in case; did he intend to also apply to 1 patent still in case?); Fleming v. Escort (not explicit re: “distance from lockout varies”).]
  • Another type of evasion, often unconscious, is “to the extent that…”, or “see for example …”, or “see also” – expert makes statement without really committing to it. [How much of all this is expert not wanting to be conclusory, vs. trying to keep it loose, avoid being locked-down?; how does this get resolved in deposition?; on related issue, other side tries to smoke out with interrogatories requesting super-pinpoint citation to “the code which does x and only x”.]

27.5.2 Be explicit: all asserted claims, all limitations, all accused products

  • Don’t merely “cover” each limitation: explicitly state an opinion about it, even if seemingly trivial such as presence of a network or of memory [case in which report noted reading file, without noting that files are read into memory]
  • Careful when repeating or cross-referencing between claims which appear very similar: since claims by definition are different from each other (the basis for claim differentiation), there must be at least one (possibly subtle) difference which must be addressed for each asserted claim
  • Similarly, state opinions for each asserted patent, even when opinion would apparently be repetitive of what report already says of another patent [case with report re: two patents no longer in case: did report apply to one patent still in case?]
  • It is easy for expert reports to neglect one or more accused products, perhaps by over-specifying one product’s name or version number and thereby neglecting others in the same product family; see xxx on “representative instrumentalities”
  • Of course, expert division of labor may dictate that a given expert report will not cover all claims, limitations, or products, if these are being covered by other expert reports.
  • Cases where parties dispute what expert report says, whether it is evidence for x, e.g. when the report employs vague overly-loose connections (“see”, “for example”, etc.); see REC v. Bamboo; Oracle v. Google; Fleming v. Escort
  • Cases where expert failure to identify limitation was fatal for SJ; see MobileMedia v. Apple
  • Cases where issues covering all accused products; see Apple v. Samsung (31 accused products); Vasudevan v. IBM (plaintiff P, and those working for P, can’t complain that “too much” when P itself chose products to accuse)
  • Pros & cons of handling multiple products and claims with cut & paste: see ch.xxx

27.5.3 Terminology & wording: “red flag” words, characterizations, and “patent profanity”

  • Consistent use of terms: avoid, eschew, and reject “elegant variation”; however boring it appears, use the same term each time to denote a single thing
  • Careful with legal terms of art, e.g. “infringe”, “obvious”; if using these terms, cover each element which comprises the legal definition (e.g., “obvious” = (a) difference between claimed invention and the prior art + (b) skills of the ordinarily-skilled person in the field at the relevant time + (c) could the difference have been surmounted using ordinary skills at the time?; see xxx)
  • “Red flag” words to avoid: both absolutes (always & never, though these will usually be implied through “is” and “is not”) and equivocals (e.g. “could”, “suggests”, “probable”, “possible,” unless the patent claim itself only calls for possibility e.g. “programmable” rather than “programmed”)
  • See Babitsky & Mangraviti, Writing and Defending Your Expert Report, ch.14 on “red flag” words such as “substantially”, “obviously”, “clearly”, “complete”
  • Don’t characterize patent limitations as “crucial”, “key”, “vital”, “most important”, etc.: see Root, Rules of Patent Drafting for the useful term “patent profanity”; the dispute may focus not only on a stand-out term in the claim (e.g. “steganography”) but rather on one which appears trivial (“RAM”)
  • Similarly, don’t characterize any single piece of evidence as “crucial”, “key”, etc. [explain why]
  • Pros & cons of using the other party’s own terminology (pro for P: focusing on what D’s source code calls x avoids the problem of “mimicking” the claim language; con for P: using D’s own specific terms for the technology may overly limit the report to the specific named technology)
  • Avoid “functional” language (focused on the purpose, role, or intent of code), in favor of “structural” language (what the code does) [though function/purpose/role may be important in showing how selected code is actually used in the commercial product; how the code relates to visible UI]

27.5.4 Degree of specificity: both broad & narrow

  • Avoid over-commitment to specifics on the one hand, and vague hand-waving on the other; see ch.xxx on the need for both broad & narrow interpretations of code in software patent litigation, and how it mirrors the both-broad-and-narrow nature of patent claims
  • Commitment, yet flexibility especially pre-Markman ruling
  • Pros & cons of “for example” (pros: avoids premature commitment to a particular code/claim alignment; cons: the other side is arguably entitled to know not only precisely what is being accused, but also what is NOT being accused?) [but that really is arguable; and how would it apply to anticipation?; clearly any such entitlement only operates within a small area]
  • Other side’s requests for super-pinpoint to specific lines of code which do x and ONLY x (see ch.xxx)
  • Is the expert report sufficiently specific that another expert could attempt to duplicate its results when examining the source code and the relevant product?

27.5.5 “Reasonable degree of certainty”: what it means; not a mere mantra

  • The expert is expected to testify, not to what could possibly (or even probably) is true, but rather to what the expert, in his or her professional opinion, regards as true.
  • Even though a professional opinion (like any opinion) is by definition offered without 100% certainty, note the difference between “probably” and “in my professional opinion, is”.
  • “In my professional opinion” means that the expert would reach the same conclusion, outside of court, in his normal engineering practice. [Need to tweak this if the expert no longer has such a practice?]
  • Courts want certainty, not possibility or probability (see xxx)
  • Yet perhaps paradoxically, courts do not insist (and obviously couldn’t feasibly insist) on absolute certainty
  • Even in criminal cases, the standard is only “beyond a reasonable doubt,” and in non-criminal cases such as patent disputes, the standards are “preponderance of the evidence” or (to show invalidity of a granted patent) “clear and convincing evidence”; while these are standards for the ultimate fact-finder, they also affect how certain the expert must be in expressing an opinion.
  • Expressing an opinion with certainty, not mere probability, even when the expert knows the opinion is only (very) probably correct, is the basis for awkward phrases such as “reasonable degree of certainty in the software field” or “reasonable degree of engineering certainty”
  • It is important that the expert understand what “reasonable degree of certainty” (RDC) means, and not use the term as a mere ritualistic mantra [cite case in which clear that expert clearly used phrase because attorney told him to, and expert had no idea what it meant]
  • RDC mimicks the language long used in medical torts, “a reasonable degree of medical certainty,” where is it means that the doctor is basing his opinion on the same type of facts as, and would come to some conclusion as, the doctor would in their daily non-litigation medical practice; this is probably something between “I would base a life-or-death decision on this” on the one hand and “Professionally speaking, it is more likely true than not, that…” (doctor would make a decision affecting patient’s health or perhaps even life based on the same basis & reasoning they’ve used as expert in litigation)
  • See ch.xxx on the expert having the same type of basis for an opinion in software patent litigation that the expert would use to base an important decision in daily non-litigation software-engineering practice.
  • Even though the RDC phrase means “I am as certain of this as I would be in making an important software-engineering decision,” the expert should be careful in use of the phrase:
  • Be prepared to be asked what you, the expert, mean by the phrase (not merely its legal definition)
  • Do not use the RDC phrase in a blanket fashion, but only in relation to opinions for which a solid basis can be found in engineering principles and/or the expert’s professional experience (e.g. if part of an opinion is based on deposition testimony, is that testimony equivalent to another engineer’s opinion you would get by walking down the hall in a job at a software company?)
  • Simply using the “certainty” mantra does not lend weight to an opinion: the mere statement that the expert opines, “to a reasonable degree of engineering certainty”, is insufficient to grant motion for preliminary injunction [case]
  • New experts sometimes fear their lack of complete certainty. This idea that “a degree of certainty” is something other than cosmic certainty is difficult for some prospective experts to grasp.
  • For example, one expert in a non-patent case was “terrified” at the idea of presenting an opinion, in part because he believed that “engineering certainty … meant, he believed, that he could only state what the PERL scripts that he examined actually did if he could run them on the systems as they existed at the time of the events in question. Since CTS, eBay, PayPal, and the web-based email services had been upgraded and otherwise changed their systems, this was impossible.” The attorneys explain to the expert that he can base his opinion on his practical experience, but he remained too anxious to be used in the case (see Schroeder, The Lure, pp.295-297). The prospective expert had an excellent point, of course, but was left stymied instead of realizing that might have to make similar call in his day-to-work non-litigation work; also note that effect of available time and resources on certainty of opinion. [Hmm, but what about the high acceptance for bugs in software?! Is there some relationship here to the standard of due care, below which one is negligent?]

27.6 Bases & reasons for software expert’s opinions: facts, principles, and methods

27.6.1 Facts: based on source-code exam and/or examiner, and non-source facts

  • When referring to source code, remember that the protective order (PO) likely prohibits “copying” the source code, and that this may be read as prohibiting any direct quotations from source code in the expert report (see e.g. Unwired Planet v. Apple)
  • See ch.xxx on how to employ source code in the report, without directly quoting the source code; use proper nouns from source code (function, class, and file names) but not “logic” (anything with an equal sign)
  • Reliance on source code: remember to describe the source-code examination itself (see ch.xxx on “diligence”)
  • Any reliance by testifying expert witness on non-testifying consultants/examiners, who may have done bulk of source-code examination?; see e.g. Symantec v. CA; Tarkus v. Adobe; Medisim v. BestMed; Verizon Cal. v. Katz; see ch.xxx
  • Testifying expert can either replicate relevant portion of work done by non-testifying consultant, or explain why reliance is reasonable
  • One technical expert report may rely on other technical expert reports as part of its factual basis (e.g., expert re: infringement relying on expert re: validity; expert on overall infringement relying on experts re: specific specialties)
  • If relying on non-source materials (see ch.xxx), such as deposition testimony, other side’s internal emails, or other side’s marketing materials, briefly explain why reliance is reasonable (would use similar materials in coming to conclusion in non-litigation work)
  • But if relying on any deposition testimony, especially when faced with conflicting deposition testimony, or conflicts between testimony and other evidence (especially source code), avoid opinining on the credibility of deponents; witness credibility is for the fact-finder
  • See 8.6.4 Facts (qualitatively & quantitatively sufficient) as basis for opinion in chapter 8

27.6.2 Principles: generalizations, background, assumptions (including claim construction), and expert’s experience/training

  • Opinions in expert report will almost always be based not only on facts, but also on some generalizations
  • These generalizations are often implicit (e.g., stating that the source code embodies hashing, and pointing to an associative array in the code, without “connecting the dots” to note that associative arrays are typically implemented with hashing or, better, that the specific programming language employed by the source code does implement associative arrays using hashing), and should often be made explicit in the report.
  • Generalizations may be well-known principles of computer science or software engineering, in which case the report should cite some specific authority, at least when the principle is possibly open to interpretation, or when providing a citation will help show a solid basis for the opinion; see xxx on “learned treatises” and xxx on searching journal articles at CiteSeer, etc.; avoid hand-waving references to “the literature” unless the expert has a specific author/title in mind.
  • Careful with generalizations, which can be undermined with exceptions; even if the exception is not applicable to the case at hand, it can undermine an carelessly-provided over-generalization.
  • The expert report sometimes presents principles of CS/SE, not only as part of the basis for an opinion, but also in a more standalone fashion to present “background” to the technology which the expert will “teach” at trial; see teaching at xxx below.
  • Generalizations may also include assumptions
  • These may be assumptions provided by an attorney, e.g. that the patent is valid, or that the accused instrumentality has been offered for sale (the extent of an “offer” may be outside technical expertise).
  • Another frequently-necessary assumption is a particular claim construction, pre-Markman; the report may even need to provide alternate assumed claim constructions (generally one broad reading, and one narrow reading).
  • In cases with inadequate facts, certain facts may need to be assumed; explicit technical reasons should be given for why a particular assumption is reasonable; though in some cases with inadequate facts due e.g. to spoliation, it is reasonable to simply make the non-technical assumption that the unavailable facts would have have been detrimental to a party responsible for the loss of the information (see xxx).
  • Be careful of implied assumptions of the “always” or “never” type (e.g., simply assuming that a given string-lookup table employs hashing, based on the hidden assumption that string-lookup tables always do).
  • See 8.6.3 General principles & assumptions as basis for opinion in chapter 8

27.6.3 Methodology: software inspection, source code review, reverse engineering, code/text comparison

  • See very lengthy section 8.6.5 Methodology (including Daubert and post-Daubert factors) as basis for opinion, and subsections, in chapter 8, including discussion of source-code reviews, code auditing, reverse engineering, and other software-engineering methodologies used as the basis for expert opinions
  • Describe the source-code examination itself: number of days/hours spent with code; specific drives, directories, folders, projects examined; tools used
  • If relying on any specific output of tools (e.g., SciTools Understand relied upon to show which of several functions with the same name/signature would be invoked), explain why the tool is known to yield reliable results in non-litigation practice
  • Describe any useful similarities to non-litigation code examination/audit/review in which the expert has experience
  • [more]

27.6.4 “Reasons” distinct from methodology

  • In addition to the software-engineering methodologies used to uncover facts (27.6.4) and e.g. computer-science principles which may ground certain assumptions the expert makes (27.6.3), there are also somewhat-separate “reasons” for the opinion: how the expert got from the raw facts to the cooked opinion
  • Absence of words such as “because” is a tip-off that reasoning is missing from the report
  • Except in the most straightforward case (the equivalent of a D source code file named “HereinWeInfringePlaintiffPatentClaim1”), it is insufficient for the expert to give opinions and the full factual basis for those opinions, without showing how those facts are woven together, or cooked down, to yield the opinion
  • See xxx on explicit reasoning, “connect the dots”
  • Courts are clear that the expert report should disclose the expert’s “thought process” [cases]
  • Again, the reasoning the expert used to reach the opinion from the facts is distinct from methods used to uncover facts [fix ch.8 to make this distinction clearer?]
  • “Thought process” and the “straight face” test: can the unashamedly expert connect the dots from the facts to the opinion, without smirking or looking sheepish or apologetic? [“From the sole fact that the accused product uses the computer’s memory, I concluded that the product employs linked lists and garbage collection.” Or, less obviously, analytical gap when expert slides from “consistent with” to “is”.]

27.7 “Teaching”: General principles & authorities in the expert report

  • If the expert plans to present general “background” at trial, presumably relevant but not (at least until later in the testimony) explicitly tied to the specific facts of the case, the topics the expert will teach must be disclosed in the expert report
  • When is it sufficient to merely list general topics (e.g. “memory management”, “3D graphics rendering”), and when must the report itself do the teaching?; bottom line: does the expert report provide adequate basis to take an efficient one-day deposition?
  • Generally, the expert will have a particular “slant” or “angle” on the topic, which supports their opinion; the expert will not be delivering a neutral dispassionate discourse on “Memory Management 101”; to the extent the expert’s teaching will likely focus on aspects of the topic which would not naturally arise in an introductory class, the report ought to disclose such specialized topics in more detail
  • If the expert report is filed pre-Markman, a solid background/teaching section in the expert report can lay the basis for an expert’s presentation at the Markman hearing
  • Fact-finders are reported to find expert opinions credible and trustworthy when the fact-finder feels that the expert has clearly and understandably taught them some general background to the technology — even when the case-specific opinion itself  is perhaps not especially grounded in the general teaching portion of the testimony?
  • See xxx on citations to learned treatises and journal articles, and xxx on the need to at least have specific authorities in one’s back pocket, rather than airily opining even on what feel like truisms of computer science (picture the expert leaning back in their chair, puffing on a pipe, dreamily saying “the way we do this in computer science is…”, and then being skewered with counter-examples which the expert failed to consider; seasoned experts are very good at “saves” in situations like this, but it’s better to avoid them in the first place)
  • Conversely, see xxx on the “no learned-treatises gambit” (expert claims that there are no reliable treatises, only journal articles)

27.8 Exclusion, weight/strength, sufficiency & insufficiency of expert reports

  • Role of expert reports (and affidavits) in summary judgment (SJ), vs. the party’s own infringement contentions
  • The expert report will act at SJ time as a proxy for the expert’s proposed testimony to the jury
  • Presentation of raw facts in expert report insufficient to survive SJ if expert doesn’t tie the facts to the issue required to be in dispute to survive SJ; see Fleming v. Escort
  • Role of expert reports in revealing (or creating) triable issues of material fact
  • Motions to strike report, or portions of report?
  • Motions to exclude or strike expert testimony, because not adequately disclosed in expert report
  • Motions in limine, Daubert hearings, expert voir dire — see xxx
  • Evidence sufficient that a rational jury could conclude x?; jury crediting expert testimony; see e.g. Uniloc v. Microsoft; Whitserv v. Computer Packages
  • Outcomes when expert report and/or testimony is excluded
  • Weight/strength of expert testimony, once admitted — how expert report can lay groundwork for arguing weight/strength to fact-finder
  • [more]

27.9 Supplemental reports, rebuttal reports, timing, and “backdooring”

  • See chapter 14 on timing, scheduling, supplementation
  • When supplementary expert reports are permitted, vs. when not permitted, vs. when obligatory
  • Supplemental reports are not to be used to artificially extend deadlines for complete expert reports; e.g. supplement not  allowed when all facts to be used in supplement were available at time of original support
  • Any supplementary expert report will generally be followed by a supplementary deposition
  • Difference between rebuttal report and supplementary report; division of labor between experts and rebuttal experts
  • When must the expert provide a supplementary report, e.g., what if “promised” at deposition to update other side if the expert does any additional work or reaches any additional conclusions?
  • Continuing obligation on expert under FRCP to supplement report if learn of errors in report, not known at time of initial report?; see FRCP 26(a)(2)(D): expert disclosures must be supplemented when required under FRCP 26(e)
  • FRCP 26(e)(1) generally requires supplementation “in a timely manner if the party learns that in some material respect the disclosure or response is incomplete or incorrect, and if the additional or corrective information has not otherwise been made known to the other parties…”
  • FRCP 26(e)(2): the duty to supplement extends both to information included in an expert report, and to information given in the expert’s deposition
  • [Examples of incomplete/incorrect which are material, and examples which are not material]
  • If don’t supplement report when required, then expert probably can’t testify at trial to the supplementary material
  • Conduit: while expert can reasonably rely on inadmissible evidence, if of the type a reasonable expert would rely upon in non-litigation practice, the expert report or expert testimony cannot be used as a “conduit” to put this inadmissible evidence before the jury [yet jury may need otherwise-inadmissible to properly assess reliability of expert testimony; see FRE 703]
  • Backdooring: if the party failed to introduce evidence in its infringement contentions, the expert will not necessarily be allowed to “correct” this in the expert report [case; contrast to fact that SJ rests on expert report, NOT on ICs]
  • [more]

27.10 Drafts of expert reports and “ghostwriting”

  • FRCP 26 amendments in 2010 re: drafts of expert reports; FRCP 26(b)(4)(B)
  • Report is to be “prepared by” the expert
  • “Ghostwriting” of report by attorneys or consultants
  • FRCP ACN car-mechanic example of when attorney can take larger role in preparing expert report
  • Discoverability of non-draft communications re: preparation of report
  • The single “rolling report,” which incorporates all written discussion of the expert report (even what would otherwise go in an email), to control discoverability of non-draft communications
  • Disputes over what constitutes a protected “draft” of the report vs. discoverable notes (see article)
  • Communications or meetings among multiple experts to coordinate report opinions: usually an attorney will be present; careful of appearance of contrived over-agreement among experts
  • Fair questions re: expert’s standard office practice involving drafts and communications
  • Mutual stipulations of non-discoverability
  • Role of expert’s staff in report preparation
  • Role of non-testifying consultant in report preparation
  • [more]

27.11 Impact of protective order (PO) on expert report

  • PO restrictions against “copying” code may mean that expert report cannot contain source-code quotations
  • Instead of source-code quotations, use of naming (file names, function names, etc.) from source
  • When expert report references source code under PO, the PO continues to apply to the expert report, even after conclusion of case
  • Other side can request sealing/redaction of expert report which references its source code; see e.g. Network Appliance (NetApp) v. Sun

27.12 Expert affidavits, especially their role in summary judgment (SJ)

  • FRCP 56
  • Requirement of personal knowledge?
  • Depending on timing, affidavit must be within scope of expert report?
  • Danger of expert affidavit providing a series of disconnected facts, which attorneys may then use to construct arguments with which the expert may not agree [example: attorney wrote brief, citing to not-yet-written expert affidavit, then asked expert to supply material on the cited-to points; expert ends up preparing “subroutines” to be called by attorneys, without adequate control over how the expert’s material is used?]
  • Affidavit as retyped most-favorable portions of expert report?
  • See Patent Case Management Judicial Guide 6.1.6 (SJ hearing) and 6.1.7 (expert declarations filed in connection with SJ motions): some expert testimony cannot defeat SJ; legal insufficiency of expert testimony; expert testimony beyond the scope of the expert report
  • [more]

27.13 Deposition & expert report

  • FRCP dictates timing: “the deposition may be conducted only after the report is provided”
  • Expert can use writing of report to prepare for deposition
  • Danger of “parroting” report at deposition; see e.g. Soverain Software v. JC Penney
  • Was report a sufficiently complete disclosure such that deposition can be done in single 7 hour session?
  • Deposition used to lock-down broad statements in report
  • [more]

27.14 The other side’s expert report

  • Weight, admissibility (reliability), and procedural (timing, inadequate disclosure) attacks on the report
  • Role of the expert witness in assessing other side’s expert report; discoverability of communications?
  • What doesn’t the report say?
  • What can be agreed with?
  • Any caveats buried in footnotes?
  • Use of hedging (“consistent with”, etc.), weasel words
  • Use of implied “always” or “never” over-generalizations
  • Does the report characterize any limitations or evidence as “crucial”, “key”, “especially important”, etc.?
  • Does the report use passive voice in order to hide who or what is carrying out a particular action?; e.g., “the record is updated” avoids saying who updates the record or which component does the updating.
  • Look for tiny changes or discrepancies between boilerplate or cut & paste sections

27.15 Excerpts from software patent expert reports

  • [tk]

Print Friendly, PDF & Email