IPMM Minimum XML

Minimum Data Elements for LEDES IPMM Invention Disclosure 1.01

This document describes an XML document that contains the minimum data elements required by the LEDES IPMM invention disclosure standard, release 1.01.  The purpose is to provide a general idea of how the data appear in the underlying XML document and also an understanding that the standard is not prescriptive, but is intended to be flexible.  Many additional data elements are defined by the standard, but are not required.  Presumably applications will enable the user to configure many of these additional elements as required based on the user’s needs.  A conforming application must use these defined elements wherever possible, rather than creating conflicting proprietary elements or attributes.

An XML document containing the minimum elements required by the LEDES disclosure standard, release 1.01, is shown below. Don’t let its appearance concern you; applications are unlikely to display the data as an XML document.  The effectiveness of data entry and display will likely remain a key differentiator among competing products.

LEDES Disclosure

The XML document depicted in Figure 1 validates against the LEDES disclosure schema and qualifies as a “LEDES disclosure”. It contains the minimum content required for conformance to the LEDES disclosure standard.

The first line in figure 1 is the XML declaration:

<?xml version=”1.0″ encoding=”UTF-8″?>

No other content or white space precedes the declaration.  The declaration indicates what version of the XML standard the document implements and what character encoding is used. Encoding defined by the LEDES disclosure standard may change in the future if warranted for internationalization, but presently is the most common XML encoding, UTF-8.

The third line of figure 1 begins the disclosure envelope:

<lip:Disclosure xmlns:lip=https://ledes.org/IPMM/2015
xmlns:xsi=”http//www.w3.org/2001/XMLSchema-instance” submitDateTime=”2001-12-17T09:30:47+05:00″ schemaVersion=”20160111″
xsi:schemaLocation=”https://ledes.org/IPMM/2015 L_Disclosure.xsd”>

Disclosure is the root element of the LEDES disclosure schema.  The Disclosure element is the envelope that contains all data regarding the invention disclosure.  It is analogous to a physical envelope into which might place information regarding various related concepts and associated documents (e.g., drawings or DVDs) and stamp with certain delivery metadata (sender and recipient addresses).

The initial “<” without a following “?” or “/” indicates that “<elementname>” is an opening tag.  An XML data element typically consists of an opening tag, followed by content, followed by a closing tag, such as:

This is element content

The “lip:” prefix indicates what “namespace” defines the Disclosure element.  A namespace is effectively a virtual dictionary, in which any definition is exclusive.  The LEDES disclosure standard uses two namespaces, “lip” for IP-specific definitions and “lco” for more generic definitions.  Immediately following “<lip:Disclosure” is the phrase


The attribute prefix “xmlns:” is reserved and defined by the World Wide Web Consortium (W3C).  “Xmlns:” is used for declaring namespaces.  The phrase defines a namespace with the name “https://ledes.org/ipmm/2015” and provides a nickname of “lip”. Per W3C rules, a namespace name must be a valid Uniform Resource Identifier (URI), but does not need to be an existing web page.  At present, the LOC is experiencing some website issues and you will NOT find an active web page at “https://ledes.org/ipmm/2015”.

Immediately after the “lip” prefix and related namespace name are declared, the next phrase is:


Similar to prior phrase, this phrase declares the namespace name “http//www.ledes.org/common/2015” and assigns the nickname of “lco”.

The next phrase is


Similar to “xmlns”, “xsi” is an attribute prefix that is reserved and defined by W3C.  For LEDES disclosure purposes, “xsi:” is used solely for defining the attribute schemaLocation used later on line 2.

The next phrase is


The attribute submitDateTime is defined in the disclosure schema as a data type called dateTimeStamp.  dateTimeStamp represents a specific date and time in the format CCYY-MM-DDThh:mm:ss.sss, plus an appended time zone expression. For example, Australian Eastern Daylight Time is eleven hours ahead of UTC and is represented as +11:00.  2014-11-19T16:28:00+11:00 would equate to 4:28 pm on November 19, 2014 in Sydney and other locations within the time zone.  The attribute submitDateTime is set by the submitting application and defines the time immediately before successful validation and transmission.  This demonstrates a significant value of XSD and XML for the user; there is little chance that the sending application will misinterpret these data.

The next phrase as shown in Figure 1 is


This attribute declares the latest version of the schema with which the XML document is compatible.  The application can compare the XML document’s schemaVersion attribute with the disclosure schema’s version attribute to determine if the appropriate schema version is used for validation.

The final phrase in line 2 is:

xsi:schemaLocation=”https://ledes.org/IPMM/2015 L_Disclosure.xsd”>

W3C defines the schemaLocation attribute.  It provides a hint as to what schema is used for validation and where it can be found.  The character “>” indicates the end of the opening tag for the Disclosure element.  Note that the very last line of the XML document contains the closing tag for the Disclosure element (i.e., </lip:Disclosure>).  The contents of the Disclosure element are contained within the opening and closing tags.

Line 4 in figure 1 displays:


The first portion between angled brackets (“<lip:SubmitterDisclosureID>”) is the opening tag for the SubmitterDisclosureID element.  The “lip:” prefix indicates that the SubmitterDisclosureID element is defined in the namespace named “https://ledes.org/IPMM/2015”.  Every disclosure must contain one and only one SubmitterDisclosureID.  To conform to the LEDES disclosure standard, the application must ensure that this SubmitterDisclosureID value (e.g., D1234) is unique compared to all SubmitterDisclosureID values in previous LEDES disclosures generated by the application.  An optional RecipientDisclosureID element is also defined in the disclosure schema if the recipient wishes to define a separate ID.  The second portion between angled brackets (“</lip:SubmitterDisclosureID>”) is the closing tag for the SubmitterDisclosureID element.

Line 5 displays


This is the opening tag for the ConceptBag element.  Every LEDES disclosure must contain one and only one ConceptBag.  The meat of the ConceptBag definition is located in the LEDES concept schema.  A ConceptBag contains one or more Concept elements.  A Concept element contains the fields that most persons contemplate when discussing an invention disclosure form.

Line 6 displays:


This is the opening tag for the ConceptBag element.  As mentioned above, every ConceptBag contains at least one Concept element, but can contain an infinite number of Concept elements.

Line 7 displays:

<lip:ConceptTitle lco:lang=”EN”>Bread   Slicer

The “lip:” prefix indicates that ConceptTitle is defined in the “lip” namespace.  The “lco:” prefix indicates that the lang attribute is defined in the “lco” namespace.  Specifically, the lang attribute contains an ISO 6391 two-character language code.  Because W3C recommends and various countries require use of a lang attribute to assist with presentation and translation of text, the LEDES disclosure standard requires the lang attribute for most text fields.  ConceptTitle is a string of at least one character.  Various optional attributes are available in addition to the required lang attribute.  One and only one ConceptTitle element must be defined for each Concept.

Line 8 displays:

<lip:ConceptDetail lco:lang=”EN”>A bread slicing device, comprising: (a) a bread holder and (b) means for slicing the bread.

The technical details for ConceptDetail are the same as for the ConceptTitle element.

Line 9 displays:


Every Concept element must contain one and only one SubmitterBag element, which in turn will contain at least one Submitter element.

Line 10 displays:


Every Concept element includes at least one Submitter element, which contains information regarding a person who submits the disclosure.

Line 11 displays:


The SubmitterInfo element can contain different types of information about the person submitting the disclosure, but only the name is required.

Line 12 displays:


The SubmitterInfo element requires one and only one PersonName.  The PersonName element can either be a full name as regular text or can be a more structured collection of given, family, other and nick names, prefixes and suffixes.

Line 13 displays:

<lco:PersonFullName>Jane Roe</lco:PersonFullName>

For purposes of displaying a simple conforming XML document, Figure 1 uses the simple full name text structure to define the PersonName.

Line 14 closes the PersonName element and line 15 displays:


This is the closing tag for the SubmitterInfo element.  All aspects of SubmitterInfo are contained between its opening and closing tags.  The element also permits optional data re citizenship, residency, primary language, contact information, and affiliations (e.g., employer).

Lines 16 and 17 close the Submitter and SubmitterBag elements.  Line 18 displays


This is the closing tag for the Concept element.  All aspects of the Concept element are contained between its opening and closing tags.  A Concept can also contain optional data re concept summary, general subject matter, technical problem, technical solution, advantageous effects, background art, similar effort, embodiment, best mode, invention mode, industrial applicability, deposited biological material, sequence list, citations, experiments, analysis, modeling, funding, third party input, relevant files, conception, reduction to practice, disclosures, publications, presentations, expenditures, and other issues.

Lines 19 and 20 close the ConceptBag and Disclosure elements.  A Disclosure element can also contain optional data re associated files, requested handling, and metadata regarding the submitting application and the transaction process.