Source Code & Reverse Engineering in Patent Cases

Andrew Schulman
www.SoftwareLitigationConsulting.com
Last updated Dec. 28, 2014

This is a work in progress, which will eventually cover several hundred patent cases in which software source code and/or reverse engineering played a part.

Below, “[tk]” indicates that further discussion is to come. Within quotation marks, “plaintiff” and “defendant” have often been replaced with P and D to indicate patent-holder and accused infringer (in some cases, even when declaratory judgment P would otherwise have been D), and “infringement contentions” has been replaced with “ICs” (or PICs, for initial or preliminary ICs).

Cases from the Court of Appeals for the Federal Circuit are collected on a separate page, Source code and reverse engineering in CAFC patent cases.

Unwired Planet v. Apple, 2013 US Dist. LEXIS 52261 (D.Nev., April 2013)
1. Source code protective order (PO)
2. Limits on printing source code
3. Quotations from source code in expert report: prior approval needed to quote?
4. Source-code access taints attorney (prosecution bar). [Similar tainting of expert/code reviewer, barring future work in a given field for a given period?]
5. [tk]
Digital Reg of Tex. v. Adobe et al. [Zynga], 2013 US Dist. LEXIS 23447 (ND Cal., Feb. 2013)
1. Source-code examination environment under PO: tools (e.g. “wingrap” [sic; wingrep], DOxygen [to build function call graphs], Notepad++), but not XCode compiler (in part because little point in P expert rebuilding D’s app on the standalone source-code computer which, per the PO, lacks an internet connection)
2. Source-code printing limits (14 complete files, 500 functions; printing not intended to enable “review” of code outside protected source-code room) [Why?]
3. Representative instrumentalities: P has burden of explaining why charted products are representative of other accused products
4. Inadequate ICs: e.g., P’s charts, for the “electronic content” limitation, sometimes point to the mobile app itself, or to time-based rewards, high scores, etc. [Need consistent mapping of claim limitation to code.]
5. Dropping or adding from list of accused products requires good cause for amendment, e.g. recent discovery of “nonpublic” info about accused instrumentality which was not discovered “despite diligent efforts” before service of ICs (Patent LR 3-6(c)). [Importance of “diligence” in these cases, both pre-filing (diligence in seeking out all reasonably-available info about accused products) and in discovery (here, P has had 4 months access to D’s source code, yet P’s ICs are still too vague).]
6. P will not be allowed to add products to its case, so after dropping some, it is left with two accused products (“Mafia Wars” and “Drop7”).
7. P is ordered to amend its ICs to conform to Patent LR 3-1.
8. [tk]
CSR v. Freescale Semiconductor, 2013 US Dist. LEXIS 17502 (ND Cal., Feb. 2013)
1. P asserts that any deficiencies in its ICs are explained by the fact that the relevant signals are generated and received by the processor “in software, which is solely within [D’s] control and has not yet been produced by [D] to [P]. But the ICs do not even mention the processor software that P now asserts is crucial in identifying P’s limitations in D’s products. That the processor runs on software is not responsive to D’s argument that P’s ICs fail to show why P believed D’s products perform the claimed method. [P tried to use “software” as a burden shifting (or at least delaying) incantation, as suggested by e.g. Theranos v. Fuisz and Rates v. Mediatrix, but it did not work here. If you’re going to say you are forced to be vague until you have the other side’s source code, you should at least explain what specific types of gaps the source code is expected to fill.]
2. Requirements for initial ICs, citing Shared Memory v. Apple, DCG v. Checkpoint, View Eng’g v. Robotic.
3. P to disclose in its initial ICs what in each accused product practices each and every limitation, “to the extent appropriate information is reasonably available to it” (emphasis added; citing DCG v. Checkpoint)
4. P to disclose in its initial ICs “why” it believes it has a reasonable chance of proving infringement (citing Shared Memory v. Apple ND CA, View Eng’g v. Robotic CAFC) [absence of linking/weaving words such as “because” in PICs are possible tip-off that P hasn’t met a possible “why” requirement]
5. P’s contentions re: certain limitations “consist of nothing more than a conclusion based ‘on information and belief’ that since calibration in the Accused Products occurs, it must according to the claimed method.” [The “inventor’s fallacy”: they’re doing x, and “the only way” to do x is by using my y, therefore they “must be” doing y. See also Bender v. Maxim.]
6. Infringement contentions based entirely on “information and belief” (citing Theranos v. Fuisz).
7. P assumes the presence of some limitations in D’s products because the products contain x, and x “requires” y: “Contending that the limitation must exist somewhere in the Accused Product is not the same as specifically identifying where each limitation is found…”. [Perhaps x really does require y, and therefore x wouldn’t be present if y also wasn’t. But even if true, this doesn’t show where y is. Claim charts are all about location, location, location. You can’t just say, a la Prego tomato sauce, “it’s in there.” Where is it? Often, “where” will be indicated by a name of some sort, such as function names in source code.]
8. However, when P points to D products’ adherence to standards (UMTS, QPSK, etc.) in modem software, this is sufficient to identify where a limitation can be found in the accused product. “D argues that P cannot simply state that the limitation resides in software” and D “without analysis” cites Network Caching v. Novell (2002), but that case held that “while reverse engineering was required … for non-software limitations,” it is not required for at least certain software limitations [under 112(6) means-plus-function] [and thus is not applicable in this largely hardware-related case?]. [Hmm, is pointing generally to “software” sufficiently specific in the context of a hardware product?]
9. Court refers to “specific software — which is exclusively in Defendant’s possession.” [Exclusive possession of software unlikely for LTE and WCDMA modem software here?; sure, exclusive possession of the source code (presumably Freescale licenses to modem manufacturers under an NDA), but was any attempt made to extract and examine e.g. firmware in products on open market?; try to find firmware download for Freescale BSC9131 Reference Design Board (RDB); “VortiQa Layer 1 software sold by Freescale” running on BSC9131 processor?; hardware available for purchase for less than $1,000?]
10. How P can fix its ICs; court gives specific direction [to paraphrase: that thing you said at oral argument, that’s what we’re looking for, why didn’t you explicitly say that in your ICs?”. Often ICs simply fail to explicitly state what seems obvious.]
11. Doctrine of equivalents: P has “blanket” or “boilerplate” recitations, without analysis, of DoE. However, even where P here has specifically called out function, way, and result, it points to D’s entire product, “rather than discrete components, as the equivalent structure.” [No “holistic” approach to DoE; “where” needed for DoE too. And don’t use F/W/R as an incantation; actually think through the differences of function/role vs. way/method vs. result/output, and specify “where” each resides as an identifiable component of the accused product.]
12. “Where” and DoE: don’t reference entire product as equivalent structure.
13. The “For instance” or “For example” problem in claim charts: P charts contain a catch-all stating that in addition to literal infringement, D’s functionality is at most insubstantially different in F/W/R, followed by: “For instance, to the extent Freescale contends that” its x is not our y, then its x is insubstantially different from our y. But P “provides no authority for the proposition that it need only provide a sampling of its equivalency theory. Rule 3-1(e) requires that P disclose its entire theory at this stage of the case.” P has 30 days to amend its ICs. [Apart from the unanalyzed use of DoE, this also demonstrates the common desire to not pin oneself down to a specific theory. Ps sometimes use “for example” to this effect. This practically invites D to come back with a demand that P exhaustively list what it’s accusing, on the theory that D can’t know what and why P is accusing D’s x, without knowing exactly what P regards as falling within x, therefore at least implicitly what it does not regard as x; and therefore what it would agree is not-x (see, in a different context, the “zone of uncertainty” in Nautilus v. Biosig). Arguably such clear boundary drawing is required to give D sufficient notice of where and how it has trespassed. P may be better off without the “for instance”.]
14. Don’t over-parse to create more limitations than actually exist; see fn.5
15. [tk]
Edward D. Ioli Trust v. Avigilon, 2012 US Dist. LEXIS 164425 (EDTX, Nov. 2012)
1. Costs
2. Still must produce source code, even if non-source has been produced, so other side can see for itself (see also DisplayLink v. Magic Control)
3. [tk]
Theranos v. Fuisz Pharma, 2012 US Dist. LEXIS 172160 (ND Cal., Nov. 2012)
1. [Not a source-code or software case as such (though 7,824,712 bodily fluid analyzer includes “method for programming”), but it implies a rule specific to source-code cases, and provides a useful example of claim chart requirements, citing mostly to software cases.]
2. Fn7: P relied on DCG v. Checkpoint for the proposition that P is allowed minimalistic PICs providing only publicly-known info, with amendment (freely?) permitted for amendment with non-public info learned in discovery. But the authority P cites “regarding courts’ recognition’ that there are situations where P is constrained by Ds’ sole possession of information relates to cases involving allegedly-infringing source code.” [In other words, were this a source-code case then P’s cited authorities would apply, but it’s not a source-code case so they don’t apply. The implied rule for cases “involving” (?) source code is that some burden is shifted onto D; see Rates v. Mediatrix for a similar instance of “this isn’t software, so don’t shift burden to D” logic and see “Catch-22” in NYU v. E.Piphany for an application of this logic in a software patent case, but with the important proviso that P must first “exhaust” public sources of information.]
3. Rules requiring reasonable pre-filing investigation (e.g. reverse engineering; see e.g. Network Caching v. Novell) apply equally to D’s infringement counterclaims as to P’s initial claims. [No “kneejerk” or “protective measure” counterclaim.]
4. Party asserting patent infringement must include in its ICs “all facts known to it, including those discovered in its pre-filing inquiry” (citing Renesas v. Nanya). [No keeping investigation facts relevant to Rule 11 in one’s back pocket?; but court later notes that a patent holder “if challenged, must be prepared to demonstrate … why it believed before filing the claim that it had a reasonable chance of proving infringement,” citing View Eng’g v. Robotic, which sounds like back-pocket readiness, not up-front full disclosure, of the pre-filing investigation.]
5. ICs must provide notice to D of “why P believes it has a ‘reasonable chance’ of proving infringement.'” [To provide this “why” notice, is it sufficient for P to show the “where” in D’s product which P asserts performs/embodies each limitation of each asserted claim, or is this “why” something more?]
6. ICs “must map specific elements of D’s alleged infringing products onto P’s claim construction” (citing Shared Memory v. Apple, 812 F.Supp.2d 1022, 1025). [“Mapping” code to claims implies consistent matching?; if x:y in one place, not x:z somewhere else; note that pre-Markman hearing, P must rely on its own claim construction, which must at least be reasonable (see Eon-Net v. Flagstar).]
7. ICs must not only show “where” each limitation is located in accused product, but also “how” (citing ND Cal. Patent LR 3-1(b)). [Does “how” require more than mapping of P’s x onto D’s y, but further e.g. “D’s y embodies/practices P’s x, because…”?; is “how” any different from the “why” which some cases (e.g. xxx) assert it is not necessary at least for P’s initial ICs (PICs) to spell out?]
8. “Parrot” claim language (see “mimic” in e.g. Vigilos v. Sling Media)
9. “Information and belief”: is over-use of this phrase in a claim chart (see quotations in court’s opinion) a tip-off of inadequate pre-filing investigation?
10. P “copies and pastes” its information/belief responses throughout its ICs, “further evidencing the presumptive nature of their claims.” [Courts are generally not fooled by enormous claim charts produced with cut & paste.]
11. No fishing: insufficient to generally allege that “there may or may not be infringement, we need further discovery to find out” nor that party is factually contending infringement “but needs discovery to gather evidentiary support for the contention” (citing Elan Microelectronics v. Apple, 2009 US Dist. LEXIS 83715). [While “fishing expedition” not allowed, contrast cases implying a kind of res ipsa loquitur to software, as if source code were flour barrels; see xxx.]
12. Pre-discovery non-availability of D’s internal materials (such as source code, schematics, design documents, etc.) doesn’t shift burden onto D; footnote distinguishing xxx which appears to say otherwise — because that case was about source code?! [Don’t shift burden, unless source code is somehow involved?; note logical fallacy: source code provides confidential info about product internals; therefore, once source code becomes important to the case, burden then shift to holder of source code; forgetting that other info about product internals could be available from other sources which are public, including the product itself; facetious recommendation to plaintiffs wanting to file bare-bones conclusory PICs: say something in the PIC about needing source code; unlikely to get push-back about whether “need”; better view is that source code typically (not always) provides mere confirmation of info which can be gleaned from product itself, except in the cases where can’t get product or it has truly been made inscrutable/inaccessible through encryption/obfuscation; some slight burden shifting if vendor has truly made its product/service uninspectable?]
13. [tk; see also Theranos v. Fuisz, 876 F.Supp.2d 1123]
Vigilos v. Sling Media et al., 2012 US Dist. LEXIS 189491 (ND Cal., July 2012)
1. P “must give defendants fair notice of the infringement beyond that which is provided by the mere language of the patent claims themselves,” and “Here, P has done more than mimic the claim language in the PICs,” because e.g. for the claim language “transmitting a communication request to communicate with one or more premises-server computing devices,” the PICs apparently repeat this and then state, “A communication request is sent by selecting the Slingbox from the Slingbox Directory”. [So one can adhere to the don’t-mimic rule merely by stating anything about the accused product beyond the claim language?; see also Sutton v. Nokia.]
2. Representative instrumentalities: P “has the burden of establishing that the products in the claim charts are representative of all the accused products” but here, the products appear to differ from each other, or at least fall into two or more categories, so P’s claim chart is inadequate.
3. Multiple Ds accused in a single claim chart, but “Defendants are not similarly situated.” Sling Media makes and sell Slingbox; EchoStar sells Sling-loaded set-top boxes. DISH Network purchases set-top boxes from EchoStar and distributes them to DISH customers. “These differences matter.” E.g. Sling Media can’t in good faith be accused of direct infringement with respect to set-top boxes, because it does not make, use, sell, offer, or import set-top boxes. “Therefore, separate [per-defendant] charts are required under Local Rule 3-1.” [Possibly contrast per-product charts which, if multiple products are truly similar in an infringement-relevant way, may be little more than an expensive Full Employment Act for consulting experts.]
4. [tk]
DCG Systems v. Checkpoint, 2012 WL 1309161 (ND Cal., April 2012)
1. PICs, pre-filing investigation, and pre-discovery information reasonably available to P
2. See use of this case in Theranos v. Fuisz Pharma to imply a rule for cases “involving” source code, which does not apply to non-source-code cases; the rule, if it truly exists, would lower pre-filing investigation and initial infringement contention requirements for P in cases that somehow involve non-public source code held by D and unknown pre-discovery to P.
3. [tk]
Implicit Networks v. HP, 2011 US Dist. LEXIS 100283 (ND Cal., Sept. 2011)
1. Public availability of source code, vendor modifications to open source, and reverse engineering: “Implicit provided a declaration from David Bernstein, arguing that HP has modified the open source Tomcat Apache software that forms the basis of the WSS [Web Server Suite] to such a degree that reverse engineering would serve no purpose…. However, in light of Implicit’s failure to specifically locate the infringement within the actual WSS product, the Court finds that HP’s position — that the WSS product is free and available — is sufficient to require Implicit to reverse engineer the WSS product itself, not the open source code it is allegedly based on.”
2. [Possibly got it backwards: lower PIC sufficiency requirements when basic source code publicly available (open source, albeit not for vendor modifications), whereas higher PIC requirements when source code not available publicly (or at least not mentioned by parties)?; unless court simply wants to confine case to product with known source code base, this sounds backwards: one would think the rule is that presence of at least some public source code raises, not lowers, the bar for initial infringement contentions.]
3. [tk]
Shared Memory Graphics [SMG; Acacia] v. Apple et al. [Sony, Nintendo], 2011 US Dist. LEXIS 99166 (ND Cal., Sept. 2011)
1. Nintendo GameCube, Wii; Sony pre-MCL iterations of Playstation (not PS2, PS3)
2. P wishes to avoid reverse engineering D’s products to determine infringement, because “these connections are too small to be seen”; it would take months, and might cost hundreds of thousands or even millions dollars; but court rejects this “It is too expensive” argument, noting that it also failed in Bender v. Maxim.
3. “Cases in which reverse engineering was not required, however, have tended to involve situations in which analyzing the accused product was either impracticable or unnecessary to create a basis for adequate ICs” (quoting Bender v. Maxim). [What reasons do Ps cite for RE impracticality?; e.g. has a P ever pointed to the “no reverse engineering” clause in text of software license to show RE impracticality? (yes: see xxx); how about difficulty of purchasing product in the first place (not on open market, must negotiate sale with vendor), as making it impracticable to RE the product?]
4. It is well established law that, for certain technologies, P must reverse engineer D’s product preparatory to accusing D’s product of patent infringement [however, it appears to not be well established whether software is such a technology, and some courts make an explicit exception for software when source code will later become available]
5. Don’t shift burden: first P provides sufficient PIC, and only then does P get discovery/disclosure of D’s confidential materials [but this is a case involving circuitry rather than software?]
6. “wherein” clause in patent claim: unresolved argument whether this is a required element [does “wherein” merely indicate the result of a process, or is “wherein” part of the process itself?; see 812 F.Supp.2d 1022]
7. Assuming presence of elements which “must be” represented although not depicted (citing Renesas) [see 812 F.Supp.2d 1022]
8. Expert can provide testimony on why one product is representative of others (citing Renesas)
9. [tk]
10. [See also Shared Media v. Apple, 812 F.Supp.2d 1022 (ND Cal., Dec. 2010), cited in Theranos v. Fuisz Pharma (re: “mapping” limitations onto construed claims), in CSR v. Freescale (re: ICs which rather than provide theory of infringement, instead invite P and the court merely to assume existence of a limitation), and in Vigilos v. Sling Media (some “ambivalence” in the case law as to whether 3-1 requires reverse engineering or its equivalent; no LPR 3-1 exception for parties who do not want to spend the time and resources necessary to identify specifically where each limitation is found).]
Vasudevan Software v. IBM, 2011 US Dist. LEXIS 33132 (ND Cal., Feb. 2011)
1. P’s borderline pre-filing investigation, just barely adequate
2. But no D Rule 11 discovery into P’s pre-filing investigation [contrast Garmin v. TomTom]
3. P tried just hard enough to get public information, but now that P has access to D’s source code, P is required to produce super-pinpoint citations (D rog requesting P identify “ONLY those lines of source code for each limitation that are necessary to allegedly meet each such limitation”) [D sometimes requests such “only those lines that are necessary” super-pinpoints, but are there cases beyond Vasudevan in which court requires?; did court accede to this more out of annoyance at P than from any specific requirement for “only those lines that are necessary” citations? Any relationship between an “only those lines” requirement in infringement litigation on the one hand, and a patent validity requirement that claims provide sufficient notice of what is not being claimed (see Nautilus on indefiniteness and the “zone of uncertainty”).]
4. [If D demands super-pinpoint from P, which is likely only available using D’s source code, can this can help rationalize P’s earlier pre-discovery failure to provide detailed PICs?; borderline software patent cases proceed further than otherwise would, given later heightened requirement for source-code citations?]
5. P made an “unduly burdensome” objection to D’s request that P perform 436 comparisons (4 products x 109 claim limitations), but this objection “fails because VSi sued IBM and has control over the scope of this action.” [P is master of its case]
Mediostream v. Microsoft et al., 2010 US Dist. LEXIS 110420 (EDTX, Oct. 2010)
1. Form & manner of source code production (flat “diff” file)
2. Does “Authorscript” name provide sufficient notice? [authorscript.dll from 2005 in Windows XP 2005 Media Center hotfix contains symbolic info, but not much re: NTSC, PAL]
3. [tk]
Big Baboon v. Dell et al., 723 F.Supp.2d 1224 (CD Cal., July 2010)
1. Diligence required: in part because P did not conduct its initial review of the code until nearly two months after it had been made available, P failed to convince the court that 4 months was insufficient time in which to analyze D’s (Amazon’s) source code and amend infringement contentions (citing e.g. provision of 1 month in AVG and only 2 weeks in DSC).
2. P “asserts that Amazon has not produced materials essential to understanding the code”, e.g. “‘Omnigrok,’ Amazon’s source code encyclopedia, nor a system level map that documents how its code functions” and “Finally, Big Baboon contends that it needs to depose Amazon programmers to understand how Amazon’s code works.” [How much is A required not only to produce source code to B, but also to help B navigate and/or understand A’s source code? What is typical scheduling for P’s examination of D’s source code, and P’s deposition of D’s programmers?]
3. In searching the code, P has found that 6 files were missing; D has agreed to produce within 2 weeks. [Some source code is nearly always missing; it can be difficult to distinguish between e.g. a party’s frequently sloppy handling of its supposed “crown jewels” on the one hand, and “hiding the ball” or spoliation on the other.]
4. Amazon produced 60,000 source-code files, and P asserts it has “not been able to separate those files currently being used by Amazon’s systems from those no longer employed, making it difficult to determine which sections of the code Big Baboon should examine”. [Whose job is it to extract the relevant code from a larger pile?; problems of over-production (dumping) as well as under-production (missing code).]
5. P asserts “that it has not been able to analyze the accused Amazon systems because Amazon has not made the source code available in an environment in which the programs are normally run”: xxx [source-code protective orders (POs) typically create a source-code examination environment unlike that which would be used in non-litigation work, but courts appear generally unsympathetic to such complaints]
6. Because P has had source-code access for 4 months already, and has produced claim charts which do not contain citations to source code, the court must determine what is a reasonable time from the start of source-code exam to filing of amended claim charts; here, the court finds a total of 6 months will provide P with a “reasonable opportunity” to analyze D’s code; D will produce the requested Omnigrok and 6 missing files within 2 weeks, and P then has over 6 weeks to amend claim charts. [Apart from time required, what constitutes a “reasonable opportunity” for one side to analyze the other’s code? Are agreed-upon PO restrictions ever later found to be unreasonable?]
7. [tk]
Bigband Networks v. Imagine Communications, 2010 WL 2898288 (D. Del., July 2010)
1. Discoverability of source code for D’s future unreleased products
  1. P contends that the court previously ordered that D disclose “all of its source code relating to future products,” but the court was referring only to source code for “commercialized products.”
  2. “Neither the Court nor counsel specified exactly what source code they were referencing…” [Attorneys often refer vaguely to “the source code” or even “the codes” (as if it were used for decrypting something else) without specifying a product, version, platform, etc. (e.g., “WonderWidget v. 3.0 for Mac OSX”).]
  3. While D asserts that source code for future products will likely change before they are released (“if they are ever released”), and further that P would not be entitled to any damages from the future products, the court concludes that D’s source code for future products is discoverable, because it is reasonably likely to lead to relevant evidence.
  4. Even unreleased products may be found to infringe: “whoever without authority makes …”; thus, mere manufacture without sale is sufficient to create infringement) [but damages?; unreleased products & injunction?]
2. Holes, gaps, and omissions in D’s source-code production
  1. While D’s production of source code may have “holes or gaps”, and while deposition testimony indicate the existence of additional versions of the ICE Broadcast system for which source code has not been produced, the court is not persuaded that this indicates an “incomplete production.” On the third hand, court concludes that additional source-code production is warranted.
3. Interrogatory requests and responses: source code instead of narrative under 33(d): source code as substitute for narrative?
  1. P asked D to identify any video compression and networking technology that D “made [or] tested”; D’s response was to “direct[] Bigband to the source code held in escrow”; while FRCP 33(d) allows such reference to records when the burden of finding an answer is substantially the same for either party, here “the burden of providing greater specificity is not substantially the same between the parties because Imagine has extensive knowledge of its own source code means.”
    1. [Who knows more about how D’s technology aligns with P’s patent claims?; D (hopefully) knows more about its own source code, but P knows what it’s looking for.]
  2. That D was already able to properly respond to some rog requests to identify its commercialized products leads to the conclusion that those rogs were not impermissibly vague or ambigious.
    1. [This logic might discourage Ds from any good-faith attempts to partially answer vague or ambiguous rogs; “no good deed goes unpunished.”]

Gregory Bender v. Maxim, 2010 US Dist. LEXIS 32115 (ND Cal., March 2010)
1. Court agrees with D that P’s infringement contentions (ICs) do not comply with Local Patent Rule (LPR) 3-1(c); grants D motion to compel compliant ICs, but denies D motion to strike (in part because “strong language” in Bender v. Micrel, “which suggested that future non-compliant ICs would be struck,” post-dates P’s provision of these ICs to D).
2. Court will not order D to proceed with discovery of proprietary schematics for over 200 electronics products, until P first provides ICs compliant with 3-1(c), identifying specifically where each limitation of each asserted claim is found within each accused instrumentality
  1. [Each x3 (limitation, claim, instrumentality); see Sutton v. Nokia]
  2. [First adequate PICs, then discovery; PICs are “key” to discovery door; possibly contrast cases involving source code, in which (unlike electronic circuits here) courts sometimes find a “Catch 22,” such that D must first produce source code before P can supposedly produce PICs compliant with LPR 3-1]
3. P’s current ICs ask the court “to assume that certain elements of the patent are present in the accused product.” E.g., “This element is located on the integrated circuit contained in the product. They are not shown; however, in this case, the current rails are necessary for buffers to perform their function…. they are required and inherent in the design.”
  1. [“Inventor’s fallacy”: I see D producing output y; “the only way” to do y is to use my limitation x, therefore D must be doing x]
  2. [Assuming the presence of an element makes it difficult to point to the “location” of that element. Location, location, location.]
4. “The Court will not order D to produce proprietary schematics for over 200 products based on an assumption. P cannot remedy the current inadequacy of the ICs merely by circling portions of a commercially available datasheet.”
  1. [P must do some real work before D will be compelled to cough up its internal documents]
  2. [“Circling portions”: this is like the “see” problem; P needs to explicitly match the evidence to each limitation]
  3. [“Commercially available datasheet”: see cases frowning on use of marketing materials as a substitute for reverse engineering, e.g. View Eng’r v. Robotic]
5. P pleaded “the expense of reverse engineering over 200 products”; while “the Court is sensitive to this concern,” D should “not be forced to produce proprietary schematics “unnecessarily.”
  1. [Pleading reverse engineering (RE) expense: see other large-quantity cases e.g. Vasudevan where court notes that P is master of its case, and should have thought of RE expense before accusing so many products]
6. Court cites Network Caching v. Novell I (2002): “reverse engineering or its equivalent are required” to generate satisfactory ICs which compare at least one accused product to P’s patents on an element-by-element basis.
7. While P has accused over 200 products, it has provided only 9 claim charts, and P “has not provided an adequate explanation of why the claim charts are representative of all of the accused products”; while P has categorized some of the 200 products (e.g., “LNAs”, “IF IQ Demod”, “RF VCO Buffers”, etc.), others are not categorized at all, and are simply listed by product number; fewer than 500 products are listed on the claim charts; “Since no information is given that would suggest the proper category for each of the remaining products, the infringement contentions fail to comply with Patent L.R. 3-1.”
  1. [Representative instrumentalities: P need not generate charts for each of the 200 products, but it must show “why” the charts it did choose to generate are representative of the non-charted products.]
  2. [Had P categorized all accused products, and had a chart been generated for each category, would the charts have more likely represented the non-charted products?]
8. See also Bender v. Maxim, 2010 US Dist. LEXIS 89957 (ND Cal., July 2010)
Diagnostic Sys. Corp. [DSC; Acacia] v. Symantec et al. [MicroStrategy], 2009 US Dist. LEXIS 53916 (CD Cal., June 2009)
1. Diligence required in source-code examination and in acting on results of source-code exam: P’s consulting expert has spend nearly a year reviewing source code, spending at least 400 hours, but D maintains P’s PICs are inadequate
2. “… as a company whose sole business is to enforce its patents [fn referring to “patent trolls”], the Court finds DSC’s failure to provide PICs that explain how MicroStrategy’s source code infringes … is without substantial justification, particularly when DSC and its software consultant have had the benefit of reviewing source code for nearly a full year…”
3. In 2007 joint report, DSC had argued that it could not be more specific in its contentions until it had source code, citing e.g. EDTX case law to the effect that in source code cases, discovery from D must precede P’s specific contentions. [This is the “Catch-22” notion of source code (e.g. NYU v. e.Piphany), which (based on a misunderstanding of the nature of source code) inverts the normal order of pleading and discovery: Normally, first adequate PICs then discovery. But when court buys “Catch-22” theory, first D produces source code then P produces adequate PICs.]
4. But here, DSC has had D’s source code for nearly a year.
5. DSC had already been ordered to provide “definitive” claim charts for accused devices “right off the bat,” without source-code discovery, so that DSC could not open “Pandora’s box” and then decide what it would file against a “universe” of products, thereby “letting the mouse drive the elephant.” [Contrast “Catch-22” notion of source code, which can enable such mouse-elephant fishing expeditions.]
6. D had taken the initiative by proactively providing P with source code, so that D could obtain clear PICs from P. [Benefit to D of early disclosing its source code, to force P to lock-in an infringement theory; see Townshend IP v. Broadcom, where D tried to push its source code onto P, and P actually resisted.]
7. “The bottom line is that, after a plaintiff-patentee has had a reasonable opportunity to review the source code for the defendant’s accused software patent, the patentee’s time for trolling the proverbial waters for a theory of infringement comes to an end, and the patentee must fish or cut bait… For DSC, trolling time is over.” [Trawling & trolling?]
8. “Despite the label ‘preliminary,’ PICs are not intended to be mere rough drafts subject to drastic modification”; rules are designed to “require parties to crystallize their theories of the case early in the litigation and to adhere to those theories once they have been disclosed” (citing Townshend, in turn citing Integrated Circuit v. Realtek, 308 F.Supp.2d 1106, ND Cal., 2004, that PICs are presumed to be final contentions, with amendments only if required e.g. by later-produced docs or claim construction).
  1. Realtek in turn cites Atmel v. Info. Storage Devices, 1998 WL 775115 at *2-3 (ND Cal., Nov. 1998): “The patent local rules were adopted by this district in order to give claim charts more ‘bite.’ The rules are designed to require parties to crystallize their theories of the case early in the litigation and to adhere to those theories once they have been disclosed. Rule 16-9(c) advances this purpose by making it difficult subsequently to revise claim charts through eleventh hour ‘discovery’ of facts. Unlike the liberal policy for amending pleadings, the philosophy behind amending claim charts is decidedly conservative, and designed to prevent the ‘shifting sands’ approach to claim construction [and] ensure that litigants put all their cards on the table up front.”
9. Software consultant’s “obtuse statements” (that source-code review has been hampered by D’s use of “spyware” and by P’s inability to determine completeness of D’s source-code production) “tend to shed light on her competency and credibility as a software consultant”; her statements do not explain “how she can remain largely clueless after spending hundreds of hours reviewing the source code,” which is much smaller than that for e.g. Microsoft Visa (with an estimated 50 million lines of code). [Court misspells expert’s name?]
10. DSC has 15 days to amend PICs, and cannot wait for deposition of D’s 30(b)(6) representative, nor can it wait for Markman claim construction.
11. DSC’s contends that D’s request for specific mapping of claims to source code would invade work-product privilege covering consulting expert’s opinions; court finds this “frivolous and misleading,” because D is not asking P to disclose P’s expert’s opinions; D is “merely asking” P to describe its theory of how D’s source code infringes P’s patent. [Consulting vs. testifying expert: usually consultant is non-testifying expert covered by FRCP 26(b)(4)(D), though this consulting expert provided a declaration regarding the source-code exam. P trying to protect any internal claims tables as “work product”?]
12. “Although it is a close call, MicroStrategy’s request for monetary sanctions is denied.” [Why, given discussion of 37(c)(1) “self-executing sanction”?]
Michael Sutton v. Nokia, 2009 US Dist. LEXIS 129747 (EDTX, Feb. 2009) (Davis J)
1. P’s supplemental infringement contentions (ICs) do not satisfy Patent Rule 3-1(c) requirement that P submit a claim chart “identifying specifically where each element of each asserted claim is found.”
2. While P is correct that its chart is not required to explain HOW the source code satisfies each claim element, P nonetheless must “identify specifically WHERE each element of each asserted claim is found within each Accused Instrumentality”
  1. [Where, not how]
  2. [Each x3: each element of each asserted claim for each accused product]
3. While P did cite source-code specifics (e.g., “The Editor_HandleMessagePackingEvents function calls the EMS_Packer function implemented in emspacker.c”), court agrees with D that P made no attempt to “correspond” the claim language to the cited source code
  1. [Even source-code function names, file names, and calling info, were here insufficient under LPR 3-1(c)]
  2. [Source code in ICs must be presented in a way which “corresponds” with individual claim elements/steps]
  3. [Insufficient to present two or more elements/steps in a single row on claim chart left-hand side, juxtaposed to source-code cites on chart right-hand side]
  4. [Claim chart must parse out separate elements/steps (even within a semicolon-delimited limitation), and tie/link/weave source-code cites to each element/step; note similarity to IRAC advice to 1Ls: in software patent claim charts, claim limitations are the law, code is the facts, and an infringement/invalidity chart must weave the two together]
4. Opinion provides two examples from inadequate claim chart
  1. Ex. 1: P failed to parse out separate steps of claim, and listed various source-code functions, “while not specifically identifying which of the listed functions relate to each step”; what P has left unparsed discloses “at least” 2 steps (“analyzing”, “assigning”)
    1. [Pay close attention to verbs/gerunds: Ex. 1 & 2 contain “analysing”, “determine” compressability, “compressing”, “treating the data as”, “stuffing”, “assigning”, “unpacking”, “substituting”, and “produce” the message packet.]
    2. [Attributes/preconditions vs. limitations: note when there is an attribute or precondition (e.g. message packet “for transmission”) without a verb/gerund (actual transmitting not required).]
  2. Ex. 2: For two separate limitations on chart left-hand side, P chart’s right-hand side states “Reference is made to Exhibit 4-F”; the exhibit is 7 pages of source code; P did not identify where in the 7 pages the individual claim elements can be found.
  3. [It is difficult to extract law/guidelines from these PIC cases, without seeing the PICs at issue; opinions rarely include PIC excerpts; they can sometimes be found in the other side’s briefs; see US Dist Ct. Pleadings LEXIS.]
5. “Grouping 2 elements together and referencing a 7-page source code [listing] does not clarify where the elements are allegedly located.”
  1. [Pinpoint citations required; however, no mention is made of super-pinpoint, i.e., citation which refers to “only those lines” of source code that are “necessary” to match limitation (see Vasudevan v. IBM)]
  2. [“Reference is made to”: this also suffers from the “see” problem: infringement contentions whose right-hand column states “see” this, or “reference is made to” that, do not actually make any contention; they merely tell to reader to go look at some code and “see” for themselves; yet a conscientious P who wishes to avoid massive claim charts generated by cut & paste must find a way to make cross-references within the chart, without falling afoul of the “see” problem]
6. Under LPR 3-1(c), P’s claim chart must refer to at least one “structure, process, algorithm, feature or function [SPAFF] of any accused product” (citing Connectel)
  1. [P’s chart must identify the location of at least one of D’s SPAFFs; in source code (and even much non-source object code), SPAFFs have names, so D’s names can be used to identify the location in D’s product of an element of P’s invention; perhaps think of this as the “proper-noun rule”: P should locate each of its claim elements in D’s pile of technology, using D’s own name for P’s element; P and its experts may resist being locked-down early in the case to a specific mapping of D’s code to P’s limitations, but the alternative of referring to D’s code using P’s patent’s nomenclature risks the “mimic” problem in e.g. Connectel (“the charts simply mimic the claim language of the patents-at-issue”) or the “for instance” problem (see e.g. CSR v. Freescale); see Vigilos v. Sling Media (suggesting that saying anything about the accused product, beyond the claim language, is sufficient to steer clear of the don’t-mimic prohibition?).]
  2. [Here, P did point to specific functions and files, but by failing to weave/tie/link/correspond these to individual claim elements/steps, it nonetheless failed the SPAFF test, which implicitly requires such correspondence]
  3. [“SPAFF” sounds vaguely like a requirement specific to 112(6) means+function infringement claims, for which 3-1(c) requires that P identify D’s means (“structure(s), act(s), or material(s)”) which carry out P’s functional limitation; but there is no suggestion here in Sutton, or in Connectel, that this is 112(6) specific.]
  4. [Connectel, cited here in Sutton, requires that P’s claim chart refer to “a single [SPAFF] of any accused product.” From context, clearly this means P must refer to at least one SPAFF. But another reading is that all P’s references to D’s source code must together comprise part of a single infringing instrumentality: see cases rejecting claim charts providing a mere “parts list”, “laundry list” (Intertrust v. Microsoft), or “bag of parts.”]
7. Protective order (PO) here requires that D’s source-code production include specific tools for working with source code, including Source Navigator [sourcenav.sourceforge.net; more recently, SciTools Understand appears to be the preferred tool in source-code review]
8. P’s request to compel D to produce source code “that segregates out” the accused applications is denied, but the parties are ordered to meet and confer on P’s stated need for D’s assistance in navigating D’s source code, and/or P’s request for specific “project files” (for Source Navigator) or [product/project specific?] “program files.”
  1. [D may in some instances be required to help P understand how to work with D’s source code; here D states it has already done so, and is willing to do more, if P would explain how it wants D to create “project files”]
  2. [Whose job is it to extract P’s asserted invention from D’s pile of technology?; D (usually) knows more about its own source code; P (arguably) knows more about what a match to its invention would or would not look like.]
9. P “has narrowed its infringement contentions to 83 pages of source code, which indicates [P] has been able to analyze [D]’s source code with the tools already produced.”
  1. [Assuming D produced much more source code than this, while P could presumably use this very small number of source-code pages to show that it has sufficiently pinpointed the location of the invention, it is likely too large an amount to tie to any one claim limitation. The small number of pages could likely be used to used to show reasonableness of P’s printing of D’s source code, or even adequacy of its ICs containing source-code extracts (e.g., Swan v. Finisar [EDTX, Jan. 2014]: “While the Court agrees with Finisar that the proportion of identified code to produced code is not dispositive, it provides an appropriate context from which to evaluate Finisar’s claim that Swan identifies an ‘undifferentiated mass’ of code in its amended contentions.”]
10. Timing: P has had over 7 months to analyze D’s source code; it will have 10 days from production of the “program files” to serve supplemental ICs.
Linex Tech. v. Belkin Int’l et al., 628 F.Supp.2d 703 (EDTX, Sept. 2008)
1. P bases its ICs entirely on the 802.11n standard, and the accused devices’ stated compliance with that standard: is this adequate as the sole basis for ICs under the Patent Rules?
2. “While using the 802.11n standard as the starting point for infringement is permissible, P failed to demonstrate how each Accused Product conforms to the standard…. Instead, P rested on each Accused Product’s advertised compliance.” [Also note use of marketing/advertising literature in infringement contentions; ever sufficient?]
3. “There may be times where an industry standard is sufficiently particular to alone be the basis for infringement cases…. Here, however, reliance on this industry standard alone is inappropriate” because the 802.11n standard “fails to delineate details which are critical to” infringement.
4. See also Townshend IP v. Broadcom re: using standards instead of using e.g. reverse engineering or source code.
5. Representative/exemplary instrumentalities & standards: “P created a single claim chart for each asserted claim and served that same claim chart on every D, notwithstanding the fact that Ds each manufacture different Accused Products…. P fails to take into account that the way in which each Accused Product is alleged to infringe the ‘322 patent will not necessarily be the same, even though all Accused Products are compliant with the 802.11n standard. Not only are there numerous different kinds of Accused Products — including wireless routers, wireless networking cards, and laptops, but the 802.11n standard does not outline specific implementation details for compliant devices.” [Ds here include D-Link, Cisco-Linksys, Netgear, Dell, Gateway, Toshiba; there are at least 68 accused products.]
6. P Linex has served PICs which are less detailed than those which were found inadequate in Connectel
7. P points to software cases in which other P’s ability to provide sufficiently detailed ICs was limited “when the source code for such software is proprietary.” But here, “This is a situation where there is publicly available information which, if utilized, would have provided more information to Ds than P’s ICs did in this case.” [Opinion does not give an example of such publicly available information, but presumably P’s sole reliance on the 802.11n standard together with widespread availability of the products themselves (Linksys routers, etc.) suggests P didn’t try?]
8. “Ds point out that P could have reverse engineered or inspected the Accused Products at minimal cost, but P did not do so.” [fn6: P’s expert noted that the relevant code “is generally incorporated as firmware … and these details are not publicly available.” [Can firmware generally be reverse-engineered from a device “at minimal cost”? In the context of a case accusing this many defendants and products, what is a “minimal” cost? Should P have been expected to use JTAG? Did P try to download the firmware update files which are frequently available on the internet, and which often enable reverse engineering, without first extracting firmware from a device; is it relevant to this case that Linksys in 2005 was required under GPL license to release source code for the WRT54G router firmware, and that e.g. OpenWrt source code was available?]
9. While reverse engineering is not synonymous with whether P has complied with Rule 3-1 (citing STMicro), “the completion of this task [reverse engineering] would evidence P’s diligence in preparing the ICs now at issue.” [Conduct even likely-unsuccessful attempt to reverse engineer to at least show diligence?]
10. P also accused products which are NOT compliant with 802.11n, because “it appears that the chipsets incorporated into these products overlap with those incorporated into 802.11n products,” but since P has proposed a syllogism that 802.11n compliance == infringement, it cannot also assert that non-compliant devices infringe in such the same manner, as not to require separate charts.
11. P is correct that Rule 3-1 does not require that P explain “how” D’s x matches P’s claim limitation y, but 3-1 does require P to disclose sufficient information to expedite discovery. [Not “how” but “where”; yet the opinion often uses the word “how,” e.g. “P must delineate, to the extent possible, how the function is asserted to be performed b y the Accused Product and how that comports with each claim limitation.” In contrast: “P must particularly point to the portion of [i.e., where in] the Accused Product which is asserted to perform the function described in each claim limitation.”]
12. If P lacks information needed to produce an adequate PIC, P “should explicitly note what information is needed and from whom it is needed.” [E.g., discovery from third-party chip manufacturers.]
13. P is ordered to supplement its ICs within 1 month.
Displaylink v. Magic Control Tech., 2008 US Dist. LEXIS 111401 (ND Cal., July 2008)
1. D [actually declaratory judgment P; alleged infringer] seeks discovery of P’s [patent holder; actually declaratory judgment D’s] source code; P responds that D does not need P’s source code to determine whether P practices its invention, because this information is available in product specifications, and (citing Rite-Hite) whether P practices the invention “is not crucial” to lost-profits calculations.
2. [Discovery of source code when same information is said to be available from non-source documents: see also Ioli Trust v. Avigilon; is source code ever viewed as “best evidence”?]
3. Working/practicing, and hence P’s source code, not crucial to lost profits: even so, cruciality is not the test; court finds that P’s source code will be “relevant or reasonably calculated to lead to the discovery of admissible evidence.”
4. [US patent law does not have a working/practicing requirement (hence the phenomenon of non-practicing entities, NPEs or “trolls”), but minimal working/practicing, albeit perhaps by a licensee, must be shown e.g. in ITC importation cases, and working/practicing may be relevant to on-sale and public-use (see e.g. Leader Techs. v. Facebook) as well as to lost profits.]
5. D asserts that P’s source code “may contain notes or comments which bear upon the design and development of MCT’s products and the claimed invention.” [Source code in some ways is as just another document containing text (though it is also operative text).]
6. [Did D also assert relevance of P’s source code for on-sale, public use?; from the opinion, D’s reasons for wanting P’s source code sounds vaguely pretextual?]
7. Court gives P two weeks to produce its source code, under the protective order already in place.
8. [tk]
Garmin v. TomTom, 2007 US Dist. LEXIS 74032 (EDTX, Oct. 2007)
1. “Although Garmin’s actions are disappointing, they do not yet rise to the level of sanctions”
2. “Gamesmanship” (citing STMicro)
3. [Rarity of sanctions re: source code; perhaps not so much the result of the “Catch-22” misconception, as simply court’s wish to avoid seemingly complicated source-code issues?]
4. “Source code” as magic words?: “the Court GRANTS, in part, Garmin’s motion to supplement for all claims mentioning source code and DENIES, in part, motion as to those claims which do not.” [Since the 7,062,378 patent does not use the phrase “source code,” the Court is referring not to the claims of the patent, but to the contentions/claims of infringement.]
5. Interaction of source code with deposition testimony: P “could not decipher” D’s source code until after deposition of D’s 30(b)(6) designee [Sven-Erik Jurgens?], though this was in part because the source code were produced an an earlier PO “in paper format” (!).
6. As P needed the dep to understand the source code, P did not unreasonably delay in moving to supplement the contentions that mention source code, but it does not explain why it waited to supplement those which don’t. [Okay, not quite source code as “magic words”; simply making the incantation “Source Code” is not a get-out-of-jail-free card; but did the Court here simply take P’s word that a deposition was required to understand source-code print-outs?; given widespread availability of TomTom devices, could P have learned more from reverse engineering these devices?; why apart from paper print-out, was source code not sufficiently understandable without deposition?]
7. Discovery allowed into P’s pre-filing investigation [contrast Vasudevan]
Rates Tech. v. Mediatrix Telcom, 2007 US Dist. LEXIS 65637 (ED NY, Sept. 2007)
1. Because this isn’t a software case (“the software issue here is tangential”), therefore (!) don’t shift burden to D to provide discovery before P has provided adequate PICs (citing NYU v. e.Piphany as example where, because D has source code, P is relieved of initial burden of providing adequate PICs).
2. See also Theranos v. Fuisz Pharma for similar “this isn’t software, so don’t shift burden to D” premise.
3. Discussion of “death penalty” sanctions
4. Expert declaration found it easier to conclude infringement by doctrine of equivalents than literal infringement. [Shouldn’t it be more difficult, and require more information, to do DoE rather than literal-infringement analysis? Or does an expert’s conclusion of literal infringement imply a thorough analysis and finding of identical function, identical way, and identical result?]
5. [tk]
Townshend IP v. Broadcom, 2007 US Dist. LEXIS 51792 (ND Cal., July 2007)
1. P wants to rely on D’s stated use of an industry standard to show D’s infringement; D wants to make P look at D’s source code: “Townshend argues that this District chose to amend the patent local rules to not require disclosure of source code prior to PICs and that Broadcom should not be allowed to upset that sequence by voluntarily producing its source code. While that amendment may have protected Broadcom from automatically being required to produce its source code now, its choice to do so serves the goal of the local rules…”. [P trying to turn source-code rule from shield for D into sword for P; the rule as cited, from Network Caching v. Novell (“This is the quintessential case allowing amendment of PICs based on information received in discovery”), was also originally in the context of a 112(6) means-plus-function limitation, which appears to not be at issue here.]
2. Cited in DSC v. Symantec for the proposition that PICs, “despite the label ‘preliminary’ … are not intended to be mere rough drafts subject to drastic modification.”
3. As described in DSC, Townshend served PICs that were lengthy and contained substantial detail but did not map D’s source code to P’s asserted claims. [Simply providing lots of detail in ICs is insufficient; P must “map” the appropriate type of evidence (here, source code) to the claims.]
4. “Instead, Townshend attempted to ‘map’ the asserted patent claims to the provisions of the V.90 standard.” [When can P properly point to D’s adherence to a standard, to avoid time/expense of looking at D’s source code for implementing or using that standard?; see also Linex v. Belkin re: 802.11n.]
5. Even if D adheres to a standard, and even if the standard arguably infringes a patent, D contends that P’s standards-based evidence is inadequate to show that D infringes P’s patent. D contends that V.90 governs sending from servers, but that D makes only client-side devices, and that P merely “cut and pasted” its PICs from prior litigation against a server-side manufacturer. [Marketing that one is “compliant” with a given standard is not sufficient proof that one embodies or carries out the relevant portion of the standard; though it may be sufficient evidence at some stages in litigation?; note difference between implementing a standard on the one hand, and interfacing to it on the other; note importance of checking that claims face in the same direction (e.g. client vs. server, send vs. receive) as the accused technology, and/or in the same direction as the evidence used to show infringement.]
6. P argued it should be allowed to defer amending PICs until after Markman hearing, so that its final ICs could reflect the court’s claim construction; court granted D’s motion to compel P to amend PICs, without waiting until after Markman hearing. [Indeed, infringement analysis is supposed to have claim construction as its first step, but P is nonetheless usually required to allege infringement in the absence of definitive claim construction, and so must adopt some claim construction (which must be reasonable; see Eon-Net v. Flagstar). And while the accused instrumentality is in theory irrelevant to claim construction, both parties’ claim construction positions will be driven largely by their infringement (and invalidity) theories.]
7. Were P willing to commit to the theory represented by its PICs, the court could conclude that its PICs were adequate; but P has “expressly declined to commit to” the theory in the PICs, and has implied that its final ICs will bear little resemblance to the existing PICs. [Other cases in which PIC bar lowered if P will commit?]
Friskit v. RealNetworks, 2007 US Dist. LEXIS 21314 (ND Cal., March 2007)
1. Code interpretation, as well as claim construction: does the GetNextTrack() function in Rhapsody source code determine whether a track is available for play before at least partially playing back the track?; do search results constitute a “playlist”?
2. Elements/steps provided by third parties
3. See also 499 F.Supp.2d 1145
4. [tk]
New York University (NYU) v. e.Piphany, 2006 WL 559573 (SD NY, March 2006)
1. Cites AVG for the proposition that D’s possession of source code poses a “Catch-22” for P, shifting burden to D to produce source code before (!) P produces adequate PICs.
2. Yet, “plaintiffs, of course, may first be required to demonstrate that they exhausted other ways of exploring potential infringement” [not merely relying on publicly-accessible information, but exhaustively using it]
3. [Court believes it is applying heightened requirements for source code, since post-discovery ICs require pinpoint source-code citations, but in the meanwhile P is allowed vaguer pre-discovery initial PICs, therefore allowing P to get its foot in the courthouse door in situations in which it otherwise couldn’t]
4. NYU cited in Rates v. Mediatrix (ED NY, 2007): under limited circumstances, D may be required to provide P with source code so P can be more specific about its claims; but P may first be required to demonstrate that it “exhausted all other ways of exploring potential infringement.”
5. [tk]
Connectel v. Cisco, 391 F.Supp.2d 526 (EDTX, May 2005) (Davis J)
1. Preliminary infringement contentions (PICs), while preliminary, must be more than perfunctory
2. Representative (“exemplar”) instrumentalities (over 100 accused products)
3. Quantity case: “shotgun” accusations of hundreds of products infringing hundreds of claims
4. P’s PICs “simply mimic” claim language
5. Pinpoint citations: P citations to product manuals do not specifically identify “where” in this literature the asserted claims are found
  1. [P’s responsibility to point D to (i.e., provide notice) where, in D’s own materials, D can allegedly find each element of P’s invention]
6. Repetitive PICs (600 footnotes refer back to same handful of string cites to product manuals)
  1. [Court not fooled by mere quantity]
7. Contrast STMicro v. Motorola (where not shotgun accusations)
8. Contrast AVG v. Electronic Arts (where P’s experts played hundreds of hours of video games, importantly to rule out many non-infringing processes)
9. Contrast AVG v. Electronic Arts (where P only wanted to view precise pieces of source code to build its case; source code was necessary to fill gaps)
  1. [Role of source code is to “fill the gaps” in P’s knowledge of D’s product, NOT to make initial case; contrast later cases such as NYU asserting a source code “Catch 22”]
  2. [According to Connectel opinion, STMicro and AVG do NOT (contrary to P assertions) stand for the proposition that cases involving source code have a “lower standard” for pre-discovery PICs; yet later cases e.g. NYU do view AVG this way.]
10. P is expected to rigorously analyze “all publicly available information” before bringing suit
11. P’s PICs do not refer to a single “structure, process, algorithm, feature or function” [SPAFF] of any accused product
  1. [SPAFF is NOT re: 112/6 means+function; Sutton v. Nokia refers to Connectel for general proposition that PIC must reference “at least” a single SPAFF]
12. Now that P is receiving source code from D, P has 60 days to supplement PICs to highlight where each element of the asserted claims are found
  1. [It is in D’s interest to provide P with D’s source code, as this raises the bar for P]
  2. [“Heightened requirements” after receive source code, even if apparently lowered pre-discovery requirements in AVG and STMicro; have courts lowered the PIC admission price to software patent litigation, on the mistaken basis that requiring source-code pinpoints in final ICs is a heightened requirement?; would it be preferable to raise the bar earlier rather than later?; would this address the perceived “software patent crisis”?]
Am. Video Graphics (AVG) v. Elec. Arts (EA), 359 F.Supp.2d 558 (EDTX, March 2005) (Davis J)
1. When D has “sole possession” of information that P needs (source code), P is “typically unable to give highly specified” PICs
  1. [Despite Connectel clarification, AVG is the basis for later opinions, e.g. NYU v. e.Phiphany, that D’s possession of relevant source code “typically” presents P with a “Catch-22” or “chicken and egg problem”]
2. “In non-software patent cases, Ps are usually able to purchase D’s products and ascertain the mechanics of how those products infringe before Ps bring suit. But, there are times when P’s preparation is restricted by D’s sole possession of the information P needs. Software cases present unique challenges for the parties and the courts because, prior to discovery, Ps usually only have the manifestation of the Ds’ allegedly infringing source code and not the code itself. From this manifestation, Ps must somehow divine whether the Ds’ code infringes. Although Ds vigorously and rightly guard their source code, until Ps have access to it, Ps are typically unable to give highly specified infringement contentions [ICs]. To the extent Ds are given vague ICs, they are hampered in their ability to prepare their defense….”
  1. [Note the assumptions here: that a product on the market (here, video games) is “only … the manifestation” of the source code, and that it is the source code which infringes, that it is the source code which constitutes “the code itself.”]
  2. [In Connectel, Davis J distinguishes AVG by noting that P in AVG spent hundreds of hours playing these video games, and “ruled out” some of them; thus, AVG is not a license to accuse first and defer researching infringement (at least to the extent of using a product, with some means of determining what does not constitute infringement) until source code becomes available]
  3. [Could/should AVG have not merely played, but also reverse engineered the games?; see 2005 U.S. Dist. Ct. Pleadings LEXIS 3939 for list of accused products, e.g. Sony Lords of Everquest, Atari Neverwinter Nights, Nintendo Legend of Zelda Windmaker; at least PC versions, if not e.g. Playstation, would have been open to reverse engineering]
3. Opinion reprints portion of PIC, and determines that “AVG has complied with Rule 3-1(c) to the best of its current ability.”
  1. [The PIC portion appears to merely “mimic” the claim language, e.g. PIC left-hand side (P’s claim element) “storing applied graphic information representing a 3D object in a first 3D coordinate modeling space” and PIC right-hand side (D’s accused product) “For example, each Accused Instrumentality listed in Ex. B-1, when executed on a computer or video game system, stores in memory information representing 3D objects in a 3D coordinate system”, which merely adds “in memory”.]
4. Now that parties have agreed to escrow arrangements for making D’s source code available, P has 30 days from when D deposits source code into escrow (“on a rolling basis”) to supplement its 3-1(c) charts with specific references to source code.
Renesas v. Nanya Tech., 2004 US Dist. LEXIS 23601 (ND Cal., Nov 2004)
1. Case re: reverse engineering (RE) circuitry, schematics, not re: source code [looks like most RE cases are non-software?]
2. Representative instrumentalities and reverse engineering
3. P grouped accused products into “A” and “B” version products; inspected two “A” and one “B” product; and explained why it could extrapolate from inspected products to others.
4. [Expert testimony permissible on whether RE of x also applies to y; see Shared Memory v. Apple]
5. Cited in Theranos v. Fuisz Pharma for the proposition that party asserting patent infringement must include in its ICs “all facts known to it, including those discovered in its pre-filing inquiry”. [How does this relate to courts’ general disfavor of Rule 11 “satellite” litigation?; contrast discovery into P’s pre-filing investigation in Garmin, with no such discovery in Vasudevan.]
6. [tk]
STMicroelectronics v. Motorola, 308 F.Supp.2d 754 (EDTX, March 2004) (Davis J)
1. The question of whether P (Motorola) conducted “reverse engineering or its equivalent” [as part of a reasonable pre-filing investigation under Rule 11] is “not synonymous” with whether P has complied with Patent Rule 3-1 covering preliminary infringement contentions (citing as persuasive Network Caching v. Novell, ND Cal., 2003)
2. Court denies STM’s motion, and finds Motorola’s PICs sufficiently specific to notify STM of the identity of accused “products and process,” at least “[d]ue to the complexity of the inventions at issue and the highly detailed nature of Motorola’s alleged disclosure deficiencies…”.
  1. [Anomalous case, suggests that, for “complex” technology, anything more than mere restatement of claim language makes PIC sufficient?; or was “highly detailed nature” of the deficiencies an indication that the PICs themselves were also detailed?]
3. “Court is unwilling to pre-try the case at this procedural stage by conducting a highly detailed and rigorous analysis of the preliminary claim infringement contentions.” (Emphasis in original)
  1. [Disputed sufficiency of PICs is not an opportunity to try the case on its merits; court will not rigorously parse PICs?]
4. “the Court will not tolerate gamesmanship that attempts to conceal or delay the production of discoverable items” [what proportion of source-code discovery issues, like discovery issues generally, result from mere gamesmanship?]
Network Caching v. Novell, 2003 WL 21699799 (ND Cal., 2003)
1. Cited in Townshend for the proposition that “The only way to pinpoint the specific routine is to analyze the source code, which is solely in D’s possession. This is the quintessential case allowing amendment of PICs based on information received in discovery,” but without noting that the “specific routine” here in Network Caching required pinpointing because of 112(6) means-plus-function, not merely because the case involved source code.
2. [tk]
Network Caching v. Novell, 2002 WL 32126128 (ND Cal., Aug. 2002)
1. Rule 11 reasonable pre-filing inquiry is minimum for Patent Rule 3-1
2. “Reverse engineering or its equivalent is required” for P’s Rule 11 obligations in patent cases [but see CSR v. Freescale suggesting RE only for non-software?]
3. What does “reverse engineering” (RE) mean in this context?; how does the use of RE as a litigation investigation tool compare to the judicial definition in trade-secrets cases, e.g. “starting with the known product and working backward to divine the process which aided in its development or manufacture” in Kewanee Oil v. Bicron, 416 US 470 (1974), cited in Bonito Boats v. Thundercraft, 489 U.S. 141 (1989)?; how does this litigation use of RE relate to the RE which many software licenses attempt to prohibit?
4. What are “equivalents” to RE?; can use of marketing materials or manuals be equivalent to RE?
5. P’s use of D’s marketing literature as “proxy” (substitute for RE) to show infringement is acceptable
6. More detail is required for 112(6) means+function claims (actually, 112(6) limitations?); later uses of this case ignore the 112(6) context; the “heightened” requirements for software means-plus-function limitations, after source code becomes available, are used to excuse earlier pre-discovery lack of what would otherwise be insufficient detail in infringement contentions. [Incantation of “source code” as magic words, free-admission ticket to patent litigation?]
7. [Tighter IC lays basis for looser PIC: Source code enables later non-preliminary pinpoint of alleged infringement, therefore excuse vaguer preliminary infringement contentions, before source code becomes available?; the bar to software patent litigation is being raised too late?]
8. CSR v. Freescale Semiconductor interprets this case as holding that “while reverse engineering was required … for non-software limitations,” it is not required for at least certain software limitations [under 112(6) means-plus-function]
9. Must link infringement evidence to specific limitations (P “provides no explanation of how the proxies described in the literature map onto the claim language”) [Must show how/why as well as where (location of infringement)?; similar to need to “weave” facts with law in IRAC]
10. Here, right-hand side (evidence) in P’s PIC mimics left-hand side (claim language)
11. Shared Memory v. Apple cites for the proposition that PIC needn’t prove infringement, but needs to show where in product P believes infringement is found [ND CA: why P believes that D infringes?]
12. [tk]

Source Code & Reverse Engineering in Patent Cases

Source Code & Reverse Engineering in Patent Cases

Search

Menu

Recent updates