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 2: Source code and the “accused instrumentality” — how source code relates to commercial products
2.1 The relationship between source code and the “accused instrumentality”
- Generally, software vendors directly generate revenue from binary/object code, rather than from source code
- Source code has a more direct relation to software/internet products/services, than schematics/blueprints/diagrams have to non-software products
- Yet source code is generally not the product/service itself
- Why examining source code is important, but generally insufficient, to determine how the product/service works
- Source code may show merely that product capable of infringing; product examination may be needed to show that does
- Source code is generally tightly held as a proprietary “crown jewel,” whereas the product/service is on the open market (also note implications for prior art)
- For example, source code is not a component of the product under 271(f) (AT&T v. Microsoft)
- Even “open source” products are generally used by consumers in binary/object code form, with the source available separately
- Is the source code itself ever the accused instrumentality?
- Source code may be accused of “making” or “using” infringement, but probably not “selling”, offering for sale, or importing
- For making/selling, source code is likely “mere evidence” (albeit crucial “mere evidence”) of internal operation and design of the accused product/service
- Single source-code tree often corresponds to multiple products/versions, some unaccused; see chapters 7 and 26 on representative instrumentalities
- Therefore, source code examination by itself should generally not be the sole source of information regarding what the product/services does
- The other key source of information is the product/service itself: see reverse engineering in chapter 6
- Source code produced in discovery often must be compared to the accused instrumentality: see chapters 16 and 22
- Patent holder’s burden to show how the accused products work is not identical to showing what the source code says: see chapter 22 on specific source/product differences (code in source not compiled into product; code in source compiled into product, but never used; etc.)
2.2 Why the source code/product distinction matters in patent litigation
- Party producing source code in discovery may have produced “wrong” source code
- Producing party in discovery often produces source code for many products/versions at once; source-code examiner must select and extract relevant code without getting “lost in the source”
- Infringing technology found in source code is not necessarily represented in commercial product
- Infringing tech found in source not necessarily invoked/used in commercial product: see “latent code” cases
- Latent code: do features disabled in product (locked, unlicensed, defeatured, etc.) still infringe?
- Latent code generally infringes apparatus and medium (Beauregard) claims, but not method claims
- Source code aligned with making/using infringement, does not necessarily align with selling/offering/importing
- Unused “dead code” in source may still infringe making/using e.g. as “scaffolding”
- Infringement contentions must show where each limitation resides in the accused instrumentality; “pinpoint” citations to source code do not necessarily show this, unless a source/product link is explicitly made or is unproblematic
- Well-known features of commercial product (e.g. adherence to standard) may reduce need to examine source code corresponding to that feature; but see chapter xxx on verifying use/implementation of standard
- Cases in which source/product link was problematic
- Cases in which source/product link was unproblematic
- Source code not matching accused instrumentality may reveal forthcoming/future products, requiring supplementary complaint and/or discovery (see chapter 14 on supplementation), or injunctive relief (see chapter 30)
- Source code not matching accused instrumentality may reveal non-infringing alternatives
- Source code not matching accused instrumentality may help show “before and after” impact of adopting patented invention
- ITC importation cases: ITC has no jurisdiction over source code [proprietary source code doesn’t sit on dock at customs; but note ITC cease-and-desist order against electronic “importation” in Hardware Logic case (1997)]
- Export cases: is source code a component of the product under 271(f)?; AT&T v. Microsoft
- Damages calculations are generally based on commercial product, not on source code; but see “lines of code” fallacy in chapter 30
- Damages: code which appears important in source code may play only peripheral role in commercial product
- Anticipatory prior art found in proprietary source code may not have been expressed in public commercial product, and therefore may not have been able to teach the PHOSITA at the relevant time
- Obviousness and compilation: object/binary code in commercial product may constitute a single “reference,” even when corresponding source-code files are disparately located [thus, may be able to use anticipation rather than obviousness]
- Products which may be operated in both infringing and non-infringing manner
- Non-infringing alternatives found in source code may be unexpressed in commercial products, or outside product’s intended use
Cases on source code/product relationship
- Globespanvirata v. TI (no need to link source code to specific product, because expert opinion based on source code from opponent’s workstation)
- Schade v. Md. Board of Elections (non-patent case; need to link Diebold source code found on Internet to actual voting-machine product)
- Banfield v. Cortes (non-patent case; need to verify that programs used in election are the same as programs officially certified?)
- Quickturn/Mentor (ITC no jurisdiction over source code; but see Hardware Logic, ITC cease and desist order re: electronic importation)
- Implicit Networks v. F5 (reliance on wrong source code?; does examined source code allow inference that accused products operate similarly to actually-examined products?)
- St. Clair IP v. Acer (looking at wrong version of products, inadvertently extending opinion to older versions)
- AT&T v. Microsoft (is source code a component of product under 271(f)?)
- Lucent v. Gateway (product can be operated in both infringing and non-infringing manner)
- Finjan v. Secure Computing (“latent code”)
- Southwest Software v. Harlequin (defeaturing, disabled features)
- eSpeed v. BrokerTek (prior art latency, inherency?)
