Source: http://www.softwarelitigationconsulting.com/articles/source-code-reverse-engineering-in-patent-cases/
Timestamp: 2019-04-21 22:28:26+00:00

Document:
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.
Quotations from source code in expert report: prior approval needed to quote?
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”).
P is ordered to amend its ICs to conform to Patent LR 3-1.
Requirements for initial ICs, citing Shared Memory v. Apple, DCG v. Checkpoint, View Eng’g v. Robotic.
Infringement contentions based entirely on “information and belief” (citing Theranos v. Fuisz).
“Where” and DoE: don’t reference entire product as equivalent structure.
“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?
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.
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.
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.
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).
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.
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.
Interrogatory requests and responses: source code instead of narrative under 33(d): source code as substitute for narrative?
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.
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).
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.
But here, DSC has had D’s source code for nearly a year.
“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).
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.
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.
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.
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?
“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.
See also Townshend IP v. Broadcom re: using standards instead of using e.g. reverse engineering or source code.
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.
P is ordered to supplement its ICs within 1 month.
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.
Court gives P two weeks to produce its source code, under the protective order already in place.
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” (!).
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).
See also Theranos v. Fuisz Pharma for similar “this isn’t software, so don’t shift burden to D” premise.
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”?
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.
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.
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.
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…”.
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.
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?
What are “equivalents” to RE?; can use of marketing materials or manuals be equivalent to RE?

References: v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v. 
 v.