From Casetext: Smarter Legal Research

Crowder v. LinkedIn Corp.

United States District Court, Northern District of California
Feb 23, 2023
4:22-cv-00237-HSG (N.D. Cal. Feb. 23, 2023)

Opinion

4:22-cv-00237-HSG

02-23-2023

TODD CROWDER, KEVIN SCHULTE, and GARRICK VANCE, on behalf of themselves and all others similarly situated, Plaintiffs, v. LINKEDIN CORPORATION, Defendant.

BATHAEE DUNNE LLP Brian J. Dunne (CA 275689) Attorneys for Plaintiffs Todd Crowder, et al. [additional counsel listed below signature] PERKINS COIE LLP Shylah R. Alfonso (admitted pro hac vice) Attorneys for Defendant LinkedIn Corporation [additional counsel listed below signature]


BATHAEE DUNNE LLP Brian J. Dunne (CA 275689) Attorneys for Plaintiffs Todd Crowder, et al. [additional counsel listed below signature]

PERKINS COIE LLP Shylah R. Alfonso (admitted pro hac vice) Attorneys for Defendant LinkedIn Corporation [additional counsel listed below signature]

INTERIM STIPULATED ORDER RE: DISCOVERY OF ELECTRONICALLY STORED INFORMATION;ORDER

Hon. Haywood S. Gilliam, Jr. United States District Judge

1. PURPOSE

This Order will govern discovery of electronically stored information (“ESI”) in this case as a supplement to the Federal Rules of Civil Procedure, this Court's Guidelines for the Discovery of Electronically Stored Information, and any other applicable orders and rules.

2. COOPERATION

The parties are aware of the importance the Court places on cooperation and commit to cooperate in good faith throughout the matter consistent with this Court's Guidelines for the Discovery of ESI.

3. LIAISON

The parties have identified liaisons to each other who are and will be knowledgeable about and responsible for discussing their respective ESI. Each e-discovery liaison will be, or have access to those who are, knowledgeable about the technical aspects of e-discovery, including the location, nature, accessibility, format, collection, search methodologies, and production of ESI in this matter. The parties will rely on the liaisons, as needed, to confer about ESI and to help resolve disputes without court intervention.

4. PRESERVATION

The parties have discussed their preservation obligations and needs and agree that preservation of potentially relevant ESI will be reasonable and proportionate. To reduce the costs and burdens of preservation and to ensure proper ESI is preserved, the parties agree that:

a) The parties shall preserve all non-duplicative ESI that is relevant to any party's claim or defense, proportional to the needs of the case, and currently in their possession, custody, or control, including the metadata of such ESI set forth in Paragraph 6(g) below. The parties are not required to modify on a going-forward basis, the procedures used by them in the usual course of business to back up and/or archive data.
b) Absent a showing of good cause by the requesting party, the following categories of
ESI need not be preserved:
1) Deleted, slack, fragmented, or other data only accessible by forensics.
2) Random access memory (RAM), temporary files, or other ephemeral data that are difficult to preserve without disabling the operating system.
3) On-line access data such as temporary internet files, history, cache, cookies, and the like.
4) Back-up data that are duplicative of data that are more accessible elsewhere.
5) Server, system, or network logs.
6) Data remaining from systems no longer in use that is unintelligible on the systems in use.
7) Data stored on photocopiers, scanners, and fax machines.
8) Electronic data (e.g., emails, calendars, contact data, and notes) sent to or from mobile devices (e.g., iPhone, iPad, Android devices), provided that a copy of all such electronic data is automatically saved in real time elsewhere (such as on a server, laptop, desktop computer, or “cloud” storage).
9) Voicemail messages.
10) Text messages (e.g., Slack, MMS, iMessages) and data from app-based messaging systems (e.g., WhatsApp, Signal, and Line).
c) The parties will endeavor to agree upon a date limitation for the preservation of ESI.

5. SEARCH

a) The parties agree that in responding to an initial Fed.R.Civ.P. 34 request, or earlier if appropriate, they will meet and confer about methods to search ESI in order to identify ESI that is subject to production in discovery and filter out ESI that is not subject to discovery. The producing party will disclose to the receiving party if they intend to use Technology Assisted Review (“TAR”) to filter out non-responsive documents.

b) Each party will provide a list of proposed document custodians and non-custodial document sources (e.g., centralized document sources other than an individual document custodian's files) reflecting those employees or sources most likely to have non-duplicative information and/or documents responsive to an agreed-on or Court-ordered scope of Rule 34 Requests. A person is a custodian of only those documents that he or she created or owns; a person is not a custodian of a document to which he or she merely had access.

c) If, after the parties identify initial document custodians, a requesting party reasonably believes that additional document custodians or sources should be added, then the requesting party shall advise the producing party in writing of the proposed additional document custodians or sources and the basis for the request. The parties will meet and confer about the proposed additional custodians. Any disputes over additional custodians that cannot be resolved between the parties during meet and confer may be presented to the Court in accordance with the Judge Gilliam or Judge Beeler's applicable standing order.

d) Each party will use its best efforts to filter out common system files and application executable files by using a commercially reasonable hash identification process. Hash values that may be filtered out during this process are located in the National Software Reference Library (“NSRL”) NIST hash set list.

e) Each party is required to produce only a single copy of a responsive document. Each party may de-duplicate ESI based on MD5 hash values at the document level across custodians. For emails with attachments, the hash value is generated based on the parent/child document grouping. To the extent that de-duplication through MD5 hash values is not possible, the parties shall meet and confer to discuss any other proposed method of de-duplication. A producing party will make a reasonable effort to identify all custodians who were in possession of any de-duplicated documents through an appropriate load file field such as DuplicateCustodian or CustodianAll/Other. Additionally, all BCC recipients whose names would have been included in the BCC metadata field, to the extent such metadata exists, but are excluded because of horizontal/global de-duplication, must be identified in the BCC metadata field specified in Appendix 1 to the extent such metadata exists.

f) Where multiple email messages are part of a single chain or “thread,” a party is only required to produce the most inclusive message and need not produce earlier, less inclusive email messages or “thread members” that are fully contained, including attachments and including identical senders and recipients, within most inclusive message. Only email messages for which the parent document, all attachments, and sender/recipients are contained in the most inclusive message will be considered less inclusive email messages that need not be produced.

6. PRODUCTION FORMATS

a) Electronic Files. The parties agree that all documents existing in electronic format shall be produced as black and white Group IV single-page TIFF image files of at least 300 dpi resolution. Page size shall be 8.5 x 11 inches unless, in the reasonable judgment of the producing party, a particular item requires a different page size. Each image file will use the Bates number of the page as its unique file name. Images shall show all text and images that would be visible in the original native format. Original document orientation as displayed in the native file should be maintained in the TIFF image (e.g., portrait to portrait and landscape to landscape). The parties shall provide image load files in Concordance (.OPT) format so as to facilitate the use of the produced images by a document management or litigation support system. The extracted, relevant metadata should be provided in a Concordance .DAT format. The full text of each electronic document shall be extracted from the native file (“Extracted Text”) and produced with each text file corresponding to a single document in the production. The Extracted Text shall be ASCII text format (or Unicode text format if the text is in a foreign language) and named with a unique Bates number (i.e., the unique Bates Number of the first page of the document followed by .txt).

b) Hard Copy Files. The parties agree that all documents that are hardcopy or paper files shall be scanned and produced in the same manner as ESI. The parties will use reasonable efforts to unitize documents correctly. Distinct documents shall not be merged into a single record, and single documents shall not be split into multiple records.

c) Native Files. The parties agree through the pendency of this litigation to exercise reasonable efforts to maintain all collected native files that may be relevant to this litigation in a manner that does not materially alter or modify the files or the metadata. The parties agree to produce Microsoft Excel or other spreadsheet files, Microsoft PowerPoint files, and other files not reasonably usable when converted to TIFF image in their native electronic format. Native files should contain the Bates number and confidentiality designation of the file in the file name. In addition, native files should be accompanied by an image (TIFF) placeholder that contains “File Produced in Native,” the beginning Bates number and confidentiality designation. The parties may elect to utilize native redaction software tools to apply redactions directly to a native spreadsheet and produce a redacted native file instead of a redacted TIFF image of a spreadsheet. Wherever feasible, the producing party shall include accompanying metadata in the load file. Either party may request the production of file or files in native format where appropriate. If a dispute arises with regard to requests for the production of files in native format, the parties will meet and confer in good faith to try to resolve the dispute.

d) Parent-Child Relationships. Parent-child relationships (the association between an attachment and its parent document) shall be preserved whenever reasonable in such a way that a document and any attachments to that document are produced in the same production set and are identifiable as parent and child.

e) Embedded or Linked Objects. Certain documents may be embedded within other documents (e.g., a spreadsheet embedded within a Microsoft PowerPoint document). Subject to claims of privilege and, as applicable, files with embedded objects shall be extracted as separate files and shall be produced as attachments to the file in which they were embedded.

f) Metadata Fields. Each of the metadata and coding fields set forth below that can be extracted from a document shall be produced for that document, to the extent already in existence and reasonably accessible or available. To the extent that metadata does not exist, is not reasonably accessible or available, or would be unduly burdensome to collect, such data need not be produced. The parties are not obligated to populate manually any of the fields below if such fields cannot be extracted from a document, with the exception of the following fields: (1) BEGBATES, (2) ENDBATES, (3) BEGATTACH, (4) ENDATTACH, and (5) Custodian, which may be populated by a party or its vendor. These metadata fields shall be provided for hard-copy documents that have been scanned in and are denoted by an asterisk (*) below. Any metadata fields for redacted documents that would reveal privileged information shall be excluded. With the exception of any metadata generated by the Parties' respective counsel for the purposes of litigation, and except as provided herein, all metadata associated with each “native” ESI file shall be provided, including without limitation:

• BEGBATES*
• ENDBATES*
• BEGATTACH*
• ENDATTACH*
• PAGECOUNT
• CUSTODIAN*
• ALLCUSTODIAN
• RECORDTYPE
• DOCUMENTTYPE
• SENTDATE
• SENTTIME
• BEGINDATE
• BEGINTIME
• ENDDATE
• ENDTIME
• TIME ZONE
• Family Sort Date
• NativeLink
• AUTHOR
• FROM
•CC
•TO
•BCC
• SUBJECT
• TITLE
• FILENAME
• FILEEXT
• FILESIZE
• DATECREATED
• DATELASTMOD
• TIMELASTMOD
• NATIVELINK
• TEXT

g) Color. Documents containing color need not be produced in color in the first instance. However, if good cause exists for the receiving party to request production of certain documents in color, the receiving party may request production of such documents in color. The producing party shall not unreasonably deny such requests.

h) Structured Data. Discovery in this matter may include the production of structured data (i.e., quantitative data organized in a formatted repository or database). Prior to the production of any structured data, the parties will meet and confer regarding the dataset to be produced. The producing party will generate a sample report of any structured data in a .CSV file or other mutually agreeable file format, as well as provide any available data dictionary or schema that describes the contents, format, and structure of the structured data being produced.

7. PHASING

When a party propounds discovery requests pursuant to Fed.R.Civ.P. 34, the parties agree to phase the production of ESI by producing documents on a rolling basis. Following the initial production, the parties will continue to prioritize the order of subsequent productions.

8. DOCUMENTS PROTECTED FROM DISCOVERY

Nothing in this Order, including the application of search terms or other ESI filters, requires disclosure of irrelevant information or relevant information protected by the attorneyclient privilege, work-product doctrine, or any other applicable privilege or immunity. The parties do not waive any objections to the production, discoverability, admissibility, or confidentiality of documents and ESI.

a) Pursuant to Fed.R.Evid. 502(d), the production of a privileged or work-product-protected document, whether inadvertent or otherwise, is not a waiver of privilege or protection from discovery in this case or in any other federal or state proceeding. For example, the mere production of privileged or work-product-protected documents in this case as part of a mass production is not itself a waiver in this case or in any other federal or state proceeding.
b) The parties agree to follow Magistrate Judge Beeler's procedures governing the production of privilege logs. Communications involving in-house or trial counsel that post-date the filing of the complaint need not be placed on a privilege log.

9. MODIFICATION

This Stipulated Order may be modified by a Stipulated Order of the parties or by the

Court for good cause shown.

IT IS SO STIPULATED, IT IS ORDERED.


Summaries of

Crowder v. LinkedIn Corp.

United States District Court, Northern District of California
Feb 23, 2023
4:22-cv-00237-HSG (N.D. Cal. Feb. 23, 2023)
Case details for

Crowder v. LinkedIn Corp.

Case Details

Full title:TODD CROWDER, KEVIN SCHULTE, and GARRICK VANCE, on behalf of themselves…

Court:United States District Court, Northern District of California

Date published: Feb 23, 2023

Citations

4:22-cv-00237-HSG (N.D. Cal. Feb. 23, 2023)