I believe very
strongly that eService is a critically important part of the business model
for eFiling. The availability of eService provides a
significant additional incentive for lawyers to participate in an eFiling system. Consequently, I very much want to see
it included within Electronic Court Filing 3.0. That does not necessarily mean that it
has to be included in the initial deliverable to the Joint Tech committee that
needs to be completed within the next few days. Jim
Cabral suggests that we could pose the issue of the competing
eService models to Joint Tech and ask Joint Tech to decide which to pursue.
I do not favor that
approach. I do
not think that Tom Clarke and I
could explain the models to Joint Tech within the time available, I doubt that
the committee members could digest the differences, and I also douct that they could provide a reasoned decision within
the time constraints of the meeting even if we were able to present the issues
in a completely understandable fashion. However, I think it would be possible
to withhold an eService model from what we present in the next week. I hope, however, that we can reach a
decision on Thursday that avoids having to present a partial
model.
The comments on the
eService models contain a few basic misperceptions that I would like to
clarify with the following statements about service and
eService:
1)
Courts
today must maintain complete and accurate records on the persons entitled to
service in each case and the addresses at which to serve them. These records are
updated on a frequent basis in every court. Parties change lawyers; lawyers change
office addresses; and lawyers cease to represent parties. It is a basic and essential role of the
clerk of court to maintain this information accurately. For this reason, some courts assign
each lawyer a unique ID which is linked to a single address
in the database; if the address is changed the new address appears
automatically in every case in which that lawyer appears. Some courts do not have this capability
and require lawyers to file change of address notices in every case in which
s/he appears. It all works out
the same – the court keeps track of whom to serve and their
current address. Both
Models A and B require the court to maintain a complete and accurate list of
electronic addresses for eService purposes. It would be possible under either
model for a court to delegate that responsibility to a
contractor.
2)
Parties
can come to the court to review the case file or the case management
information system to update their own records concerning parties entitled to
service. Or they can maintain their own service list, compiled and
updated as they receive documents that change who is to be served or where
they are located. The parties get
copies of the same documents the court uses to update service
information.
3)
Courts
are required to serve copies of their notices, orders and judgments on
all parties in a case. They use
their CMS database of parties and addresses to do so. Many CMSs
have the capability to produce mailers for this purpose
automatically.
4)
Many
courts implementing eFiling have established their
own registries of eFiling users. State or local eFiling rules often require registration in order to
obtain a UserID and to register a password, which
together constitute a signature by the submitting attorney on the lead
document submitted. However, this
is not an essential component of an effective eFiling and eService system. The small group that developed Model
A started with the assumption of such a registry.
We concluded that a registry
would not be needed if the eFiling/eService system were designed effectively.
So,
Model A does not assume a central state or local registry. Neither, for that matter, does Model
B. Relieving the court of the
need to maintain such a registry would be a welcome
development.
5)
Rules
authorizing eService will undoubtedly continue to come in various
flavors. The current Washington rule is
extremely restrictive, requiring “agreement among the parties” in each case in
which it will be used. I prefer a
state rule that says if you eFile, you consent to
eService. The current federal
system is based on local option. The federal CM/ECF software supports eService, but each court decides
whether and on what terms it will use that system. The court may implement it on a
“voluntary” basis – applicable only to persons to choose to be served electronically; it may make eService mandatory
for all eFilers. Electronic Court Filing 3.0
will have to support all rule variations; consequently, it must be designed to support eService databases unique to
each case. If it can support that
use case, it can easily support mandatory eService
courts.
6)
Current
service rules require the filing party to perform secondary service prior to
or contemporaneously with the filing of the document with the court. The “federal” model – where the court’s
computer performs eService – alters that process. Service occurs at the time the court
dockets the document filed. (The
federal system no longer employs a Clerk Review function; filings go directly
onto the court docket and into the court document management
system; quality control is performed after the fact not before the
fact.) In discussions of this
model within the TC we concluded that
court-delivered eService would have to occur at the time a filing is received, not when it is docketed, because docketing may
be delayed significantly by the Clerk Review function (which we now call the
Review Filing MDE). The rules of procedure provide
that a party’s time for response begins on the date
of receipt of a hand delivered copy or three days after mailing of a
copy. One argument in favor of
eService is that it eliminates the three day rule for
mailings and hence speeds up case processing; this is true only if the time of
service is independent of delays created by clerk’s office docketing
processes.
Given this
background, let me summarize my understanding of the distinctions between the
two models.
Model A requires the
Filing Assembly MDE to perform eService at the time
of filing, using a list of eService recipients and electronic addresses
provided by the court. This model
requires no changes to current rules governing service, other than the
authorization of eService as a form of secondary service. A court could conceivably hire a
contractor to build and operate the electronic service and addressing
component of its case management application. That seems unlikely to me; adding
electronic addresses is a relatively straightforward addition to the
functionality of a CMIS. On the other hand, a court can choose
to provide its own Filing Assembly and Filing Review MDE functionality.
So, the entire eFiling/eService process can be performed by the court
itself under Model A.
The federal system
operates its own Filing Assembly and Filing Review MDEs. All
filings are done through a web interface created by
the federal courts. All filings
are received and processed by the CMS component of that
system. eService is performed by the same two processes. However, eService is
not performed according to Model A. The filing is
served after it is received and docketed by the court. But, as noted
above, because of the absence of a manual Filing Review process, the timing of
eService under the federal system is virtually the same as contemplated by
Model A.
Dallas’s expressed concern
that the submitterID under Model A is not the same
as the ID of the attorney submitting the filing is misplaced. The submitterID is the person or machine in the attorney’s
office from which the filing actually originates. It is entirely appropriate for eService
to go to that same person or machine in the attorney’s
office.
Model B provides for
the court (or a vendor hired by the court) to perform eService after a filing
has been received by the court, using exactly the same list of eService
recipients and electronic addresses used in Model A. Model B ensures that the documents
received by the court are the documents served on the parties entitled to
service. However, it is
altogether possible that the documents are not
transmitted at all; the Notice of Electronic Filing proposed for
Orange
County does not transmit
the filed document; it merely sends a URL for the document on the court’s
website. This process is only
possible if the eService notice goes out after the filing has been processed through the manual Clerk Review process and
committed to the court’s CMS and DMS. This creates the timing issue
discussed at length by the TC.
Both models allow for
the existence of commercial eFiling service
providers and both models require those providers to transmit eService
messages to the eFilers they support. Both models transmit information to
eFilers (through their Filing Assembly MDEs) concerning the persons for whom they must perform
traditional paper-based service.
Consequently, the
results of Model A – as I perceive it – are that it
-
maintains the current
rule structure for eService – having it occur contemporaneously with
filing;
-
provides the served party
with the actual electronic documents submitted for filing (Under our proposed
structure, it uses the identical Review Filing message. While it is conceivable that a Filing
Assembly MDE could create a system that allowed a
Filer to construct different messages with different documents for the filing
and service versions of the same Review Filing message, this functionality
would not be available to the Filer absent such collusion by the Filing
Assembly MDE. We could include provisions in our
specification requiring the Filing Assembly MDE to
create the service and filing messages from the same message constructed by
the Filer.)
-
allows a court that wishes
to provide Filing Assembly and Filing Review MDEs as
a public service to do so and to support eService
accordingly.
-
allows a
court to have commercial Filing Assembly providers perform
eService;
-
eliminates any
possibility of delay in eService arising from court processing of the Review
Filing message; and
-
provides an elegant solution
to the messaging structure for ECF 3.0 (a single
message structure accomplishes both filing and
service).
The results of Model
B – again as I perceive it – are that it
-
requires
a revision of the rule structure for eService in every state using it – having
eService follow filing rather than accompany
filing
-
necessarily requires
a court to assume responsibility for eService (by itself or through a
contractor);
-
allows a court to opt to
transmit a URL in lieu of the documents submitted for filing, at the cost of
delaying eService until after the Filing Review, docketing, and DMS submission processes are completed, introducing
uncertainty as to the timing of eService. (Of course, the court’s computer will
maintain a record of the actual moment of eService, so this process will not introduce uncertainty about the responding
party’s deadline for filing a response. The uncertainty will arise from the
fact that delays in the clerk’s office will create delays in service – a
situation that does not occur under paper service rules. It will be possible that opposing
counsel receiving eService will not know for a week that a document has been filed while counsel receiving paper service knew
the next day.)
-
ensures that eService will
not be performed for documents that are not received by the Filing Review
MDE because, for example, they are not correctly
addressed to the court, are corrupted, or contain a
virus.
This analysis causes
me to favor Model A because it allows for greater flexibility and, with the
exception of the possible transmission to opposing counsel of a filing that
bounces when it reaches the court, provides all of the features of Model B
without requiring any major rule changes or risking any delays arising from
clerk’s office processing of filings. I believe that Model A should and will
become the preferred model and that ECF 3.0 should
support it exclusively. I see no
need to postpone a decision on this issue.
From: Cabral,
James E. [mailto:JCabral@mtgmc.com]
Sent: Tuesday, June 28, 2005 11:25
PM
To: Electronic Court
Filing Technical Committeee
Subject: [Norton AntiSpam]
[legalxml-courtfiling] Please review 'Proposed Service Models for
ECF3'
Everyone,
Thursday and Friday last week,
John Greacen, Christoph Hoashi-Erhardt, another MTG consultant, and I made a
first attempt at developing a domain model and GJXDM mapping for electronic
service. We wrote up a quick 3 page summary of the model and solicited
initial feedback from some of the vendors actively participating on the TC
with the expectation that we would send it to TC Monday. We did not
expect the considerable response we received.
With the hope of coming to a
consensus as a TC as soon as possible, I have summarized the comments over the
last couple days and a proposed alternative model in the attached
document. I have also attached a service cover sheet that Tybera is
currently developing with Orange
County, that Dallas graciously
provided as an example.
As you will see from the main
document, the main decision point is whether we need to support one or two
service models. We request feedback from all TC members on
this important issue as soon as possible so that we can finish up the
specification. Please be sure to send your response to the entire
list. If you can make your comments via "Track Changes" in Word, that
would simplify our aggregation of the comments. I will leave it to the
TC chairs to propose a decision making process.
<<Proposed
Service Models for ECF3.doc>> <<NEF Draft 1 dated
04-20-05.doc>>
Thanks!
Jim
Cabral
James E. Cabral Jr.
MTG Management Consultants,
L.L.C.
1111 Third
Avenue, Suite 2700
Seattle,
WA 98101-3201
(206)
442-5010
www.mtgmc.com
The
information transmitted is intended only for the person or entity to which it
is addressed and may contain confidential and/or privileged material. If you
received this in error, please contact the sender and delete the material from
any computer.