WILLIAM H. PAULEY III

Charles A. Stillman, Esq., Stillman & Friedman, P.C., New York, NY, for Plaintiffs. Michael H. Gruenglas, Esq., Skadden, Arps, Slate, Meagher & Flom LLP, New York, NY, for Defendant.

OPINION

WILLIAM H. PAULEY III, District Judge:

Dan Harkabi (“Harkabi”) and Gidon Elazar (“Elazar,” together, “Plaintiffs”) assert a breach of contract claim against SanDisk Corporation (“SanDisk”) relating to its sale of flash memory drives incorporating Plaintiffs' technology. In 2004, SanDisk acquired Plaintiffs' start-up company MDRM and promised to pay them a $4 million earn-out if MDRM technology drove sales of SanDisk products. Plaintiffs assert that after SanDisk acknowledged its obligation to pay the earn-out, it reneged and terminated them. While the dispute is relatively straightforward, the litigation has been protracted and hard-fought. SanDisk warned Plaintiffs that pursuing their claim would be very expensive. Regrettably, SanDisk's unyielding tactics ensured its prophecy became reality. After a week-long bench trial, this Court concludes that Harkabi and Elazar are entitled to the full $4 million earn-out plus prejudgment interest. This Court makes the following findings of fact and conclusions of law pursuant to Federal Rule of Civil Procedure 52.

FINDINGS OF FACT

I. The Spoliation of Plaintiffs' Laptops

As an initial matter, in addition to the extensive proof at trial, SanDisk's spoliation of evidence buttresses certain findings of fact and the resulting conclusions of law. By Memorandum & Order dated August 23, 2010 (the “Spoliation Order”), this Court sanctioned SanDisk for its spoliation of Plaintiffs' laptop computers, awarded Plaintiffs attorneys' fees, and authorized an adverse inference against SanDisk at trial. See Harkabi v. SanDisk Corp., 275 F.R.D. 414, 420–21 (S.D.N.Y.2010). As this Court noted, the missing data “includ[ed] meeting notes, calendar entries, and digital photographs of technical schematics drawn by Elazar on white boards ... showing [Plaintiffs'] involvement in developing the U3.” Harkabi, 275 F.R.D. at 417. Accordingly, and as detailed below, SanDisk's destruction of Plaintiffs' laptops containing highly relevant evidence supports the following findings of fact that cite to the “Spoliation Order.”

II. The Parties

Harkabi and Elazar are Israeli citizens with extensive experience in the electronics industry. (Trial Transcript (“Tr.”) 4:2–3; Tr. 5:3–7, 5:12–20, 5:21–24, 6:7–14; Tr. 228:24–25.) In 2002, they established a company named MDRM, an acronym for “Mobile Digital Rights Management.” (Tr. 11:6–22; Tr. 233:18–234:5.) At MDRM, Elazar was in charge of product development and Harkabi handled business matters. (Tr. 12:3–4; Tr. 234:6–11.)

SanDisk is a Delaware corporation with its principal place of business in California. (Complaint, dated Sept. 23, 2008 (“Compl.”) ¶ 4; Answer, dated Nov. 14, 2008 (“Ans.”) ¶ 4.) During the relevant period, SanDisk was the world's largest manufacturer of computer flash memory storage products. (Tr. 17:16–21; Plaintiff's Trial Exhibit (“PX”) 105–2.)

III. MDRM Technology

Plaintiffs created MDRM to develop products using USB flash drive technology. (Tr. 11:10–14.) Flash memory is a semiconductor chip that retains storage in the absence of power. (Tr. 7:16–18.) For example, a digital camera typically stores photographs on a semiconductor chip with flash memory when the camera is turned off. (Tr. 7:19–23.) A USB flash drive is a consumer electronics device that enables the user to copy and store files on the drive after connecting it to a computer and thereafter transfer the files to another computer. (Tr. 8:25–9:3.)

The first flash drive MDRM created was known as “BookLocker.” (Tr. 12:13–18.) BookLocker was a system that enabled schools to acquire educational materials, such as electronic books, and assign a specific book to a specific student based on a BookLocker device in the student's possession. (Tr. 12:19–23.) BookLocker enabled the download of electronic content from a remote server in a secure transaction. (Tr. 13:5–15.) To provide this unique function, the server needed to recognize the specific BookLocker device and differentiate that device from every other BookLocker device. (Tr. 14:3–13.) The differentiating characteristic of each BookLocker device was its device identification, or “DID,” which is a unique code programmed into each flash drive. (Tr. 14:17–18; Tr. 341:16–17; Tr. 457:15–17; Tr. 847:3–4.)

MDRM's BookLocker and DID system involved: (i) a dedicated DID server to generate DIDs; (ii) an MDRM server that distributed the DIDs over the network inside the manufacturing plant to production servers; (iii) a “golden unit” (also referred to as a “golden key”) that decrypted the DIDs; (iv) the download of a DID into the BookLocker device under production using a specialized testing machine, or “Tanisys” machine; and (v) code on the BookLocker device itself which accepted and verified the integrity of the DID. (Tr. 15:2–16:18; Tr. 713:25–733:4.) While at MDRM, Elazar filed two United States Patent Applications disclosing MDRM's BookLocker technology. (PX 463, PX 464.)

IV. SanDisk Acquires MDRM

In the summer of 2002, Plaintiffs first met with Eli Harari (“Harari”), SanDisk's Chief Executive Officer, and Yoram Cedar (“Cedar”), SanDisk's head of engineering. (Tr. 17:10–15.) During this meeting, Harari informed Plaintiffs that a new SanDisk “controller” would be compatible with MDRM's technology and suggested a collaboration between the two companies. (Tr. 18:11–23.) In 2003, Plaintiffs worked with SanDisk personnel to develop a SanDisk product that incorporated BookLocker technology. (Tr. 18:24–20:8; Tr. 235:3–15.) Elazar explained the BookLocker technology to SanDisk firmware engineers and detailed what MDRM would need from SanDisk to manufacture a product. (Tr. 19:6–15.) As a result of the collaboration, Plaintiffs were able to create prototypes of secure SanDisk flash memory cards with BookLocker technology. (Tr. 20:12–15.)

Beginning in or around January 2004, SanDisk collaborated with Plaintiffs' former employer—M-Systems—in connection with the research and development and marketing of a next-generation USB flash drive. (PX 27–2; Tr. 751:5–9; Tr. 810:10–21, 815:15–816:3.) This new flash drive became known as the U3 device. (PX 27–2, 27–5 at § 1.29, 27–6 at § 1.38; Tr. 751:10–752:5; Tr. 27:12–24; Tr. 242:5–8; Tr. 339:10–340:12; Tr. 816:4–8.) SanDisk and M–Systems created the specification for the U3 (the “U3 Specification”), which included the requirement that the U3 have the ability to create a secure session and safely upload or download content from a remote server. (PX 102–1, 102–54 at § 4.5; Tr. 344:16–345:1.) The U3 Specification did not provide details regarding how to manufacture a U3 device. (Tr. 346:4–6; Tr. 753:7–15.)

In April 2004, SanDisk approached Plaintiffs about buying MDRM. (Tr. 21:5–9; Tr. 235:16–18.) After receiving and rejecting a number of offers from Harari, (Tr. 21:7–25; Tr. 238:1–3; PX 13), Harkabi met with SanDisk Board member Cathy Lego, who made a final offer to acquire MDRM. (Tr. 238:4–23.) The terms of the final offer included an earn-out cash payment based on the number of devices sold over a two-year period that used MDRM's technology, with a maximum payment of $4 million for the qualified sale of 3.2 million devices. (Tr. 22:1–15; Tr. 238:18–239:20.) Plaintiffs accepted SanDisk's final offer in May 2004, in part because Harari told them that SanDisk intended to use MDRM's technology in all of SanDisk's products. (Tr. 21:20–22:22; Tr. 239:8–240:13.)

In July 2004, SanDisk executives prepared a presentation to SanDisk's Board of Directors to obtain approval for the acquisition of MDRM. (PX 24; Tr. 809:14–24.) The presentation included a description of the “Deal Thesis.” (PX 24–7.) The “Deal Thesis” set forth SanDisk's reasons for acquiring MDRM: (i) digital rights management was a key enabling function for the growth in commercial content stored on flash memory cards; (ii) MDRM's technology could implement digital rights management; and (iii) SanDisk wanted to use MDRM technology for SanDisk memory cards to differentiate SanDisk's products and enable the development of unique applications for medical, education, enterprise, and government users. (PX 24–7; Tr. 811:9–814:5.) The board presentation included an explanation that MDRM would aid SanDisk's U3 project with M–Systems. (PX 24–8; Tr. 814:6–16.) Thus, SanDisk executives, including Harari, knew that SanDisk was acquiring MDRM to incorporate its technology into SanDisk products, including the U3. (Tr. 814:21–23; PX 15–1; Tr. 785:4–787:5; PX 29–3.)

In connection with the acquisition, MDRM became an operating group within SanDisk named Secure Content Solutions (“SCS”). (Tr. 23:24–24:2; Tr. 241:1–3.) Harkabi became vice president of SCS, and Elazar became senior director of product management and architecture. (Tr. 24:3–5; Tr. 241:9–11.) Elazar was responsible for helping SanDisk integrate MDRM technology, developing the BookLocker product, and managing the development team. (Tr. 24:6–9.) Harkabi was in charge of SCS, promoted products, recruited personnel, and managed the budget. (Tr. 241:12–16; Tr. 339:4–5.) Both Harkabi and Elazar relocated with their families from Israel to California. (Tr. 24:12–19; Tr. 241:21–22.)

V. The Pertinent Terms of the Merger Agreement and Earn Out Provision

SanDisk and MDRM entered into an Amended and Restated Stock Purchase Agreement on September 13, 2004 (the “Agreement”). (PX 34.) The pertinent terms and provisions of the Agreement are the following:

(a.) Contribution Consideration. At the Closing, Buyer [SanDisk] shall pay to the Sellers [Plaintiffs] (through the Escrow Agent) U.S. $4,000,000 (the “ Contribution Consideration ”), which amount shall be forwarded to the Sellers in accordance with and subject to the Contribution Consideration Earn–Out provisions set forth below in Section 1.4. (PX 34–4, § 1.1(b)(ii).)

(b.) Contribution Consideration Earn–Out. Forty five days following each fiscal quarter from the Closing Date and through the fiscal quarter during which the second anniversary of the Closing Date (the “ Two Year Date ”) takes place, the Buyer shall provide the Escrow Agent and Seller's Representative with notice of the number of units (whether in the form of Secure Digital cards, USB Drives or other formats) using or embedding the firmware developed by the Company Group [MDRM] before the Closing Date (the “ MDRM Technology ”) and/or Derivatives thereof (as defined below) developed by any member of the Buyer Group [SanDisk] after the Closing Date (“ MDRM Units ”) Sold (as defined below) during the fiscal quarter then ended. (PX 34–5, § 1.4.)

(c.) [Contribution Consideration Earn–Out.] Buyer shall, and shall cause each of the corporations, partnerships, limited liability companies and other entities as to which a majority of the outstanding voting interests are owned, beneficially or of record, directly or indirectly (each, a “ Subsidiary ”) by the Buyer (together, the “ Buyer Group ”) to give Seller's Representative and its authorized representatives (including its attorneys and accountants) reasonable access to all books and records thereof as Seller's Representative may reasonably require, in order to establish the number of MDRM Units Sold as specified in the aforesaid notices of Buyer. (PX 34–5, § 1.4.)

(d.) [Contribution Consideration Earn–Out.] The Escrow Agent will then release to each of the Sellers, in the ratios set forth in Section 1.1(b) of the Disclosure Schedule, an amount equal to: (A) the total Contribution Consideration multiplied by (B) a fraction, the numerator of which is the number of MDRM Units Sold during such preceding calendar quarter and the denominator of which is 3.2 million (the “ Proportionate Contribution Consideration ”). (PX 34–5, § 1.4.)

(e.) [Contribution Consideration Earn–Out.] “ Sales ” and “ Sold ” means the sale, lease or license of products of Buyer which (x) are marketed by a member of Buyer Group by reference to the MDRM Technology or Derivatives thereof or to their functions and/or capabilities, (y) are used by a member of the Buyer Group to provide content stored on such unit, or update firmware, upload or download data, or any other use which is enabled by the MDRM Technology to [ sic ] Derivatives thereof, or (z) have been pre-activated by a customer, distributor, reseller or any other channel for ultimate sale to an end-user that result in revenue recognition (e.g., not channel inventory or consigned goods) on the sale of the MDRM Unit by the Buyer Group, in each case before the Two Year Date or within the nearest fiscal quarter ending after the Two Year Date. For the avoidance of doubt, a Sale shall not occur (i) merely as a result of the sale of products of Buyer which use or embed the MDRM Technology or Derivatives or a portion thereof (ii) as a result of the routine authentication and logging of contacts between a unit and a central server or (iii) merely as a result of listing the MDRM Technology on data sheets of the Buyer Group. (PX 34–5 to 34–6, § 1.4.)

(f) [Contribution Consideration Earn–Out.] “ Derivatives ” means: (a) any computer program (whether in source or object code form.) port, work, product, service, improvement, modification, revision, alteration, enhancement, abridgement, condensation, expansion, new version, translation, adaptation, design, concept, in any medium, format or form whatsoever, that is derived in any manner, directly or indirectly, from the MDRM Technology or any part or aspect thereof or that utilizes or incorporates such a preexisting work or any part or aspect thereof, or any other form in which the MDRM Technology may be recast, transformed or adapted; (b) all “derivative works” as defined in the copyright law of the United States, the MDRM Technology and (c) all materials and documentation related to each of the foregoing. (PX 34–6, § 1.4.)

(g.) Governing Law. This Agreement and transactions contemplated hereby shall be governed and construed under and in accordance with the laws of the State of New York (without giving effect to any choice of law rule thereof which would cause the application of the laws of another jurisdiction). (PX 34–39, § 10.6.)

VI. Elazar and Harkabi Integrate MDRM Technology into SanDisk's U3 Devices

Prior to 2005, SanDisk did not have a product that had the capability to authenticate itself to a server over the internet. (Tr. 344:8–15; Tr. 951:12–14.) This functionality was a design requirement for the U3 device. (Tr. 343:19–344:7; PX 102–54.) In early April 2005, with the U3 development project underway, SanDisk's Carlos Gonzalez (“Gonzalez”), a senior director on the U3 project, wrote to Elazar proposing a meeting “to go over the U3 infrastructure needs and establish a game plan.” (PX 280–1.) Gonzalez and Elazar then discussed a plan in which SanDisk would generate secret keys for the U3 inside the device. Gonzalez also asked whether MDRM's technology could be adapted to load certificates and serial numbers to the U3 using a DID. (Tr. 29:9–22.) SanDisk dubbed this plan for the manufacturing process “Case A.” (Tr. 29:6–22, Tr. 37:1–18; PX 65–6; Tr. 369:16–370:2.)

On May 4, 2005, Elazar described in an e-mail the steps that needed to be added to the process to load certificates using a DID into the U3 device during the Case A manufacturing. (PX 60–1 to –2; Tr. 31:10–16.) The steps described were part of MDRM's BookLocker technology. (Tr. 33:20–22.) More specifically, Elazar outlined the MDRM BookLocker DID technology that would need to be implemented for the U3. He also provided the instruction for storing the DID and verifying its validity. (PX 60–1, 60–2; Tr. 32:24–33:19.) Elazar sent his e-mail to Sean Chang, head of SanDisk's firmware team for the U3, and several other members of the U3 team. (PX 60–1; Tr. 30:18–31:6; Tr. 779:13–780:10; Tr. 347:23–25; Tr. 358:23–359:4.) In response to Gonzalez's question “What is DID?” Elazar responded that the DID was part of the structure of BookLocker used to store certificates in manufacturing and that it would need to be part of the U3 manufacturing process. (Tr. 34:8–25; PX 60–1.) Elazar subsequently discussed with Gonzalez and other SanDisk personnel further details of the DID and its structure. (Tr. 213:7–214:1.)

On May 9, 2005, Elazar received an e-mail from Steve Needels (“Needels”), a member of the U3 team, regarding “U3 questions for manufacturing process.” (PX 475–1.) Needels stated that SanDisk was unable to create unique serial numbers for the U3 under the current methodology for manufacturing first generation storage-only flash drives. (PX 475–1; Tr. 35:8–18.) Needels asked: “Can the server create a unique serial number and pass it along with the two certificates? ... Have you [Elazar] discussed with [Gonzalez] about using the same device ID as for book locker with the U3 info added into the empty space?” (Tr. 35:14–25; PX 475–1.) Needels then sent an e-mail to Elazar and Gonzalez to schedule an “[u]rgent meeting to resolve serial number and device ID for [the] U3.” (PX 283–1.) Elazar met with Gonzalez and Needels, and they concluded that the manufacturing process for the U3 was not finalized because the capability to create a unique serial number in the DID had not been accomplished. (Tr. 36:23–37:3; Tr. 37:1–9.)

Late in the day on May 11, Needels sent an e-mail to various SanDisk personnel, including Gonzalez and others, attaching a document entitled “U3 Manufacturing Requirements,” which set forth definitions and specifications for the U3 manufacturing process. (PX 65–1; Tr. 369:3–15; Tr. 780:11–23.) The document included the Case A plan for the manufacturing process, which was described as “preferred.” (PX 65–6.) The document also described a “Case B” plan whereby the keys and certificates were loaded from a CD–ROM. (PX 65–9.) Case B was described as a “fallback” and was “the equivalent system to the current SCS (formerly known as MDRM) Book Locker system.” (PX 65–9; Tr. 781:14–17.)

Shortly thereafter, in May or June 2005, Gonzalez informed Elazar that SanDisk would not be using the Case A plan because of a technical problem, and that he was concerned about SanDisk's ability to ship the U3 device to market as planned in August or September 2005. (Tr. 37:19–38:5.) Gonzalez asked to meet with Elazar about using MDRM's technology to get the U3 to market on time. (Tr. 38:6–13; Tr. 40:12–14.) On June 1, Needels e-mailed numerous SanDisk personnel: “We just learned that [Case A] will most likely not ... meet the schedule for builds on 6/22. Given that, we need to follow a strategy similar to the one we are using for SCS—loading keys and certificates onto the cards. Today we held a meeting to discuss how to get back on track.” (DX 118–5.) Needels attached to his e-mail an “Items Needed” list for firmware and data, which identified numerous items for Elazar to address, including “Definition of Device ID,” “Generate keys,” and “Generate golden units.” (DX 118–6.)

At the meeting with Gonzalez, Elazar made diagrams and notes on an erasable whiteboard relating to his explanations, including diagrams of how the different components worked, descriptions of the components, and changes to the U3 firmware necessary to adapt it to the MDRM technology. (Tr. 40:17–41:6.) At the conclusion of the meeting, Elazar took a picture of the whiteboard with his camera and stored the picture on his SanDisk laptop. (Tr. 41:7–12; Spoliation Order.)

Gonzalez repeated his concern to Elazar that SanDisk would miss its schedule for getting the U3 device to market on time and that SanDisk wanted MDRM's DID system for the U3. (Tr. 39:4–15; Tr. 353:10–20; Spoliation Order.) Elazar then explained in detail how MDRM technology for the BookLocker system worked, including the process for using DIDs for the secret keys. (Tr. 39:16–21; Spoliation Order.) Specifically, Elazar discussed how the DID generation servers worked to generate the DIDs; the function of the MDRM server; the CD–ROMs and the golden unit; the role of the production server to cycle the DID through the golden unit to the Tanisys machines; and the download from there onto the BookLocker device itself. (Tr. 39:21–40:3; Spoliation Order.) Elazar also discussed how the U3 device firmware needed to change in order to adopt MDRM technology. (Tr. 40:4–5; Spoliation Order.) He advised Gonzalez that space would have to be allocated for the DID, that a special command would need to be implemented to download the DID, and that a checksum would have to be implemented to verify the validity of the DID. (Tr. 40:5–9; Spoliation Order.)

Elazar spoke with Harkabi immediately after the meeting, and Harkabi agreed that SCS should make U3 its top priority. (Tr. 41:13–14; Tr. 242:16–243:9.) Harkabi promptly spoke to Cedar, who was pleased that Elazar and Harkabi would help integrate MDRM technology into the U3. (Tr. 243:10–16.) Elazar then told Gonzalez that he needed to meet with the U3 firmware team as soon as possible because the technology involved a complex system with many components, and the work was on a tight schedule. (Tr. 42:11–14.) On June 1, Gonzalez also e-mailed numerous SanDisk personnel concerning “U3 Certificate Management in Manufacturing.” (PX 268; PX 457.) Gonzalez directed SanDisk personnel: “In order to reduce risk to the program, we would like to load keys and certificates from CDs (as is currently done for SCS (formerly known as MDRM)). The keys and certificates will be distributed via CD and loaded by the servers to the devices in the form of DID packets.” (PX 268–2, PX 457–1.)

Elazar then met with SanDisk's different teams to explain what they needed to do to adapt MDRM's BookLocker system to the U3. (Tr. 47:4–11.) Elazar instructed the manufacturing team to keep the components of the process the same as in BookLocker. He further explained that they needed to place a second MDRM server in the manufacturing process to create the U3 device. (Tr. 47:12–48:10.) The manufacturing team agreed and ultimately used that methodology to produce the U3. (Tr. 48:11–13; Tr. 47:22–48:10; Tr. 371:16–372:5; Tr. 782:14–18; PX 65–9.) Elazar also met with the U3 product manager, Hutton, who was in charge of writing specifications and coordinating activities of different teams for the U3. (Tr. 48:14–19.) Elazar took notes of his meeting with Hutton, which he maintained on his SanDisk laptop. (Tr. 49:20–24.) Elazar described elements of MDRM technology and that the U3 firmware would need to be changed; that a special command would need to be implemented to receive the DID; that a checksum would need to be implemented to validate the DID; and that an instruction of the different portions of the DID on the U3 device would also need to be implemented. (Tr. 49:10–15; Spoliation Order.)

On June 7, 2005, Elazar sent a memo entitled “X509 using DUD” to Hutton and other SanDisk personnel on the U3 project regarding the certificates for the U3 manufacturing process. (PX 476–2; Tr. 50:13–51:3.) The purpose of the memo was to “[d]escribe the manufacturing process of loading certificates into a U3 device” and it stated that “[t]he cycle of producing units with X509 certificate is similar to the cycle of producing BookLocker devices with DIDs, and uses the exact same mechanisms. Additional steps that are U3 specific may apply.” (PX 476–4.) The memo set forth the “DUD Format” for the U3, explaining the serial number in the DID, the public and private keys in the DUD, the fields and their content for the X509 certificate, and the use of the golden units in the procurement cycle—all of which were based on MDRM's BookLocker technology. (PX 476–4;Tr. 52:25–54:9.) After early June 2005, Elazar met with the U3 team approximately ten more times to discuss the adoption of MDRM technology in the U3 device. (Tr. 54:10–55:1.)

SanDisk began producing its U3 devices in August or September 2005. (Tr. 74:10–11.) Prior to the MDRM acquisition, SanDisk's products did not use DIDs. (Tr. 74:17–24.) The U3 used a DID and corresponding data structure that was developed by MDRM. (Tr. 73:7–14; Tr. 89:21–90:6.) The “ADIR 2 Firmware Download” document indicates that the U3 firmware included the special Save DID command developed specifically to download a DID into a U3 device. (PX 94–29: “This command is used to save DID info. The data sending out from the host that follows this command is written to card.”.)

VII. Expert Testimony

The Court accepted Dr. Vijay Madisetti (“Dr. Madisetti”) as an expert witness for Plaintiffs at trial in the fields of electrical engineering and computer science. (Tr. 392:2–14; PX 458.) Dr. Madisetti's expert analyses and his related trial testimony established the following facts: A. MDRM System Developed Prior to SanDisk's Acquisition of MDRM Constitute “Firmware ”

MDRM Technology is defined in the Agreement as “firmware” developed by MDRM/Plaintiffs before the December 2, 2004 closing of the acquisition. (PX 34–5, § 1.4.) But “firmware” itself is not defined in the Agreement. (PX 34.) Firmware has four characteristics that are accepted in the industry: (i) software that has a dedicated and specialized functionality that interacts with low-level hardware; (ii) the intended location for software storage prior to execution is a semiconductor circuit which retains storage after power resets, i.e., the original values are retained even in the absence of electrical power; (iii) software that is embedded for a particular purpose; and (iv) the software storage location is not easily overwritten by an end-user. (Tr. 549:21–550:3, Tr. 552:1–555:10.)

MDRM's BookLocker system involved a manufacturing process, device code, and a DID, all of which were created before SanDisk's acquisition of MDRM. And they all have accepted characteristics of “firmware.” (Tr. 549:6–20; Tr. 550:5–19.) B. The U3 Device Used Manufacturing Firmware, Device Firmware, and DID Firmware Derived from MDRM Firmware

The term “Derivatives” is defined by the Agreement and is very broad. (Tr. 429:12–13; Tr. 916:5–8.) A Derivative can be a computer program port whereby an existing piece of a computer program, i.e., a set of instructions or statements intended for execution on a computer, is “ported,” or moved, to another platform or product. (Tr. 425:10–21; PX 34–6.) A Derivative can be a product—something that is created for eventual sale, branded, or marketed. (Tr. 426:4–9; PX 34–6.) A Derivative can also be a concept, an abstraction, or a particular idea that could be used to develop a particular translation or adaptation. (Tr. 427:5–8; Tr. 916:9–11; Tr. 968:23–969:5; PX 34–6.) Thus, a Derivative of MDRM Technology can be derived in any manner, in any medium or format, directly or indirectly from MDRM Technology. (Tr. 432:15–433:6.)

The components for the U3 device, like BookLocker, include manufacturing firmware, device firmware, and DID firmware. (Tr. 464:813.) Each was derived in whole or part from MDRM Technology. In the first step of the U3 manufacturing process, DID server firmware generates the DIDs in a secure manner to provide authentication, confidentiality, and integrity. (Tr. 464:18–2.) Portions of the BookLocker manufacturing firmware are quoted, adapted, or modified for the U3. (Tr. 471:13–14.) U3 devices use device firmware to help implement additional functionality that is unique to each U3 device—that is, the ability to set up secure sessions and create private and public partitions. (Tr. 472:8–13.) This U3 device firmware is MDRM Technology or Derivatives. The U3 device also uses DID firmware when it checks and stores for various fields relating to functionality of the U3 Specification and embeds DID firmware by accepting and storing it within the U3 unit. (Tr. 474:21–475:6.) The U3 DID is MDRM Technology or Derivatives. (Tr. 475:7–11; see Tr. 475:10–20.)

Dr. Madisetti's exhaustive review of computer source code files for MDRM's BookLocker and SanDisk's U3 devices confirm that SanDisk used or embedded MDRM Technology or Derivatives in the U3. For example, the functionality described in the BookLocker source code file “ blmake_ manufacturing.cpp ” at lines 419–423 is the same as the functionality described in the U3 source code file “ blmake_manufacturing.cpp ” at lines 476–482. Both code excerpts perform the same function and use the same instructions for implementing the matching of the golden key and the DID CD–ROM. (Tr. 512:12–513:4; PX 310, In. 419–423; PX 344, In. 476–482.) And each code excerpt from the “ blmake_manufacturing.cpp ” file contains a reference to “lot 6,” which is an identifier for the CD–ROM that consists of a large number of DIDs and is used to initiate the creation of the DIDs for both BookLocker and U3. (Tr. 513:4–12.)

Many other excerpts from the BookLocker source code and the U3 source code further demonstrate that the source codes for each provide the same or similar functionalities for the BookLocker and U3 devices:

• the BookLocker source code file “ blmake_device.cpp ” (at lines 180–181 and 270279) and the U3 source code file “ blmake_U3.cpp ” (at lines 806–816) both perform the same function of creating a new device ID and a serial number based on a fixed number and a changing number (Tr. 513:22–515:3; PX 308, In. 180–181, 270–279; PX 346, In. 806–816);

• other lines of the BookLocker source code file “ blmake_device.cpp ” and the U3 source code file “ blmake_U3.cpp ” also perform several of the same functions—naming the new device with a unique serial number and providing a self-check on the uniqueness of the number (Tr. 515:4–25; PX 308, In. 281–287; PX 346, In. 817–824); storing the serial number in a representation for the DID data structure (Tr. 517:1–14; PX 308, In. 412–414; PX 346, In. 729–737.); building secret keys (Tr. 517:17–25; PX 308, ln. 289–291; PX 346, ln. 371–375.); and storing the secret keys (Tr. 519:7–14; PX 308, ln. 327, 414–415; PX 346, ln. 769–778.);

• certain lines of the BookLocker source code file “ blmake_ manufacturing.cpp ” and the U3 source code file “ blmake_U3.cpp ” perform the same function of generating the DID checksum (Tr. 520:3–12; PX 310, ln. 155156; PX 346, ln. 787–792);

• various lines of the BookLocker source code file “ blmake_ manufacturing.cpp ” and the U3 source code file “ blmake_manufacturing.cpp ” implement several of the same functionalities (with only minor/“cosmetic” BookLocker code changes for the U3 code)—generating the CD–ROM ID (Tr. 520:23–521:9; PX 310, In. 404–413; PX 344, ln. 453–464); taking the groups of 64 DIDs and packing them together (Tr. 522:24–523:11; PX 310, ln. 449458; PX 344, ln. 516–537); creating a label, or header file, for the CD–ROM to be shipped to the manufacturing site (Tr. 524:13–525:5; PX 310, ln. 474–477; PX 344, ln. 591–601); generating the golden key and saving it to a file using a random number generator (Tr. 525:24–526:18; PX 310, ln. 62–69, 78–84; PX 344, ln. 67–75, 83–88); starting the encryption of one DID with the golden unit encryption layer (Tr. 526:25–527:10; PX 310, ln. 136–145; PX 344, ln. 136–144); reading the golden key encryption layer and preparing the DID file after applying the encryption layer (Tr. 528:5–20; PX 310, ln. 293–294, 368–378; PX 344, ln. 291–292, 370–374); encrypting a package of 64 DIDs (Tr. 528:21–529:11; PX 310, In. 379–394; PX 344, ln. 375–384, 396–410); preparing the DID file and setting the file name on the CD–ROM (Tr. 529:17–530:1; PX 310, ln. 110–120; PX 344, ln. 112–121); and checking to ensure that a DID batch of 64 was not previously created (Tr. 530:7–15; PX 310, ln. 121–134; PX 344, ln. 122–133);

• certain lines of the BookLocker source code file “ OS9.c ” and the U3 source code file “ DosImage.cpp ” perform the same function whereby the Tanisys programmer initiates a request for the USB device to verify the checksum and serial number (Tr. 532:19–534:15; PX 210, ln. 136–154; PX 366, ln. 2902–2917);

• certain lines of the BookLocker source code file “ blcrc32.c ” and U3 source code file “ fe_fw_Diagnostic.c ” perform the same function on the device itself of computing and comparing the checksum (Tr. 534:21–536:6; PX 298, ln. 106–123; PX 369, ln. 1929–1935, 1966–1978);

• various lines of the BookLocker source code file “ BLdid.h ” and the U3 source code file “ fe_fw_Diagnostic.c ” perform the same functions on the device itself of extracting the various components of the serial number after production, i.e., extracting the sectors and the fields inside the DID (Tr. 536:7–25; PX 305, ln. 82; PX 369, ln. 1949–1950); and extracting and storing the secret keys (Tr. 538:13–541:1; PX 305, ln. 83; PX 369, ln. 20242040; Tr. 907:3–7);

• various lines of the BookLocker source code file “ BLfu_update.c ” and the U3 source code file “ fe_fw_Diagnostic.c ” perform the same function, again on the device itself, of retrieving the secret key and then storing it so that it is available for subsequent activities in compliance with the U3 specification (Tr. 541:3–21; PX 299, ln. 164–176; PX 369 ln. 2024–2040);

• the code file “ DID.pm ” is almost identical for both BookLocker and the U3 (containing only minor changes between the BookLocker and U3 versions), and the file performs the same functions for both BookLocker and U3 of extracting the DJDs from the CD–ROM, verifying the CD lot number (the Batch ID), and decrypting the second layer of encryption of the DID (Tr. 530:16–531:14; PX 356.)

SanDisk's expert Dr. Margaret L. Johnson (“Dr. Johnson”) reviewed the source code files and functions that Dr. Madisetti analyzed in performing his source code analysis. (Tr. 935:8–946:13.) Dr. Johnson understood that the source files, and not just isolated lines of code, had to be reviewed with a focus on their functionality. (Tr. 940:2–941:10; Tr. 943:4–7; Tr. 958:5–24.) Nonetheless, Dr. Johnson acknowledged that while called upon to opine on whether the U3 device used or embedded MDRM firmware developed prior to the acquisition, she had no knowledge of the firmware that MDRM developed prior to the acquisition. (Tr. 960:16–963:23; Tr. 969:6–970:3.) Indeed, Dr. Johnson did not dispute Dr. Madisetti's source code analysis or present her own independent analysis of the BookLocker and U3 source codes. (Tr. 933:19–935:7; Tr. 955:23–958:4.)

At trial, SanDisk attempted to impeach Dr. Madisetti because of his failure to track and describe Google searches he conducted in preparing his report. But their arguments were overblown. Dr. Madisetti was well qualified to offer opinion testimony on the issues at trial, and this Court finds his testimony to be credible. This Court gives Dr. Madisetti's opinions substantial weight in determining the issues raised by this action.

By contrast, Dr. Johnson's testimony contributed sparse analysis of the issues, and this Court affords little weight to her expert opinions. Moreover, Dr. Johnson misrepresented her credentials to the Court by describing herself as a former “professor” at Stanford University when, in fact, she was only a lecturer. (Tr. 894:23–896:3.) She incorporated an erroneous description of her qualifications in her expert report. (Tr. 970:4–14.) Dr. Johnson conceded that describing herself as a professor “was wrong,” and that she understood the tribunal might credit her exaggeration of her credentials. (Tr. 970:17–22.) Accordingly, this Court discounts Dr. Johnson's opinions and views them skeptically. C. MDRM Technology and/or Derivatives Enabled the U3 Device to Comply with the U3 Specification

The U3 Specification describes a variety of functions for a U3 device, including the ability to set up a private and public area, (PX 102–38 to –53), and the ability to support a secure session (PX 102–54 to –71). These particular functions of the U3, and their implementation in the U3 source code, involve technology developed by MDRM. (Tr. 456:14–457:14.) A specification describes “what needs to be done.” (Tr. 480:15–16.) To implement the U3 Specification, SanDisk required MDRM's Technology. (Tr. 480:24–481:8.) As a consequence, if the U3 device did not use MDRM manufacturing firmware for its production, the U3 unit would not be able to comply with the U3 Specification. (Tr. 479:24–480:12.) Likewise, if the U3 device did not use or embed MDRM device firmware, the device would not comply with the U3 Specification. (Tr. 482:8–16.) And if the U3 device did not use or embed MDRM DID firmware, the device also would not comply with the U3 Specification. (Tr. 482:17–25.) Accordingly, MDRM Technology and Derivatives enabled the U3 device to comply with the U3 Specification. (Tr. 479:20–23.)

VIII. Sales of U3 Devices

SanDisk started producing its U3 devices in August or September 2005. (Tr. 74:4–16.) SanDisk incorporated the U3 technology into various products it sold, including U3 devices sold as Cruzer Micro, Cruzer Mini, and Cruzer Titanium. (Tr. 801:8–802:15; Tr. 367:5–17.) In 2005, SanDisk sold to end users 75,247 U3 devices. (PX 230–2; Tr. 796:13–797:6.) All of these sales occurred in the fourth quarter of 2005. (PX 230–2.)

In 2006, SanDisk sold to end users a total of 6,392,939 U3 devices. (PX 230–2; Tr. 796:13–797:6.) Thus, the aggregate quantity of U3 devices that SanDisk sold from January 1, 2005 through December 31, 2006 was 6,468,186. (PX 230–2.)

IX. SanDisk Marketed U3 Devices By Highlighting Functions and Capabilities of MDRM Technology

When SanDisk introduced the U3 to the market, it issued a press release dated January 7, 2005, stating: “U3 Compatible USB Flash Drives Will Let User Carry, Store and Launch Applications Anywhere They Go.” (PX 222p–2.) The press release further touted that “[f]or the first time, users will be able to move more than just data. With U3, users will be able to choose from a wide range of applications that can be easily carried, stored and launched from any U3compatible USB flash drive to any PC wherever they go. U3 technology will enable users to carry not only stored files, but entire computer applications on a tamperproof USB flash drive and launch such applications from any computer.” (PX 222p–2.)

The January 7, 2005 press release also stated: “U3 aims to expand the USB flash drive market beyond storage by creating a new standard platform; ... and providing developers with development tools and ongoing technical and marketing support including a Web-based distribution channel where users can easily purchase and download U3–compatible applications.” (PX 222p–2 to –3.) The press release included endorsements of the U3 by several software application companies. (PX 222p.) One company quoted in the press release stated: “ ‘ICQ supports the U3 initiative because it gives people the power to carry, store and launch essential applications by simply plugging a U3 device into any PC,’ said Ronen Arad, director of product management for ICQ. ‘The intelligent USB is the perfect way to provide convenience and security for users who want non-stop, portable access[.]’ ” (PX 222p–3.) Another boasted: “ ‘By leveraging U3 technology, Check Point can allow enterprises to manage and control secure usage of USB devices, enabling productivity gains without compromising corporate security standards.’ ” (PX 222p–3.)

When SanDisk sold products that complied with the U3 Specification, the product packaging indicated the products were U3 devices. (Tr. 364:3–6; PX 128–6; PX 128–4; Tr. 441:25–442:5; Tr. 183:17–22.) SanDisk's September 2005 press release announcing the shipment of its first U3 device stated that “SanDisk Cruzer Micro smart drives with U3 technology ... are identified by the U3 smart logo on the product as well as on the package[.]” (PX 105–2.) By the terms of the U3 Specification, only drives that met the U3 Specification requirements could be identified with the U3 logo. (PX 27–15.)

SanDisk contends that because the January 2005 press release pre-dates Plaintiffs' active involvement in the development of the U3 device, the release cannot be found to have involved marketing within this condition. But that contention views the evidence far too narrowly. When SanDisk issued the January 2005 press release, it was marketing the U3 concept and the device then being developed, which involved the U3 Specification. SanDisk used MDRM technology (such as secure session functionality) to implement that specification.

X. SanDisk Admitted that Plaintiffs Earned the Full Earn–Out and then Reneged

Between November 8, 2005 and February 13, 2007, SanDisk issued a series of six earn-out reports to Plaintiffs pursuant to Section 1.4 of the Agreement, purporting to set forth the number of “all MDRM Units Sold” in 2005 and 2006. (PX 218–1, PX 218–4, PX 218–7, PX 218–10, PX 218–13, PX 218–16.) Cedar signed each of the reports. (PX 218–2, PX 218–5, PX 218–8, PX 218–11, PX 218–14, PX 218–17.) While the reports accounted for sales of Cruzer Freedom, SanDisk's brand name for SCS's BookLocker product, none of the reports listed any sales of U3 devices, which Plaintiffs believed counted towards the earn-out. The total amount set forth as due for the sales of Cruzer Freedom products in the six earn-out reports was $143,436.10. (PX 218–2, 218–5, 218–8, 218–11, 218–14, 218–17.) That amount was paid to Plaintiffs.

Shortly after receiving a report on February 14, 2006, Plaintiffs met with Cedar and complained that U3 devices were not being counted towards the earn-out. (Tr. 81:2–82:20; Tr. 758:2–15.) Cedar responded that Plaintiffs were entitled to inclusion of the U3 devices and that he would “take care of it.” (Tr. 81:17–82:2.) Despite their repeated complaints, and Cedar's assurances, the following two reports did not count sales of U3 devices towards the earn-out. (Tr. 83:12–84:14; Tr. 86:15–87:18; PX 169–1 to–2; PX 173.) Eventually, Cedar proposed a meeting with all involved to discuss the matter. (PX 169–1.)

In mid-September 2006, a meeting was held to discuss the earn-out issue. (Tr. 88:16–20.) Plaintiffs, Harari, Cedar, Richard Chernicoff (“Chernicoff”), SanDisk's vice president of business development, and other SanDisk employees initially attended the meeting. (Tr. 88:21–89:5; Tr. 246:19–25; Tr. 761:25–762:14.) But before the meeting began, Harari left the room to take a telephone call, and as a result did not participate. (Tr. 89:18–20; Tr. 248:1–5.) While Harari was out of the room, Elazar explained the manufacturing process for the U3; the DID generation server; the MDRM server and production server; the golden keys; and the generation of DIDs for the U3 and BookLocker. Elazar also explained how U3 firmware accepts the DID and verifies it, providing the basis for a secure session. (Tr. 89:23–90:6; Spoliation Order.) Chernicoff asked questions about the DID and how the U3 was changed to adapt to the system. (Tr. 90:17–91:2; Tr. 247:7–8; Spoliation Order.) Elazar answered Chernicoff's questions, and the group had a detailed discussion about how the DID provided the basis on which U3 devices created secure sessions. (Tr. 91:8–11; Spoliation Order.)

Chernicoff then reviewed the Agreement and stated that the U3 sales fell within the earn-out provision of the Agreement and that Plaintiffs were entitled to the full earn-out. (Tr. 91:12–18; Spoliation Order.) Chernicoff even offered to deliver a check to an MDRM shareholder owed money under the earn-out because Chernicoff was visiting the shareholder the following week. (Tr. 91:21–24; Tr. 247:14–25; Tr. 817:8–16; Spoliation Order.) At the close of the meeting, Cedar said that he was very happy that “this was over.” (Tr. 91:25–92:2; Spoliation Order.) Elazar later made notes on his laptop about what transpired at the meeting. (Tr. 92:3–7; Spoliation Order.)

At trial, SanDisk did not deny that the September meeting took place, and did not offer a single witness to rebut Harkabi and Elazar's testimony that Chernicoff admitted Plaintiffs' entitlement to the full earn-out. Instead, SanDisk challenged the credibility of Harkabi and Elazar by pointing to a number of purported discrepancies between their trial and deposition testimony. While this Court found some of Plaintiffs' testimony difficult to reconcile with their earlier deposition testimony, the inconsistencies are largely attributable to the fact that Plaintiffs are non-native English speakers who were faced with highly technical questioning. This Court finds Harkabi and Elazar to be entirely credible, especially in view of the corroborating documentary evidence including contemporaneous e-mails, SanDisk's spoliation of Plaintiffs' laptop computers, and SanDisk's choice not to call a single witness to rebut Plaintiffs' testimony. Throughout trial, Harkabi and Elazar were forthright and did not evade questions. And their demeanor reflected nothing but an eagerness to present the truth to the tribunal.

At the conclusion of the September meeting, Harari returned to the conference room, having conveniently avoided the substance of Elazar's presentation. Harkabi and Elazar told Harari that Chernicoff concluded that Plaintiffs were entitled to the full earn-out, and Harari said that he was pleased with that outcome. (Tr. 92:13–21; Tr. 248:17–24.) Harari then wanted to discuss problems with the U3 device, but Harkabi said that he felt uneasy going over Cedar's head. After Harari insisted, Harkabi outlined his complaints that the U3 device became excessively hot, was not compatible with popular operating systems, and cost too much to develop. (Tr. 93:12–25; Tr. 249:23–250:16.) Apparently Harkabi's reluctance was justified because after he offered his honest assessment to Harari, everything changed.

Later that day, Cedar was enraged when he learned of Harkabi and Elazar's discussion with Harari about the U3. (Tr. 250:23–251:10.) Cedar called Harkabi and angrily told him that he should not have stated his concerns directly to Harari. (Tr. 251:14–21; Tr. 266:8–18; Tr. 94:17–95:12.) Harkabi was upset by Cedar's call. (Tr. 251:22–23; Tr. 94:24–25.) In the early hours of the following morning, Harkabi e-mailed Harari and Cedar, attempting to ease the tension with Cedar and expressing Harkabi's thanks “for resolving the ‘earnout’ according to the agreement.” (Tr. 252:7–10; PX 175.) By e-mail, Cedar replied that Harkabi “[was] completely taking things out of context,” but Cedar did not take issue with Harkabi's statement about resolving the earn-out. (PX 175.) Despite Harkabi's conciliatory efforts, Cedar continued to be upset with Harkabi and Elazar. (Tr. 95:19–96:15.)

In October 2006, Cedar came into Elazar's office and told him there was a problem with the earn-out and that Elazar should talk with Megan Comport (“Comport”), a SanDisk attorney in charge of accounting for qualified sales under the earn-out. (Tr. 97:6–13.) Elazar first spoke with Chernicoff who said that he did not know of any problem with the earn-out. (Tr. 97:14–25.) Elazar then spoke with Comport who requested documents and e-mails and said that she was asked to look at the earn-out issue again. (Tr. 98:1–5.)

The following Monday, Harkabi and Elazar received a message that Cedar wanted to talk with them. Later that evening in a conference call, Cedar advised Harkabi and Elazar that SanDisk would not pay the full earn-out. (Tr. 98:13–23.) Instead, SanDisk offered Harkabi and Elazar $400,000 each, payable over two years. (Tr. 98:24–99:4; Tr. 255:13–24.) During the call, Harkabi and Elazar asked if Harari was involved in the decision, and Cedar acknowledged he was. (Tr. 99:9–10.) At the conclusion of the call, Harkabi and Elazar rejected SanDisk's $400,000 per-person offer. (Tr. 99:6–9; Tr. 255:25–256:2.)

Harkabi and Elazar then met with Harari in January 2007 and attempted to present a set of documents, including specifications and code, showing that SanDisk's decision not to pay the full earn-out was inconsistent with the parties' agreement. (Tr. 99:11–100:3; Tr. 256:7–16.) But Harari refused to review the documents and said that he did not want to be involved. Harari also said that Elazar and Harkabi should reconsider SanDisk's offer. They responded that they would not accept it. (Tr. 99:25–100:12.)

On March 1, 2007, SanDisk terminated Harkabi's and Elazar's employment, purportedly as part of a reduction in the company's workforce. (Tr. 100:13–19; Tr. 256:25–257:3.) That day, Harkabi sent an e-mail to Harari urging a discussion about the earn-out, but Harari did not respond. (Tr. 261:17–19.) When Plaintiffs were fired, Plaintiffs were required to return their company laptops, which included notes and pictures from various meetings. (Tr. 101:4–9.)

In June 2007, Elazar met with Harari in Cupertino, California about the earn-out. (Tr. 101:13–21.) Elazar relayed to Harari that a SanDisk lawyer told Elazar that if Plaintiffs sued SanDisk, the case would proceed in New York and would be very expensive. Elazar asked Harari why SanDisk's counsel would say such a thing. (Tr. 101:22–102:3.) Harari responded that since Elazar was living in Israel, litigating in the United States would be very difficult and expensive, and of little consequence for SanDisk. (Tr. 102:4–8.) Undaunted, Plaintiffs commenced this action on September 24, 2008. (Compl., ECF No. 1.) From that time forward, SanDisk waged a war of attrition against Plaintiffs, with attendant legal fees undoubtedly eclipsing the amount in dispute.

CONCLUSIONS OF LAW

I. Jurisdiction and Venue

This Court has subject matter jurisdiction over this action under 28 U.S.C. § 1332(a) because there is complete diversity of citizenship between Plaintiffs and Defendant SanDisk. The amount in controversy exceeds $75,000, exclusive of interest and costs. Venue here is proper because the parties agreed to the United States District Court for the Southern District of New York as the exclusive forum for any action arising out of the Agreement. (PX 34–40, § 10.7.)

II. Governing Law and Applicable Legal Principles

New York law governs this action because the Agreement includes a New York choice-of-law provision, (PX 34–39, § 10.6), and the parties have presented the case under New York law. To recover for breach of contract under New York law, a plaintiff must prove (a) the existence of a contract between plaintiff and defendant; (b) performance of the plaintiff's obligations under the contract; (c) breach of the contract by the defendant; and (d) damages to the plaintiff caused by the defendant's breach. See Diesel Props S.r.l. v. Greystone Bus. Credit II LLC, 631 F.3d 42, 52 (2d Cir.2011); Broyles v. J.P. Morgan Chase & Co., No. 08 Civ. 3391(WHP), 2010 WL 815123, at *3 (S.D.N.Y. Mar. 8, 2010) (“The four elements of a breach of contract claim are: (1) the existence of a valid contract, (2) plaintiff's performance of the contract, (3) defendant's material breach of the contract, and (4) resulting damages.”) (citing cases). To prevail, a plaintiff must prove the elements for breach of contract by a preponderance of the evidence. Diesel Props, 631 F.3d at 52.

Contractual language is interpreted according to its ordinary and plain meaning. See Krumme v. WestPoint Stevens Inc., 238 F.3d 133, 139 (2d Cir.2000) (“When interpreting an unambiguous contract, words and phrases are given their plain meaning. Under New York law, therefore, a court must enforce that plain meaning, rather than rewrite an unambiguous agreement.” (internal citations, quotation marks and alterations omitted)); see also Laba v. Carey, 29 N.Y.2d 302, 308, 327 N.Y.S.2d 613, 277 N.E.2d 641 (1971) (“Although we do not fashion new contracts for the parties under the guise of contract construction, we are required to adjudicate their rights according to the unambiguous terms of the contract and therefore must give the words and phrases employed their plain meaning.” (internal citations omitted)).

III. Plaintiffs Proved that SanDisk Breached the Agreement

Plaintiffs seek damages for breach of contract due to SanDisk's failure to pay the amount due under the Agreement. The Agreement was a binding contract between Plaintiffs and SanDisk, and Plaintiffs performed their obligations under the Agreement. The only issue to be determined is whether SanDisk breached the Agreement by failing to meet its earn-out payment obligation.

Under the Agreement, SanDisk placed the $4 million maximum earn-out in escrow, subject to release to Plaintiffs of a portion of the funds for each device (a) “using or embedding” the “MDRM Technology” developed by MDRM before the Agreement's closing date, described as “firmware,” “and/or Derivatives thereof,” as developed by SanDisk after the closing date (described as “MDRM Units”) that was (b) “Sold” by SanDisk through the fiscal quarter ending upon the second anniversary of the closing date, in accordance with terms as defined in the Agreement. (PX 34–3 to –5, § 1.1(b)(ii), § 1.4.) Accordingly, under the terms and formula set forth in the Agreement, the full $4 million earn-out would be due if 3.2 million or more of SanDisk devices, as defined by the terms of the Agreement (the “MDRM Units”), were sold through December 31, 2006 (the fiscal quarter ending the closing date's second anniversary) in accordance with the terms of the Agreement. (PX 34–5 to –6, § 1.4.)

The evidence presented at trial demonstrated that SanDisk sold more than 3.2 million U3 devices during the two-year earn-out period. Thus, the issue boils down to whether (i) the U3 device “used or embedded MDRM's Technology or its Derivatives” under the agreement's terms; and (ii) the U3 device was “Sold” under the Agreement's terms. As set forth below, Plaintiffs proved by a preponderance of the evidence that these terms were met, thereby entitling Plaintiffs to recover damages for SanDisk's failure to pay the full earn-out due pursuant to the Agreement. A. SanDisk's U3 Device Used or Embedded MDRM's Technology or Its Derivatives Within the Meaning of the Agreement

Fundamentally, SanDisk's U3 device replicated certain basic functionality of MDRM's BookLocker device. In particular, the U3 device—like BookLocker—included security-related functions, such as the ability to establish a secure session over the internet between the U3 device and a remote server. An integral component for the security functionality of the U3 was the DID. The DID can be analogized to the key to an automobile, giving the U3 user access to the U3 device's unique functions, such as a secure session, the same way the car key enables the driver to start the engine and access the car's functions. (Tr. 967:7–968:22.) The DID was created and downloaded into each device as part of the U3 manufacturing process. The various steps of this complex manufacturing process are implemented in firmware by a security system developed by MDRM to keep the DID secret, so that the U3 device thereby maintains security at all times. Prior to acquiring MDRM, SanDisk did not have a product that provided these security functions, such as secure session functionality. Indeed, SanDisk did not have DIDs or any security system like MDRM's. Once the acquisition occurred, SanDisk was able to develop the U3 based upon MDRM's Technology, which resulted in U3 devices using and embedding firmware MDRM had developed, as well as contractually-defined “Derivatives” of the firmware.

SanDisk took the position at trial that firmware can only exist (i) in the form of executable software (ii) that is stored in ROM or “some ROM variant.” Dr. Johnson testified: “firmware is an executable code that's stored on ROM or some ROM variant.” (Tr. 965:23–966:2; Tr. 966:21–23.) Based on that contention, SanDisk asserts that the U3 device never used or embedded MDRM Technology or a “Derivative.” (Tr. 833:15–18.) But Plaintiffs offered extensive evidence at trial disproving SanDisk's cramped meaning of “firmware.” This Court accepts Plaintiffs' well-supported definition of “firmware” and rejects SanDisk's narrow construction.

In any event, the evidence established that the U3 used or embedded MDRM Technology or its Derivatives even under SanDisk's view of “firmware.” Dr. Johnson admitted that there is firmware on the BookLocker device that accepts and verifies the DID. (Tr. 859:23–24; Tr. 860:2–3; Tr. 866:25–867:4; Tr. 978:20–25.) Although Dr. Johnson did not know which source code files were associated with the function, (Tr. 978:17–19), Dr. Madisetti explained, through examples, how the code files operated. Thus, for example, BookLocker used source code files “ BLdid.h ” (PX 305) and “ BLfu_update.c ” (PX 299) that become executable software when assembled, linked, and loaded onto the processor. (Tr. 433:11–434:22; Tr. 671:13–22.) Moreover, these code files reside on flash memory—and SanDisk's expert recognized that so-called protected flash memory is one type of “ROM variant.” (Tr. 674:20–675:2; Tr. 837:16–22; Tr. 906:11–16; Tr. 841:10–842:1.) Thus, under SanDisk's definition, these BookLocker files are, at the very least, a precompiled version of BookLocker firmware.

As Dr. Johnson also testified, source code that is a precompiled version of firmware can be used to create a derivative of firmware. (Tr. 926:7–21 (“a derivative can be created by reference to the source code that is the precompiled version of the firmware”).) The U3 device used source code files “ fe_fw_Diagnostic.c ” (PX 369) and “ u3_app_commandParser.c ” (PX 411) that were derived from the BookLocker files. (Tr. 433:15–434:22; Tr. 672:7–19; Tr. 675:3–13.) These U3 files therefore are “Derivatives” of BookLocker firmware and, as such, are “Derivatives” of MDRM Technology. Indeed, like Booklocker firmware, these U3 files also become executable software and reside on flash memory in the U3. (Tr. 672:7–19; Tr. 675:3–13.) Not surprisingly, Dr. Johnson also acknowledged that the U3 device itself contained “firmware.” (Tr. 907:8–13; Tr. 860:2–3; Tr. 866:25–867:4; Tr. 978:20–25.) And that firmware, as shown, was derived from MDRM's BookLocker firmware. The U3 device therefore used or embedded MDRM Technology even under SanDisk's restrictive definition of “firmware.”

Tellingly, Dr. Johnson's testimony contradicted her earlier contention that firmware can only be “executable” code. At first, Dr. Johnson contended that firmware cannot be “source code,” i.e., “non-executable code” (as represented by the numerous exhibits received in evidence as computer source code files). (Tr. 926:7–13.) This Court questioned Dr. Johnson: “What would an engineer call draft code that's intended to be compiled and stored on ROM”? [A.] “... I would call that source code. It doesn't become firmware until it's stored on the ROM.” (Tr. 966:16–23.) But, when confronted with the language of the Agreement defining a “Derivative” to include “any computer program ... whether in source or object code form” (PX 34–6), Dr. Johnson acknowledged that firmware could be “a computer program in source or object form.” (Tr. 919:19–22.) Simply put, Dr. Johnson's testimony belied SanDisk's position that source code—such as MDRM's numerous BookLocker code files adapted for the U3—cannot be “firmware.” B. SanDisk “Sold” the U3 Under the Agreement

The U3 device qualified as being sold under the earn-out provision, as the Agreement defines the terms “Sales” and “Sold.” (PX 34–5 to –6, § 1.4 (conditions (x), (y) and (z)).) A sale of the U3 device qualified as being “Sold” under the earn-out provision if the device “[was] marketed by [SanDisk] by reference to the MDRM Technology or Derivatives thereof or to their functions and/or capabilities.” (PX 34–5, § 1.4 (condition (x)).) SanDisk's sales of the U3 device in 2005 and 2006 met this condition because SanDisk promoted and publicized the U3 device in press releases by referring to its unique functions and capabilities, outlined in the U3 Specification. Some of these features, including the ability to establish a secure session, were based on or enabled by MDRM Technology or its Derivatives. SanDisk sold the product in packaging that marked, displayed, and promoted these unique functions and capabilities of the U3 device. Indeed, SanDisk was required to mark its U3 devices with a logo designating it as a U3 device. Accordingly, SanDisk marketed U3 devices by reference to functions and capabilities derived from MDRM's Technology.

The Agreement's “Sales”/“Sold” provision also provides that, “[f]or the avoidance of doubt, a Sale shall not occur (i) merely as a result of the sale of products of [SanDisk] which use or embed the MDRM Technology or Derivatives or a portion thereof[.]” (PX 34–6, § 1.4.) By its plain terms, this provision excludes from the earn-out payment a device using or embedding MDRM's Technology (or Derivatives) that is sold in circumstances that do not meet one of the three expressly described conditions constituting a contractual “Sale.” In other words, the provision clarifies that the earn-out is not triggered where a unit merely uses or embeds MDRM's Technology/Derivatives and is sold without being “marketed” in accord with the stated conditions of provision (x) of Section 1.4; or without being “used” in accord with the specified conditions of (y); or without being “pre-activated” as prescribed in (z). Whether such “non-contractual” sales actually occurred is irrelevant here. Plaintiffs conceded as much at trial. (Tr. 194:6–195–7; Tr. 663:8–664:6.)

Accordingly, all of SanDisk's sales of its U3 devices in 2005 and 2006 constituted “Sales,” and the devices were “Sold” within the meaning of those terms as set forth in the Agreement, and they therefore qualified for the earn-out.

Proof of motive or state of mind is not necessary to prevail on a breach of contract claim. See Zurich Am. Ins. Co. v. Ace Am. Reinsurance Co., No. 05–Civ9170 (RMB)(JCF), 2006 WL 3771090, at *1 (S.D.N.Y. Dec. 22, 2006) (“[M]otive is generally irrelevant in breach of contract actions [.]”); Brown v. Paul Revere Life Ins. Co., No. 00–Civ–9110 (KMW)(HBP), 2001 WL 1230528, at *6 (S.D.N.Y. Oct. 16, 2001) (same). Nevertheless, this Court concludes that after having first acknowledged that the earn-out was due, SanDisk personnel, and Cedar in particular, ultimately decided to retaliate and refused to pay the earn-out because Plaintiffs complained about the U3 device directly to Harari. And SanDisk decided that its financial might and legion of lawyers would exhaust Plaintiffs' modest resources and overwhelm their will to vindicate their contractual rights. But SanDisk's stratagem backfired. Undoubtedly, SanDisk has spent more on attorneys' fees and sanctions than it would have spent had it honored its contractual obligation to Plaintiffs. Whether SanDisk will abandon this failed strategy or continue to pour good money after bad is an open question.

IV. Plaintiffs Are Entitled to Breach of Contract Damages

It is undisputed that SanDisk did not include the sales of its U3 devices as MDRM Units Sold under the Agreement in determining the amount to be paid to Plaintiffs and that SanDisk refused and failed to pay any part of the earn-out for the sales of the U3 devices. As such, SanDisk breached the Agreement. The total amount SanDisk paid Plaintiffs for the earn-out under the Agreement (for sales of Cruzer Freedom) was $143,436.10. Had the sales of the U3 devices in 2005 and 2006 been included as MDRM Units Sold, the maximum earn-out of $4 million would have been due. Accordingly, SanDisk owes the difference to Plaintiffs, and Plaintiffs are entitled to damages in the amount of $3,856,563.90.

V. Plaintiffs are Entitled to Interest on the Damages Award

Plaintiffs are entitled to prejudgment interest on the damages award at the New York State statutory rate of 9% per annum. SeeN.Y. C.P.L.R. § 5001(a) (prejudgment interest “shall be recovered upon a sum awarded because of a breach of performance of a contract[.]”); see also Schipani v. McLeod, 541 F.3d 158, 164 (2d Cir.2008) (“In a diversity case, state law governs the award of prejudgment interest.”); Graham v. James, 144 F.3d 229, 239 (2d Cir.1998) (“Under New York law, ‘prejudgment interest is normally recoverable as a matter of right in an action at law for breach of contract.’ ”) (quoting Adams v. Lindblad Travel, Inc., 730 F.2d 89, 93 (2d Cir.1984)). New York law also provides that interest upon damages incurred after a cause of action existed “shall be computed from the date incurred. Where such damages were incurred at various times, interest shall be computed upon each item from the date it was incurred[.]” N.Y. C.P.L.R. § 5001(b). In calculating prejudgment interest here, this Court considers the specific amount of damages incurred at specific dates as a result of SanDisk's failure to pay earn-out amounts when due under the Agreement's terms.

The Agreement provides that payments under the earn-out provision were to be made 45 days after each fiscal quarter during the two-year earn-out period. (PX 34–5, § 1.4.) The amount to be paid for each quarter was determined by a formula prescribed under the Agreement. Based on the quarterly Sales of U3 devices, damages were incurred as follows: $94,058.75 incurred on February 14, 2006 (for Q4 05); $166,418.75 incurred on May 15, 2006 (Q1 06); $934,221.25 incurred on August 14, 2006 (Q2 06); and $2,661,865.00 incurred on November 14, 2006 (Q3 06). These amounts represent the amount of Plaintiffs' damages incurred as of each of the foregoing dates. Statutory prejudgment interest should be calculated from each date based on the amount due at that date.

CONCLUSION

For the foregoing reasons, this Court awards Harkabi and Elazar $3,856,563.90 plus prejudgment interest, to be calculated consistent with this Opinion against SanDisk. The parties are directed to submit a proposed judgment to the Court by September 19, 2012.

SO ORDERED.