Google Inc. v. Netlist, Inc.

Filing 34

Letter to Magistrate Judge Joseph C. Spero re Discovery Dispute (Production Server), from L. Scott Oliver and Christina Jordan, dated 06/12/09. (Oliver, Larry) (Filed on 6/12/2009) Modified on 6/15/2009 (jlm, COURT STAFF).

755 PAGE MILL ROAD PALO ALTO CALIFORNIA 94304-1018 TELEPHONE: [phone] FACSIMILE: 650.494.0792 WWW.MOFO.COM

MORRISON & FOERSTER LLP NEW YORK, SAN FRANCISCO, LOS ANGELES, PALO ALTO, SAN DIEGO, WASHINGTON, D. C. NORTHERN VIRGINIA, DENVER, SACRAMENTO, WALNUT CREEK TOKYO, LONDON, BEIJING, SHANGHAI, HONG KONG, SINGAPORE, BRUSSELS

June 12, 2009

Writer's Direct Contact 650.813.5733 [e-mail]

Honorable Joseph C. Spero United States District Court 450 Golden Gate Avenue 15th Floor, Courtroom A San Francisco, CA 94102 Re: Google, Inc. v. Netlist, Inc., Case No. C 08-04144 SBA (JCS)

Dear Judge Spero: Pursuant to the Court's Order of May 25, 2009, Defendant Netlist, Inc. ("Defendant") and Plaintiff Google, Inc. ("Plaintiff") jointly file this letter concerning unresolved issues regarding the protocol for inspection of a Google server. Defendant's Proposal Because Google has yet to produce sufficient technical documents to enable a full understanding of the server to be inspected, and because Netlist's technical advisers have not yet cleared the seven-day wait ing period under the Protective Order to view confidential information, Netlist presently outlines its inspection protocol and expects to refine it with specificity as those documents are made available. Netlist has requested from Google basic information about the server to be produced, including (1) the operating system it uses, (2) confirmat ion that the servers is functionally representative of servers using allegedly infringing FBDIMM memory modules in Google's data centers, and (3) confirmation that the server will have a command line interface allowing Netlist to read and write to the memory registers and verify the system memory available.1

1

Addit ional information that Netlist requires includes: · · schemat ics of the Google FBDIMMs and their connections on the server motherboard to the central processing unit via the memory controller hub, and any other circuits associated with activation of the FBDIMMs; source code of the system BIOS for the software that controls the FBDIMMs;

pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Two Subject to the receiving the information above, Netlist intends to carry out the following inspection: 1. Obtain information about the server's platform, including: · Memory controller hub informat ion (vendor and model) for the platform; · Number of DIMM sockets per board for the platform; · BIOS information (manufacturer, version, and last update date) for the platform; 2. Obtain information about the FBDIMM, including: · AMB manufacturer and part number/revisio n number; · Memory densit y, number of DRAMs per module, number of AMBs · DRAM information (part number and organization); 3. Verify that the memory reported by the system includes all four ranks of memory devices on the installed FBDIMM; 4. Read and write to the AMB Registers outlined in the JEDEC FBDIMM AMB specification in order to: · verify that on start-up the memory controller hub activates Mode C; · verify system memory utilization; · de-activate Mode C 5. Splice into motherboard's and/or memory board's power connector and measure the current drawn in order to: · observe the power consumption of Google FBDIMM;

· · ·

details of the operating system running on the server and the software/firmware and/or hardware that is used to control the operation of the FBDIMMs; the interfaces that are available to communicate with the server to control the server and start and stop programs' execution; details of the server's user interface (e.g. whether the server maintains a graphical user interface and whether it can be controlled by keyboard and mouse);

All of this discovery is called for by Request for Production No. 1, which seeks "All documents referring or relating to GOOGLE's use of 4-Rank 4G FBDIMM;" Request No. 12, which seeks "A GOOGLE server . . . utilizing 4-Rank Fully-Buffered Dual Inline Memory Modules . . . including all software, firmware, and/or register-setting code used in the operation and/or configuration of such memory module;" and Request No. 13, which seeks "All documentation regarding GOOGLE'S operation and configuration of 4-rank memory modules in GOOGLE servers, including, but not limited, documents related to setting 4-Rank FBDIMMs to run in 4-rank mode."
pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Three compare power consumption of Google FBDIMM versus commercially available FBDIMMs of different configurations (standard x4 and x8) provided by Netlist and installed on the server; · compare power consumption between two FBDIMMs with the same density ­ Google FBDIMM versus non-Google FBDIMM provided by Netlist and installed on the server; 6. Monitor thermal characteristics of the server while operating in Mode C and nonMode C using an infrared thermometer; 7. Photograph the server, including the memory controller hub and connections to the FBDIMMs; 8. Photograph memory modules. The proposals above may need to be modified based upon the information Google produces or Netlist's technical advisors discover. Netlist's proposal outlines the basic intended inspection with as much particularity as possible in the absence of Google's production of specific technical information about the server Netlist will inspect. To the best of its present ability, Netlist has laid out specifically the information it will seek from the inspection and the operations it intends to perform. Responses to Google's General Objections Google's objections are a thinly-concealed attempt to re-argue whether Netlist should be permitted to inspect a Google server. Google's posit ion is littered with arguments that the servers are irrelevant to this case. But the Court has already ruled on that issue. Everything Net list has requested of Google is within the scope of legit imate discovery. The point of this test protocol was to give Google fair notice of the testing Netlist will perform. Google argues that Netlist may "run any number of irrelevant tests," but tellingly, Google isn't able to identify a single example. Google also objects that Netlist has requested information that Google cannot provide, stating that Netlist's demands are "impossibly vague" and that Google cannot provide details without knowing what details Netlist needs. Leaving aside that the details are spelled out above, Google is attempting to shift an impossible burden onto Netlist. In order to conduct the inspection that the Court has already ruled is allowed, Netlist must know more about the operating system and the software and hardware used to operate the FBDIMMs. Google, not Netlist, is in possession of that informat ion. Indeed, it is inconceivable that Google does not ·

pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Four provide precisely that information to its business partners. Netlist simply seeks to facilitate this inspection. 2 Responses to Google's Specific Objections 3. Netlist will use whatever user interface exists on the server to determine what the operating system reports to be the installed memory capacity. Because Google has provided no details about that user interface the server employs, nor any details about the server's operating system, Netlist cannot presently be more detailed. 5. "Splicing" is not destructive. Netlist intends to unplug the server's and FBDIMMs' power lines, plug them into the test equipment, and then run the power lines from the test bench back into server's original connectors. Once the testing is complete, the unaltered original plugs will be snapped back together. Had Google simply asked Netlist, it would have known this. Regarding "commercially available FBDIMMs of different configurations" and "non-Google FBDIMM", Netlist will identify those other FBDIMMs as soon as Google provides sufficient information to enable Netlist to know what alternative memory modules could be used in the Google server. 7. Google's argument regarding photographs makes no sense. First, Netlist agrees that any photos will be designated at the highest confidentiality level under the protective order. Second, because the inspection of the server is likely to generate evidence relevant to infringement, any photographic evidence that documents or explains the inspection is relevant and highly likely to be admissible. Netlist must document its inspection for evidentiary purposes, to be able to show the jury how it conducted the tests, and to defend against arguments that its inspection was somehow flawed (e.g., without a photo, it will be near-impossible to defend against charges that Netlist measured the temperature of the wrong chip on the server.) Through the use of photos in their expert reports and at trial, the experts can demonstrate precisely what they did. Ultimately, Google seems to be arguing that Netlist's counsel--officers of the court--cannot be trusted. Those arguments ought not be made, much less heeded. Plaintiff's Proposal Based on the vagueness and overbreadth of Netlist's proposed protocol, Google's initial concerns about this inspection turning into an invasive fishing expedition appear to have been well-founded.
2

It bears noting that Google has complained at length about the amount of time the server to be inspected will be offline and unavailable to Google, claiming this is immensely burdensome. But that injury is self-inflicted by Google's refusal to provide background technical information to Netlist so that Netlist's inspection may proceed efficiently.
pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Five Google's previous letter to this Court emphasized that the server is not an accused product in this case ­ the only accused product is a 4-rank FBDIMM. Netlist claimed that it needed to inspect a server "to verify that the FBDIMMs used in Google servers function as described in the `386 patent." (Dkt. #27, pg. 2.) Google raised serious concerns relating to proprietary intellectual property located on its servers and Netlist's refusal to disclose what it proposed to do to "inspect" Google's server. (Id., pgs. 5-6.) At the hearing, Google expressed its concern that Netlist would use an inspection as a blank check to conduct irrelevant and uncontrolled testing, including invasive or destructive testing which could result in a compromised FBDIMM or server. Ult imately, the Court allowed Netlist "to inspect a funct ioning server." (Dkt. #31.) However, to address Google's concerns, the Court ordered the parties to meet and confer to reach an agreed-upon protocol for inspection. Netlist's protocol lacks the specificity that was contemplated by the Court at the hearing and requests information that is outside the bounds of legit imate discovery. After meeting and conferring on the above protocol, Google submits the following unresolved issues for resolution. General Objections to Netlist's Proposed Protocol Netlist states openly that it expects to alter ("refine") the above protocol because Google has not produced technical documents "to enable a full understanding of the server." The server is not an accused product and has never been at issue in this litigation; Google has no obligation to educate Netlist on those details of a server that do not related to the accused 4rank FBDIMMs. Indeed, Netlist has not requested any such information ­ it has requested, more appropriately, documents, software, and firmware relating to the use, operation, configuration of the accused 4-rank FBDIMMs. Google has agreed to comply with these requests, and will provide all relevant source code relating to operation of the accused 4-rank FBDIMMs for Netlist's inspection, as well as PCB schematics and design files. This statement evidences the very threat that Google raised during the hearing ­ that Netlist would use this inspection, which Netlist originally represented as intended to verify FBDIMM operation, as carte blanche to run any number of irrelevant tests on highly proprietary technology. For example, Netlist proposes to "splice into [a] power connector" ­ which is hardly a harmless `diagnostic' on the FBDIMM. This initial protocol should be considered a strict outer limit on what Netlist is allowed to do during the inspection. Netlist's preliminary statements also make wholly unclear the scope it contemplates for the inspection. As explained in multiple meet and confer calls, Google has agreed to produce a (one) 4-rank FBDIMM of the type used in its servers. Pursuant to this Court's Order, Google also intends to produce a "functioning server" that will allow Netlist to operate this FBDIMM in a manner that is functionally representative of the operation of 4-rank FBDIMMs used in Google's servers. Google wants to make clear that, while its production

pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Six includes technical information relating to FBDIMMs more generally, there will be only one FBDIMM and one server provided for inspection ­ again, pursuant to this Court's Order. Netlist also demands various information that Google cannot necessarily provide. First, Netlist asks for "details of the operating system. . . and the software/firmware and/or hardware that is used to control the operation of the FBDIMMs." This is an impossibly vague request; without a better idea of what these "details" might be, Google cannot provide an answer. Additionally, and as mentioned during the hearing, various third-party intellectual property hardware and software exists on the compelled server. Google is working diligently to obtain consent for disclosing such intellectual property, but disclosure of this information will necessarily depend on the third-parties' willingness to cooperate. Specific Objections to Netlist's Proposed Inspection Protocol Google makes the following specific objections to Netlist's inspection protocol (reference numbers correspond to the protocol outlined above). 3. "Verify" provides absolutely no limits on or informat ion about what tests or procedures Netlist plans to run on Google's server. Netlist must specifically state what it intends to do with Google's server and 4-rank FBDIMM. 5. First, Netlist states that it intends to "splice into" a power connector. Netlist should not be allowed to interact with Google's components invasively or destructively ­ Google requires a more particular definition of what Netlist means by the term "splice." Additionally, Netlist refers to "commercially available FBDIMMs of different configurations" and "non-Google FBDIMM," but provides no indication of what these other FBDIMMs might be or whether it intends to use them in connection with the inspection. If Netlist intends to use any FBDIMM other than the Google-provided 4-rank FBDIMM in the inspection, Netlist must specifically identify and state what it intends to do with any such FBDIMM before Google can comment on the propriety of such inspection. 7. Photographs of the server are absolutely irrelevant to any claim or defense in this case and will not lead to admissible evidence. This raises significant risks of improper disclosure of proprietary Google and third-party hardware on the server ­ these risks greatly outweigh any tangential relevance Netlist might be able to articulate. In meet and confer, Netlist said that it needs server photographs to confirm that Google's FBDIMMs operate in its servers. Google does not now, and has not ever, contested this statement. Netlist has no need for photographs of the servers, which are themselves irrelevant to this case and include highly sensitive and proprietary intellectual property.

pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Seven Google's Requested Relief In sum, Google asks this Court for the following relief: 1. Confirm that the parties' agreed-upon protocol will serve as an outer limit on the testing procedures Netlist can conduct during an inspection; 2. Require Netlist to specifically state how it intends to "verify that the memory reported by the system includes all four ranks of memory devices on the installed FBDIMMs" (part 3); 3. Require Netlist to specifically identify its intended "splicing action" and, if necessary, prohibit Netlist from interacting invasively or destructively with the components of Google's server and FBDIMM (part 5); 4. Require Netlist to specifically identify and state what it intends to do with any "co mmercially available FBDIMMs of different configurations" and "non-Google FBDIMM" (part 5); and 5. Prohibit Netlist from taking any photographs of the server (part 7).

Sincerely, /s/ L. Scott Oliver L. Scott Oliver Morrison & Foerster LLP Counsel for Defendant Netlist, Inc. /s/ Christina Jordan Fish & Richardson PC Counsel for Plaintiff Google, Inc.

pa-1340155

Magistrate Judge Joseph C. Spero June 12, 2009 Page Eight

I, L. SCOTT OLIVER, am the ECF User whose ID and password are being used to file the JOINT LETTER. In compliance with General Order 45, X.B., I hereby attest that Christina Jordan has concurred in this filing. Dated: June 12, 2009 MORRISON & FOERSTER LLP By: /s/ L. Scott Oliver L. Scott Oliver Attorneys for Plaintiff NETLIST, INC.

pa-1340155