Searching over 5,500,000 cases.

Buy This Entire Record For $7.95

Official citation and/or docket number and footnotes (if any) for this case available with purchase.

Learn more about what you receive with purchase of this case.

Ameranth, Inc v. Pizza Hut


February 20, 2013


The opinion of the court was delivered by: Hon. Nita L. Stormes U.S. Magistrate Judge United States District Court



In this consolidated case plaintiff Ameranth, Inc. alleges a patent infringement action against 30 remaining Defendants in the hospitality, entertainment, ticketing, travel, restaurant and food service industries. The technology at issue concerns an integrated system for coordinating orders, reservations, tickets and other services that is used across several industries.

The parties filed a joint motion to resolve a discovery dispute regarding the anticipated production of source code that will be required under Patent Local Rule (PLR) 3.4(a). In sum, Ameranth asks this court to order each Defendant to produce the entire source code tree for each accused product. Defendants argue that they need only produce the portions of source code that show the operation of the system aspects identified in Ameranth's PLR 3.1(c) charts. For the following reasons, the court DENIES Ameranth's request to compel production of the entire source code tree and GRANTS Defendants' request to produce select portions of the source codes.


On November 14, 2012, the court held an initial Case Management Conference (CMC). The court discussed with counsel, among other things, various issues regarding production of source code. The court requested "further briefing on the issue of whether the entire source code tree as it has been maintained under a revision control system needs to be produced." The court ordered Plaintiff to "address why it needs the complete source code tree from each defendant" and to support that argument with a declaration from its technical expert. The court also asked Defendants to "address how they propose to provide a complete production of source code as it is kept in the ordinary course of business without producing the entire source code tree for the alleged infringing programs." The court also asked for supporting declarations from in-house technical experts from a sampling of the Defendants. [Dkt. No. 306 ¶ 4.]

After meeting and conferring on the issue, the parties submitted this joint motion to determine their dispute. The parties argue over what, exactly, PLR 3.4(a) requires with regard to the scope of production of source code. Second, if PLR 3.4(a) requires production of the entire source code tree, Defendants argue that it would be an undue burden for them to comply with such a requirement.


A. Legal Standard.

The Federal Rules regarding discovery promote "the goal of informing parties in civil cases of all material facts prior to trial." In re Google Litigation,2011 WL 286173, *4; 2011 U.S. Dist. LEXIS 9924, *17 (N.D. Cal. Jan. 27, 2011) (citing Herbert v Lando, 441 U.S. 153, 177 (1979)). This broad approach is also reflected in patent cases, where under the patent local rules parties must make substantial disclosures regarding the Accused Instrumentalities. Id.,2011 WL at *4; 2011 U.S. Dist. LEXIS at *17. Under amended PLR 3.4,*fn1 a party opposing a claim of patent infringement must produce or make available these documents, to accompany its invalidity contentions:

a. Source code, specifications, schematics, flow charts, artwork, formulas, or other documentation sufficient to show the operation of any aspects or elements of any Accused Instrumentality identified by the patent claimant in its Patent L.R. 3.1.c chart[.]*fn2

Even where there are specific discovery rules regarding patent cases, the discovery in such "cases is always subject to 'ultimate and necessary boundaries' imposed by the trial court." In re Google Litigation,2011 WL at *4; 2011 U.S. Dist. LEXIS at *17 (citations omitted). Here, Ameranth and Defendants argue over the meaning of the PLR 3.4(a) language "sufficient to show the operation of any aspects or elements of any Accused Instrumentality."

In the federal discovery rules, all relevant information is discoverable if it "appears reasonably calculated to lead to the discovery of admissible evidence." Fed. R. Civ. Proc. 26(b)(1). But this liberal approach to discovery may be limited. Id. To help determine the scope of discovery required by PLR 3.4(a), this court will consider whether "the burden or expense of the proposed discovery outweighs its likely benefit, taking into account the needs of the case, the amount in controversy, the parties' resources, the importance of the issues at stake in the litigation, and the importance of the proposed discovery in resolving the issues." Fed. R. Civ. Proc. 26(b)(2)(C)(iii); see Kelora Sys., LLC v. Target , 2011 U.S. Dist. LEXIS 96724, *6 (N.D. Cal. Aug. 29, 2011).

B. Scope of Discovery.

1. Benefit to Ameranth of Producing Entire Source Code Tree.

Ameranth argues that PLR 3.4(a) requires each Defendant to produce the entire source code tree for each Accused Instrumentality, which shall include a complete list of all software tools used to create and maintain the source code and copies of any such software tools that are not publicly available for use or purchase. Jt. Mtn., p.2. Producing the entire source code tree will allow Ameranth to examine "all 'aspects or elements' of the Accused Instrumentality." Jt. Mtn., p.3. Ameranth asserts that its ability to examine the software operation as a whole is crucial to fully assess the infringing nature of any Accused Instrumentality. Id.; see Lydia Pallas Loren & Andy Johnson-Laird, Computer Software-Related Litigation: Discovery and the Overly-Protective Order, 2012 Fed. Cts. L. Rev. Vol. 6, § III(B)(1) (Sept. 2012) (the "Loren & Johnson-Laird Article"). Producing the entire source code tree,*fn3 Ameranth argues, would eliminate the time and expense spent in figuring out whether the production is complete or not. Jt. Mtn., p.4. The unnecessary time and expense can be eliminated if the Defendants each recreate "an executable version of the software produced and [provide] the means for the reviewing consultant(s) to replicate the process." Effertz Decl. ¶ 4(d). Without a complete production, Ameranth says it will have "to try and piece together a complete picture of each Accused Instrumentality while having only a few pieces of each defendant's 'jigsaw puzzle.'" Jt Mtn., p.1.

Ameranth argues that several cases support its interpretation that PLR 3.4(a) requires the production of an entire source code tree. For example, it cites to Weiland Sliding Doors & Windows v. Panda Windows & Doors, LLC, where the court stated: "In practice, [3.4(a)] requires the alleged infringer to turn over any and all documents describing the operation of structures of the accused infringer's accused devices." 2011 WL 318046, *2; 2011 U.S. Dist. LEXIS 8985, *4 (S.D. Cal. Jan. 31, 2011) (Sammartino, J.). That order examined the sufficiency requirement under PLR 3.4(a) with regard to the disclosure of prior art references, and denied the plaintiff's motion to strike the defendant's preliminary invalidity contentions. Because it did not address whether an entire source code tree should be produced, the court does not find it instructive on this issue.

Next, Ameranth cites to I-Flow Corp. v. Apex Medical Techs., where this court granted the plaintiff's motion to compel the defendant to produce additional materials under PLR 3.4(a). This court stated: "Rule 3.4(a) requires the alleged infringer to produce 'any and all documents describing the operation or structures of [the] accused devices . . .'" (citation omitted). 250 F.R.D. 508, 510, 511 (S.D. Cal. 2008) (Stormes, J.). What the court was deciding in that order, however, was a motion to compel a further production because the defendant had produced only 13 pages of documents, consisting of a sales brochure and a drawing, to support its invalidity contentions. The order did not address whether an entire source code tree should be produced, and thus does not support Ameranth's position here.

Further, the I-Flow order actually supports the Defendants' position here, as it points out that "'the responding party [need only] provide the raw data (source code, schematics, formulas, etc.) sufficient to show the operation of the accused aspects of the products in order to allow the patentee to make its own determinations as to infringement.'" Id. (citing NessCap Co. v. Maxwell Techs., Inc., 2008 U.S. Dist. LEXIS 3357, *10 (S.D. Cal. 2008) (Major, J.)) (emphasis added). This statement contradicts Ameranth's assertion that it need is entitled to examine "all 'aspects or elements' of the Accused Instrumentality." Jt. Mtn., p.3 (emphasis added).

Ameranth also relies on IXYS Corp. v. Advanced Power Tech., Inc., where in granting a motion to preclude certain untimely produced documents, the court reiterated that its Patent Local Rule "requires [defendant] to turn over to [plaintiff] any and all documents describing the operation or structures of [defendant's] accused devices." 2004 WL 1368860, *3; 2004 U.S. Dist. LEXIS 10934, *9 (N.D. Cal. June 16, 2004).*fn4 The only question that court answered regarding PLR 3.4(a) was whether that rule applied to the disclosure of devices that had not been accused. Id. The court found that it did

Id. 2004 WL at *3; 2004 U.S. Dist. LEXIS at *9-*10. Similar to the other cases cited above, this case did not address whether an entire source code tree should be produced, and thus lends no support to Ameranth's position.

Ameranth relies on one case that considered the issue of whether a complete copy of a defendant's source code need be produced. In In re Google Litigation, the court considered, among several other issues, the plaintiff's motion to compel defendant Google to produce the entirety of its source code and other technical documents for each accused Google analysis. Google argued that the plaintiff's "demands for the entire code base for its search engine call[ed] for many millions of lines of code written by hundreds of engineers over the last 14 years and include[ed] competitively sensitive trade secrets relating to areas not relevant to this case." 2011 WL 286173, *4; 2011 U.S. Dist. LEXIS 9924, *17 (N.D. Cal. Jan. 27, 2011). The court found that the source code demanded was "material to [the plaintiff's] contention that these analyses practice one or more limitation of [the plaintiff's] asserted patent claims." Id., 2011 WL at *5; 2011 U.S. Dist. LEXIS at *21.

In the face of that materiality determination, and the court's noting of a lack of any declaration, deposition testimony or any other evidence "providing a concrete or particularized assessment of the risk or burden of such a production[,]" the court understood the potential harm in compelling Google to produce the entirety of its proprietary source code. Id. The court found an "appropriate balance between [the parties'] competing concerns" and granted the motion to compel only in part. It ordered Google to produce all source code for each accused "link analysis," "input to any link analysis" and "any components of any further analysis . . . that use the results of any link analysis." Id. Regarding other (non-alleged) components, it found that Google did not need to produce source code at that time but should produce documents describing the operation of these other components. Id.

While Ameranth notes that the Google court "granted plaintiff's motion to compel production of the entirety of Google's source code and other documents," this court does not read the order to say that. First, at the hearing the plaintiff limited its request to only source code relating to the accused analyses. In re Google Litigation, 2011 WL at *4; 2011 U.S. Dist. LEXIS at *15. Then, even though finding all the requested source code to be "material," the court ordered production of only the source code for the alleged components, accompanied by a document production for the non-alleged components. Id., 2011 WL at *5; 2011 U.S. Dist. LEXIS at *21. Accordingly, this court finds that In re Google Litigation lends more support to Defendants' position than that of Ameranth.

2. Burden on Defendants to Produce Entire Source Code Tree.

Defendants argue Ameranth seeks source code that is beyond what the Patent Local Rules deem relevant and necessary to produce. They point out that Ameranth's view is not in line with cases coming from the Northern District of California, which has a Patent Local Rule with requirements identical to PLR 3.4(a) at issue here. Defendants rely heavily on technical expert declarations, which explain that analyzing source code that has no relevance to the accused aspects or functionality of the Accused Instrumentalities will waste time and money and will unnecessarily delay the case. Larson Decl. ¶¶ 25, 28. These declarations explain the enormous burden the Defendants would bear if ordered to produce the entire source code trees for all aspects of all Accused Instrumentalities.

To help interpret PLR 3.4(a), Defendants rely on Nazomi Comm's, Inc. v. Samsung Telecomms., , where the plaintiff requested source code in a request for production of documents regarding products listed in the plaintiff's infringement contentions as well as for other products. 2012 WL 1980807, *1; 2012 U.S. Dist. LEXIS 76468, *7 (N.D. Cal. 2007). The plaintiff requested a "complete copy of the source code compiled onto each [defendant] device" so as to help plaintiff "fully understand the operation of [defendant's] products and to determine whether relevant source code is in the exclusive possession of one or more third parties." Id., 2012 WL at *3; 2012 U.S. Dist. LEXIS at *11. The court found that the plaintiff did not demonstrate the necessity of "'fully understand[ing] the operation of [defendant's] products' as opposed to understanding the portion that is covered by its infringement claims." Id. In light of the sensitive nature of source code, the court did not order production of the entire source code tree and ordered a limited production based on an agreement by the parties. Id., 2012 WL at *4; 2012 U.S. Dist. LEXIS at *11.

The court finds Nazomi relevant to this issue, as Ameranth has made a similar demand regarding the scope of source code production. In light of the following discussion regarding the burden on Defendants, Defendants' technical experts' explanation of the sufficiency of their proposed productions, and Ameranth's failure to object to the scope of the source code productions by the Original Defendants,*fn5 this court finds that Ameranth has not shown that it needs to fully understand all the operations of Defendants' products as opposed to understanding only those aspects accused in the infringement claims.

Defendants argue it would be a tremendous burden for them to produce a complete, functional build environment for the source code of the Accused Instrumentalities. The Northern District of California addressed precisely this issue when it reviewed a joint discovery statement that detailed disputes over certain provisions in the parties' proposed protective order regarding source code inspection. Kelora Sys., LLC v. Target Corp.,2011 WL 6000759, *3; 2011 U.S. Dist. LEXIS 96724, *8-*10 (N.D. Cal. Aug. 29, 2011). In negotiating the terms of a protective order, the plaintiff wanted to include a term requiring defendants to provide "'a complete, functional build environment for the source code of its accused instrumentalities, including build instructions, scripts and/or other information used in the ordinary course of business to develop, build, test and debug the source code.'" Id. Plaintiff argued that such a production was within the broad scope of Rule 26(b)(1) discovery, and would help counsel and experts to evaluate the Accused Instrumentalities. Id. Defendants countered that such a proposal "would effectively require each Accused Infringer to provide source code for the entire accused website even though the vast majority of the source code for each accused website is completely unrelated to the accused functionality." Id. The court balanced the benefit to the plaintiff and the burden on the defendant and found that the benefit did not outweigh the burden on defendant to make such a production. Id.

Ameranth distinguishes Kelora because it says that what the plaintiff sought in that case was far more burdensome than what it requests in this case, which is production of each defendant's source code tree as described in the Loren & Johnson-Laird Article. In the article the authors state, "Given the huge size of modern programs, the most technically viable way of determining completeness is to compile the source code into a working program. This task demands all of the source code and all of the ancillary control files, as well as all of the third party components (be they source or object code) that are necessary for the program to function." § II.B.1. Ameranth also argues that Defendants greatly overexaggerate what would be required by producing the entire source code tree, because Defendants include in their time and cost estimates the production of all of their hardware, in addition to the software. Jt. Mtn., p.2.

Defendants' technical expert, however, explains that the Loren & Johnson-Laird Article focuses "on a scenario in which a single software program runs on a single machine that uses a single operating system." Larson Decl. ¶ 10. The e-commerce systems at issue here are complex and involve different types of source code, computer languages, hardware systems, operating systems, third party interfaces, applications and data under third parties' control. Id. They involve applications running on iPhones and Android mobile phones, client devices and web servers that communicate through the Internet to web servers, which in turn communicate to one or more application, database and third party servers. Larson Decl. ¶ 14. The e-commerce systems identified in the complaints combine proprietary software and data, and third party software and data that can be accessed over the Internet or secure networks. Larson Decl. ¶ 18. To construct an "entire source code tree"--as Loren & Johnson-Laird propose--would be a monumental task requiring the collection of each system's functionality (comprised of several million lines of code broken into thousands of different functional modules), procurement of executable copies of third-party software (which requires purchasing licenses), acquiring of the relevant hardware on which the software and database components can operate, getting access to third-party systems that supply functionality, content or data to the e-commerce system (e.g. a third party airline ticket inventory system or a shipping system), and setting up a working version of the accused system, all without help from employees of the producing party, who know how the system is constructed. Larson Decl. ¶¶ 20-

In well-designed systems, Defendants' expert explains that "particular functionality is embodied within a relatively small number of modules," and those modules can be verified in isolation. Larson Decl. ¶ 26. More efficient than producing an entire source code tree, Defendants' expert advocates to have Defendants' technical employees--who are intimately familiar with their own source code--"identify and provide the portions of source code that specifically relate to the aspects or functionality identified by the plaintiff in its infringement contentions." Larson Decl. ¶ 27. In this particular case, Defendants' expert opines that the potential for waste is particularly apparent . . . where there are over 30 different defendants. It would border on impossible for the plaintiff in this case to have 2-3 experts to meaningfully review an 'entire source code tree' for each of the 30 defendandants and independently determine, in a reasonably short amount of time, which portions of that code specifically relate to the accused aspects or functionality.

Larson Decl. ¶ 28.

To further quantify the burden, Defendants submit declarations from the technical officers for a sampling of Defendants. For example, the Technical Manager for Orbitz explains that for its source code, there are 937 separate repositories of source code, each of which contains multiple files, and each file has multiple versions. Korabelnikov Decl. ¶ 5. Orbitz changed its source code system in 2012, so for files dating back to more than one year, it would have to produce a second set of source code. Id. ¶

6. Many of the repositories contain source code used to accomplish adminstrative, configuration or testing tasks, and it would take weeks or months to filter out that code. Id. ¶ 7. He believes that much of the source code would be irrelevant to Ameranth, such as the algorithms used to rank product options or create combinations of air, car and hotel products. Id. ¶ 8. If Orbitz took that time and expense to collect all its source code, then it would have to use third party code and software--for which Orbitz has obtained rights and licenses that is has no authority to copy or distribute--to implement certain functionalities for the website. Id. ¶ 9(a). It would take a team of Orbitz engineers approximately 3-5 months to get a "full test environment" website up and running. Id. ¶ 9(c). Further, it would take approximately 100 servers to provide enough memory space, network ports and computational throughput to provide a full test environment. Id. ¶ 9(f). Tellingly, developers for Orbitz "do not use a separate 'full test environment' to test the source code." Id. ¶ 9(d). Rather, the "developers typically execute an actual transaction that utilizes the same communication with third party systems that a normal transaction utilizes." Id.

The Principal Operations Architect for StubHub, Inc. describes a similar burden if ordered to produce an entire source code tree. Some aspects of buying a ticket through StubHub are provided by software based on StubHub's source code, while other aspects rely on software for which the source code is owned by third parties. Reynolds Decl. ¶ 4. StubHub provides a "pool diagram" that shows the many components of its websites and a legend for how to read the pool diagram. Id. ¶ 5(a). Multiple source code trees provide the functionality for the StubWeb web experience. Id. ¶ 5(d). When running its own quality assurance, StubHub takes at least 40 hours to configure a workstation, for which StubHub must acquire hardware and third party licenses. Id. ¶ 5(f). Such a workstation does not include all of the source code required to run StubHub and does not include any databases. Id.

StubHub's Principal Operations Architect goes on to explain the substantial number of hours, equipment, time and effort to produce a full test environment. Id. ¶ 5(h)-(k). Further, it could not acquire some of the third party support provided for some of its functionalities, such as systems by PayPal for payment processing and FedEx for physical delivery of tickets, and the result would not be fully-functioning and compilable versions of the software for the StubHub websites. Id. ¶ 6(a), 7.

The Chief Technical Officer for Micros Systems explains the effort that would be required to produce source code for eight of its products, which provide information management for hotels, resorts, restaurants, food service and other service industries. First, each implementation of a Micros solution for a customer is custom designed, and configuration takes two to eight weeks. Russo Decl. ¶ 6. There are three versions of the management systems with numerous products for each, and thus over 20 millions lines of source code. Id. ¶¶ 9-10. The code is written in 18 unique code languages. Id. ¶ 11. Micros estimates it would take 79 weeks to create a full test environment for Ameranth and approximately $250,000. Id. ¶ 13. Micros is also dependent on third party hardware and software for its products. Id. ¶ 23. Micros itself does not maintain a single test environment that allows testing for all eight of its products. Id. ¶ 17.

In assessing the burden, the technical officers for the sampled defendants propose an alternative. Orbitz explains that in previous patent infringement cases where it was a defendant, it was required to only produce the specific source code related to the functionality identified in the infringement contentions. Korabelnikov Decl. ¶ 10. StubHub proposes that it produce a non-compilable copy of the StubHub-owned source code pertaining to the specific functionalities that Ameranth identified in infringement contentions. Reynolds Decl. ¶ 8. Micros believes a reasonable production would require that it collect the specific code related to the functionality Ameranth identifies in its infringement contentions. Russo Decl. ¶ 26. This form of production appears to be the way that the Original Defendants in this case produced their source code. While Ameranth complains now that some of the production was not in native format, some source code was missing comments and notations as well as missing all relevant versions, Ameranth never raised the issue of an incomplete production or an inability to review a functionality for an Accused Instrumentality to the court. See Effertz Decl. ¶ 3.

3. Proper Scope of Source Code Production.

Considering the limited source code productions ordered in In re Google Litigation and Nazomi Comm's, Inc. v. Samsung Telecomms., Inc., the burden quantified by Defendants' technical experts, Ameranth's failure to contest the scope of the source code production by the Original Defendants, and the lack of an apparent benefit if Ameranth procures the entirety of the source code trees for 30 Defendants as opposed to obtaining only the source code for the accused functionalities, the court adopts the Defendants' position regarding what is required for the production of source code. To the extent that Ameranth's PLR 3.1(c) charts identify any particular aspects or elements of a Defendant's system that relate to source code, the court ORDERS that the Defendant is only required to produce the source code that is "sufficient to show the operation of" those system aspects identified in Ameranth's PLR 3.1(c) charts.

C. Format of Source Code to be Produced.

Parties must "produce documents as they are kept in the usual course of business or must organize and label them to correspond to the categories in the request." Fed. R. Civ. Proc. 34(b)(2)(E)(I); see Geotag, Inc. v. Aromatique, Inc., 10cv570-MHS, Dkt. No. 582 (E.D. Tex. Jan. 8, 2013) (finding production in native format was sufficient as opposed to production in compilable form). Ameranth asks that the source code be produced in native format. It complains that in the earlier source code production of this case, Defendants did not produce source code in native format. Effertz Decl. ¶

3. In their proposed order, Defendants agree--and this court ORDERS--that any source code produced must include original file names and be in native format.


Buy This Entire Record For $7.95

Official citation and/or docket number and footnotes (if any) for this case available with purchase.

Learn more about what you receive with purchase of this case.