MHonArc v2.5.0b2 -->
legalxml-courtfiling message
[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'
From: "John M. Greacen" <>
To: "'Electronic Court Filing Technical Committeee'" <>
Date: Thu, 30 Jun 2005 02:36:08 -0600
Title: 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.
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 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 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. 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.
’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
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:]
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
, that 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!
James
E. Cabral Jr.
MTG
Management Consultants, L.L.C.
(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.
References:
Please review 'Proposed Service Models for ECF3'
From: "Cabral, James E." <>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
