5. Searches During EDRM Workflow Steps

Each step in the EDRM workflow requires deploying certain search techniques to speed up and automate the process. This section illustrates, with an example, how search is incorporated into the EDRM workflow.

5.1. Brief Background

This scenario involves two companies, Alpha Corporation and Beta Corporation, fierce competitors of one another in the field of Web-based record-keeping and analysis of insurance claims for medical treatments. Alpha has developed a technological advantage over Beta with its new Web 2.0 MedicEye monitoring technology – a combination of hardware, software, data storage and various analytical methodologies.

Alan Baker, a software developer and former employee of Alpha, has recently moved to Beta. Alan worked on a portion of the software development for Alpha’s MedicEye. Beta has refused to comment on the hire, but Alpha suspects that Alan was hired to work on Beta’s development of a competing offering. Alpha also suspects that Alan copied and took with him to Beta large amounts of source code, planning documents, financial analyses and market studies. Alpha further suspects that Beta has directed certain unnamed persons to hack into Alpha’s computer system and obtain copies of some of the same sorts of materials Alpha suspects Alan has taken.

Alpha is based in Palo Alto, CA, and has offices in Chicago, Houston and Tokyo. Beta is based in Boston, MA and has offices in New York City, Paris and Abu Dhabi. For each company, most of the relevant documents and communications are in English, but some potentially important hard-copy materials and electronically stored information (“ESI”) are in the respective local languages of each of the various non-U.S. offices.

5.2. “Early” Early Case Assessment

Proux LLP Receives Miscellaneous ESI Collected by Isis LLP During Its Internal Investigation for Alpha’s Board of Directors

Proux LLP is one of Alpha’s regular outside counsel. On June 1, 2008, Paula Proux, a partner with Proux LLP, receives a call from Alex Arnold, General Counsel of Alpha. Alex tells Paula a little about Alpha’s situation, including Alan’s move from Alpha to Beta and Alpha’s suspicion that Alan, and perhaps others at Beta’s direction, have improperly taken copies of Alpha proprietary materials.

Alex also informs Paula that over the past several months, Ivan Isis from Isis LLP has been conducting an internal investigation for the Audit Committee of the Alpha Board of Directors, has interviewed a number of people, and has “informally” collected some hard-copy documents and ESI from a range of sources. Alex asks Paula to assemble a team, review the materials already collected, identify and interview potential witnesses, analyze the situation, and advise Alex how Alpha should proceed.1

Over the next several weeks, Ivan Isis from Isis LLP provides Paula with the following fruits of his internal investigation:

  • A binder of short reports on interviews of key Alpha personnel, including a small number of relevant emails and related documents (in hard-copy form).
  • A series of emails attaching a variety of ESI – other emails with attached documents, zipped folders containing numerous emails and attachments, and a range of other loose ESI (Word documents, Excel spreadsheets etc.).
  • Three DVDs containing largely (but not completely) overlapping sets of the ESI collected during the investigation.

The ESI in the emails and on the DVDs does not appear to be organized in any structured manner, nor does it include information about custodians or source folders/machines. Ivan Isis did not include, and as far as Paula can determine has not prepared, any additional record of what data was collected, from what sources, using what technologies, or any other information about the ESI collection process.

Paula needs to coordinate a review and analysis of the ESI received from Ivan Isis. Among other things, she needs to create a record of what ESI she has received, what ESI she has reviewed (including her team’s use of search queries), and what her assessments are.

Paula and her team retain an e-discovery vendor to help them analyze and review the ESI received from Isis LLP.

Processing & Analysis

Since the ESI has already been collected and the team does wish to perform a formal multi-person review, the evaluation of ESI at this stage of the case comprises the Processing and Analysis stages of the EDRM model. The e-discovery vendor processes the various sources of ESI so that it is possible to analyze and view the data within an e-discovery software application that has search and analysis capabilities.

Processing involves extraction of email container files and archive files (e.g. zip files) so that each individual item is cataloged and its associated meta data is captured. Indexing is also performed in order to allow for searching the full text of the documents. At this point, Paula and the vendor agree that they will perform limited searching and filtering as part of processing, only deciding to exclude certain operating and application files which are identified as being part of the NIST list.

Once processing is complete, Paula asks one of Proux’s associates, Patricia Polk to analyze the ESI. Patricia decides to perform some simple keyword searches including:

  • MagicEye
  • Betacorp or Beta Corp
  • The names of all the known parties including Alan Baker, Alex Arnold and Ivan Isis.

After running each of these searches, Patricia reviews some of the documents that the application’s search engine has ranked highly based on their relevance ranking algorithm. The documents returned by the above search criteria confirm the information gained from some interviews that employees also refer to this project as “Project Magic.”

Patricia also uses the application’s social network analysis capability which automatically performs searches in order to identify who was talking to whom. In particular, Patricia wants to find out who Alan has been emailing.

Patricia notices from some of the filters or faceted search capabilities that the data contains foreign languages and identifies some additional important email addresses.

Based on their review of this preliminary data, and several follow-up interviews of Alpha employees, they learn:

  • The MedicEye project is referred to inside Alpha as “MedicEye” or “Project Magic” or “Magic”.
  • Alan Baker worked at Alpha from January 1, 2005 until May 1, 2008. His email address was bakera@alphatech.com. He also has a Yahoo account: ohnonono@yahoo.com.
  • Work on the MedicEye project began on January 1, 2004.
  • Other Alpha employees who work or worked on the MedicEye project include – but may not be limited to – the following:
    • Aileen Arvidson of the Business Development Department (arvidsona@alphatech.com) (January 1, 2004 to date).
    • Anton Agnew, a software programmer in the Software Development Department (agnewa@alphatech.com) (March 15, 2005 to date). He is sometimes referred to as “AA” or “A.A.”
    • Audrey Astor of the Marketing Department (astora@alphatech.com) (June 1, 2006 to date).
    • Aki Arata of the Business Development Department in the Tokyo office (arataa@alphatech.com) (September 1, 2005 to date). He does his work both in English and in Japanese.
  • While he was still employed by Alpha, Alan Baker may have been in touch with several people at Beta:
  • Alex Arnold, General Counsel of Alpha, had some involvement in the internal investigation after Alan Baker moved from Alpha to Beta. His email address is arnolda@alphatech.com.
  • Ivan Isis of Isis LLP, who carried out the internal investigation, may have corresponded by email with people inside Alpha. His email address is Ivan_Isis@IsisLLP.com.

5.3. More Traditional Early Case Assessment

Proux LLP Undertakes an Organized Collection and Analysis of Alpha’s ESI (i.e., a more traditional early case assessment)

Based on the findings of the internal investigation and the interviews and ESI analysis that Patricia has performed, Alpha decides to proceed further with the case. Paula drafts a demand letter to Beta. Alex and Paula also decide to undertake a formal collection and analysis of Alpha’s ESI in order to perform a comprehensive early case assessment. Alpha wants additional information before deciding to file a complaint.

After further discussions with Alpha personnel, Paula and her team learn that Alpha’s ESI includes the following:

  • 1 Microsoft Exchange server.
  • 1 Lotus Notes server.
  • 20 unlabeled backup tapes suspected of including email backups from 1/1/00 – 12/31/07.
  • A complete set of email backup tapes from 1/1/08 forward – daily, weekly and monthly.
  • 2 eRoom sites.
  • 5 software programmers in Palo Alto and Chicago (including Anton Agnew) with ThinkPads running XP Pro.
  • Personnel in the Marketing Department and the Business Development Department with Dell laptops running XP Pro.
  • Networked file servers in Palo Alto and Tokyo containing source code, planning documents, financial analyses and market studies in English and Japanese.
  • 20 unlabeled backup tapes suspected of including Palo Alto and Tokyo server backups from 1/1/00 – 12/31/07.
  • A complete set of Palo Alto and Tokyo server backup tapes from 1/1/08 forward – daily, weekly and monthly.

Using the preliminary facts gathered thus far, Paula wants to

  1. Identify, collect and preserve potentially relevant data, and
  2. Carry out searches to identify and review potentially relevant data and isolate potentially privileged communications and documents.

Identification, Preservation, Collection, Processing and Analysis

The evaluation of ESI at this stage of the case involves many more of the stages of the EDRM model. She recognizes that in almost every phase of this process search will be an essential element.

Identification – As part of identification, Paula and Patricia begin to formalize who from Alpha and Beta are custodians of data relevant to the case, what time period is critical to the case and what content on shared information stores might be relevant to the case. In order to identify the appropriate custodians, they use fielded search and/or social analysis on the ESI that was previously collected and analyzed and conduct additional interviews. They identify up to 30 likely custodians, of which 5 are designated as high priority. They conduct interviews with various Alpha IT personnel and identify the multiple sources of ESI listed above and the location of that data. For the backup tapes, they work with IT to conduct sampling to determine whether all of the ESI identified needs to be collected or whether it falls outside the scope of the case. In order to identify content on shared information stores including file servers and the eRoom sites, they develop a set of search terms including important people, topics and time frames. They use these to search both content and metadata, such as last modified date, on the file servers and eRoom sites. It is important that not only full documents are searched but also all associated metadata, which can show patterns of interaction and key points of activity.

Based on an analysis of metadata and the text searches against the eRoom data, they determine that the file servers contain relevant information but the eRoom sites were never used by Alan or anyone involved in the MagicEye development. The eRoom ESI is thus unlikely to contain information relevant to the case.

Preservation – Paula prepares and distributes a Litigation Hold letter to the relevant custodians and IT personnel to suspend destructive activities, isolate and protect potentially relevant data associated with the custodians or on relevant shared information stores. This preservation of data will create a static set that can be used moving forward for collection, processing and analysis of data.

Collection – In order to expedite the early case assessment and keep it within an agreed budget, the team decides to first collect the high priority custodians and ESI on the networked file servers that match a set of search terms and a date range. This collected data is copied to a dedicated server at Alpha and is submitted to the e-discovery Vendor for processing and additional analysis. The preservation set will be retained and returned to for additional search and collection activities once the selection criteria have been further refined.

Processing and Analysis – The procedure for processing remains the same as for the initial Early Case Assessment. Application and operating system files are excluded. Files within email container files and archive files (e.g. zip files) are extracted so that each individual item is cataloged and its associated metadata is captured. This data need to be formatted into a digital form that can be searched against in the next stage. It is also important at this stage that the search engine being used can support indexing and searching Japanese as well as English since key documents are composed in both languages. Any translation capabilities would also be important to use at this stage so that an English query could be translated to Japanese to search documents in that language. If anyone in question can speak Japanese they could have attempted to hide communication in this second language.

This is where she must begin to record all item-level metadata as it existed before moving to the processing stage. At this point, Paula is basically taking a snap shot of what the data looks like and identifying that at this point in time this is how the data looked like in relation to the queries executed against it. Here also, the exact date the query took place and the actual query term is recorded. These steps are all necessary in order to prove defensibility of the search criteria in court.

This is also the stage where entity extraction is best used. This means that specific heuristics are used to identify the people, places and things that are re-occurring within the collection set. It is also time to run de-duplication so that only a single instance of a document is processed for analysis. This is another stage where unrelated data can be removed from the collection set. For example, in the collection stage all emails sent and received in a specific date range may have been collected. Using search methods such as key terms or analysis tools like clustering may show which email is spam. Search criteria may then be developed to exclude these types of documents to ensure they do not go to the next stages of analysis or ultimately to review.

At this point in the project, the goal of this phase is not to collect all the data that are relevant to these key terms and individuals but rather to continue to identify a list of good key terms or fielded searches that can be used for the additional collection and processing needed once production requests are received and also to gather information regarding the issues of the case and the documents supporting same. The searches being developed can then be used either during the collection or processing phases to reduce the volume of data that must be reviewed by the case team.

There are several types of advanced search methods that can be used to identify hidden terms, unknown relationships or suggested other searches. These include such things as conceptual search, clustering and auto-classification. Conceptual search will identify related terms and bring searches back for those items. So perhaps through conceptual search they would identify other documents that had related terms. Clustering will automatically categorize result sets into hierarchical categories to demonstrate hidden relationships or identify groups of documents that may be irrelevant to the case. Then finally, using auto-classification all documents could be categorized again looking for hidden themes or eliminating irrelevant documents. All advanced search methods will help identify key terms or document types that may be used for additional collection and processing.

In addition to the advanced search technologies described above, Patricia also performs more traditional full text searches. Understanding that the project name is ‘MedicEye’ and the other nick name is ‘Project Magic’ is important. Using the same methodology for discovery as outlined above is critical for identifying additional keyword terms. Paula begins scanning documents and performing some general queries to see if the project has other code names. She also will be looking to see if any of the custodians have other names that they are referenced as or reference themselves as. Additional searches may be performed against multiple fields. An example is looking for emails sent by one custodian to another custodian within a specific date range containing a key term in the title. This is helpful to identify very specific document sets. It is also important to execute queries using a variety of query operators. This stage is helpful to do queries such as find “patent” within 8 words of “Project Magic” to find documents that have both terms in close proximity of another. Another, query type could be a wildcard to find cases where perhaps a misspelling has occurred. Detection of misspellings can be performed in an automated way or via manual searches, such as “Ma*c”. The query would find documents that have ‘Magic’, ‘Majic’, ‘Magc’ , etc. Care would need to be taken to exclude false positives such as magnetic. When typing quickly, letters are often left out of words or incorrectly typed. By testing these search criteria, Paula and Patricia can determine how effective their search criteria are in returning responsive documents.

The analysis stage is also the point where Paula must ensure that all assumptions are true in identifying critical metadata. For example, she must know that when searching exchange bcc’s are not always indexed and require specific mechanisms to extract this kind of data. She must also know that metadata used to describe content in eRoom might be stored in a separate system all together. It is critical that in the analysis stage all of these atypical behaviors are recognized and accounted for. This stage alone may take Paula the most amount of time to navigate through everything and begin building the case she needs in preparation of review.

Throughout this iterative process, the queries performed and the associated documents resulting from the particular queries should be captured and recorded to assist Paula and Patricia with the development of their searches but also to add to the defensibility of their process.

Once they complete their analysis above, Paula and Patricia develop and document an initial list of textual search terms, fielded search terms (like date range) and any other search methodologies that they would like to be used in the case going forward.

5.4. Preparations for Lawsuit

Beta Begins Preparations for a Possible Lawsuit after Receiving a Demand Letter from Alpha

Beta’s General Counsel, Bettina Bloch, receives a letter from Alpha’s outside counsel, Paula Proux, which describes Alpha’s understanding of the general facts of Alan Baker’s departure from Alpha and advises Beta that Alpha intends to take “whatever legal steps are available and necessary” to protect Alpha’s rights and interests.

Bettina Bloch meets with former Alpha employee Alan Baker, Beta’s CEO and several other senior Beta personnel, and with Diego Dominguez of Dominguez LLP, Beta’s regular outside counsel, to gather some preliminary facts and discuss how to respond to Alpha’s letter. Among other things, Bettina and Diego identify Beta employees who may have information, hard-copy documents or ESI regarding the issues raised by Alpha’s letter and they prepare and distribute a litigation hold notice to those Beta employees.

Based on their preliminary meetings, interviews and other inquiries, Bettina and Diego learn that –

  • The relevant facts include:
    • The Beta project intended to compete with Alpha’s MedicEye project is referred to inside Beta as “InsureTrak”, and sometimes as “Project AlphaBust”.
    • Alan Baker has worked at Beta since May 15, 2008. His Beta email address is bakera@betacorp.com. As Alpha learned, he also has a Yahoo account: ohnonono@yahoo.com.
    • Work on the InsureTrak project began on January 1, 2007.
    • Other Beta employees who work or worked on the InsureTrak project include – but may not be limited to – the following:
      • Bonnie Benson, Beta’s CTO (bonnie@betacorp.com) (June 15, 2006 to date).
      • Brad Boqin, head of Beta’s Special Projects Group (brad_boqin@betacorp.com) (September 1, 2005 to date).
      • Bashir Baktiar, a software developer in Beta’s Abu Dhabi office (bashir@betacorp.com) (November 1, 2004 to date). He does his work both in English and in Arabic.
      • Boris Bonaparte, a software developer in Beta’s Paris office (boris@betacorp.com) (April 1, 2006 to date). He is sometimes referred to as “Napoleon”. He does his work both in English and in French. He also maintains a set of Beta servers, located in the Paris office, which contain source code, personnel records (including Alan Baker’s), and Beta’s email (Microsoft Exchange).
    • Bettina Bloch, General Counsel of Beta, had some involvement in the recruitment of Alan Baker from Alpha. Her email address is bettina_bloch@betacorp.com.
    • Diego Dominguez of Dominguez LLP, Beta’s outside counsel, was also consulted in connection with Beta’s recruitment of Alan Baker. His email address is diego@dominguezesq.com.
  • Beta’s ESI includes the following:
    • 1 Microsoft Exchange server (located in the Paris office).
    • A complete set of email backup tapes from 1/1/03 forward – daily, weekly and monthly.
    • 7 software programmers in Boston, Paris (including Boris Bonaparte) and Abu Dhabi (including Bashir Baktiar) with ThinkPads running XP Pro.
    • Networked servers in Boston and Paris containing source code, planning documents, financial analyses and market studies in English and French.
    • A complete set of Boston and Paris server backup tapes from 1/1/08 forward – daily, weekly and monthly.

Using the preliminary facts gathered thus far, Diego Dominguez and his team want to

  1. Identify, collect and preserve potentially relevant data, and
  2. carry out searches to identify and review potentially relevant data, including isolating potentially privileged communications and documents.

Identification, Preservation, Collection, Processing and Analysis

The evaluation of ESI by Diego and his team also involves many more of the stages of the EDRM model.

Identification – Following their internal interviews, Diego and Bettina have developed an initial list of Beta employees that may have data relevant to the case, the critical time period and what content might be relevant.

Preservation – Diego prepares and distributes the Litigation Hold letter to suspend destructive activities, isolate and protect potentially relevant data. This preservation of data will create a static set that can be used moving forward for collection, processing and analysis of data.

Collection – Various search, sampling and analysis techniques may be employed against the preserved data set to analyze the documents that they have available regarding the facts at hand and also to begin the development of search criteria that they may use moving forward in the case.

As Alpha had previously done, Diego used fielded search and/or social analysis, to recognize who at Beta was in contact with and could present relevant details to the case.  Diego also performed similar searches for Bonnie Benson, Brad Boqin, Bashir Baktiar, Boris Bonaparte and Bettina Bloch as they were identified as persons with knowledge of the issues and potential custodians of relevant ESI.

Diego also created searches to identify the date ranges of emails sent during this time in question, documents created and even documents edited based on last modified date and time.

Once Diego developed an initial scope for the project, he contacted and hired his own e-discovery vendor and submitted the collected data for processing and additional analysis.

Processing and Analysis – The ESI collected for the preliminary group of custodians from the Beta’s much larger preserved data set is sent to their e-discovery Vendor for processing. The preservation set will be retained and returned to for additional search and collection activities once the selection criteria have been further refined.

The procedures and issues discussed above relative to processing are the same for Beta as they were for Alpha’s case assessment.  Beta now needs to identify and develop their own list of good key terms or fielded searches that can be used for the additional collection and processing needed once production requests are received and also to gather information regarding the issues of the case and the documents supporting same.  The searches being developed can then be used either during the collection or processing phases to reduce the volume of data that must be reviewed by the case team.

They used similar types of advanced search and full text searches as described above only targeted to their particular issues. For example, Diego created searches for “InsureTrak”, “Project AlphaBust” and “AlphaBust” and upon reviewing documents responsive to those queries may make further refinements to his search criteria.

Throughout this iterative process, the queries performed and the associated documents resulting from the particular queries should be captured and recorded to assist Diego with the development of his searches but also to add to the defensibility of his process.

5.5. Preparations for Meet-and-Confer

After Alpha Sues Beta in Federal Court (D. Md.), Outside Counsel for Alpha and Beta Prepare for and Engage in Rule 26(f) Meet-and-Confer Process

Outside Counsel should first familiarize themselves with the current case law and any local rules applicable to the discovery of ESI. In this case, the District Court of Maryland has a “Suggested Protocol for Discovery of Electronically Stored Information (“ESI”).”

5.5.A. Preparing For the Rule 26(f) Meet And Confer

In preparing for the Rule 26(f), the goals of Outside Counsel for Alpha and Beta should be to:

  1. Define the sources of and become familiar with potentially responsive information (i.e. systems, servers, custodians and documents);
  2. Understand their client’s ESI policies related to those sources of potential responsive information;
  3. Instruct their clients and the identified custodians about their preservation (i.e. “litigation hold”) obligations; and
  4. Determine how to identify responsive information (i.e. time restrictions, search methods, search terms, search results), including running preliminary searches to test adequacy of suggested approach.

(i) Alpha

Potential Sources of ESI. During its investigation, Proux identified the potential sources of ESI within Alpha as detailed above in Section 5.3.

Jurisdictional Issues. Potentially Responsive ESI may reside on networked servers in Japan. This raises jurisdictional issues that may come into play during discovery. Proux should begin the research and analysis of international laws and treaties applicable to obtaining this information within a foreign sovereign territory.

Document Retention Policies Related to Sources of ESI. Proux next needs to determine the back-up, retention and destruction policies related to this ESI. Questions to ask:

  • When was the policy implemented?
  • How is the policy enforced?
  • Has the policy changed during the relevant time period?

Proux’s investigation revealed that Alpha changed its backup tapes for both its email and networked servers on January 1, 2008. Proux needs to understand why this change was made and if the policy changed at the same time as well and, if so, how it changed.

Become Familiar with Current and Past ESI. Proux needs to gain an understanding, usually through the assistance of an Alpha employee(s), of how each source of ESI works, how it used by Alpha employees and which Alpha employees have access to this ESI.

Identify Key Witnesses and Key Custodians. Proux also identified the following Alpha employees that may either have responsive ESI related to the case (i.e. witnesses) or may be Alpha representatives that can assist Proux in understanding and accessing responsive ESI (i.e. custodians):

  • Alan Barker, former employee, Software Development Department
  • Aileen Arvidson, Business Development Department
  • Anton Agnew, Software Development Department
  • Audrey Astor, Marketing Department
  • Aki Arata, Business Development Department, Tokyo Office
  • Alex Arnold, General Counsel of Alpha (privileged)
  • Ivan Isis, Outside Counsel, Isis LLP (privileged)
  • Information Systems Custodian, Information Technology Custodian, Network Administration Custodian, Records Management Personnel

Suspension of Document Retention Policy and Litigation Hold. The scope of the suspension and hold will be based on the particular facts of a case. Here, Proux should suspend any overwrite, deletion and/or purging related to systems and servers identified in the investigation. The suspension and hold notifications should extend to all the ESI Proux identified in its investigation and should issue to the witnesses and custodians identified by Proux in its investigation.

Someone within Alpha legal should be designated as the litigation hold compliance officer who monitors compliance and who sends periodic reminders. Additionally, as the case develops the suspension and hold notices should be revisited both as to their scope as well as whether additional witnesses need to be added.

Preliminary Searches

Based upon the work that Paula and her team performed during their case assessment and the documentation created during the criteria development process, they shared with Beta what they felt were search criteria that could be effectively used to reduce the volume of data needed to be reviewed while returning relevant material.

(ii) Beta

Potential Sources of ESI. During its investigation, Dominguez identified the potential sources of ESI within Beta as detailed above in Section 5.4.

Jurisdictional Issues. Potentially Responsive ESI may reside on networked servers in Paris and Abu Dhabi. This raises jurisdictional issues that may come into play during discovery. Dominguez, like Proux, should begin the research and analysis of international laws and treaties applicable to obtaining this information within a foreign sovereign territory. Since both parties have jurisdictional issues, this issue should definitely be raised at the Rule 26(f) meet and confer.

Document Retention Policies Related to Sources of ESI. Dominguez next needs to determine the back-up, retention and destruction policies related to this ESI. Questions to ask:

  • When was the policy implemented?
  • How is the policy enforced?
  • Has the policy changed during the relevant time period?

Dominguez’s investigation revealed that Beta only has backup tapes for emails servers from January 1, 2003 and networked servers from January 1, 2008. This should not be a problem given the probable relevant time frame Beta may have obtained Alpha’s confidential information. However, Dominguez needs to understand the history of the email and network servers, including whether any information that pre-dates the back-up tapes is archived or stored in any manner.

Become Familiar with Current and Past ESI. Dominguez needs to gain an understanding, usually through the assistance of a Beta employee(s), of how each source of ESI works, how it used by Beta employees and which Beta employees have access to this ESI.

Identify Key Witnesses and Key Custodians. Dominguez also identified the following Beta employees that may either have responsive ESI related to the case (i.e. witnesses) or may be Beta representatives that can assist Dominguez in understanding and accessing responsive ESI (i.e. custodians):

  • Bonnie Benson, CTO
  • Brad Boqin, Special Projects Group
  • Bashir Baktiar, Software Developer in Abu Dhabi Office
  • Boris Bonaparte, Software Developer in Paris office(Note: Bonaparte is the custodian of email and network servers; he may also be a witness in the case. Dominguez should consider whether or not to suspend Mr. Bonaparte access to these servers during the pendency of the case).
  • Bettina Bloch, General Counsel (privileged)
  • Diego Dominguez, Outside Counsel, Dominguez LLP (privileged)
  • Information Systems Custodian, Information Technology Custodian, Network Administration Custodian, Records Management Personnel

Suspension of Document Retention Policy and Litigation Hold. The scope of the suspension and hold will be based on the particular facts of a case. Here, Dominguez should suspend any overwrite, deletion and/or purging related to systems and servers identified in the investigation. The suspension and hold notifications should extend to all the ESI Dominguez identified in its investigation and should issue to the witnesses and custodians identified by Dominguez in its investigation.

Someone within Beta legal should be designated as the litigation hold compliance officer who monitors compliance and who sends periodic reminders. Additionally, as the case develops the suspension and hold notices should be revisited both as to their scope as well as whether additional witnesses need to be added.

Preliminary Searches

Based upon the work that Diego performed during his case assessment and the documentation created during the criteria development process, he also had developed a list of search criteria that he felt should be performed.

5.5.B. The Rule 26(f) Meet And Confer

Proux and Dominguez have engaged in a thorough early case assessment and preparation and are now ready for a meaningful Rule 26(f) conference to set the stage for discovery in this matter.

The primary goals of the meet and confer process should be to:

  1. Agree to terms of appropriate protective order;
  2. Agree to technical form of production, including provisions for native files, static files, metadata, redaction and identifying labeling such as bates-stamping;
  3. Possible exchange of sources of ESI, including technical specifications and identification of ESI “not reasonably accessible” and potential cost-shifting, discuss scope of suspension of document retention and litigation hold; an
  4. Agree on search methodologies and search terms.

Protective Orders. The parties should discuss the terms of a protective order given that this matter concerns Alpha’s trade secrets. One of the most critical provisions concerns the protocol for handling the inadvertent production of privileged information. Rule 502 of the Federal Rules of Evidence now provides statutory protections against the inadvertent production of ESI and should be considered when drafting this provision of the protective order. Additionally, if meta-data is going to be produced, the parties should discuss how to handle, including an agreement not to view meta-data or specific types of meta-data without notice to the producing party.

Technical Form of Production and Limits on Initial Scope of Discovery. The parties should agree to whether production will be static (.pdf, .tiff) image or native image. If native files will be produced, the parties need to consider how to handle meta-data and redactions of meta-data or native files. The parties need to discuss the method of identifying documents produced (e.g. Bates stamping or renaming native files with a numbering system).

The parties also need to consider the scope of discovery requests, including an initial focused stage of discovery. For example, the parties might limit their initial search of ESI to that which is reasonably accessible. This might mean initially searching (a) only the on-line email server and network server; or (b) the local drives and email accounts of the witnesses identified in Proux and Dominguez investigations; or (c) only the complete sets of backup email and network tapes from January 1, 2008 forward.

Sources of ESI, Hold Policy and ESI “Not Reasonably Accessible”. Proux and Dominguez might agree to exchange the technical details of Alpha’s and Beta’s information and network systems that might contain responsive ESI. The parties could also exchange the key custodians identified in their respective investigations. The parties should exchange each other’s litigation hold policy in order to identify any objections early-on to what information is, or is not, being preserved. The parties might also consider preliminary custodian of record depositions related to the collection of ESI.

The parties should also discuss the types of ESI that might be “not reasonably accessible” and any associated costs related to the preservation, retrieval and production of ESI “not reasonable accessible.” For example, Alpha has unlabeled backup tapes from both email and network servers that might contain responsive ESI. The Beta investigation revealed that it only has server backup tapes from January 1, 2008 forward. Alpha may want to inquire about the accessibility of server ESI that pre-dates 2008.

Search Methodologies and Search Terms. The parties should discuss and agree on proposed search methodologies (e.g. keyword, Boolean, concept). Restrictions and limitations on the search methods, documents searched and time frames should be discussed. A set of common keywords could be proposed by each side and agreed upon. The parties could also agree to an initial sampling of ESI returned from the common search terms.

Both parties exchanged and discussed their initial criteria that each side had developed during their case assessment process.

Both parties agreed upon a list of custodians to be collected and also the date ranges to be applied. A method of sampling was also discussed relative to the many backup tapes that both parties had within their ESI. It was felt that there would be a large amount of duplication would be contained within the sets but that sampling would be performed to determine the volume that needed to be restored and collected from the preservation sets.

Each side also had suggested changes to the search criteria to be used and agreed to run the modifications against the sample data that they had already processed to provide them with an opportunity to review the requested changes and to determine the effectiveness of those changes.

During this sampling exercise, Alpha found that several of Beta’s requested terms contained wildcards that returned an overly broad set of results that did not return a high percentage of responsive documents. They then provided alternate search criteria created to address the issue and were able to negotiate an agreed upon list of terms with Beta with the understanding that as additional data was processed and anomalies were found within the results that either side could request additional negotiation of the search criteria.

Also, both sides requested that a sample of documents be reviewed that are not hitting on any of the search criteria to determine whether any of those documents are responsive and, if so, additional criteria will need to be developed to capture those items.

5.6. Requests & Responses

Alpha and Beta Run Searches, Propound Discovery And Produce ESI

Based upon the parameters established in the Rule 26(f), Alpha and Beta both propound discovery requests. Each company uses the agreed upon searches to review results and produce ESI.

Collection, Processing, Analysis, Review and Production

The evaluation of ESI at this stage of the case involves different stages of the EDRM model as well as additional iterations through many of the stages already discussed. Identification and Preservation were already completed by both parties during their initial case assessments.

Collection – Although they had collected certain data sets to be used with their case assessment processes, there was now a larger volume of data that needed to be collected for processing due to the agreed upon searches and the discovery requests.

Processing – The mechanics of processing, particularly as they relate to searching, have already been discussed during the Alpha and Beta case assessments in Section 5.3 and Section 5.4.

Now that the case is entering a much larger scale review process, classification criteria may be used by either of the case teams to organize the documents in review to assist with the review process. One of the most common types of classification criteria are those searches developed to identify potentially privileged documents. Attorney names, law firm domains and other common terms may be used to identify these documents. Exclusionary criteria may also be used if a privilege term is found to be overly broad. For example, if the term “privileged and confidential” were to be used it is quite often found in email footer language and the search term may need to be modified to exclude those items where the term is found only in the footer but capturing other instances of the phrase.

Analysis & Review – In addition to the use of classification criteria, many of the same advanced searching methodologies that were discussed earlier (e.g. conceptual search, clustering and auto-classification) may be used during the review process to assist reviewers in making consistent review calls across the larger review set.

Also, during review feedback relative to search criteria should be provided to the case team. The reviewers may find that certain searches are yielding a large volume of non-responsive documents. Samples of the documents should be reviewed and modifications to the criteria may be made to limit those types of documents.

Additionally, reviewers may find new issues that need to be addressed by search criteria that are not contained within the current search criteria lists.

Production – once the review completes, or as agreed upon during the 26(f) productions will be made to the opposing side.

Use Case Scenario – Actors

PlaintiffDefendantUnaffiliated Third Parties
Party:Party:
Alpha CorporationBeta Corporation
Current employees: Current employees:
Anton Agnew (formerly James Winston)Alan Baker (former Alpha employee) (formerly Alan Adams)
Aki Arata (formerly Yoshi Tanaku)Bashir Baktiar
Alex Arnold (General Counsel) (formerly Larry Landry)Bonnie Benson (formerly Rona Roberts)
Aileen Arvidson (formerly Susan Smith)Brad Boqin (formerly Joe Liu)
Audrey Astor (formerly Ellen Eleanor)Boris Bonaparte
Alpha’s outside counsel:Beta’s outside counsel:
Proux LLP (formerly Law Firm 1)Dominguez LLP
Paula Proux, PartnerPatricia Polk, AssociateDiego Dominguez
Counsel for Audit Committee investigation:
Isis LLP (formerly Law Firm 2)
Ivan Isis
  1. As we’ll see, Alpha ultimately sues Beta in the U.S. District Court for the District of Maryland – chosen because of the illustrative value of its “Suggested Protocol for Discovery of Electronically Stored Information” – and this suit proceeds far enough for us to illustrate the various EDRM/litigation steps for purposes of the Search Project’s work.
Print Friendly, PDF & Email