Mike Pasque and Joel Henry – Law Technology Today https://www.lawtechnologytoday.org From the ABA Legal Technology Resource Center Fri, 15 Jan 2016 19:54:27 +0000 en-US hourly 1 https://wordpress.org/?v=5.4.1 Metadata: Is It Really Worth It? https://www.lawtechnologytoday.org/2016/01/metadata-really-worth/ https://www.lawtechnologytoday.org/2016/01/metadata-really-worth/#respond Tue, 12 Jan 2016 13:00:00 +0000 http://www.lawtechnologytoday.org/?p=4722 The different types of metadata and what you should know about them.

The post Metadata: Is It Really Worth It? appeared first on Law Technology Today.

Many attorneys consider metadata a must have piece of e-discovery, but in fact whether this “data about data” provides useful information in most cases tends to be misunderstood. The already startling cost of e-discovery is keeping pace with evolving technology ensuring that vast amounts of metadata exist. Certainly metadata can contain useful, even case-critical, information but just because it exists doesn’t mean that you need it to support your case. In the end you should only demand or agree to produce costly metadata when such data is truly imperative to providing information which bolsters a successful and cost-effective argument for your case.

Metadata Simplified

Computer applications typically translate user input into the information you see on a computer screen. A Microsoft Word document is a simple example: what you see on the screen is the result of a user inputting characters into the application, usually through a keyboard or stylus. However, there is background data that the application uses which is not visually presented, this is metadata. Depending on the file, this metadata can contain information about who created the file, on what computer, at what time, as well as who last updated or printed the file. In our Word example, other data includes detailed “track changes” information, comment fields, and hidden text fields. With emails, metadata can contain information about when the email was created, when it was sent, the recipients it was sent to (including all blind carbon copy recipients), and even when the email was delivered. Metadata is not an all-encompassing term, the above examples are contained within various types of metadata, thus it is important to understand what those types are. The Southern District of New York examined metadata thoroughly in Aguilar v. Immigration & Customs Enforcement Division, looking at case law, the Federal Rules of Civil Procedure, and the Sedona Principles. From this, the Court defined three types of metadata: substantive, system, and embedded.

Substantive metadata is commonly referred to as application metadata and is “created as a function of the application software used to create the document or file.” In other words, this metadata includes features like the history of changes made to a document, paragraph spacing information, and how fonts are displayed. System metadata is the type of information most people think of when they hear the word “metadata.” This type of data includes file names, creation date, last edited date, the user who last saved the file, etc. Lastly, embedded metadata captures the hidden information within a document such as spreadsheet formulas, hyperlinks, geographical coordinates in a photo, and hidden columns.

It is important to understand these types of metadata so you know what to ask for during a meet and confer conference. Simply asking for “metadata” might result in any one of these three being produced. This tactic can be detrimental considering that courts often deny subsequent requests for metadata as a violation of Fed. R. Civ. P. 34(b)(2)(E)(3). Being specific will ensure you get the metadata you need. Likewise, if you are the producing party, having a specific type of metadata to go after will help reduce costs and time spent finding that data. Practice tip – come to an agreement with opposing counsel during the meet and confer conference to avoid costly battles over whether metadata production is required or warranted.

Federal courts across the country have ruled differently on when and whether metadata production is an absolute requirement. Professor James Moore has noted that “[t]he courts appear to be moving toward a general presumption against the production of metadata.” This presumption against production reflects the fact that metadata often fails to provide truly relevant information; in other words, metadata very rarely actually changes what is already known about the case or a set of documents or emails. On the other hand, when parties have agreed to produce metadata, then courts are likely to compel production of metadata “unless it finds such production to be overly burdensome or costly.”

Costs of Metadata

The production of metadata has two costs, real and practical. The real costs of metadata production include the actual cost imposed on either the producing or requesting party to get the data. In a very simple case, where standard file types like spreadsheets and word processing documents exist, producing the native file will include the substantive, system, and embedded metadata (assuming the native files were preserved properly in the first place). If you follow the suggestion of one of our previous articles and produce in the native format, then you may be wondering where the additional cost comes from. There are two instances where the cost of metadata production will always present a significant hurdle. The first is when the file is in an industry specific or proprietary format and the second is when the original file is buried in backup storage (offline disks or drives).

Files in industry specific or proprietary formats present a number of difficulties. Companies may utilize systems that are either uncommon to the general public (industry specific systems), or completely unavailable to the public (proprietary systems), which would make delivery of the native file completely useless to the receiving party because the files cannot be opened, viewed, or printed. Imagine if someone gave you an eight-track tape today, it would be completely unusable to the average person. The Federal Rules of Civil Procedure provide an avenue to ensure that this type of electronically stored information (“ESI”) is provided in a format that is “in a reasonably usable form.” Abiding by this rule, in the case of proprietary data, often results in documents being provided in a PDF or TIFF file. While this ensures the receiving party will be able to read the document, it makes collecting the metadata a headache since the original file’s metadata is not provided with PDF or TIFF files. These industry specific or proprietary formats prevent the requestor from reading the native file, necessitating the producing party to export the metadata from each file manually; a process that will be both time intensive and costly, as well as complex and sometimes error prone.

A file buried in an image backup (a bit by bit duplication of a hard drive or disk) can also present significant production hurdles. A file can become solely contained within an image backup after data has been purged from a local system but saved to backup medium, this is what IT personnel might do when you request a legal preservation hold. Even more common is when data is still within the company’s data retention period, but the local user updates or deletes the file, here the only copy of the file may exist on a weekly backup tape. If you know the document exists, but must resort to digging it out of a backup, there is a tremendous cost associated with locating and extracting that file from the larger backup image. This is partly due to keeping backups economically feasible, the only way to control cost is to compress all files when stored on backup media (as more space costs more money), which requires expanding upon retrieval, making it exceedingly difficult to sift through this data to find the desired file. These “archiving systems [are] described… as ‘business efficient, not litigation efficient,’ primarily designed for emergencies rather than searching and retrieving specific files, a process characterized as ‘neither fast nor cheap.’” A 2012 presentation by the Association for Information and Image Management estimated that while “it costs about 20 cents a day to buy one gigabyte of storage… it costs around $3,500 to review that same gigabyte of storage.” So if your file is buried within a 30 gigabyte backup storage tape, it could cost $105,000 just to find what you are looking for.

Practical costs are easier to understand. When producing ESI you likely have no idea how much metadata exists or, even scarier, what it contains. One example of a practical cost includes the additional privilege and confidential review of metadata, requiring knowledgeable attorneys who understand how metadata is presented. These associated aspects of production (i.e. review before release, creation of a privilege log, etc.) grow the practical costs of metadata production.

The actual cost of metadata production varies case-by-case, making it nearly impossible to be able to tell an attorney what they will save by excluding metadata from production. In one example, the defendant had already spent $3 million on e-discovery production before being asked for the metadata of the documents already produced. The additional cost to produce the metadata was calculated to be about $500,000, which was 1/6th the overall e-discovery cost. While this figure might be lower if metadata had been requested at the outset, it demonstrates the significant cost to provide metadata.


Whether or not metadata should be included in an e-discovery request depends on the facts and circumstances of the case. As a practical matter, you should carefully consider if any of the three types of metadata might provide information key to your case. If the authenticity of a file is likely not to be questioned or all of your ESI consists of Microsoft Word files created on a known set of computers, metadata may not be warranted. However, if you have a complex case involving financial records, with spreadsheets and databases, metadata will likely help you understand what those documents mean and how the information, values, and calculations were derived. Similarly, if your case depends on tracking which employee e-mailed certain documents to whom, when, and why, metadata may be useful in answering these key questions.

So when is it useful to explore if metadata is worth the cost and effort? The general rule is that the more complex and interactive the computer program, the more likely metadata will actually help you understand what the program did in relation to each user and each piece of data or file. It is more often than not that simple applications, like word processers, presentation software, and scanned files, will yield very little value in metadata production and will waste enormous amounts of time and money for both producing and receiving parties.

[1] 255 F.R.D. 350 (S.D.N.Y. 2008).
[2] Id. at 354 (citing The Sedona Principles, Second Edition: Best Practices Recommendations and Principles for Addressing Electronic Document Production).
[3] 7 J. Moore, Moore’s Federal Practice § 34.12[3][c], at 34-48 to 34-49 (3d ed. 2012).
[4] Law Technology Today, Native Format: You and Opposing Counsel’s Best Friend, lawtechnologytoday.org, http://www.lawtechnologytoday.org/2015/10/native-format (last visited Dec. 20, 2016).
[5] Fed. R. Civ. P. 34(b)(2)(E).
[6] RAND Corp., Where the Money Goes Understanding Litigant Expenditures for Producing Electronic Discovery, rand.org, http://www.rand.org/content/dam/rand/pubs/monographs/2012/RAND_MG1208.pdf (last visited Dec. 20, 2015).
[7] Ralph Losey, Metadata and E-Discovery, floridalawfirm.com, http://floridalawfirm.com/ West.Metadata.Chapter.pdf (last visited Dec. 20, 2015).


https://www.lawtechnologytoday.org/2016/01/metadata-really-worth/feed/ 0
What You Probably Don’t Know About Keyword Searches https://www.lawtechnologytoday.org/2015/12/what-you-probably-dont-know-about-keyword-searches/ https://www.lawtechnologytoday.org/2015/12/what-you-probably-dont-know-about-keyword-searches/#respond Thu, 03 Dec 2015 13:00:53 +0000 http://www.lawtechnologytoday.org/?p=4549 Behind the scenes of your keyword searches.

The post What You Probably Don’t Know About Keyword Searches appeared first on Law Technology Today.


There are also unknown unknowns. There are things we don’t know we don’t know. —Donald Rumsfield

Keyword searches embody this remark; it is easy enough to enter words that make sense to you as being associated with what you want to find, but the truth is keyword searches only find some data in e-discovery. If you don’t know exactly what you are looking for, and all the words that were used in communicating information, then a keyword search will likely leave relevant data hidden from your view.

How Keyword Searches Fail

A keyword search is a basic search technique, where the user enters words into a search engine and is provided with a list of all of the documents that contain those specific words. Think of the last time you used your favorite internet search engine to find crock pot recipes. Here, your keywords are crock, pot, and recipes, and you probably get a lot of websites that contain… you guessed it: recipes for crock pots! What keyword searches won’t find are those documents that are related to the words that you are searching for. That isn’t a fault of keyword searching, as those searches are performing exactly as designed; it’s the fault of the user expecting that search to do more—to find other items the user wants, for example slow cooker meals.

Unfortunately, attorneys may find documents through a keyword search that relate to their case, but fail to find the other documents that contain relevant information.  Worse yet, the attorney assumes no other documents exist or, if they do, have no idea how to search for those additional documents. In our crock pot example above, the search will leave out potentially relevant terms such as slow cooker, meal, and beef stew. It is easy to fall into the trap of using keyword searches to guess what other documents may contain because—according to Nat’l Day Laborer Org. Network v. United States Immigration & Customs Enf’t Agency, 877 F. Supp. 2d 87, 108 (S.D.N.Y. 2012).—“…searching for an answer on Google (or Westlaw or Lexis) is very different from searching for all responsive documents in the FOIA or e-discovery context.”

It is easy to run into other issues when using keyword searches in more complex matters, like litigation. The data searched may include everyday e-mails and documents that contain jargon, slang, acronyms, punctuation, and misspellings that a keyword search simply will not find. Again, in our crock pot example, that keyword search may miss the obvious trademarked term crock-pot due to the hyphen.

If you’re asking yourself why anyone would ever use a keyword search in an e-discovery issue, you are not alone. Courts have weighed in on this issue, Judge Facciola opined:


Judge Andrew Peck, the federal judge who first approved technology assisted review, also eloquently stated:

“In too many cases, however, the way lawyers choose keywords is the equivalent of the child’s game of ‘Go Fish.’ The requesting party guesses which keywords might produce evidence to support its case without having much, if any, knowledge of the responding party’s “cards” (i.e., the terminology used by the responding party’s custodians). Indeed, the responding party’s counsel often does not know what is in its own client’s ‘cards.'”

Alternatives to Keyword Searches

I can hear it already, “Ok you’ve convinced me to stop using keyword searches, but what do I look for in my next e-discovery solution?” The two most popular alternatives used in e-discovery are predictive coding and concept searching. While both processes are complicated, and would take an entire law journal article to explain just one, we provide a brief overview of each below.

Predictive coding has been the buzz word in e-discovery over the last few years. This method uses humans to review small portions of large datasets in an attempt to train the computer to find similar documents based on characteristics of those marked relevant by the reviewer. The reviewer marking the training set used by the computer will typically be a lawyer intimately familiar with the case, to ensure the intricacies of that case are identified. The predictive coding algorithm will identify different sets of data based on how the reviewer categorizes that data (i.e. relevant or non-relevant). Eventually the user will be presented with a smaller “relevant” subset of data and a larger “non-relevant” pile. How long the lawyer physically trains the system depends on the accuracy of the reviewer and the acceptable cost/benefit level the law firm and client have identified for that particular case.

In contrast to predictive coding, a concept search does not require the user to train a computer system. While there are several categories of concept searches, latent semantic indexing is a commonly used one. This technique is based on the assumption that words used in the same contexts will likely have similar meaning. Latent semantic indexing does what keyword searches cannot do; it finds groups of words that a human reader would likely relate to the keyword being searching for, even if the specific keyword is not located within the document at all. Continuing with the crock pot recipe example, documents might contain slow cooker, beef stew, and ingredients which a human reader could reasonably relate to the keywords crock pot recipe without having to actually contain those keywords. The methods a reviewer uses to accomplish this vary from algorithm to algorithm, but the basics remain the same.


At the 2012 LegalTech conference, Judge Peck stated, “Keyword searching is absolutely terrible, in terms of statistical responsiveness.” While keyword searches might be appropriate in certain cases, when you are faced with large amounts of data that you know nothing about, instead of playing Go Fish with your client’s data and money, ditch the keyword searches and invest in technology that will help you find those documents that you didn’t even know existed.



A Primer on Using Electronic Redaction https://www.lawtechnologytoday.org/2015/11/a-primer-on-using-electronic-redaction/ https://www.lawtechnologytoday.org/2015/11/a-primer-on-using-electronic-redaction/#respond Fri, 13 Nov 2015 13:30:28 +0000 http://www.lawtechnologytoday.org/?p=4397 Redaction can be one of the most important, and sometimes the most costly, part of document review.

The post A Primer on Using Electronic Redaction appeared first on Law Technology Today.


No matter your choice of discovery tools, one thing remains the same: redaction. Redaction removes privileged or protected information prior to production to opposing counsel. Redaction can be one of the most important—and sometimes the most costly—part of document review. Unfortunately, as the volume of data continues to rise, so will the cost to redact.

While this may seem like a trivial subject, the problems with redacting electronic documents have made big news. Take, for example, the study by Timothy Lee of the federal judiciary’s PACER system. Instead of focusing on documents that should have been redacted, he focused on documents that had been redacted where the actual redaction itself was unsuccessful, meaning the redacted data still existed in the document and could be retrieved. Out of the 1.8 million documents analyzed, 194 had failed redactions. This study does not even count those documents where information had failed to be identified as requiring redaction altogether (a study by Carl Malamud found 1,600 out of 2.7 million  cases in the PACER system that contained information like Social Security numbers, with no attempt whatsoever to redact them).

Don’t Waste Time, Redact Electronically

No half-decent lawyer needs to be reminded that responsive documents (i.e. relevant and discoverable) can contain privileged, confidential, or private information that should be redacted. This process of redacting in the paper world involves teams of lawyers, with black markers in hand, who spend countless hours scouring documents for information to redact. While this process should change in the e-discovery world where technology assists legal teams every step of the way, often responsive documents are printed, redacted, and then scanned back into TIFF or PDF format for production instead. If you don’t redact electronically stored information (“ESI”) in its electronic form, you consume large amounts of time, as well as clients’ money.

At the very core of the issue, redacting ESI manually on paper defeats the entire purpose of e-discovery. Being able to filter, search, review, and produce information with the aid of technology allows the e-discovery process to move efficiently while still protecting your clients’ rights and your obligations as a lawyer. Electronic redaction allows you to produce documents to opposing counsel in whatever form agreed upon in the meet and confer discovery conference (often native or near-native form) along with all metadata if necessary. The most successful e-discovery software vendors recognize this and offer redaction as part of their software solutions. These solutions allow redacting the native file while keeping the original file protected in order to review and defend redactions. Why is this important? If you simply take the Word file that is responsive, and replace the Social Security number with “XXX-XX-XXX,” save the redacted file over the original, you will destroy the original file. This can result in spoliation issues, which come with stiff consequences such as adverse inference instructions, as well as making it impossible to defend the redactions as legally sound.

Additional Thoughts

Redacting information without a privilege log to describe why you redacted the information within your ESI puts your entire production at risk. Remember that the Federal Rules of Civil Procedure impose a requirement—Fed. R. Civ. P. 26(b)(5)(A)—that any withheld information be described, “in a manner that, without revealing information itself privileged or protected, will enable other parties to assess the claim.” While this language is not specific, it doesn’t mean that you can redact your ESI and refuse to explain why you did so. Almost all e-discovery solutions will offer a privilege log with its redaction functionality, however, if it does not, or if you are redacting with a program like Adobe Acrobat, it is important to remember that you need to log what was redacted.

Images within a document require human review or the use of special software that can recognize characters within images—optical character recognition (“OCR”). Your search for information within OCR’ed documents (image documents converted to documents containing the text within images) depends heavily on the quality of the OCR platform itself. Even the best OCR engine can misinterpret words, leading to failed searches for privileged or confidential information. This becomes especially important when using an automated redaction feature, as is common in the leading e-discovery platforms, which search for specific words or phrases. The safest approach to ESI that has been OCR’ed is to flag each document that requires redaction. This will allow you to ensure you manually oversee all redaction on these documents, reducing the chance of a missed redaction due to poor OCR. Requiring more eyes-on time for these documents may just save you that sanction, malpractice claim, or adverse inference in the future.


Electronic information continues to grow at an explosive rate, but that doesn’t mean you have to invest more time and money in the discovery process. Completing the e-discovery process with electronic redacting is a relatively easy process once you understand how to do it. Utilize all this great technology to your advantage. Not only will it save your firm time and money, it will save your client the same as well.


https://www.lawtechnologytoday.org/2015/11/a-primer-on-using-electronic-redaction/feed/ 0
Native Format: You and Opposing Counsel’s Best Friend https://www.lawtechnologytoday.org/2015/10/native-format/ https://www.lawtechnologytoday.org/2015/10/native-format/#respond Thu, 29 Oct 2015 12:00:12 +0000 http://www.lawtechnologytoday.org/?p=4311 How your files' data can help or harm you.

The post Native Format: You and Opposing Counsel’s Best Friend appeared first on Law Technology Today.

E-discovery can be a complicated process starting with the question of what format data must be in when exchanged. The most common, and least useful, way that data changes hands continues to be either in paper form, or scanned copies of that paper. Neither of these forms permits even a simple keyword search beyond the human “eye scan” of words on pages or a computer screen. In today’s world of technology, the choices in data production range from native, near-native, near-paper, or paper formats. But what do these all mean and what option should you choose?

Formats Defined

The aforementioned formats each have benefits and drawbacks. Before explaining why native and near-native formats will become your new best friend, a quick understanding of each is necessary.

Native production is the format used by the application that created the document.  For instance, when you create a document in Microsoft’s PowerPoint, the native format is a PPTX file; creating a document in Microsoft Word creates a DOCX file, etc.  Production in this format requires no conversion by the producing party, thus saving money in the short run. The receiving party may convert the format, if time, money, and technology make such a conversion advantageous.

The near-native format produces the data with as much original information as possible in a different, often more easily accessible file type. This can result in a partial loss of metadata (the “data about data”), but often the information counsel needs will still be available. For instance, Microsoft Exchange e-mails are not natively produced in the commonly referred to PST format; however it is a format that Exchange can export the true native format to, providing entirely all of the information as is contained in the true native format.

Near-paper and paper formats essentially limit production to the data that a user would see if they printed what they were viewing. The only difference is that near-paper produces this data in a scanned electronic format (i.e. TIFF, JPG, PDF), often without any ability to search for text within the document because the document has become, in essence, a photograph. On the other hand, paper production is a printout of that visual representation, likely delivered to your office in multiple boxes for you to sift through without the aid of technology.

The Case for Native Formats

While native format production may concern some lawyers for providing too much information, it can often be the only way to provide the scope of information discovery production requires. Most don’t realize that items like spreadsheets have a lot of data behind what is presented to the user (i.e. the users sees the result of a calculation but not the formula used to calculate this result). In a business or financial case, the formulas that create values in the spreadsheet often will be more critical to the case than the calculated results presented to the user on the screen. Neglecting to provide this data can often land you with costly reproduction of the native data, or even sanctions by the court.

In some instances, near-native format production yields similar results to native format, and will be preferred. The most notable is e-mail production from Microsoft Exchange platforms. Email exported to a PST file produces a near-native format; however is commonly referred to as native by attorneys. For reviewers of data, the ability to analyze a PST is much more efficient and cost-saving than going through thousands of e-mails in TIFF or PDF form. Given thousands of e-mails containing multiple responses flow between email users each day, working with a PST file affords both sides the ability to understand email threads and purge duplicate messages during review saving time and money. Additionally, PSTs, like many near-native formats, still allow the user to examine most, if not all, of the increasingly important metadata.

Native format allows electronic evidence to be preserved without degradation. However, when reviewing in the native format, you should be careful to only review copies of the original files. This is especially important for the producing party, since altering the native file, even accidentally, can alter both data and metadata resulting in inadvertent evidence tampering. An easy way to avoid this pitfall is to review your data with e-discovery software tailored for that purpose. The top vendors of this type of software ensure that users are only working with copies of data when performing functions like marking, reviewing, and redacting. Additionally, these powerful tools allow reviewers to search through both the presented data and the metadata; preventing the producing party from inadvertent disclosure of privileged or confidential information and making it efficient for the receiving party to search through the evidence.

Attorneys continue to provide electronic data in either paper or near-paper forms because that is how it was always done. Yet the benefits of native and near-native production often outweigh the costs. Authenticating evidence is easier, costly conversions to TIFF and PDF files are avoided, evidence manipulation through tampering decreases, and review by both parties becomes more efficient. Most e-discovery software also allows for redaction and Bates stamping from the native dataset for an easy transition to the courtroom environment. In the end, native formats provide a greater benefit to both producing and receiving parties and will quickly become your best friend, no matter what side of the aisle you sit.


https://www.lawtechnologytoday.org/2015/10/native-format/feed/ 0