April 01, 2008

Paperless depositions

Picture_2I don't use paper in depositions.  If I'm taking the deposition I cheerfully agree to have the deposition held in my opponent's office, asking him or her to make sure to have the case documents available and organized by bates-number.   If you can't count on an attorney to have lots of paper what can you count on?

I have my deposition notes set up in an outline on my computer.  When I get to a place that calls for me to talk about a certain document I inform my opposing counsel what the document bates-number is, and ask him to show it to the witness.  I have all the documents bookmarked in Acrobat.  It takes me about 3 seconds to get to the document, and I make good use of the time it takes my opponent to pull the document and show it to the witness.  I have notes superimposed on the PDF and I examine those and get ready to frame my questions.  At the end of the deposition I don't offer any documents as exhibits.  If opposing counsel asks me why I'm not doing that I tell him that the bates-numbers (which I announced on the record before starting my questions about each document) constitute sufficient reference.

If I'm attending a deposition it's even easier.  When a document is offered I ask what the bates-number is and I just pull it up, much more quickly than if I were to wait for it to be handed over.  Plus I have my PDF notes superimposed on my copy which helps me quickly figure out the relevance of the document to my theory of the case.   And of course I can add more notes on the fly if I want to.  I also bookmark the document and indent it under a main bookmark labelled for the deposition in question.  So when the deposition is over I have a listing of all the documents that were referenced in that meeting.

It's not as high-tech as this paperless deposition system, but it doesn't need to be.  Often the best solution is the simplest one, and I think that's true for Adobe Acrobat.  It does a lot of things pretty darn well, and since I use it all the time I'm very familiar with its organization.  Next time you take a deposition consider how much smoother it could be if you didn't have to deal with paper. 

Of course, if you have a deposition like this one it wouldn't matter.

09:22 AM in Acrobat 8.0, Bookmarks, Discovery, Observations re: technology, Workflow | Permalink | Comments (5)

January 17, 2008

States adopt E-Discovery rules

Here's a list of the states that have adopted E-discovery rules.  This list is pretty long, and will undoubtedly be growing rapidly.

03:44 PM in Discovery | Permalink | Comments (0)

August 07, 2007

Controversy over the "Send to FedEx" feature in Acrobat

Last week we reported on the "Send to FedEx/Kinkos" function in Acrobat 8.1.  Now it appears that, because of complaints by printing organizations, Adobe and FedEx will no longer partner to offer this feature.  In October, when Adobe releases new versions of Acrobat and Reader, the 'Send to FedEx/Kinkos" link will be removed, although a separate version of Reader will be available from FedEx that will contain this functionality.  Hopefully, FedEx/Kinkos will also create a plug-in for Acrobat that enables the "Send to" feature.

09:50 AM in Acrobat 8.0, Discovery, PDF: Intermediate, Workflow | Permalink | Comments (0) | TrackBack

August 01, 2007

"Send to FedEx/Kinkos" from within Acrobat

Picture_6 I just noticed that in Acrobat 8.1 (I have the Mac version, but it works with Windows too) I have the choice while viewing a PDF to "send the document to FedEx/Kinkos" for printing.  I have a FedEx/Kinkos about 5 minutes away from my house.  Sometimes I when I've needed to print out large document sets for discovery production, and the most effective way to accomplish this was to go to FedEx/Kinkos store.

Now I don't have to get in my car to submit my job.  I can just use the handy "send to FedEx Kinkos" option from within Acrobat.  How does it work?

Once your document has been uploaded your browser will be directed to the FedEx/Kinko's webpage where you can set print options, preview your document, select pickup and delivery options, and pay (of course).  The file size limit is 100 MBs, and it only works in version 8.1 of Acrobat.  They'll even ship the job to whomever you designate when the job is complete. Orders without special instructions take a minimum of 4 hours to produce, and orders with special instructions take a minimum of 10 hours to produce.

More Information: FedEx/Kinkos Webpage Explanation
                                   FedEx/Kinks FAQ Page

UPDATE:  It appears that, because of complaints by printing organizations, Adobe and FedEx will no longer partner to offer this easy solution.  In October, when Adobe releases new versions of Acrobat and Reader, the 'Send to FedEx/Kinkos" link will be removed, although a separate version of Reader will be available from FedEx that will contain this functionality.

11:13 PM in Acrobat 8.0, Discovery, Workflow | Permalink | Comments (0) | TrackBack

Civil Subpoena Form for Federal Court

If you need to fill out a subpoena form for use in a federal court proceeding, feel free to use this one.  I found it by simply searching online.  It has form fields, and even includes a place for a digital signature.  As much as I love digital signatures, I wouldn't use the digital signature in most cases because it looks strange to most people. 

12:55 AM in Discovery, Forms, Workflow | Permalink | Comments (0) | TrackBack

May 21, 2007

Bates-Stamping Documents the easy way

Paper Whenever I see a set of documents that has been bates-stamped by hand, I cringe.  The only place that one should be able to see that kind of thing is in a museum.  And, yet amazingly, you can see it any day of the week in a typical law practice.  What's so bad about bates-stamping documents by hand?

First, it's mind-numbingly tedious work.  Which means that the poor paralegal that has been assigned to do it is probably going to make a mistake.  Most importantly, it takes a really long time to do it by hand.  Frankly, if I was a corporate client I would add a section to my standard terms of representation stating that I refuse to pay for paralegal time associated with bates-stamping.

Let's say you have 1,000 documents to bates-stamp.  I seriously doubt that any paralegal could finish the task in less than 4 hours.  It would probably take at least a day, maybe more.  But to scan those documents would only take about an hour, maybe two hours if you had a really slow scanner.  Once you've scanned the documents it takes about 30 seconds to bates-stamp them using Acrobat 8.0.   

Using a computer to bates-stamp ensures that you don't miss any pages.  And you can tell Acrobat to shrink the borders of the page and apply the bates-stamp in the resulting white area.  This guarantees that the bates-number on every page is visible.  Also you can add text before or after the bates number, (e.g. as "2nd Production - No. 000345").  Finally, if you realize you made a mistake and included some pages that should not have been bates-stamped, you can remove the bates-stamping and start over.

So all you have to do is scan the documents first.  And this is a good thing.  Because, as an added bonus, you have not only bates-stamped your documents, but now you have them in digital form.  Then if you want to make the documents searchable (and, trust me, you want to do this) you can OCR them first.   Let me emphasize this point: OCR before you bates-stamp the documents.  Otherwise, for reasons I won't get into, you won't be able to OCR the documents later (but, as I said, you can remove the bates-stamping, OCR, and then bates again). 

In short, there's a smart way to bates-stamp documents, and a really stupid way. Why anyone would want to make someone bates-stamp documents by hand is beyond me.  Frankly, I think it should be considered a form of cruel and unusual punishment.  Apparently, though, it's not all that unusual. 

And that is really sad.

12:57 AM in Acrobat 8.0, Discovery, PDF: Advanced, Workflow | Permalink | Comments (7) | TrackBack

April 02, 2007

E-Discovery News

Check out this article entitled "Incorporating EDD into Your Depositions - the 5Ws of EDD Depositions," by Tom Mighell, Dennis Kennedy and Evan Schaeffer.  Lots of great practical tips.

09:43 PM in Discovery | Permalink | Comments (0) | TrackBack

December 20, 2005

Electronic Discovery Primer for Judges Available in PDF

David Isom has an article in the Federal Courts Law Review that provides an excellent overview of electronic discovery (circa January 2005). On the first page is a link to download the article in either PDF or WordPerfect format.

The PDF is a nicely laid out article, the links (mostly to Westlaw cites) work, and there are bookmarks for navigating the 43-page document. It appears to have been generated by WordPerfect (the metadata says it was created by the Corel PDF Engine). I would be interested to know if WordPerfect generates the bookmarks and other links, similar to the PDFMaker macros in MS Word.

This article would be a good place to start using your PDF-fu, for example, by adding newer cases, marking it up with some comments and notes, and adding it to your reference library (which you are indexing for super-fast search).

~~ Dave

08:57 AM in Discovery | Permalink | Comments (1) | TrackBack

January 31, 2005

Why PDF #3 -- The Unified Document Theory

When I first started doing discovery using electronic documents -- about 10 years ago -- the industry practice was to scan paper documents to TIFF images. The docs were then sometimes put through the Optical Character Recognition (OCR) process to make them word-searchable. In addition, a bibligraphic database was hand coded so that it was possible to search for a document by author, addressee, date, or some other field that had been included in the bib database. The vagaries of both the OCR and biblio databases can wait for another time... but the problems were many and the costs were high.

Most frustrating to me, however, was the fact that, having gone to all this trouble, each document was split in a least three pieces -- the images (often kept on optical jukeboxes because hard drive capacities were orders of magnitude smaller) from which you could view or print an exact copy of the original; the text (often kept in a litigation support database like Summation or XyIndex); and the metadata (in a bibliographic database such as FoxPro, Lotus Notes, or something similar). Then there was the custom code that tied all these pieces together, so that you could do word searches, and then view the images on which there were hits.

A recurring complaint from many lawyers was that when you did a full text search, you couldn't see your hits on the document itself -- because the text was separate from the image. There was a plethora of proprietary image viewers, few of which were either fast or stable. None were free.

It was frustrating to have documents in pieces so that you could not take a subset of electronic documents -- say documents relating to a specific witness or issue -- and share them with someone on the team (like an expert witness) that didn't or shouldn't have access to the entire document system. In order to have any access to the system, a person needed to have all of the software, as well as the image files, OCR text database, and biblio database (plus the code that glued them all together). Most maddening to me was the fact that, once having identified such a set of documents, about the only thing I could do was to print them, thus coming full circle to a stack of paper. Not searchable, no metadata -- just paper.

All of which led me to team up with some techies to try to create a litigation management system that would solve these (and other) problems. I came up with a design for something we coined a "SmartDoc." It would have the image, text and metadata all in one file. You could view thumbnails, so that you could visually identify pages. It would support hyperlinking within the documents, and to other items in the database. It would be smart enough to know when it had been produced in discovery, which witness files it was in, and whether it was privileged. It could be encrypted and password protected at the document, not the database, level. We worked on this problem for awhile with very limited success, and then went on our way to solve a few other problems of the day (locating docs via GIS, developing a timeline interface for case development, and other sci-fi scenarios).

By the time I got back to the SmartDoc idea, Acrobat 4 was out. And there it was -- image, data and metadata all in one unified package. You could search it and see your hits on the page. It had built-in metadata fields, and you could basically add whatever metadata you wanted. It could be hyperlinked, automated, and password protected. The "big iron" search engines we preferred could index it (hell, it included the Verity search engine). The viewer was free.

Despite my enthusiasm for the format, some in litigation support had objections. Some thought PDF files were too big. ("Compared to what?" I would ask. "The TIFF file alone, or the whole shebang?") Cost was also an issue since Adobe was basically charging by the page for its Acrobat Capture OCR product. However, my crude ROI calculations led me to conclude that over the life of a case, using PDF would pay for itself many times over in database costs and attorney time alone. Not to mention copying and storage of all the duplicates you had to print in order to distribute documents.

In the time that has elapsed since then, the case for PDF in litigation has only strenghthened. At the core, I still like the fact that a PDF can be a "unified" document. It has the image, text, and metadata all in one file. Moreover, in the time since I started on the quest for the "SmartDoc," corporate enterprises, the courts, government agencies, and yes, even some lawyers, have adopted PDF as a standard. Adobe says it has distributed 500 million copies of the Reader. A PDF can be a smart, self-contained document.

In future posts, I'll talk about the reasons NOT to accept PDFs from the other side in discovery.

-- Dave

07:39 PM in Discovery | Permalink | Comments (0) | TrackBack