Second Generation Electronic Filing Specifications
 

Staff and Consultants
Winchel "Todd" Vincent III, Author
WTVIII, Inc. and <xmlLegal>
Todd.Vincent@xmllegal.org
Christopher Smith,
Senior Business Systems Analyst
California Administrative Office of the Courts
christopher.smith@jud.ca.gov
 
Notice Schema
Last Updated: 2008-11-13
 

Schema Namespace and Documentation
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Notice/01/
Schema Prefix
Notice
Schema Repository Location
http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Notice/01/Notice.xsd
 
Table of Contents
1. Elements
 Internal
  1.1. Notice
  1.2. Date
  1.3. Time
  1.4. LegacyCases
  1.5. Filers
  1.6. Filer
  1.7. People
  1.8. Organizations
  1.9. Things
  1.10. Charges
  1.11. LeadDocuments
  1.12. Attachments
  1.13. Fees
  1.14. Services
  1.15. Calendars
  1.16. Extensions
  1.17. Confidential
  1.18. Sealed
  1.19. PolicyVersion
  1.20. PolicyMajorVersion
  1.21. PolicyMinorVersion
  1.22. RunMode
 External
  1.23. Message
  1.24. Key
  1.25. Case
  1.26. LegacyCase
  1.27. CourtDetails
  1.28. Person
  1.29. Organization
  1.30. Thing
  1.31. Charge
  1.32. Fee
  1.33. Service
  1.34. Coversheet
  1.35. LeadDocument
  1.36. Attachment
  1.37. Payment
  1.38. Calendar
  1.39. Extension
2. Simple Types
  2.1. Memo
  2.2. RunModes
3. Imported Schemas
  3.1. Attributes
  3.2. CourtDetails
  3.3. Extension
  3.4. Fee
  3.5. Key
  3.6. Organization
  3.7. Person
  3.8. Thing
  3.9. Calendar
  3.10. Case
  3.11. Charge
  3.12. Document
  3.13. Message
  3.14. Payment
  3.15. Service
4. Change History
  4.1. 2005-06-13
  4.2. 2005-08-16
  4.3. 2005-09-23
  4.4. 2005-12-03
  4.5. 2008-09-30
  4.6. 2008-11-13
5. Legal Notices
6. Authors and Contributors

1. Elements

1.1. Notice:Notice
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Key11
Date11
Time11
Case01
LegacyCases01
CourtDetails01
Filers11
People01
Organizations01
Things01
Charges01
Coversheet01
LeadDocuments11
Attachments01
Fees01
Payment01
Services01
Calendars01
Extensions01
Confidential01
Sealed01
Message01
PolicyVersion01
RunMode11

Introduction

[1]  Notice XML includes requisite elements to send court initiated transmissions and firm-to-firm transmissions. Court initiated transmissions are communications to parties that originate from the court without an associated filing. Firm-to-firm transmissions are communications to parties that originate from a law firm, but that are not sent to the court. This specification refers to these types of transmissions collectively as notices.

[2]  Although the Notice schema is located in a Filing schema subdirectory, the Notice schema stands on its own and is not part of the Filing schema.

[3]  Notice XML includes an ancillary specification named Notice List XML that is not part of the Filing XML specification.

[4]  As a general rule, unless this document specifies otherwise, the rules for Notice XML and confirmations to Notice XML are the same as the rules for Filing XML and confirmations to Filing XML. This documentation includes special rules for Notice XML and common rules that apply to both Filing XML and Notice XML.

Envelope XML and Header XML

[5]  Notice XML uses Envelope XML and Header XML in the same way as Filing XML. See the Envelope schema, the Header schema, and the Filing schema for more information.

Envelope and Transmission Protocols

[6]  It is logically possible to transmit Filing XML, Confirmation XML, and Notice XML by HTTP, HTTPS, FTP, SMTP, facsimile, postal mail, and bar coded paper (fax or post). The recommended approach is to use HTTP and HTTPS as the transmission protocol for electronic filings and notices. It is possible, however, that some parties in a case that are entitled to notice do not have an HTTP address to which a notice can be transmitted. In such situations, notices should be converted to paper or facsimile and transmitted using traditional methods.

Pre-Case Notice and Existing-Case Notice

[7]  Filing XML can be used for initial filings and subsequent filings. In the context of a filing, initial means a filing that initiates a new case and generates a new case number while subsequent means a filing with an existing case number.

[8]  In the context of a notice, there is a distinction between a pre-case notice and an existing-case notice. A pre-case notice is a notice about a matter that is sent prior to the existence of a case number assigned by a court. An existing-case notice is a notice sent after a court has created a case and assigned a case number.

Synchronous and Asynchronous Confirmations

[9]  An application that receives Notice XML over HTTP must send a synchronous confirmation using Confirmation XML to the sending application. There is, however, no requirement for a receiving application to send asynchronous confirmations to Notice XML.

Elements of a Notice

[10]  The Notice element is the intended root element of the schema.

[11]  Notice must contain one of each of the following elements: Notice:Key, Notice:Date, Notice:Time, Notice:Filers, and Notice:RunMode.

[12]  Notice must contain one LeadDocuments/LeadDocument element, but may contain several. This is not to say that there may be more than one logical lead documents; rather, the purpose is to allow one lead document to be simultaneously filed in different electronic formats, such as Adobe PDF and TIFF. See Notice:LeadDocument and the Document schema for more information.

[13]  Notice may contain Notice:Case, Notice:CourtDetails, Notice:LegacyCases, Notice:People, Notice:Organizations, Notice:Things, Notice:Charges, Notice:Coversheet, Notice:Attachments, Notice:Fees, Notice:Payment, Notice:Services, Notice:Calendars, Notice:Extensions, Notice:Confidential, Notice:Sealed, and Notice:Message.

1.2. Notice:Date
Data Type: xsd:date
go to top

[14]  Notice:Date is the sender's assertion of the date of the notice. The Notice:Date is not the same as the transmission date, although these date values should be the same or very close in time. Notice:Date is not a date from the transmitted document.

1.3. Notice:Time
Data Type: xsd:time
go to top

[15]  Notice:Time is the sender's assertion of the time of the notice. The Notice:Time is not the same as the transmission time, although these time values should be the same or very close in time.

1.4. Notice:LegacyCases
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
LegacyCase1unbounded

[16]  Notice:LegacyCases is a container element for one or more Notice:LegacyCase elements.

1.5. Notice:Filers
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Filer1unbounded

[17]  Notice:Filers is a container element for one or more Notice:Filer elements. The term filer and sender are synonymous. The sender's information must not be duplicated in Notice:People or Notice:Organizations.

1.6. Notice:Filer
Content Model: choice
go to top
Child Element(s)minOccursmaxOccurs
Person11
Organization11

[18]  Notice:Filer contains information about who sent the notice. Notice:Filer may be a Person or an Organization. A person is a natural person. An organization is a legal entity, such as a corporation, a limited liability company, or a government subdivision.

[19]  Specific courts and jurisdictions should define business rules for this element. There are a number of options for the meaning: (a) Notice:Filer could be the exact person who sends the notice, such as a legal secretary or a lawyer, (b) Notice:Filer could be a lawyer, even though the actual person who clicks the button and files the document is the lawyer's legal secretary, (c) Notice:Filer could be the firm for which a lawyer works, even though a lawyer or a lawyer's legal secretary actually clicks the button and files the document or (d) Notice:Filer could be the party on whose behalf a lawyer or law firm files a document.

[20]  The Person and Role schemas can be used to assign additional roles to the sender (such as Attorney, Plaintiff, or Defendant) and associate senders and other people and organizations. As a result, the sender does not need to be, and must not be, duplicated in the Filer:Person or Filer:Organization elements.

1.7. Notice:People
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Person1unbounded

[21]  Notice:People is a container element for one or more Notice:Person elements. Notice:People may contain people, whether parties, officials, or judges, associated with the case or matter. This information is not required for notices, but may be sent at the discretion of the sender.

1.8. Notice:Organizations
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Organization1unbounded

[22]  Notice:Organizations is a container element for one or more Notice:Organization elements. Notice:Organizations may contact the organizations, whether parties, state agencies, or others, associated with the case or matter. This information is not required for notices, but may be sent at the discretion of the sender.

1.9. Notice:Things
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Thing1unbounded

[23]  Notice:Things is a container element for one or more Notice:Thing elements. A Notice:Thing is an animal or inanimate object (i.e., not a legal entity) that is a party or potential party to a case. This information is not required for notices, but may be sent at the discretion of the sender.

1.10. Notice:Charges
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Charge1unbounded

[24]  Notice:Charges is a container element for one or more Notice:Charge elements. A Notice:Charge is the details of an offense or complaint in a criminal, juvenile, or other criminal-like case. Notice:Charge will not usually be used in civil cases. This information is not required for notices, but may be sent at the discretion of the sender. See the Charge schema.

1.11. Notice:LeadDocuments
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
LeadDocument14

[25]  Notice:LeadDocuments is a container element for one or more Notice:LeadDocument elements. A Notice:LeadDocument is the primary and most important document in a notice. A notice may contain several Notice:LeadDocument elements; however, it may contain only one logical lead document. The purpose of allowing multiple Notice:LeadDocument elements is to allow one logical lead document to be simultaneously sent in different electronic document formats, such as Adobe PDF and Microsoft Word. For example, a sender might submit Interrogatories as both a Microsoft Word document and as an Adobe PDF document, so that the receiver has both an editable version and a static version of the document. See the Notice:LeadDocument element.

1.12. Notice:Attachments
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Attachment1unbounded

[26]  Notice:Attachments is a container element for one or more Notice:Attachment elements. A Notice:Attachment is a secondary document, as described in Notice:LeadDocument. Other than its meaning, Notice:Attachment works in the same way as Notice:LeadDocument, except that Notice:Attachment can and should have different Document:Key values. See Notice:LeadDocument and Document schema.

1.13. Notice:Fees
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Fee1unbounded

Attribute(s)typeusefixed/default
FeeTotalxsd:stringrequiredNone

[27]  Notice:Fees is a container element for one or more Notice:Fee elements. Notice:Fees must include each individual fee submitted by the sender to a service provider. The total amount of the fees, whether there is only one fee or multiple fees, must be included in the required attribute FeeTotal. This information is required in a notice, only if a service provider is associated with delivering the notice and only if the service provider charges a fee for delivery services. Service providers may use Policy XML to publish fees. See the Fee schema.

1.14. Notice:Services
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Service1unbounded

[28]  Notice:Services is a container element for one or more Notice:Service elements. A Notice:Service element represents one service of process event. To express more than one service of process event, applications must use more than one Notice:Service elements. See Notice:Service element.

1.15. Notice:Calendars
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Calendar1unbounded

[29]  Notice:Calendars is a container element for one or more Notice:Calendar elements. A Notice:Calendar element represents multiple calendar events on a single day for a given organization. To express multiple calendar events on a single day for a single organization, applications must use only one Notice:Calendar element. To express multiple days, applications must use multiple Notice:Calendar elements. To express events taking place in different organizations, applications must also use multiple Notice:Calendar elements. See Notice:Calendar element.

1.16. Notice:Extensions
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
Extension1unbounded

[30]  Notice:Extensions is a container element for one or more Notice:Extension elements. A Notice:Extension is a generic name/value pair that allows applications to send information not included in the filing specification. The Notice:Extension element may include a SendBack attribute value equal to Yes. Receiving applications that encounter a SendBack value equal to Yes must send back the exact name/value pair in Confirmation:Extension element. See the Extension schema.

1.17. Notice:Confidential
Data Type: xsd:boolean
go to top

[31]  Notice:Confidential is an optional element of type boolean. When set to true, Notice:Confidential means that the sender wishes the communication to remain confidential.

[32]  If the Notice:Confidential element value is equal to true, then all documents in a filing are requested to be confidential. As a result, if the Notice:Confidential element value is equal to true, then the Document:Confidential element must be absent or it must be ignored, if present.

1.18. Notice:Sealed
Data Type: xsd:boolean
go to top

[33]  Notice:Sealed is an optional element of type boolean. When set to true, Notice:Sealed means that the sender wishes the communication to be part of settlement discussions. Notice:Sealed is distinguished from Notice:Confidential in that Notice:Confidential is merely a sender's request to keep the communication confidential, whereas Notice:Sealed is a sender's request to associate the documents with settlement discussions. Generally, information from settlement discussions may not be used in other aspects of litigation. This element provides a means of distinguishing this type of information.

[34]  If the Notice:Sealed element value is equal to true, then all documents in a filing are requested to be part of settlement discussions. As a result, if the Notice:Sealed element value is equal to true, then the Document:Sealed element must be absent or it must be ignored, if present.

1.19. Notice:PolicyVersion
Content Model: sequence
go to top
Child Element(s)minOccursmaxOccurs
PolicyMajorVersion11
PolicyMinorVersion22

[35]  To be done.

1.20. Notice:PolicyMajorVersion
Data Type: xsd:string
go to top

[36]  To be done.

1.21. Notice:PolicyMinorVersion
Data Type: xsd:string
go to top

[37]  To be done.

1.22. Notice:RunMode
Data Type: RunModes
go to top

[38]  Notice:RunMode is a single element with two possible values: Test or Live. Notice:RunMode is used when sending test notices to a live server so that downstream applications will know to ignore or behave differently toward the test notice. The element may also be useful in situations where test notices into a live server need to be purged mechanically, rather than deleted manually.

[39]  Applications are urged to implement Notice:RunMode in both test and live systems. When migrating from a test environment to a live environment, this element allows applications to send and receive notices and confirmations in a live system, while retaining the ability to identify a notice or a confirmation as a test. The ability to send and receive test notices and confirmations in a live system is helpful in the final stages of going live with an electronic filing system.

1.23. Notice:Message
Data Type: Message:Message
go to top

[40]  Notice:Message is a message intended to be conveyed to the receiver from the sender on any topic.

1.24. Notice:Key
Data Type: Key:Key
go to top

[41]  Notice:Key is a unique identifier for the notice. See the Key schema.

1.25. Notice:Case
Data Type: Case:Case
go to top

[42]  Notice:Case contains information about the case being sent. This information must be sent for existing-case notices using the Case:Existing element. This information should be sent for pre-case notices using the Case:New element. See the Case schema.

1.26. Notice:LegacyCase
Data Type: Case:Case
go to top

[43]  Notice:LegacyCase contains information about a case or a matter with a case number that is associated with, and a predecessor of, Notice:Case. For example, if a case is appealed, then the original case information can be included in Notice:LegacyCase when sending documents for a new case. See the Case schema.

1.27. Notice:CourtDetails
Data Type: CourtDetails:CourtDetails
go to top

[44]  Notice:CourtDetails contains information about the court associated with a case or matter. If a matter is associated with a court, then this information is required. If a matter is not associated with a case, then this information is not required. Sending applications should copy this information from the court's Policy XML. See the CourtDetails schema.

1.28. Notice:Person
Data Type: Person:Person
go to top

[45]  Notice:Person contains information about a person that is a party to a case or is otherwise associated with a case or a matter. See Notice:People documentation. See the Person schema.

1.29. Notice:Organization
Data Type: Organization:Organization
go to top

[46]  Notice:Organization contains information about an organization that is a party to a case or is otherwise associated with a case or a matter. See Notice:Organizations documentation. See the Organization schema.

1.30. Notice:Thing
Data Type: Thing:Thing
go to top

[47]  Notice:Thing contains information about a thing that is a party to a case or a potential party to a case. See Notice:Things documentation. See the Thing schema.

1.31. Notice:Charge
Data Type: Charge:Charge
go to top

[48]  Notice:Charge contains information about a charge or a potential charge. See Notice:Charges documentation. See the Charge schema.

1.32. Notice:Fee
Data Type: Fee:Fee
go to top

[49]  Notice:Fee contains information about a fee charged by a service provider to deliver a notice. Sending applications should copy this information from the service provider's Policy XML. See the Notice:Fees element, the Fee schema and the Policy XML specification.

1.33. Notice:Service
Data Type: Service:Service
go to top

[50]  Notice:Service contains information about documents for which service of process has taken place. See the service Schema.

1.34. Notice:Coversheet
Data Type: Document:Document
go to top

[51]  Notice:Coversheet contains a coversheet document, such as a cover letter, if any. Notice:Coversheet is not a lead document and is not an attachment. See the Filing:Coversheet element.

1.35. Notice:LeadDocument
Data Type: Document:Document
go to top

[52]  Notice:LeadDocument is the primary and most important document in a notice. For example, if a party is sending a Demand Letter supported by an Affidavit and two Exhibits, then the Demand Letter would be the lead document and the other three documents would be attachments. See the Filing:LeadDocument element and the Document schema.

1.36. Notice:Attachment
Data Type: Document:Document
go to top

[53]  Notice:Attachment contains information about a secondary document. See the Notice:LeadDocument, Filing:LeadDocument, Notice:Attachments, and Filing:Attachments element.

1.37. Notice:Payment
Data Type: Payment:Payment
go to top

[54]  A Notice:Payment provides information about a sender's credit card so that a sender can pay a service provider for delivering a notice. See the Payment schema.

1.38. Notice:Calendar
Data Type: Calendar:Calendar
go to top

[55]  A Notice:Calendar provides information about calendared events. In the context of a notice, the Calendar schema can be used to convey an event scheduled by a court or an event proposed to be scheduled by a law firm. For example, a firm might send another firm a Notice of Deposition with a proposed date and time for the deposition. See the Calendar schema.

1.39. Notice:Extension
Data Type: Extension:Extension
go to top

[56]  A Notice:Extension is a generic name/value pair that allows applications to send information not included in the filing specification. See the Notice:Extensions element.

2. Simple Types

2.1. Memo
Data Type: xsd:string
go to top
2.2. RunModes
Data Type: xsd:string
go to top
Enumeration(s)

Value
Test
Live

3. Imported Schemas

3.1. Attributes
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Attributes/03/
  
3.2. CourtDetails
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/CourtDetails/03/
  
3.3. Extension
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Extension/03/
  
3.4. Fee
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Fee/03/
  
3.5. Key
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Key/03/
  
3.6. Organization
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Organization/03/
  
3.7. Person
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Person/03/
  
3.8. Thing
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/BuildingBlocks/Primitives/Thing/03/
  
3.9. Calendar
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Calendar/01/
  
3.10. Case
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Case/01/
  
3.11. Charge
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Charge/01/
  
3.12. Document
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Document/01/
  
3.13. Message
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Message/01/
  
3.14. Payment
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Payment/01/
  
3.15. Service
go to top
Namespace
  http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/02/Service/01/
  

4. Change History

4.1. 2005-06-13
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/01/
go to top

Copied. Changed Case and CourtDetails to optional based on the assumption that in a law-firm to law-firm transaction, a court might not yet be involved.

4.2. 2005-08-16
Editor: Winchel Vincent
go to top

Completed documentation.

4.3. 2005-09-23
Editor: Winchel Vincent
go to top

Minor edits.

4.4. 2005-12-03
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test06/Notice/01/
go to top

Copied.

4.5. 2008-09-30
Editor: Schema Generator
go to top

Normalized using xmlSchemaGenerator Normalizer 0.1.5.

4.6. 2008-11-13
Editor: Winchel Vincent
Copied From: http://www.xmllegal.org/Schema/Court/US/California/2GEFS/Filing/Test07/Notice/01/
go to top

Copied.

5. Legal Notices

Unless otherwise agreed, All Rights Reserved except those granted by xmlLegal General Public License at:

LICENSED WORKS ARE PROVIDED "AS IS," AND HOLDERS OF INTELLECTUAL PROPERTY RIGHTS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED,INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE LICENSED WORKS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS.

HOLDERS OF INTELLECTUAL PROPERTY WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE LICENSED WORKS.

Contact Winchel "Todd" Vincent III (Todd.Vincent@xmllegal.org) or xmlLegal Help (help@xmllegal.org) for more information.

6. Authors and Contributors


Staff and Consultants
Winchel "Todd" Vincent, III, Author
WTVIII, Inc. and <xmlLegal>
Todd.Vincent@xmllegal.org
Kevin Stannard, Original Editor
Swiftnet Solutions, Ltd.
kevin.stannard@swiftnet-solutions.com
Charlene Hammitt, Project Director
California Administrative Office of the Courts
charlene.hammitt@jud.ca.gov
Christopher Smith, Senior Business Systems Analyst
California Administrative Office of the Courts
christopher.smith@jud.ca.gov
Tom Smith, Consultant
AVI/IT Decision
tjsmith@itdecision.com
Courts
Contra Costa Superior Court (http://cc-courts.org/)
Kathy Ridgeway, KRIDG@sc.co.contra-costa.ca.us
Karen Ortega, KORTE@sc.co.contra-costa.ca.us
Orange Superior Court (http://www.occourts.org/)
Allen Jensen, ajensen@occourts.org
SacramentoSuperior Court (http://www.saccourt.com/)
Doug Kauffroath, KauffrD@saccourt.com
Ryan Hurlock, HurlocR@saccourt.com
Judith Kerrin, KerrinJ@saccourt.com
Marcia Barclay, BarclaM@saccourt.com
Huldeni "Zito" Souza, SouzaH@saccourt.com
Michael Alexander, AlexanM@saccourt.com
Gary Nishi, NishiG@saccourt.com
San Mateo Superior Court (http://www.sanmateocourt.org/)
Tim Benton, tbenton@co.sanmateo.ca.us
Rick Walery, rwalery@sanmateocourt.org
Bill Harven, wharven@sanmateocourt.org
Carrie Warren, cwarren@sanmateocourt.org
Santa Clara Superior Court (http://www.sccsuperiorcourt.org/)
Barry Lynch, blynch@scscourt.org
Deborah Barker, dbarker@scscourt.org
Francine Collier, fcollier@scscourt.org
 
Contributors
counterclaim, inc. (http://www.counterclaim.com)
Shogan Naidoo, shogan@counterclaim.com
Michelle Naidoo, mnaidoo@counterclaim.com
Jim Beard, beard@counterclaim.com
Jason Van Cleve, jason@vancleve.com
Deloitte Consulting (http://www.deloitte.com/)
Bruce Scheffle, bscheffel@deloitte.com
E-Filing.com (http://www.e-filing.com)
Mohammed Shaikh, mohammed@e-filing.com
Amrit Singh Nandrey, amrit@imagexx.com
Prabhath Pallati, prabhath@imagexx.com
Essential Publishers (http://www.essentialpublishers.com)
Martin Dean, dean@epubs.org
George Rothbart, george@softsci.com
Glotrans (http://www.glotrans.com)
Andy Jamieson, ajam@glotrans.com
Conor Dixon, conordixon@comcast.net
Intresys (http://www.intresys.com)
Yegor Borovikov, yegorb@intresys.com
Tania Wasser, taniaw@intresys.com
ISD Corporation (http://www.essentialpublishers.com)
Rob Beach, Ron.Beach@isd-corp.com
Holly Ramirez, Holly.Ramirez@isd-corp.com
John Coughlin, john.coughlin@isd-corp.com
Bob Gehringer, bob.gehringer@isd-corp.com
Robert Entrican, robert@entrican.com
Lexis-Nexis (http://www.lexisnexis.com)
Jonathan Gill, jonathan.gill@lexisnexis.com
Shane Durham, shane.durham@lexisnexis.com
One Legal, Inc. (http://www.onelegal.com)
Robert DeFilippis, rtd@onelegal.com
Matt Marshall, matt@mattmarshall.com
Bryan Barringer, bbarringer@onelegal.com
Bill Porterfield, billp@servicehub.com
Patrick Zanone, patrick.zanone@macroburst.com
U.S. Court Forms/American LegalNet (http://www.uscourtforms.com)
Erez Bustan, erez@uscourtforms.com
Kin Lee, kin@uscourtforms.com
Harry Thakkar, Hthakkar@uscourtforms.com