How Should Productions of Mobile Device Messages Be Formatted?

As mobile device sources have rapidly increased in number and importance, practitioners are struggling more often with the question of what format to use for such productions

Mobile devices have become frequent sources of relevant ESI in litigation.  According to one litigation trends survey, roughly half of all litigation matters in 2015 and 2016 involved preservation and/or collection of mobile device data.  Of the mobile device sources implicated in 2016, 93% were smartphones.  In its 2019 Report on Industry Trends for Law Enforcement, Cellebrite (maker of forensic tools for mobile devices) found that smartphones were far and away the most common source of digital evidence with 91% of “Investigator” respondents indicating that smartphones were “Very Frequent” (81%) or “Frequent” (10%) sources.

As mobile device sources have rapidly increased in number and importance, practitioners have struggled to adapt to these evolving expectations and challenges.  Among those challenges is the question of what format to use for the production (or request) of mobile device data.

What Kind of Data Is Being Produced from Mobile Devices?

In Riley v. California, 573 U. S. 373 (2014), the Supreme Court summed up the kind of all-encompassing data source that smartphones have become: “. . . it is no exaggeration to say that many of the more than 90% of American adults who own a cell phone keep on their person a digital record of nearly every aspect of their lives – from the mundane to the intimate.”  A single smartphone will routinely contain thousands upon thousands of unique records, including: phone-specific materials, mobile application and Internet materials, and traditional office documents.  Despite this great volume and diversity, however, it has so far been text messages (including SMS, MMS, and OTT messages) that have been relevant most often.

What Makes Mobile Device Message Production Complicated?

Production of mobile device messages is complicated for a three main reasons:

• First, mobile device data collection is accomplished using specialized collection kits akin to those used for forensic acquisitions from computers. After collection, the acquired files must be exported from the acquisition software for incorporation into your project workflow for assessment, review, and production.  Unfortunately, it is common for these tools to output all of the files as a single exported document (e., a long multi-page PDF or large multi-tab spreadsheet).  These files are not generally conducive to convenient review or production, and if you wish to break those concatenated records out into individual files, additional work (or a specialized software solution) is needed.

• Second, a clear standard has not yet emerged for how best to format such productions, with some parties and courts insisting on native files with metadata, others pushing for near-native options that are optimized for display and review (e., simulating chat bubbles or other contextual elements), and others seeking near-paper productions of page images with metadata and extracted text (like those used for email productions). On a technical level, there is also more variability among review platforms and providers with regard to text and chat message handling, with some treating them the same as other types of documents and others offering dedicated viewers with emoji support and specialized features.

• Third, a clear standard has not yet emerged for how best to handle the unitization of messages and threads. Should each individual message be treated as an individual document?  Should distinct threads be treated as individual documents instead?  If so, should they be complete or broken into separate records by date?  Should the whole message database be treated as a single record from which irrelevant messages can be redacted?  Currently litigants are working through these questions on a case-by-case basis (with limited guidance from the courts, as we will discuss below).

What Do the Rules Say About ESI Production Formats?

Under the Federal Rules of Civil Procedure, litigants are directed (in FRCP 26(f)(3)) to negotiate about “the form or forms in which [ESI] should be produced” as part of their overall 26(f) meet and confer process.  During this process, litigants are free to negotiate whatever stipulated production formats and specifications they wish for relevant mobile device messages.

If nothing is negotiated in advance, FRCP 34(b)(1)(C) allows the litigant requesting production of ESI to “specify the form or forms in which [ESI] is to be produced.”  The requesting litigant is free to ask for whatever production formats and specifications they wish, though the responding litigant is also free to object and propose an alternative (FRCP 34(b)(2)(D)).

When no ESI production format has been stipulated through negotiation or specified in the request, FRCP 34(b)(2)(E)(ii) specifies that “a party must produce it in a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms.”  This translates to a choice between producing ESI in its native format or in some other reasonably usable form or forms, which typically means near-paper or near-native format, accompanied by a load file with relevant metadata, searchable text, etc.

Courts have emphasized the importance of maintaining searchability and sortability in assessing whether a given production format is “reasonably usable” under the rules.  In David A. Johnson & Alda, Inc. v. Italian Shoemakers, Inc., Case No. 3:17-cv-00740-FDW-DSC (W.D.N.C. Oct. 22, 2018), the plaintiffs repeatedly produced emails in PDF format rather than in native format with metadata, as required by the applicable discovery order.  In its analysis, the court explained that the requirement in FRCP 34(b)(2)(E)(ii) to produce ESI “in a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms” is satisfied “when the party provides documents that are searchable and/or sortable by metadata fields” [emphasis added].

What Have Cases Said About Mobile Device Message Production?

In, Laub v. Horbaczewski, 331 F.R.D. 516 (C.D. Cal. Apr. 22, 2019), several disputes arose related to the production of relevant text messages and “iNotes” from the defendant’s iPhone, and among them was a dispute over the appropriate format in which to produce such materials.  The Magistrate Judge reviewed the relevant rules and committee notes and came to the same conclusion as in the case above: that searchability is central to reasonable usability under the rules: “Further, ‘[i]f the responding party ordinarily maintains the information it is producing in a way that makes it searchable by electronic means, the information should not be produced in a form that removes or significantly degrades this feature,’” [emphasis added; citation omitted].

In reaching this conclusion, the Magistrate Judge, also reviewed prior case examples in which parties were directed to “produce any relevant text messages in native format or in another format agreed to by the moving party” and to “produce these text messages in a form that shows the sender, recipient, time, and date the messages were sent, as required by the Federal Rules of Civil Procedure.”  She also stated a clear preference for producing in “aggregated” formats in which the various individual messages could be seen in context with each other, preserving “the integrity of the threads of communication reflected in the text messages” [emphasis added].

So, How Should You Request Mobile Device Message Production?

Based on the limited guidance available, it is clear that a litigant could propose or request production of mobile device messages in a few different ways that would all preserve searchability and sortability, as well as thread relationships.  When choosing how you wish to proceed from among these options, there are four main considerations to bear in mind:

1. You will want to request either native files, near-native files, or near-paper image files, and regardless of which, you will want to request with them a load file containing metadata and extracted text

2. You will want to request the inclusion of attachments (e.g., images, animations, etc.) and the documentation through metadata of their relationships to specific messages

3. You will want to request your preferred handling of message unitization and thread documentation (e.g., handling each message as an individual record with a custom metadata field documenting thread groupings, producing complete threads together as single documents, producing threads divided up by days, etc.)

4. You will want to request your preferred metadata fields to ensure you have the information you need to work with the produced materials in your preferred manner; kinds of fields to consider requesting include:

• General Information Fields: Custodian, Attachments, Time Zone, From, To, Date/Time Sent, Date/Time Received, File Name, Message Text

• Mobile Messaging Information Fields: Application, Account, User Name, Chat Room/Channel Name, Participants, Thread Group

• Procedural Information Fields: Hash Value, Request Number(s), Search Term(s)

For Assistance or More Information

Xact Data Discovery (XDD) is a leading international provider of eDiscovery, data management and managed review services for law firms and corporations.  XDD helps clients optimize their eDiscovery matters by orchestrating precision communication between people, processes, technology and data.  XDD services include forensics, eDiscovery processing, Relativity hosting and managed review.

XDD offers exceptional customer service with a commitment to responsive, transparent and timely communication to ensure clients remain informed throughout the entire discovery life cycle.  At XDD, communication is everything – because you need to know.  Engage with XDD, we’re ready to listen.