Recovering Costs on Pacer/ECF Systems

By Erik Adams, Email: eadams at sheppardmullin.com

Erik Y. Adams is the Electronic Services Librarian at Sheppard, Mullin, Richter and Hampton in Los Angeles, where he develops web applications and does the same sort of stuff law librarians everywhere do. He is a certified dot-com survivor, having spent 4 years bouncing from one unprofitable company to another. He received his MLIS from UCLA in 1995, back when the "blink" tag had just been invented.

Introduction

This article documents techniques for creating a simple web application that will populate the user name, password, and client id for a PACER or CM/ECF docketing system. At my firm we have derived several benefits from doing this:

• Secretaries can pull dockets for cases without having to have their own ID or know a shared id
• Our application requires users to enter a client ID, which has led to a significant increase in our recovery of costs of PACER charges
• Most of our PACER searches are being done on a single ID, which has greatly simplified billing

Parts of this article are somewhat technical in nature. I have assumed a basic knowledge of HTML and Internet terminology, and tried to explain everything else. If anything is incomprehensible please feel free to contact me and let me know.

It should be pointed out that this is not something that the courts support. I contacted them asking for an opinion, and was rebuked with a statement that they don't help law firms with their intranets. It is entirely possible that the courts will change something on their systems and the methods described here will stop working.

At the end of this article I include a link to sample programs that implement what this article describes. I offer these samples to help people create applications on their own intranet, but make no guarantees or warranties. They worked when I tested them, and didn't damage any systems I ran them on. Your mileage may vary.

Into the Breach

The most basic web application has two components: an HTML form for gathering data, and a program of some kind that processes the form data. After processing, the program may output an HTML document or may redirect the browser to another web page.

This is how the login screens for the PACER and CM/ECF web sites work:

• The user accesses a web page on the court's web site with fields for the user name, password, and client id.
• That form data is then submitted to a program, also on the court's web site, which checks that the user name and password are valid.
• If everything is ok, the browser is redirected to the system's main search screen.

The web application we have built takes the place of the PACER login screen. Our users access an web page on our intranet server, enter a client identifier, and select the court they want from a pop-up menu. That page submits its data to a program, also on our intranet, which validates the client number and then redirects the user to the appropriate PACER or CM/ECF system, passing along the login information and the validated client number.

To the end user, the process is completely transparent; a client number is entered, a court selected, and a moment later they are logged in and searching a PACER system.

There are two ways for an HTML form to submit data to a script: get and post. Data submitted via the get method appears in the URL, as in

	http://intranet/pacer_script.cgi?username=jdoe&password=fnord&client=rroe

Data submitted via the post method is passed from the browser to the web server behind the scenes. There isn't much difference between the two methods, but both the PACER and CM/ECF systems require that login information be submitted via the post method. Which means that strictly speaking the program on our intranet doesn't perform a redirect; it outputs an HTML form that is basically a modified and condensed version of the form found on the PACER or CM/ECF web sites. The two main differences are that all of the form elements are both pre-populated and hidden, and the form contains a little bit of Javascript that causes the form to be submitted automatically to the court's web server.

These modified forms are tailored to each court's docketing system. As of this writing, there are three different systems in use: two versions of PACER and one version of CM/ECF. The only way to tell the difference between them is to visit the court's login web page and view the HTML source. Look for the <input ... > tags and check the name elements, as in:

	<input type="text" name="username">

Each system has slightly different names for user name, password, and client
identifier; also, the PACER systems have additional hidden elements. These differences are documented, in detail, below.

PACER, first kind

The first type of PACER system is the one used by the Southern District of California. The main login screen for this PACER system can be found at https://pacer.casd.uscourts.gov/dc/pacer150.html. On this page, the user name is called "loginid", the password is "passwd", and the client identifier is "client". There is also a hidden form element named "newloc", which always seems to have the same value, "/dc/cgi-bin/pacer250.pl". Our script outputs an HTML document that looks like this:

	<html>
	<head></head>
	<body onload="document.forms[0].submit();">
	<form method="post" action="https://pacer.casd.uscourts.gov/dc/cgi-bin/ChkPasswd.pl">
	<input type="hidden" name="loginid" value="[ user name ]">
	<input type="hidden" name="passwd" value="[ password ]">
	<input type="hidden" name="client" value="[ client identifier ]">
	<input type="hidden" name="newloc" value="/dc/cgi-bin/pacer250.pl">
	</form>
	</body>
	</html>

The Javascript on this form has been tested and is known to work on Internet Explorer, Netscape (and its Mozilla brethren), and Safari (for all you Macintosh users out there.)

PACER, second type

The second type of PACER system can be found at the California Central District Bankruptcy Court, Los Angeles Division's web site at https://pacer.login.uscourts.gov/cgi-bin/login.pl?court_id=CACBLA. On this type of system, the user name, password, and client have the same names as the other kind of PACER system. However, there are two hidden input tags: "appurl", which is always blank, and "court_id", which will have a different value depending on the court. For the Los Angeles Bankruptcy Court, the value is "CACBLA". Our script outputs a form that looks like this:

	<html>
	<head></head>
	<body onLoad="document.forms[0].submit();">
	<FORM METHOD="post" ACTION="https://pacer.login.uscourts.gov/cgi-bin/check-pacer-passwd.pl" NAME="f_login">
	<INPUT type="hidden" name="loginid" value="[ user name ]">
	<INPUT type="hidden" name="passwd" value="[ password ]">
	<INPUT type="hidden" name="client" value="[ client identifier ]">
	<INPUT type="hidden" name="appurl" value="">
	<INPUT type="hidden" name="court_id" value="CACBLA">
	</FORM>
	</body>
	</html>

ECF Courts

The ECF courts are a little more complicated than the PACER courts. Such is the march of progress, I suppose.

The Northern District of California Bankruptcy Court is an ECF court, and its login page can be found at https://ecf.canb.uscourts.gov/cgi-bin/login.pl. The user name is called "login", the password is called "password", and the client identifier is called "clcode".

What makes the ECF courts more complicated is that embedded in the login page is an ID number that is generated each time the page is loaded. Before our script can generate a form to automatically log in a user, it has to get that ID and submit it along with the other login information. Fortunately, the ID number is always embedded in the "form" tag on the login page, and it's pretty easy to write a program that retrieves the login page and finds the ID. Once you've got the ID, you can output an HTML form like this one:

	<html>
	<head></head>
	<body onLoad="document.forms[0].submit();">
	<FORM METHOD="post" ENCTYPE="multipart/form-data" ACTION="https://ecf.casb.uscourts.gov/cgi-bin/login.pl?[ ID number ]" name="f_login">
	<INPUT type="hidden" name="login" value="[ user id ]">
	<INPUT type="hidden" name="key" value="[ password ]">
	<INPUT type="hidden" name="clcode" value="[ client id ]">
	</FORM>
	</body>
	</html>

Conclusion

In the best of all worlds, as Dr. Pangloss might say, the courts would support account management features that are common in the commercial world, including:

• multiple login IDs on one account, to simplify billing
• IP based authentication, to get rid of the ID problem altogether
• client ID masking, so not only could we require our users to enter a client identifier but also get it in the right format

But they don't. So, we have to add those features on our own and hope the courts don't do something that breaks them.

Samples

Code samples can be found at http://home.earthlink.net/~erik/pacer/. The files are:

sample.html

A simple HTML form that prompts a user for a client number and to select a court. Three real courts are listed, and each is example of the three kinds of court documented above.

coldfusion.cfm

A Cold Fusion script, suitable for use on Lawport.

iis.asp

A version in VBScript, suitable for use on a Microsoft server. This script requires a change in the configuration of Internet Information Server that has security implications. Comments in the script describe the changes.

perl.cgi

A version in Perl, suitable for use in a Unix environment. The Perl script requires a module that is not normally installed by default. It also may not be in the best Perl style - my skills in that language are a little rusty.

Pointers on style and corrections on technique are welcome.