1362 West 130 South

Orem, Utah 84058

801.226.2746

www.tybera.com

Within the past few years, there has been substantial growth in the interest of filing court documents electronically. Courts and attorneys both see the value in minimizing the costs associated with the current manual process. In answer to this need, numerous solutions have surfaced for providing efiling. The ultimate goal of these solutions is to simplify the filing process and saving resources. This whitepaper reviews the different e-filing business models available, their architecture, and the interoperability issues involved.

As each court initiates the process of designing, planning, and deploying an electronic filing solution there are many decisions that need to be made. These decisions can be complex. One decision may affect the outcome of another. How much each decision impacts another is not always clear. Some of the key decisions that should be considered when designing an electronic filing solution are:

• Does the court want to try and conform to NACM and COSCA standards?

• Does the court want an open system so that no one vendor can control the electronic filing system of the court?
• How open does the court want to be?

• Can a few select vendors control the electronic filing process?
• Will any e-filing vendor be allowed to file to the court?
• Can attorneys install their own e-filing software to file to the court?

• Who will collect the court filing fees? Vendors or the courts?
• Who will control the official court documents in electronic format?

• What document management system "DMS" stores the official court documents?
• Are all documents submitted directly to the courts?
• In large cases that create tens of thousands of documents, how does the court establish a shared repository of documents?

• What is the official docket time for the electronic filing?
• If the filings are stored at a vendor’s DMS, what defines the official docket time? When it reaches the vendor’s system, or when it is entered into the court CMS?
• What processes are to be automated?
• For the court
• Case initiation,
• Case filing fee,
• Case updates, default judgements, post judgement remedies,
• For the attorney
• Case generation, case updates, receipt processing,
• Filing transmissions,

Many of these decisions impact each other and at times can conflict. For example, if the court wants to allow the attorneys to automate their processes and communicate directly to the courts it affects who collects fees and who stores official documents.

The purpose of this document is to present various e-filing architectural models, using the OASIS LegalXML Court Filing concepts, and the effects each decision has on interoperability issues. These models define how various processes interface together, thus affecting the flow of activity in an electronic filing system. There are many variations of models that are not represented here. This document also presents how the Utah AOC LegalXML installation was affected by their decisions.

In Figure 1, the court controls all aspects of the e-filing system. Several courts have stated that they feel uncomfortable with vendors having control over strategic aspects of their e-filing system. This does not mean courts are not willing to use vendor products, it means they want their IT staff to control and maintain the system. Several courts have also stated the desire to control official documents. In Figure 1, the attorney logs into the electronic filing product (EFP) at the court through a browser. The EFP communicates to the electronic filing manager (EFM).

Court Advantages:

• Court IT personnel administer the EFP and EFM,
• The EFP and EFM can be collapsed into one web server instead of two,
• Court IT personnel administer the DMS,
• Official documents are under the control of the court in the DMS,
• The court controls login and authentication of all e-filing users,
• Security between the EFP, EFM, CMS, and DMS is optimized because it is all controlled within the court’s network.

Business Considerations:

• The court controls what fees, if any, are charged to use the system,
• The court can create a portal for attorneys and a separate portal for Pro Se litigants where more scrutiny is required,

Interoperability Considerations:

• The court controls all processes, so conformance levels defined by the LegalXML Court Filing Technical Committee are not an issue,
• If the court discards the LegalXML envelope after the filing is received, and only stores the documents inside the envelope, then the only time the envelope is needed is when the court communicates to other courts.

The Utah AOC felt the need to control the collection of filing fees. They required control of the official court documents by storing them in their DMS. In addition to those business rules Utah needed to support digital signatures. They felt that there was a conflict between legislation mandates of fees, and adding charges to the electronic filing process. In addition, they could not justify surcharges if the court anticipated saving money by receiving documents electronically.

Other states have similar models but do not use the LegalXML concepts of an EFP and EFM. They frequently provide a web interface to accomplish the tasks of an EFP and EFM without the overhead of splitting the functionality apart or requiring the court filing envelope.

In Figure 2 the court releases some control to the electronic filing service provider (EFSP) vendor. Multiple EFSP vendors can interface with the court EFM. In this model all attorneys must establish an account with an EFSP vendor. This system appears to be an open model because it supports multiple EFSP vendors. In this model, the attorney logs into the EFSP installation through a browser or an application provided by the EFSP. The EFSP communicates to the EFM.

In this configuration, the:

• Court IT personnel administer the CMS, DMS, and EFM,
• Vendor (EFSP) personnel administer the hosted application,
• Vendor controls login and authentication of all e-filing users,
• Vendor collects filing fees for the court.

The business decisions that must be dealt with are:

• There is conflict between how many EFSP installations are allowed and the collection of court filing fees:
• An open system means that many EFSP installations can exist. This could include attorneys installing or creating their own EFSP applications to by-pass the EFSP installations that charge for services.
• If the court allows the EFSP to collect court fees, does the court need to contract with each EFSP installations for that? Or, can the court trust the installations of the attorneys to collect and submit filing fees?
• In order to establish a new EFSP installation, will the court need to create a contractual relationship for the filing fee collection process?
• If the court limits the number of EFSP installations, how does the court prevent EFSP installations from submitting documents, when they are not authorized to do so?
• Is the court responsible to filter which EFSP providers may participate? If this is true, the court needs a security model to determine which EFSP installations are authorized to submit filings.
• How does the court establish a test system for vendors that want to come in after the system is up and running?
• If an EFSP is delinquent in their payment to the court, does the court suspend all accounts using the EFSP?
• In an open system can Pro Se litigants install their own software to create Court Filing envelopes and submit them to the EFM? If so, how do payments get collected?
• If the number of EFSP installations is limited, do Pro Se litigants have to get an account through the EFSP to submit electronically?

Interoperability issues:

• Conformance Level 1 can be accomplished without business decisions.
• Conformance Level 2 can be accomplished but decisions about whether the court will restrict the number of EFSP installations or whether it will receive filings from all applications that pass level 1 must be made.
• Conformance Level 3 cannot be accomplished until the court decides whether they will let the EFSP installations collect court-filing fees. If this is the case, it suggests that a restricted number of EFSP installations will be approved and placed under contract to collect fees. (If the EFSP does not collect court fees, the EFSP still must somehow collect fees from the attorneys to support their services.)
• The simplest model is to not allow the EFSP installations to collect the filing fees for the court. Adopting this model will allow any EFSP or EFP that passes the Conformance Level 1 and 2 to participate in e-filing. This does force upon the courts the need to integrate a security model where they can tell what installations have passed the conformance test.
• Conformance Level 4 should exist whether the court is going to limit the number of installations and place them under contract, or if it is going to be open.
• If the number of EFSP installations is limited, then the court can punch a hole in the firewall for the few installations. This is not a scalable security model when many EFSP providers participate.
• If the number of EFSP installations is open, then a security model must exist where non-reputable evidence can be embedded into the LegalXML Court Filing envelope that defines which installation the submission came from. This type of security model must be open so that anyone can read the specification and write to it, yet at the same time the security can be enforced and not breached.

In Figure 3 the court releases some control to the EFSP vendor. It is my impression that this model grew from an earlier practice of courts using external document management systems for posting documents in cases where large volumes of data are generated. For example, tobacco cases generate thousands of documents. A central repository is beneficial to all parties involved in the case. A natural process that extends from a central repository is the electronic transfer of information from the repository to the courts. These EFSP vendors provide software for the courts so that the clerks can download case information. This information can be manually or automatically loaded into the court CMS. In this model, it is unclear who controls the official document when they may be stored either at the court or at the vendor. In this model, the attorney logs into the EFSP installation through a browser or an application provided by the EFSP. The EFSP communicates to the EFM.

In this configuration:

• Court IT personnel administer the CMS and EFM,
• Vendor (EFSP) personnel administer the EFSP,
• Vendor controls login and authentication of all e-filing users,
• Vendor personnel install and administer the DMS,
• Vendor controls official documents or the court downloads and duplicates them,
• Vendor collect filing fees for the court.

The business decisions of this configuration are:

• Court may not want to manage the DMS,
• Court may not want to manage the official documents of the court, or must duplicate them at the court,

• Court must provide a way for the EFSP vendor to support their services. Transaction fees added to the standard court filing fees frequently accomplish this purpose.
• The court must create contractual relationships with each EFSP vendor for the collection of filing fees.

• If a user account is delinquent in their payment to the EFSP vendor, the account is suspended,
• Pro Se litigants must have accounts just as attorneys do.

Challenges of this configuration are:

• If the EFSP provides the central repository for court documents it is difficult to understand how multiple EFSP vendors could participate,

• It is unclear how security and document integrity is insured between the EFSP and the EFM.

Interoperability issues:

• Conformance Level 1 cannot be addressed until the court has decided whether to limit the number of EFSP providers or not.
• All other conformance levels are dependent on decisions of the courts.

The second business requirement of the Utah AOC identified that attorneys who can afford to automate their internal processes can install or create their own software to interact with the court’s system. Figure 4 demonstrates the ability of a system to be configured as a single source control yet at the same time allows attorneys to interface to the EFP. This means that the court can allow all attorneys to file electronically at not cost. In addition, it allows attorneys to improve their process at their own cost.

Figure 4 shows that attorneys can use the EFSP installed at the courts as they would in a single source control as in Figure 1. In addition attorneys can install an EFP at their facilities that integrates to their CMS. This EFSP will communicate to the EFSP at the courts. No login information is passed using this process. The security embedded into the envelope authenticates the submission and the installation that sent the envelope.

Through discussions with the court clerks it became obvious that a small percentage of legal firms submitted 80% of debt collection filings. The same was true with other courts and other types of filings. Many of these legal firms want to automate their processes as well.

With the external interface, the court has the ability to support only state employees with the EFSP installed at the courts and force the attorneys to select an EFSP installation or install software at their facilities. Multiple EFSP installations can act as service providers as shown in Figure 2 but the control of court fee collections remains at the courts.

In this configuration:

• Court IT personnel install and administer the EFM, and EFSP
• The EFM and EFSP can be collapsed into one web server,
• Court IT personnel install and administer the DMS,
• Official documents are under the control of the court DMS,
• Court IT personnel administer the CMS,
• The court controls login and authentication of all e-filing users at the court installation and all EFSP or EFP installations. The court does not manage the users of an EFP or EFSP, only the installation. This means that if there are 1,000 attorneys using a specific EFSP the court configures an account just for the EFSP installation and not the users of that installation.
• Security and document integrity between all EFSP installations are controlled by the security embedded into the LegalXML Court Filing envelope. We extended the DTD to support this security.

Business decisions:

• Does the court want to support all attorneys, state employees, or both.
• If the court wants a central repository for large cases do they expose the repository at the courts or select an external repository to duplicate the documents? If they select to duplicate to an external source then each case could select a specific repository.

Interoperability issues:

• Conformance Level 1, 2, 3, unless it is in conjunction with Conformance Level 4 which includes security and document integrity support. A test environment must be established to allow developers to test their systems.

Figure 5, demonstrates how the court can install an EFSP and EFM to support the Attorney Generals office, District Attorneys, and other state personnel but does not all attorneys. Where the court does not want to support attorneys, EFSP installations can be installed. For attorneys that want to integrate software at their system they can do so. If the attorney installs our software locally, they can configure their system to allow their clients to file documents electronically to them also. In addition, this model shows how a central repository can be identified for each large case. The documents are submitted to the court and then duplicated to the external repository.

EFC 1.1 Conformance levels for Interoperability testing and issues at each level.

1. Communication and basic processing
2. Required elements for case initiation and case update
3. Required elements for filing fees
4. Security Model

Note: Electronic Filing Service Provider (EFSP) includes all applications that can generate Court Filing 1.1 envelopes. This may be an application hosted by a service provider, but does not require the application be designed for hosting. The focus is the ability to generate a Court Filing 1.1 envelope with proper content.

Level 1 Communication and basic processing

Objective: Make sure each EFM and EFSP can send, receive, and open embedded documents with all communications.

• Define the method for sending a court filing from an EFSP to an EFM
• Define the responses from an EFM to an EFSP
• Insure Secure Sockets are used during the communication.

• Make sure that the XML document instances validate against the reference EFC 1.1 DTD.
• Make sure the DTD references in the document instances are installation independent and can function properly from one application to another without modification.
• Make sure that the base64 encoded binary blobs embedded in the document instances can be extracted and viewed in their native application.
• Make sure that embedded XML documents can be extracted and parsed against the proper DTD.

Requirements:

• An EFSP application from each organization will generate court filings that conform to the ECF 1.1 DTD, embed Binary Blobs, and transmit the filing to the EFM.
• The EFM will run a validation process against the envelope and extract the Binary Blobs from the filing.
• The Binary Blobs must be retrieved into their native applications to verify that they are not corrupt.
• The EFM must be able to respond to the EFSP based on the responses defined in the test.
• The EFSP must be able to accept all responses returned by the receiving party based on a given submission.
• Server Certificates must be installed to support SSL. They can be self-signed certificates for the test.

Level 2 Required elements for case initiation and case update functions

Objective:

• Define what elements are required for case initiation
• Define what elements are required for case update

• Define what elements are optional for a given CMS
• Define what elements are excluded for a given court
• Test to insure that the EFM can be identified the lead document and all attachments
• Test to insure that the information for processing all attachments automatically is included.

Requirements:

• An application from each organization will generate court filings that conform to the ECF 1.1 DTD, embed Binary Blobs, and send the filing using the HTTP methods of communication to an IP address of an EFM. The receiving EFM must be able to process all required and optional elements defined in the test and automatically load the CMS.

Level 3 Required elements for filing fees

Objective: make sure fees are coordinated among vendors and collected properly

• Define what elements are required for fee processing

• Define what elements are required to update to CMS
• Define how to exchange the fees between multiple systems

Requirements:

• An application from each organization must be able to process the fee collection as defined in the interoperability test.

Level 4 Security Model

Objective: The EFM must determine that all filings are submitted by a valid EFSP authorized to send envelopes.

• Determine that the envelope came from an authorized source

• Determine that the envelope has not been tampered with

Requirements:

• Because this is not included in the standard at this time it is completely dependent on the existing court implementation.