Source Code & Reverse Engineering in Patent Cases at the Court of Appeals for the Federal Circuit (CAFC)
Andrew Schulman
www.SoftwareLitigationConsulting.com
Last updated Jan. 2, 2015
This is part of a work in progress, which will eventually cover several hundred patent cases in which software source code and/or reverse engineering played a role. Below, “[tk]” indicates that further discussion is to come. Within quotations, plaintiff/defendant or party names have often been replaced with “P” and “D”.
For non-CAFC cases, see Source Code & Reverse Engineering in Patent Cases.
- Versata Software v. SAP, 717 F.3d 1255 (CAFC, 2013)
- SAP asserts that trial court’s failure to grant JMOL of noninfringement was erroneous, in part because SAP’s software is incapable of performing the accused function without adding computer instructions. However, sufficient portions of the record clearly support the jury’s conclusion that SAP’s accused products infringe the asserted claims without modification or additional computer instructions. [A recurrent theme in CAFC cases regarding software patent infringement is whether the accused software actually embodies/performs the claimed invention, in contrast to accused functionality merely “latent” in the source code for a product, or only enabled with some modification. Alternatively, some cases hinge on whether the claims, as construed, may be infringed by mere presence in the source code (e.g. “making” infringement of apparatus claims, or here, claim limitations requiring mere capability to do x, without necessarily doing x).]
- SAP stipulated to claim construction calling for “computer instructions causing a computer to implement” the claimed operations, or “computer instructions capable of” performing those operations.
- Versata’s expert explained SAP’s source code to the jury, pointing in particular to comments written in the source code by SAP engineers. In part from these comments, P’s expert Versata’s expert concluded that the code was written by SAP engineers “so that it could perform the [claimed] functions…. [The] writing of that code means that the code has been configured to implement these particular functions or to be able to cause the computer to do these things.” [Using purpose/intent/function as expressed in comments, to match patent claim construction calling for code “capable of” performing an operation. The purpose/intent/function of code may also be expressed in names of functions or modules. Defendants sometimes respond that the comment or name in their own code is not completely accurate, and indeed comments and function names are not guaranteed to accurately reflect operative portions of the code (often because the code has been changed without a corresponding change to the name or comment; see xxx), but it is often unpersuasive to be seen as asserting that one’s own source code is somehow inaccurate.]
- Demonstrative exhibit: “The most telling evidence was the expert’s demonstrative data setup…. The expert testified that this data setup did not require any modification to SAP’s source code, and that SAP’s accused products all included the code to accomplish his demonstration. In essence, the expert confirmed his theories that the accused software was capable of performing the claimed functionality by making the software perform the function without modifying the software.” [Confirming source-code observations by testing live software. Contrast Lucent v. Gateway re: Windows Media Player, where expert examined source code, but where answering the critical factual question required testing the actual product.]
- “SAP does not dispute that its software, as set up by Versata’s expert, performed the claimed functionality. Instead, it claims that Versata did not prove that SAP’s software, as shipped to the customer, infringed the ‘350 Patent. It argues that the claim language ‘computer instructions capable of’ and ‘computer instructions causing a computer to implement’ are not directed to source code. Rather, the language requires that the software, as shipped, contain computer instructions to perform the claimed functionality. In its view, the expert’s data setup added new computer instructions to SAP’s software, thereby changing and modifying a noninfringing product into an infringing product. [] SAP misinterprets the claim language…. It does not appear that SAP requested any claim construction of the term “computer instructions,” much less a construction that limits the phrase to exclude source code or require that the patented function be “existing as shipped” in the computer instructions.” [While it didn’t help here, because claim construction required only capability, rather than actual enabling of feature in shipped product (similarly, see “changeable” in Broadcom v. ITC), D should always look at whether P’s expert’s source-code analysis covers the accused product as shipped to or used by customers. As to whether a claim limitation such as “computer instruction” likely matches source code (as opposed to executable, object, and/or binary code), also see cases e.g. AT&T v. Microsoft where the fact-finder must decide whether a “golden master disk” constituted a software “component” for purposes of import/export infringement.]
- “SAP also misinterprets the expert’s data setup. As this court has previously explained, when ‘a user must activate the functions programmed into a piece of software by selecting those options, the user is only activating the means that are already present in the underlying software.” [Finjan v. Secure Computing] … While ‘a device does not infringe simply because it is possible to alter it in a way that would satisfy all the limitations of a patent claim,’ … [High Tech Med. Instrumentation v. New Image Indus.], an accused product ‘may be found to infringe if it is reasonably capable of satisfying the claim limitation,’… [Finjan, quoting Hilgraeve v. Symantec].” [In addition particularly to Finjan (“locked” feature), see other CAFC cases re: “latent code”, e.g. Southwest Software v. Harlequin (de-featured versions), and Telemac Cellular v. Topp Telecom (code capable of literally infringing, but only with modification, is not thereby infringing under the doctrine of equivalents). Here in Versata, court’s “reasonably capable of” language could be mis-interpreted to indicate that reasonable capability would infringe generally, even in the absence of the specific “capable of” claim construction here?]
- “Versata’s expert did not alter or modify SAP’s code in order to achieve the claimed functionality. Rather, he followed SAP’s own directions on how to implement pricing functionality in its software and activated functions already present in the software…. SAP cross-examined the expert, but the jury ultimately chose to credit the expert’s testimony and documentary evidence. SAP has not met the high standard needed to disregard the jury’s fact-finding function on this issue.”
- [See excellent earlier discussion of “The ‘Latent Code’ Cases” (Jan. 6, 2011) in Bill Vobach’s blog on CAFC oral arguments.]
- Leader Techs. v. Facebook, 678 F.3d 1300 (CAFC, 2012)
- After verdict of patent invalidity from on-sale bar, Leader points to the “clear and convincing evidence” standard as requiring evidence such as source code or schematics, but in reviewing jury verdict, court only need look at whether there was sufficient evidence for a reasonable juror to draw conclusion that the version of Leader2Leader demonstrated and offered for sale prior to the critical date embodied the asserted claims.
- Here, Leader asserts that the only evidence presented was for validity. [Does the clear and convincing evidence standard for patent invalidity require positive evidence of invalidity (such as source code), or can it reasonably be grounded on the fact-finder’s disbelief of the inventor’s testimony supporting validity?]
- [Alternatively, is Leader asserting that the only evidence for invalidity was witness credibility, and the jury’s apparent disbelief in inventor’s testimony?; either way, oral testimony which jury discredits could weigh more than absent source code.]
- In fact, there was more evidence than the apparently-discredited oral testimony, including Leader’s own rog response that Leader2Leader “embodies” the asserted claims. Leader states that the use of present tense “embodies” was deliberate, and that this should not be read back onto versions before the critical date; however Leader did not so qualify its response at the time: “The responses did not specify any date ranges nor did they identify versions or builds of the software…” [Importance of software version numbers, date ranges; attorneys are sometimes unnecessarily vague on formal product names, versions, platforms, and even dates.]
- [Interrogatory responses, deposition testimony, admissions, non-source documents can help avoid or shorten source-code examination; there is no “best evidence” rule for source code.]
- [Case is of course about sufficiency of evidence in reviewing jury verdict, not about source code as such. Compare with e.g. i4i v. Microsoft, in which patent holder’s own loss of relevant source code did not relieve D’s burden of showing invalidity by clear and convincing evidence.]
- Eon-Net v. Flagstar Bancorp, 653 F.3d 1314 (CAFC, 2011)
- Pre-filing investigation: necessary but insufficient to look at publicly available info, such as web site or publicly available source code; P and its attorneys must also reasonably construe claim language, as part of its reasonable pre-filing investigation.
- Attorney’s implicit pre-filing claim construction, in which claims re: hard-copy documents were read onto a web site, was not reasonable. [Failed straight-face test?]
- [tk]
- Advanced Software Design v. FiServ, 641 F.3d 1368 (CAFC, 2011)
- District court did not abuse its discretion or commit clear error in not permitting P to amend its patent-infringement complaint to include a false-advertising claim. Such amendment would require good cause, which P failed to show.
- The district court found that P unduly delayed seeking to amend; it “had ample time to conduct discovery and to have [its] experts analyze defendant’s product.” P contends that it was not aware that D’s Secure Seal product lacked public key encryption until D’s attorney so admitted when P had had access to the source code for “only about four months.”
- “Before litigation, D had allegedly represented to the banking industry that Secure Seal used two distinct encryption algorithms, one of which used public keys. P sought D’s source code during discovery, but it did not obtain the complete source code until October 2008. On January 8, 2009, after attorney discussions about the source code, D changed its representation to declare that Secure Seal used only one encryption algorithm that did not use changeable public keys. A little more than a month after that change in D’s position, P moved to amend the pleadings to assert a Lanham Act claim based on D’s advertisements, which stated that Secure Seal was more secure than other barcode systems (such as P’s system). The district court denied the motion because the deadline for amendments under the court’s initial case management order had passed and, in the court’s view, P had not provided any ‘legitimate reason’ for the delay.”
- [Was P’s initial complaint of patent infringement based in part on D’s representations that D’s product used public keys? Presumably yes, given that P’s patents are in the area of check-security using “key-based” cryptography. When P learned that D does not use public keys, P itself moved to dismiss the relevant patent-infringement claims, and to substitute a false-advertising claim. While the false-advertising amendment was not allowed here because of timing, the case suggests that, when P grounds its patent-infringement complaint in part on D’s marketing materials, and then learns during source-code discovery that the public representation was incorrect, P may consider pursuing the false representation. This may also apply to cases where P relies on D’s stated compliance with a standard (see e.g. Linex v. Belkin; Fujitsu v. Netgear). At the same time, courts generally frown on P pre-filing investigations which rely entirely on D’s marketing representations, rather than on P’s reverse engineering of D’s products; see e.g. xxx. Here, could Advanced Software have learned of FiServe’s non-use of public keys from inspection of FiServ’s product?
- [Does a competitor have standing to raise a false-advertising claim in the situation where D is arguably making public representations that it practices P’s patented technology?]
- Uniloc v. Microsoft, 632 F.3d 1292 (CAFC, 2011)
- Expert testimony (David Klausner) that MD5 algorithm performs addition, summation
- [tk]
- Finjan v. Secure Computing, 626 F.3d 1197 (CAFC, 2010)
- Product contains source code (or build from source code?) for all features, but only some licensed; infringing feature was locked/disabled in product (Cyberguard TSP, Webwasher)
- Latent code; see Versata v. SAP
- Latent code can infringe apparatus or medium claims, even if not infringe method claim
- [tk]
- i4i v. Microsoft, 589 F.3d 1246 (CAFC, 2009)
- Lexis overview: “Finding of infringement of patent for method of editing custom computer language was proper since distinct storage means did not require separate files, invention was not shown to be anticipated or obvious, evidence sufficiently showed direct, contributory, and induced infringement, and substantial damages and injunctive relief were warranted.”
- “In evaluating the evidence, the jury was free to disbelieve Microsoft ‘s expert, who relied on the S4 user manual, and credit i4i’s expert, who opined that it was impossible to know whether the claim limitation was met without looking at S4’s source code. Although the absence of the source code is not Microsoft ‘s fault, the burden was still on Microsoft to show by clear and convincing evidence that S4 embodied all of the claim limitations. The jury’s finding of validity was supported …”
- [P lost its source code relevant to D’s invalidity claim; even though loss of evidence can lead to inference (rebuttable presumption) that lost evidence would have spoken against the party which lost it, here the burden is still on patent-infringement D to show by clear and convincing evidence the invalidity of P’s patent (which is presumed valid).]
- [tk]
- See also i4i v. Microsoft, 598 F.3d 831 (CAFC, 2010) re: on-sale bar, spoliation, corroboration
- See also i4i v. Microsoft, 670 F.Supp.2d 568 (EDTX, 2009)
- Lucent v. Gateway, 580 F.3d 1301 (CAFC, 2009)
- Date-picker in Microsoft Outlook; remand for new trial on damages
- Damages & lines of code (LOC) measurements: “As explained by Microsoft’s expert Mr. Kennedy, Outlook consists of millions of lines of code, only a tiny fraction of which encodes the date-picker feature. Although the weighing of [Georgia-Pacific reasonable royalty] Factor 13 [“portion of the realizable profit that should be credited to the invention as distinguished from non-patented elements, the manufacturing process, business risks, or significant features or improvements added by the infringer”] cannot be reduced to a mere counting of lines of code, the glaring imbalance between infringing and non-infringing features must impact the analysis of how much profit can properly be attributed to the use of the date-picker compared to non-patented elements and other features of Outlook. Here, numerous features other than the date-picker appear to account for the overwhelming majority of the consumer demand and therefore significant profit. [] The only reasonable conclusion that can be drawn from this evidence is that the infringing use of Outlook’s date-picker feature is a minor aspect of a much larger software program and that the portion of the profit that can be credited to the infringing use of the date-picker tool is exceedingly small. For these reasons, Factors 10 [“nature of the patented invention; the character of the commercial embodiment of it as owned and produced by the licensor; and the benefits to those who have used the invention”] and 13 of Georgia-Pacific provide little support for the jury’s lump-sum damages award of $357,693,056.18.” [Role of technical evidence (including source code) in damages calculations; other cases in which lines of code (LOC) play a role for economists/accountants?; interplay between software expert and economics/accounting experts; other technical evidence, apart from LOC, showing relative importance v. non-importance of an accused feature?; usually such evidence is non-technical, based on consumer demand (rather than technical supply); but can e.g. frequency with which code is run, or other dynamic code analysis (contrast static analysis of counting LOC) inform damages calculations?]
- SJ on non-infringement of certain claims was not erroneous when Lucent did not analyze source code of accused programs, and did “nothing more than demonstrate that the accused products reach the same result” as the claims without even circumstantial demonstration of the steps used to arrive at the result. [See cases e.g. xxx involving the “inventor’s fallacy”: “D produces x, the ‘only way’ to produce x is to use my patented y, therefore D ‘must be’ doing y.”]
- [tk]
- Touchcom v. Bereskin, 574 F.3d 1403 (CAFC, 2009)
- Patent attorney malpractice case: “Touchcom will be required to show that, had appellees not omitted a portion of the source code from its application, the resulting U.S. patent would not have been held invalid.” [But-for causation; malpractice “trial within a trial”]
- The district court “premised much of its finding of indefiniteness on the absence of portions of the source code from Touchcom’s patent” (referring to Touchcom v. Dresser, 427 F.Supp.2d 730 (EDTX, 2005)). [Under what circumstances is “source code necessary to satisfy the definiteness requirement of 35 U.S.C. ç 112”? Here, the two limitations at issue were “display and input task means” and “application task means” under 112(6).]
- [EDTX court noted: ‘large portions of the source code are missing from Schedule A. The various code modules are listed in alphabetical order in the ‘282 patent at columns 31-47. However, in the actual code section of the patent, at column 1341, the source code ends part of the way through through the “P” or “pump” section. Thus, a portion of the “P” section, all of the “S” section (for switches) and the “T” section (for touch) are missing.’]
- [tk]
- Lucent v. Gateway, 543 F.3d 710 (CAFC, 2008)
- Microsoft Windows Media Player (WMP); don’t confuse with Lucent v. Gateway 2009 re: Outlook date picker; Lucent v. Gateway (2008) re: loop in Fortran code (shown in patent spec)
- Lucent relied on circumstantial evidence to attempt to show that WMP “necessarily” infringes. Infringing two claims required proof that High Quality encoder [HQE] has actually run. Lucent evidence established only uncertainty and speculation as to whether HQE had run even once. Expert opinion that errors would occur that would cause Fast encoder to fail and not cause HQE to fail “was based only on his review of the source code … he did not know at what rates such errors occurred and did not ever observe such errors.” [Need to examine/test product (dynamic) as well as read source code (static).]
- Cites Acco Brands, 501 F.3d 1307 at 1310: accused device could be operated in two ways, one infringing and one non-infringing; in that case, lock users received instructions describing only the non-infringing method; see also E-Pass, 473 F.3d at 1216. [See latent code cases, e.g. Finjan.]
- [tk]
- Scanner Tech. v. Icos Vision, 528 F.3d 1365 (CAFC, 2008)
- While P was prosecuting its patent application, it learned of D’s new product, which P believed would infringe the proposed claims of P’s pending application. P filed a “petition to make special” with the PTO, seeking accelerated review of the pending patent application. P based this petition on an assertion, per MPEP 708.02, that the accused product is “actually” on the market, that P had made a “rigid comparison” of D’s product with P’s proposed claims, and had reasonably formed the opinion that at least some claims were “unquestionably infringed.” The PTO granted the petition and accelerated the application process.
- Fast forward to P’s infringement case. The district court found the patent unenforceable due to inequitable conduct, based in part on P’s statements in its petition to make special that it had performed a “rigid comparison,” when according to the district court it could have done no such thing, as “The UV+ was not on ‘open display’ at the December 1998 trade show, at least not in the sense that Beaty tried to convey, for the system was in a black sealed box and an inspection of the module would not have revealed how the calculations were performed.”
- CAFC ruled that the district court erred: “… a physical inspection should not be an implied requirement for use of the phrase ‘rigid comparison’ in a petition to make special in that, depending on the technology, and whether the claims are directed to an apparatus or a method, a physical inspection may not provide any more information than what can be ascertained from review of product literature. In some cases, a review of source code may be the only way to make a comparison of an accused device to proposed patent claims, which cannot be accomplished by physical observation of a ‘black box’ enclosing the hardware that stores the application generated by such source code. The district court seemed to recognize as much when, in criticizing Beaty’s use of the term ‘open display’ to describe Scanner’s system at a trade show, the court stated ‘the system was in a black sealed box and an inspection of the module would not have revealed how the calculations were performed.’ … [] Furthermore, the district court did not credit the fact that the ‘rigid comparison’ words are not of Leone’s creation. The PTO’s rules for the contents of a petition to make special require recitation of those words. In sum, the district court’s inference that Leone misleadingly suggested he saw the ICOS device, when weighed against a equally reasonable inference of good faith that the plain words of his statement and supporting material engenders, does not support the conclusion that the attorney’s statement is misleading, or false under the clear and convincing evidentiary standard.” [Would this have come out differently under a lower standard? Albeit not rising to the level of inequitable conduct, was the statement of having made a “rigid comparison” nonetheless untrue, given the relative inaccessibility of the competitor’s device at the trade show?]
- [Note that “rigid comparison” requirement is a third instance in which fact-finder possibly must assess whether a product on the market can reasonably be examined” (which in turn may implicate state trade-secret law re: reasonable security precautions [RSP]). The other product-public-visibility areas in patent litigation are invalidity cases re: public use, and reasonable pre-filing investigation (e.g. Rule 11) cases re: ability to inspect an accused product on the open market. Discuss (somewhere else, not with this case) whether there is more than a superficial similarity between the public-use cases and the pre-filing investigation cases; note that public use need not be enabling.]
- Metropolitan Life Insurance v. Bancorp, 527 F.3d 1330 (CAFC, 2008)
- Conflict in expert declarations creates genuine issue of material fact, rendering summary judgment inappropriate. [Experts’ ability to create factual issues, and hence to defeat SJ. D’s expert, stretching to agree with P’s expert on a dispositive factual issue, is also able to promote SJ (as generally desired by D)?]
- Here, P’s expert (Klausner) states that D uses certain calculations on spreadsheets used to administer certain policies. D’s expert agreed that spreadsheets did make these calculations, and that some spreadsheets were used in administering these policies, but denied that the particular spreadsheets containing the relevant calculation were used in administering the policies, as required under claim construction of P’s patent. The district court could not dismiss this conflict merely by crediting D’s expert declaration over P’s, as credibility disputes are not appropriately resolved on SJ.
- P’s expert looked not only at the spreadsheets, but at other source code and documents indicating how the spreadsheets fit into D’s policy administration. [Spreadsheets with formulas, macros, VBA, etc., are source code. Non-source docs or quasi-source docs (such as spreadsheets with formulas, but not extensive macros, custom programming, etc.?) can often be correlated with source code, and sometimes this can resolve, or at least (as here) raise, a central issue in litigation.]
- District court, in reconsidering its earlier denial of SJ, explained that it had previously misunderstood Klausner’s declaration as stating that D module calculating x was the equivalent of claim-relevant y, but later concluded that Klausner merely indicated that a mathematical ratio exists to convert x into y, without providing adequate evidence that D’s system actually made this conversion. [Whether software does something, or is merely capable of doing it, is often a crucial distinction. Experts sometimes maintain that x an inherently also a y, because the conversion from x to y is trivial. See also “latent code” cases e.g. Finjan. But here, don’t know whether this will be important until court clarifies claim construction; maybe showing x is sufficient. And allowing P discovery may uncover that D does use x to do y.]
- Remand to district court for more explicit claim construction (to infringe, must a system “administer” policies?), and to allow reasonable discovery by P.
- Lucent v. Gateway, 525 F.3d 1200 (CAFC, 2008)
- Communication between host processor and terminal device; digitizing speech
- Properly-construed claim may exclude source-code preferred embodiment
- Patent 4,701,954 has FORTRAN source code in appendix (“Predictive Filter Processor”, “Compute Coefficients for the Predictive Filter”, “Generate y Signal”, etc.)
- Lucent contends that source code in patent appendix shows steps performed only one time during each iteration of frame loop, and NOT during each iteration of pulse loop; claim construction contradicts preferred embodiment; but claim construction NOT incorrect, since claim itself supports construction; don’t redraft claims to fix even obvious drafting error. [Thus, limit to use of source code in patent to understand claims; P’s claims (properly construed) trump P’s source code, even though source code would appear to be unambiguous.]
- Lexis overview: “Claim for ‘terminal device’ in patent for communications protocol was misconstrued since device itself was not required to manage associated display rather than host processor, but claim in patent for methods of digitizing speech required all iterative steps in forming each pulse of frame, even though such claim excluded preferred embodiment.”
- [tk]
- Aristocrat Tech. v. Intern. Game (IGT), 521 F.3d 1328 (CAFC, 2008)
- Means-plus-function (112/6) and source code
- 112 ¶ 6 does NOT require a source-code listing or highly detailed listing of algorithm to be used to achieve the claimed functions, but it DOES require at least disclosing the algorithm that transforms the general purpose microprocessor into a “special purpose computer programmed to perform the disclosed algorithm” (citing WMS Gaming, 184 F.3d at 1349).
- Lexis overview: “U.S. Patent No. 6,093,102 was invalid under 35 U.S.C.S. 112 because it was indefinite. The patent, which protected an electronic slot machine, did not disclose the required algorithm or algorithms the machine used to function, and a person of ordinary skill in the art would not have recognized the patent as disclosing any algorithm at all.”
- [tk; see also Katz v. AA re: functional claiming]
- Intamin v. Magnetar, 483 F.3d 1328 (CAFC, 2007)
- When reverse engineering is infeasible, it is not required for pre-filing investigation: No sanctions for failure to obtain and cut open metal casing in roller-coaster braking system; distinguished from ease of obtaining sample bar-code scanner in Judin v. US. [RE not required, or merely that failure to RE not sanctionable?; in any case, if the accused product is more like a bar-code scanner than like a roller coaster, plaintiff would be wise to get and thoroughly examine the product, before accusing it of patent infringement.]
- The magnets at issue were encased in metal tubes, and “a visual inspection would not disclose the orientation of the magnets within the tubes…. the technology presented the patentee with unreasonable obstacles to any effort to obtain a sample of Magnetar’s amusement ride brake system, let alone the difficulty of opening the casing.”
- [Below is summary of cases on whether reasonable pre-filing investigation of patent infringement requires reverse engineering; but the summary does not take into account the procedural posture of the case or what precisely is being requested at this stage (motion to strike, dismissal, Rule 11 sanctions):
- Intamin v. Magnetar – no sanctions because element at issue was encased, visual inspection would not disclose, and technology was a roller coaster, presenting unreasonable obstacles to obtaining, “let alone the difficulty of opening”.
- Judin v. US – sanctions applicable when scanner would have been easy and inexpensive to obtain, and observation from a distance was insufficient to disclose two “critical” limitations.
- Antonious v. Spalding & Evenflo (275 F.3d 1066, CAFC, 2002) – remand to determine whether Rule 11 sanctions applicable when extrapolating from one cut-open and inspected golf club, and one sentence in marketing literature, to a larger product line.
- Q-Pharma v. Jergens (360 F.3d 1295, CAFC, 2004) – no sanctions when lotion product label itself listed relevant product characteristic, even though this turned out, post-filing, to not be present in sufficient quantity to infringe.
- View Eng’g v. Robotic – sanctions when rely on inventor’s word who merely cited expense and difficulty of obtaining machine for scanning microprocessors.
- Bender v. Maxim – no dismissal or sanctions, but harsh warning that case probably can’t continue without reverse engineering, despite pleaded expense of reverse engineering circuits; exceptions to reverse-engineering requirement noted when impractical or unnecessary, but no showing of either made here; expense not seen as constituting impracticality.]
- [A fair summary, then, is that “reverse engineering or its equivalent” is required when a critical limitation cannot be discerned from outward visual inspection, but it is not roller-coaster-impractical to obtain and open up the product (what is the meaning of “open up” or “cut open,” vs. “visual inspection” in the context of software products and services?). Expense of acquiring the product or of reverse engineering it carries no weight, such explanations being seen as “lame” and not as an example of impracticality. Impracticality (buying and opening up roller-coaster brakes?) and lack of necessity (the critical limitation is listed on the product packaging, albeit without specifying amount, which amount may be important) can be reasons to not reverse engineer at this stage.]
- [tk]
- Eolas v. Microsoft, 399 F.3d 1325 (CAFC, 2005)
- Does code (source code? object code?) on “golden master disk” constitute, under 35 USC 271(f), “components” of an infringing product for combination outside the US?
- See Microsoft v. AT&T, 550 US 437 (2007)
- [To the extent these cases apply to source code (e.g. exported to be compiled abroad) rather than to object/binary code (e.g. EXEs, DLLs, etc. on Windows master disk), is source code more like blueprints (a guide to constructing a building, but clearly distinct from the building itself), or more like raw materials (parts of source code are “in” the final software product)?]
- [tk]
- HP v. Mustek Systems, 340 F.3d 1314 (CAFC, 2003)
- Vacate district court’s JMOL of infringement under doctrine of equivalents (DoE)
- No new trial, because HP did not make sufficient record for DoE
- HP points to 4 different literal infringement showings by its expert at trial, including “reverse engineering” of source code, to argue that this literal-infringement evidence also went to equivalence; according to HP (quoted in the opinion), “Dr. Stevenson confirmed his findings [of literal infringement] four different ways — external operation and observation, internal oscilloscope testing, review of the Mustek documents and depositions, and reverse engineering of Mustek’s source code…. After explaining this evidence, Dr. Stevenson expanded his conclusions on literal infringement to include that Mustek’s scanners performed the same functions the same ways to achieve the same results.”
- But DoE requires evidence as to each of function, way, and result (F/W/R), not simply lots of evidence almost showing literal infringement [showing literal infringement does not imply showing equivalence; DoE F/W/R is more difficult to show than literal infringement, as each of F/W/R must be handled separately, which is not required (but perhaps should be, to refine expert opinions?) for literal infringement]
- HP’s expert merely answered “yes” to a series of three boilerplate questions re: F/W/R [F/W/R as “mantra”; expert needs to actually think through each of function = purpose or role; way = implementation; result = output]
- [expert mere ipse dixit is not evidence; expert opinion must have basis in facts and methodology (Daubert)]
- Further, HP evidence did not include “linking argument” (citing Lear Siegler v. Sealy Mattress, which refers to “testimony reasonably served to articulate the comparison”, and which notes that only attempt to link was attorney’s closing argument that testimony “has to do with equivalents”) [need to tie/link/weave facts of infringement on the one hand to law of claim limitations on the other; such linking or articulation of comparison is often done using the word “because”; merely indicating that D’s x “has to do with” P’s claim limitation y is inadequate]
- Moba v. Diamond Automation, 325 F.3d 1306 (CAFC, 2003)
- Software used as analogy in biotech concurring opinion.
- Rader (concurring): While the court did not “fall for” its use here, the court’s Lilly “super-enablement” standard (Regents of Univ. of Cal. v. Eli Lilly Co., 119 F.3d 1559 (CAFC, 1997)) presents severe consequences for biotechnology. The jury had to decide “possession” separate from enablement, considering whether “the patent’s disclosure can enable a skilled artisan to make and practice the entire invention, but still not inform that same artisan that the inventor was in possession of the invention. Puzzling.”
- Lilly judicially created a new disclosure requirement, and attributed it to “written description”. “This new disclosure doctrine, applied so far only to biotechnology cases, requires a nucleotide-by-nucleotide recitation of the structure of a biotechnological invention…. This burdensome disclosure standard is tantamount to requiring disclosure, for a new software invention, of the entire source code, symbol by symbol, including all source code permutations that would not alter the function of the software. Ironically, the Federal Circuit has expressly rejected such a requirement for software inventions, but apparently enforces the requirement for biotechnology,” citing e.g. N. Telecom v. Datapoint, 908 F.2d 931 (CAFC, 1990) (overturning a finding that a patent did not adequately disclose “batching” software). “This discrepancy emphasizes another problematic aspect of the Lilly doctrine. That is, it imposes a different disclosure standard for biotechnology than for computer technology.” [See Burk & Lemley, The Patent Crisis, re: technology-specific “policy levers”?]
- [tk]
- Netscape v. Konrad, 295 F.3d 1315 (CAFC, 2002)
- Patent invalidity through public use
- Existence of non-public source code does not turn otherwise public use of software into a confidential use
- Konrad says that the demonstration of the high energy physics remote database object system at the Stanford Linear Accelerator Center was not enabling because there was no evidence that the source code was delivered to the Superconducting Super Collider Laboratory before the critical date.
- But the test here for public use is whether patent holder demonstrated and marketed the invention for
others more than one year prior to the earliest application filing date [the test is not whether the patent holder additionally had some internal documents (such as source code here) which was not made public] - [Netscape (D) had to rebut presumption of patent validity; invalidation requires clear & convincing evidence; but SJ for D if no issue of material fact; compare i4i v. Microsoft (P’s loss of evidence re: public use not shifting burden from D)]
- Case history: P’s patents were found invalid under 102(b) public use and on-sale bars; P appealed
- Question: Has P raised a genuine issue of material fact re: pre-critical date demonstrations, public use by others, or his commercial offer?
- Answer: no; affirm
- Holding: Pre-critical date demonstrations without obligation of confidentiality were public use; offer to create in exchange for employment satisfies on-sale bar; this despite relationships between inventor and those shown or offered the invention.
- Rationales:
- If done by another would be prior art, so 102(b) if done 1 year + before by inventor [So inventor will argue that his own prototype != claimed invention; wasn’t ready; didn’t work; etc.]
- P argues that invention wasn’t ready for patenting at time of offer to create; and that offer was not a contract but a mere accounting instrument within two DOE labs; but P admitted invention was reduced to practice (i.e. ready for patenting) ca. Sept. 26, 1990
- Even if demonstrated prototype didn’t include every claimed limitation, it also meet 102(b) via obviousness; missing element was init by starter client, which obvious
- No experimental use (City of Elizabeth) exception here, because patent holder sought to convince others that it had a viable project; P was testing the market not the device; sought endorsements [not feedback]; didn’t maintain records; put onto workstation but didn’t know where located; didn’t monitor workstation; simply let people try it out [similar to outboard-motor experimental-use case, not to pavement case]
- P argues that not public or on sale, because all pre-critical period activities were among same employer (Lawrence Berkeley Labs, US Dept. of Energy), but no proactive control/restriction at LBL, and DOE merely provided funding, it didn’t have onus to control use of the invention; DOE never exercised such control as to render all funding recipients part of the same entity
- P argues that his own activities were not enabling because did not deliver source code before the critical date; but failure to monitor & failure to impose confidentiality put claimed features into public possession [but P’s argument is that invention wasn’t disclosed through use, because no source code?; if that is argument, then still doesn’t work, because public-use and on-sale bars do not require enablement]
- 102(b) public use totality of circumstances 7 factors:
- Public access to, and public knowledge, of public use
- Whether any confidentiality obligations imposed on observers
- Did persons other than inventor perform testing
- Number of tests
- Length of test period in relation to tests of similar devices
- Whether inventor received payment for testing
- [tk]
- Robotic Vision v. View Engineering, 249 F.3d 1307 (CAFC, 2001)
- Source code & on-sale bar: “In Robotic II [112 F.3d 1163 (CAFC, 1997)], we indicated that, unless the software was completed before the critical date, the method itself could not have been on sale…. However, under Pfaff, actual completion of such software is not required, provided that there is a disclosure that is sufficiently specific to enable a person skilled in the art to write the necessary source code to implement the claimed method.”
- [tk]
- See also View Engineering v. Robotic Vision, 208 F.3d 981 (CAFC, 2000) re: kneejerk counterclaim, attorney sanctions for failure to investigate
- Telemac Cellular v. Topp Telecom, 247 F.3d 1316 (CAFC, 2001)
- Un-executed code: “P contends that, even though D has chosen not to permit direct dialing of international calls, the capability of billing for international rates is nonetheless present in the phone’s source code. According to P, because D’s system is capable of being modified to place, and charge for, international calls, D’s system infringes. [] Under the precedent of this circuit, however, that a device is capable of being modified to operate in an infringing manner is not sufficient, by itself, to support a finding of infringement. High Tech Med. Instrumentation v. New Image Indus.… [49 F.3d 1551 (CAFC, 1995); cited for the same proposition in e.g. Blount v. Peterson, 438 F.3d 1354 (CAFC, 2006)]. In this case, due to a restriction built into the software program stored in the telephone’s memory, a user of D’s system is prevented from directly placing international calls. Therefore, international rates, and the calculation of charges for such calls, are not included in the billing algorithm of the accused device. The district court correctly concluded that P’s allegations of literal infringement must fail.” [It isn’t source code as such that infringes, but rather actual product on market?]
- [See “latent code” cases, e.g. Finjan. But even unused code can infringe by “making.” On the third hand, “making” infringement is inapplicable to method claims, which in order to infringe must (any counter examples?) be carried out. See also e.g. xxx where mere ability do x was sufficient to infringe, because claim limitation only required ability to do x (e.g. “programmability”). Half-way decent analogy between latent code on the one hand and dicta in an opinion on the other?]
- [What is interrelation between a vendor shipping software with unusued code on the one hand, and inducement/contributory infringement on the other?; presumably this would require something like the instruction sheets or assembly instructions in e.g. Sharper Image v. Target, 425 F.Supp.2d 1056 (ND Cal., 2006) and other cases citing Blount v. Peterson, including software-related Lucent v. Gateway, 580 F. Supp.2d 1016 (SD Cal. 2008), and Broadcom v. Qualcomm, 543 F.3d 683 (CAFC, 2008). When can software itself constitute such an instruction sheet or assembly instruction?; install, config, make, build, batch files, scripts, macros, sample code?]
- [tk]
- Novartis v. Ben Venue Labs, 271 F.3d 1043 (CAFC, 2001)
- Expert witness’s source code: opinion reproduces entirety of P’s expert’s source code (used in on-software case to determine whether crystalline form of x exists at any point during D’s process for manufacturing x in solution): “The program’s main routine appears to begin at line 28. The astute reader will have noted that line 28 is not commented. Nor is line 29. Nor is line 30. In fact, this court has searched all the lines of Dr. Nauman’s model for comment or explanation, in vain. While we concede that line 12, which defines Pi to be 3.14159, is self-explanatory even to a judge of this court, the remainder of Dr. Nauman’s code is populated by inscrutably named variables such as ‘dollarsmoved’ and ‘centsmoved,’ which may or may not represent the conditions of Ben Venue’s commercial process, upon which are performed unexplained mathematical operations, which may or may not represent the dynamics of Ben Venue’s neutralization reaction. Neither the basic theoretical framework nor the derivation of the necessary inputs is apparent from Dr. Nauman’s source code.” [Daubert and expert’s own source code in case otherwise unrelated to software; cases dependent on e.g. damages expert’s SPSS or SAS code?; variables and formulas in expert source code relevant to Daubert assessment of bases for expert opinion.]
- Since this inscrutable computer model was the only evidence in the record for P’s theory of infringement, D was entitled to summary judgment of non-infringement.
- [tk]
- Southwest Software v. Harlequin, 226 F.3d 1280 (CAFC, 2000)
- De-featuring product after suit filed: code was not removed from product; “Instead, using a common industry practice, the source code was modified so that the automatic selection feature could not be invoked during normal operation of the software.” However, D’s revised product does contain a “warm system” alerting the operator to the need for manual calibration, but without even suggesting a better calibration set. [Interesting, but how does this relate to CAFC remand decision?]
- [tk]
- Hoffmann-La Roche [& Syntex] v. Invamed et al. [Torpharm], 213 F.3d 1359 (CAFC, 2000)
- Reverse engineering in pharmaceutical patent-infringement case
- Affirming that (unsuccessful) suit nonetheless had sufficient Rule 11 basis, where P did everything possible to obtain facts regarding D’s alleged infringement, was unable to, and elected on the basis of this inability to proceed with litigation.
- District court: Ps “attempted to ‘reverse engineer’ [D’s] sample tablets to determine whether the process by which the tablets were made infringed upon the P patents. However, Ps could not ascertain the process and could not determine whether it infringed the P process patents.”
- “It is difficult to imagine what else [Ps] could have done to obtain facts relating to D’s alleged infringement of their process patents. D has pointed to nothing else that it believes they could or should have done. [D’s] position apparently is that because [P] were unable to obtain and set forth in their complaint facts showing infringement, they should not have filed suit at all.” [“Exhaustion” (see xxx) in pre-filing investigation of all available information; if exhaust all public info and nonetheless can’t find infringement, then okay to proceed to litigation?]
- [When does failure to find infringement become an implicit finding of non-infringement?; only when find evidence of non-infringement? trying to prove a negative?; what if suspect infringement from some public source, and then more fully investigate this source, only to find that original suspicion is not borne out by this particular source — is that evidence of non-infringement? or merely failure to-date to find infringement?; it seems it is at least some evidence of non-infringement, but: just because element/feature A of a product does not infringe, doesn’t mean there isn’t some other element/feature B, C, or D which does infringe; while “fishing expeditions” are frowned upon mid-case, they are entirely appropriate before P decides to file the case; pre-filing investigation = “fishing” in that P decides what to keep, what to throw back; once P files its case, there are limits on changing its theory of the case, especially when it learns in discovery what it could have learned pre-filing.]
- Failure to find infringement in an exhaustive pre-filing investigation does not rule out proceeding with litigation: “The district court correctly rejected that theory. As it stated, although Ps ‘could have assumed non-infringement’ when ‘[a]t the end of the plaintiff’s pre-suit investigation it had neither evidence of infringement nor non-infringement . . ., that they chose to file suit and engage in discovery instead does not subject them to sanctions.’ … If D initially had told them, under a confidentiality agreement, the process used to manufacture the drug €” as it subsequently did €” it could have avoided this litigation and the expenses incurred in defending it.” [Shifting burden onto D, pre-filing, to disclose information relevant to possible infringement?; if D opts not to provide this info (see e.g. xxx with P-to-be’s pre-filing request to D for D’s source code), then if P’s case later fails, P won’t be sanctioned?]
- [Conversely, risk to P-to-be of pre-filing request to D for confidential info; this may rise to the level of D reasonable apprehension of suit, providing D with declaratory judgment standing; see xxx.]
- [tk]
- View Engineering v. Robotic Vision, 208 F.3d 981 (CAFC, 2000)
- Kneejerk counterclaim: attorney sanctions were upheld for the attorney’s sole reliance on the inventor’s say-so, which in turn was based solely on advertising and statements made to customers, without any physical access to the accused machines (for three-dimensional scanning of computer chips to insure proper lead alignment), whose expense and difficulty of purchasing from a competitor were cited as reasons for going no further.
- [Attorney obligated to do some independent investigation, not rely entirely on inventor’s mere say-so (similar to expert ipse dixit)]
- Cited in Theranos v. Fuisz Pharma [Is info that P gleaned during its pre-filing investigation to be kept in P’s back pocket, held back until a Rule 11 challenge by D as to the adequacy of P’s pre-filing investigation, or must essentially all of the pre-filing investigation be disclosed in PICs?; it seems that especially negative results in pre-filing investigation (e.g., P’s reverse engineering uncovered several clear instances of non-infringement, before it finally came upon a less-clear potential instance of infringement) is pure work product, but see apparently contradictory statements in Theranos]
- “Why P believes it has a reasonable opportunity of proving infringement” (cited in e.g. CSR v. Freescale) [is this “why” requirement merely identical to showing “where” infringement is believed to exist (naming each specific element or step in D’s accused product/service which allegedly embodies/carries out each limitation of P’s asserted claim), or is it something more, e.g. a “because” clause in the ICs giving (unless D’s wording/naming is identical to that of P’s patent claim) the reason why P believes that D’s element/step x literally or equivalently infringes P’s claim limitation y?; if “why” is more than “where,” is this mostly a ND CA requirement?]
- [tk]
- Lockwood v. American Airlines (107 F.3d 1565, CAFC, 1997)
- re: “secret aspects of SABRE” (airlines reservation software)
- This case, and In re Epstein (32 F.3d 1559, CAFC, 1994), are important on the status of software products themselves (as opposed to source code for, or documentation about, the software) as prior art. See Open to Inspection: Using Reverse Engineering to Uncover Software Prior Art, Part 2.
- “Lockwood attempts to preclude summary judgment by pointing to record testimony that one skilled in the art would not be able to build and practice the claimed invention without access to the secret aspects of SABRE [i.e., source code]. However, it is the claims that define a patented invention [citing Constant v. AMD]…. American’s public use of the high-level aspects of the SABRE system was enough to place the claimed features of the ‘359 patent in the public’s possession [citing In re Epstein: “Beyond this ‘in public use or on sale’ finding, there is no requirement for an enablement-type inquiry.”]. Lockwood cannot negate this by evidence showing that other, unclaimed aspects of the SABRE system were not publicly available. Moreover, the ‘359 patent itself does not disclose the level of detail that Lockwood would have us require of the prior art. For these reasons, Lockwood fails to show a genuine issue of material fact precluding summary judgment.” [P shouldn’t demand more detail from the prior art than P itself provided in its patent. P — 359 employed “means for”, but only software descriptions in — 359 spec are high-level exemplary functional flowcharts. Is this an estoppel argument? Or conflating enablement with obviousness?]
- “We agree with American that those aspects of the original SABRE system relied on by the district court are prior art to the ‘359 patent. The district court held that SABRE, which made and confirmed reservations with multiple institutions (e.g., airlines, hotels, and car rental agencies), combined with the terminal of the ‘631 patent rendered the asserted claims of the ‘359 patent obvious. The terminal of the ‘631 patent admittedly lacked this ‘multiple institution’ feature. It is undisputed, however, that the public was aware that SABRE possessed this capability and that the public had been using SABRE to make travel reservations from independent travel agencies prior to Lockwood’s date of invention.” [So the SABRE feature on which court relies was visible on the face of the SABRE software service, and was not something which in the absence of source code would have required reverse engineering by PHOSITA to uncover?]
- Case is also about expert’s ability to create genuine issues of material fact sufficient to preclude summary judgment; P expert failed to respond adequately to D’s motion; affirm JMOL for AA
- Cited [where?] for proposition that “secret computer program could be prior art under 102(a) where it was ‘known or used by others,’ even though they could not see how it worked”
- Cited [where?] for facts/proposition that “D’s own SABRE was prior art, even though ‘critical aspects’ not accessible to the public, even though D’s expert concedes essential AA SABRE algorithms were proprietary, confidential; and even though didn’t enable; but disclosure & enablement not required for public use or use by others under 102(b)” [and/or because the crucial element for obviousness analysis, ‘multiple institution’ feature, was in any case public knowledge?]
- [tk; don’t confuse with Katz v. AA (some claims indefinite under WMS Gaming and Aristocrat standards; functional claiming without adequate structural support in spec]
- Robotic Vision v. View Eng’g, 112 F.3d 1163 (CAFC, 1997)
- Source code, enablement, PHOSITA, on-sale bar, best mode (yawn): “it has not been shown that there is a genuine issue as to whether one skilled in the art would have known how to create specific source code for this purpose. We have previously held in Hayes and in Fonar (after the district court decided this case) that when disclosure of software is required [for best mode], it is generally sufficient if the functions of the software are disclosed, it usually being the case that creation of the specific source code is within the skill of the art…. We therefore must conclude that the district court erred in granting summary judgment to View that the ‘227 patent is invalid for failure to disclose the best mode.”
- But see Robotic Vision v. View Eng’g, 249 F.3d 1307 (CAFC, 2001): “In Robotic II [112 F.3d 1163 (CAFC, 1997)], we indicated that, unless the software was completed before the critical date, the method itself could not have been on sale…. However, under Pfaff, actual completion of such software is not required [for on-sale bar], provided that there is a disclosure that is sufficiently specific to enable a person skilled in the art to write the necessary source code to implement the claimed method.”
- Pfaff v. Wells Elecs., 525 U.S. 55 (CAFC, 1998), supplanting the “substantially complete” standard previously applied to on-sale bar
- [same standards being applied for on-sale bar and best mode?]
- [tk]
- Judin v. US, 110 F.3d 780 (CAFC, 1997)
- Purchase, observation, and/or reverse engineering of accused device required for reasonable pre-filing investigation: P “observed an accused [bar-code scanner] device from a distance while it was in use at a post office, but neither Judin nor his attorney attempted to obtain a device from the Postal Service or the manufacturer so that they could more closely observe the device, nor was any attempt made to dissect or ‘reverse-engineer’ a sample device.”
- Attorney relied on inventor’s say-so: “attorney acted unreasonably in giving blind deference to his client and assuming his client had knowledge not disclosed to the attorney”; trial court’s contrary determination was abuse of discretion.
- Cited in e.g. Eon-Net v. Flagstar, ResQNet v. Lansa
- Contrast difficulty of reverse engineering roller-coaster braking system in Intamin v. Magnetar.
- [tk]
- In re Epstein, 32 F.3d 1559 (CAFC, 1994)
- This case, and Lockwood v. American Airlines (107 F.3d 1565, CAFC, 1997) re: SABRE airlines reservation software, are important on the status of software products themselves (as opposed to non-public source code for, or printed documentation about, the software) as prior art. See Open to Inspection: Using Reverse Engineering to Uncover Software Prior Art, Part 2.
- [Software product, without source code, as prior art: in fact, if the source code was not open source at the relevant time, then not only can the software itself constitute prior art, without the source code, but furthermore the source code likely is NOT prior art, as prior art must have been publicly accessible at the relevant time (see e.g. the library/theses cases).]
- [Closely-held proprietary source code would only be “mere evidence” as to whether the public software product did or did not put the invention on sale or in public use. The source code itself would not have been in public use; but what about tightly-restricted sale of source code?]
- [Why can software without source code constitute prior art? For on-sale and public-use bars, the reasoning is different from that in a novelty or obviousness inquiry. Here, “closed” software, without source code, works because on-sale and prior-use bars do not require that the prior art have enabled the PHOSITA at the time. Epstein is cited in Lockwood for the proposition that “Beyond this ‘in public use or on sale’ finding, there is no requirement for an enablement-type inquiry.” In contrast, prior art for novelty or obviousness must have enabled the PHOSITA at the time, and so closed software, without source code, is only prior art for novelty or obviousness to the extent that the PHOSITA could contemporaneously have gleaned the invention from the non-source software; but see “non-informing prior art” discussed in Open to Inspection: Using Reverse Engineering to Uncover Software Prior Art, Part 2 starting at fn. 62, with background in the section titled “If Nobody Saw it at the Time, Is it Still ‘Prior’ Art? (Answer: Of Course It Is; the Question is Instead Whether the PHOSITA Could Have Seen It at the Time, Possibly via Reverse Engineering)”. Because of the ability to reverse engineer, software products without source code are in any case more “informing” than commonly thought; see Open to Inspection: Using Reverse Engineering to Uncover Software Prior Art, Part 1 at fn. 29.]
- Further, under Epstein, the date of prior-art software can be evidenced by later (or undated) materials. The case provides useful examples of such materials:
- “In a subsequent office action dated May 23, 1991, a new examiner, relying on several newly discovered publications, withdrew the previous allowance and rejected all pending claims. As listed by the examiner, the newly discovered publications were” (listed below):
- “CONTROL SYSTEM 7.0” software product, as described in a database print-out (no date), which states a release date of January 1982;
- “SMART/SCSS” software product, as described in a Datapro Research Group catalog dated February 1991, which states a first installation date of January 1987;
- “Pro-Search” software product, as described in a database print-out (no date), which states a release date of October 1986, for version 1.08, and October 1, 1987, for version 1.07;
- “DIALOG” database system, as described in a seminar book dated June 1988, which contains DIALOG file descriptions separately dated March 1987 and sample DIALOG searches (not separately dated);
- “CONTROL SYSTEM” software product, as described in a Datapro Research Group catalog dated February 1991, which states a first installation date of March 1982; and
- “DCS2000” software product, as described in a Datapro Research Group catalog dated February 1991, which states a first installation date of 1977.
- “Only one of these publications — the DIALOG seminar book — is a prior art publication. The other publications are not prior art themselves; rather, they allegedly evidence prior art products.”
- “In a subsequent office action dated May 23, 1991, a new examiner, relying on several newly discovered publications, withdrew the previous allowance and rejected all pending claims. As listed by the examiner, the newly discovered publications were” (listed below):
- [Careful: the abstracts in Epstein may relate to more superficial aspects of a product than what one typically can learn from even the simplest reverse engineering. Such post-dating is thus likely more useful for on-sale or public-use bars (where, however, it must still be determined whether what was on-sale or in public-use was in fact the invention; the inventor will typically deny this: “that thing we sold or offered for sale or put in public use? that old thing? that wasn’t our invention, etc.”) than for novelty or obviousness.]
- [See also MPEP 2133.03 (b) (“non prior art publications can be used as evidence of sale before the critical date”)]
- [Post-dated references used to show prior public use, when that public use was not documented at the relevant time: possible odd analogy between software object/binary code on the one hand, and unwritten native/tribal/aboriginal practices on the other. See e.g. the EDC “hoodia” case: “The Board is aware that the traditional knowledge of the original inhabitants of the Kalahari desert, like the San people, is the subject of a large number of publications. Many thereof have been published on the Internet. However, most of these documents have been published after the filing date of the present patent application and there is no convincing evidence on file that this post-published information, about what was known before the filing date, reflects reality. Therefore, the Board will not take into account postpublished documents relating to traditional knowledge allegedly available to the public before the filing date, and consider only those documents which have been published before said date and which refer to different uses of plants of the genera Trichocaulon and Hoodia.” EPO, Pharmaceutical Compositions Having Appetite Suppressant Activity, T 053/04 – 3.3.4 (27 Jan. 2005) ¶ 9 (re: publications from 1937, 1966, and 1993, and affidavits from 2004; order to grant patent). Courts however have accepted later testimony regarding earlier unpublished practices; an example is the testimony of Abhay Phadke in the famous neem cases. EPO, T 416/01 (2005). See rough notes for a paper on foreign unpublished prior art. Note however that object/binary software code is still a “printed publication.” See xxx.]
- [What is the printed-publication (or prior-art generally) status of computer object code which has been publicly distributed? If the PHOSITA could at the time reverse engineer information contained in the object code, is that information prior art? What if the evidence presented of this is later (non-contemporaneous) reverse engineering? Does the PHOSITA’s skill at reverse engineering, at the relevant time, need to be shown, so that there is no “undue experimentation” in digging out the information? What about code widely distributed nominally under a shrinkwrap or clickwrap agreement with language purporting to forbid reverse engineering? What about DMCA restrictions on learning what, apart from the DMCA, would be within the PHOSITA’s skill to learn from a DMCA-protected product? Generally, the issue is whether prior art includes (a) a contemporaneous partial description of the product, (b) later-produced source code, and/or (c) contemporaneous object code.]
- [tk]
- Northern Telecom v. Datapoint, 908 F.2d 931 (CAFC, 1990)
- Excluding D’s source code evidence was not abuse of discretion; D didn’t produce its source code during discovery despite P requests.
- Reverse district court’s finding of lack of enablement; inclusion of program code in specification not required for enablement when disclosure sufficient to allow one skilled in the art to write program code: “The great weight of the expert testimony on both sides was that a programmer of reasonable skill could write a satisfactory program with ordinary effort. This requires the conclusion that the programs here involved were, to a skilled programmer, routine. The district court’s finding that undue experimentation was necessary to write the program is clear error.” [It is merely routine for a PHOSITA to implement an inventive/novel method/apparatus — once the PHOSITA is told how in sufficient detail. What detail is sufficient? How much disclosure of details does ordinary programmer require?; see Microsoft antitrust protocol disclosures xxx.]
- Contrast White Consol. v. Vega Servo-Control, 713 F.2d 788, (CAFC, 1983), where the production of the program required one and one half to two person-years of work.
- [Case also cited for rejection of prior art which shows all components, but without overall structure? (T/S/M)]
- Cited by Rader concurrence in Moba v. Diamond Automation (CAFC, 2003) as contrast to Lilly written-description requirement for biotechnology (“nucleotide-by-nucleotide recitation”).
- [tk]
- Fonar v. General Electric, 107 F.3d 1543 (CAFC, 1987)
- Source code not required for best mode (yawn): “… what is within the skill of the art need not be disclosed to satisfy the best mode requirement as long as that mode is described. Stating the functions of the best mode software satisfies that description test. Thus, flow charts or source code listings are not a requirement for adequately disclosing the functions of software.” [Presumably, “stating the functions” here does NOT refer to listing the named function appearing in source code e.g., CarryOutStepsABCAndD(), but rather describing the function/role/purpose to be achieved, as in the “F” part of F/W/R analysis.]
- Q: Was there substantial evidence to support jury’s finding that €˜966 satisfied the best-mode requirement? A: Y; substantial evidence from P’s own inventors sufficient to support jury finding. [Possibly can’t extrapolate from defential “sufficient to support jury finding” standard to some other procedural posture.]
- Rationales:
- Writing code is well within PHOSITA skill, once a specification has been provided to disclose the function that the code is to serve; therefore writing code according to a specification does not require undue experimentation. [Implications for obviousness analysis?]
- That which is within the skill of the art need not be disclosed. [Note arguments around Microsoft antitrust protocol disclosure requirements?]
- Best “mode” is just that, a mode, not a specific implementation
- P’s witness testified: “It wouldn’t help someone to have that software anyway because that software only works on a Fonar machine. What’s much more important is to have a description of what the software has to do, and that is what you will find in the patent.”
- Court agrees with P’s witness that providing functions of software more important than providing source code; each machine has its own set of requirements, so a general description of functionality is more useful than any given source-code implementation. [But what about sample “working implementations,” e.g. the Rotor implementation for Microsoft Shared Source CLI? There are general issues, not related to any particular machine or implementation platform, which won’t be worked out until an implementation is created for some/any particular machine.]
- According to P’s witness, P’s source code wasn’t the only means to implement the invention, and “it was not necessarily the best way to do it for every machine”.
- Software at issue here: P’s €˜966 re: MRI via single scan instead of multiple scans; P didn’t disclose source code for LGRAD and GETMAO programs, which (according to D) P’s inventors said were best mode
- [tk]
- White Consol. v. Vega Servo-Control, 713 F.2d 788, (CAFC, 1983)
- Does enablement of software-related invention require disclosure of program code?
- Here, yes: PHOSITA would have needed 1.5 to 2 years to write code from specification
- Contrast Northern Telecom v. Datapoint (CAFC, 1990)
- [tk]