[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Norton AntiSpam] [legalxml-courtfiling] Please review 'Proposed Service Models for ECF3'
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. 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 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. 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 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] 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 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>> James
E. Cabral Jr. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]