President Obama and USPTO Director David Kappos on USPTO's IT Systems

“Believe it or not, in our patent office -- now, this is embarrassing -- this is an institution responsible for protecting and promoting innovation -- our patent office receives more than 80 percent of patent applications electronically, then manually prints them out, scans them, and enters them into an outdated case management system. This is one of the reasons why the average processing time for a patent is roughly three years.”  -President Obama, Forum on Modernizing Government (Patently-O, 18 Jan 2010)

Our infrastructure needs are also dire – so dire that President Obama referenced the USPTO’s antiquated IT systems in his remarks last week on modernizing government. We must improve those systems to become an efficient 21st century agency – and to be able to effectively serve the innovation community and the American economy.   -David Kappos, letter to PTO employees  (Patently-O, 21 Jan 2010)

Patent Office Priorities
The USPTO's prime strategy in its mission to foster innovation and competitiveness is to "optimize patent quality and timeliness" (2009 Annual Report).  To achieve this, the USPTO has hired more examiners, improved their training, and launched new programs (First Action, Accelerated Examination, and Peer Review).  However, more examiners doing better work can only do so much to optimize quality and timeliness.  The USPTO's average pendency in 2008 was 32 months and the Government Accounting Office (GAO) predicted the USPTO’s backlog would nearly double in four years.  In particular, the GAO stated that "the [USPTO] has acknowledged that it cannot hire its way out of the backlog and is now focused on slowing the growth of the backlog instead of reducing it."  A technical solution is needed that encourages applicants to provide more complete information to examiners in a "ready to examine" format.  A "ready to examine" format implies that formal requirements have verifiably been addressed and the document format is structured to streamline examination.  The requirements for such a solution includes:

1. Structured data format definition
2. Software to generate and maintain patent documents with chosen structured data format
3. Formal requirements verifiably addressed
4. Facilitate comprehension of claim scope
5. Integration with eDAN, EAST, and OACS

Structured Data Format Definition
The USPTO currently seeks to semantically identify claims, claim terms, parts, and even callouts.  In future, the USPTO will likely require support for more complex entity-value relationships (i.e. the values of parts and claim terms) such as "soot particles measuring 0.2-0.5um", which would allow more targeted searching.

The structured data format would preferably be an open XML standard allowing all software vendors to participate.   Formulation of such a standard would allow stakeholders (PTO's, patent prosecutors/litigators/researchers, and software companies) to specify what tags will be useful. 

TeamPatent's structured data format currently tracks the fundamental relationships and has previously demonstrated entity-value relationship support in the context of an Electronic Medical Record (EMR) prototype available here in which the system tracks medications and their corresponding dosages such as "Adderall XR 20mg po qDay".  TeamPatent therefore appears to be extensible to support the requirements of any standard chosen in the future by the USPTO.

Software to Generate and Maintain Patent Documents with Structured Data
Software to create and maintain documents with this structured data format either must operate without applicants' involvement or it must be easy to use and help applicants' productivity.  If it requires applicants' involvement and is burdensome, it will likely fail as did PASAT and ABX.  There are three methods to semantically tag and maintain elements in a document:

1. Automatically parse from free-form text & tables
2. Textual semantically-aware editor™
3. Graphical semantic editor

Comprehensive automatic parsing could operate without any applicant involvement so could achieve 100% participation.  However, the commercial patent search industry has applied enormous amounts of attention to this problem over decades so if automatic parsing could achieve the USPTO's goals, it presumably would have been applied already.  The USPTO will undoubtably apply such technologies as they become available but human-assisted markup appears to be necessary at the present time.

A textual semantically-aware editor™ would require users to enter the XML markup directly.  For example, they might tag a claim term as, "...comprising a <claim term>widget</claim term>..."  This is clearly unacceptable as it is beyond the capabilities for many patent professionals. 

Wikipedia describes graphical XML editors as "easier for some people to use than text editors, and may not require knowledge of XML syntax".  However, this same entry notes, "These kinds of editors are generally more useful for XML languages for data rather than for storing documents. Documents tends to be fairly freeform in structure, which tends to defy the generally rigid nature of many graphical editors."

TeamPatent's graphical semantic editing tools were designed from the ground up to allow applicants to intuitively manipulate patent internal relationships.  It currently tracks the fundamental relationships (e.g. figure refs, part refs, callouts, claim refs, and claim terms) and can be extended to support more complex entity-value relationships (e.g. "soot particles measuring 0.2-0.5um").  Markup is rendered so as to be visible when naturally reading the document, automatic natural language processing continuously tags every change, and users can conveniently modify the classification rules without losing their train of thought.  TeamPatent thereby solves the key problem of generating and maintaining structured patent data with a semi-automatic graphical semantic editor that can be used by most practitioners.

Formal Requirements Verifiably Addressed
Examiners as of mid-2009 are allotted just twenty hours per Balance Disposal including two office actions.  Quotas prevent examiners from checking formal requirements so many errors and omissions are overlooked.  These deficiencies can become prominent in litigation and/or prevent US grants from being accepted at foreign PTOs (e.g. inconsistent claim term usage that would be ignored at the USPTO can lead to a final rejection abroad).

TeamPatent's automatic natural language processing continually validates every change, allowing users to address errors and omissions before examiners encounter them.  These immediate, comprehensive validation checks improve quality and timeliness.

Comprehend patent documents more easily
TeamPatent quickly and comprehensively assesses the scope of claims for a given patent document.  No need to print to more easily read.  TeamPatent allows users to more easily read patent documents on-line with side-by-side specification/drawings, visualize the claim tree, navigate from callouts to part references (and vice versa), and identify claim terms and help you understand how they're used in the documents. 

Integrate with eDAN, EAST, and OACS
To improve examiner productivity, TeamPatent may be integrated with the USPTO's tools.  First, TeamPatent can be integrated with the eDAN docketing system, allowing applicants to submit directly into the docketing system and examiners to launch applications directly into TeamPatent's analysis tools.  Second, TeamPatent can be integrated with the Examiner Automated Search Tool (EAST) allowing examiners to trigger creation of search queries from claim terms in an application, automatically suggesting synonymous claim terminology, and preserving a record of searches performed.  Third, TeamPatent can be integrated with the Office Action Correspondence System (OACS), allowing examiners to click on identified errors and automatically generate office actions including citations in the required format.

WIPO XML Standard
WIPO's XML DTDs specify how the file wrapper for a patent document may be encoded for PCT and national applications.  PTOs are capable of transforming simple transactions such as declarations or fee sheets into XML.  PASAT and ABX were designed to collect application bodies in the WIPO Application Body Standard but proved too difficult for patent professionals to use. 

TeamPatent's semantically-aware editor™ works with the patent professional in an intuitive WYSIWYG user interface to automatically recognize elements of interest and reconcile ambiguities.  TeamPatent already tracks the sections of the specification, individual figures, individual claims, claim references, and many other elements specified in the WIPO XML schema.  TeamPatent's internal XML schema (HTML) may therefore be automatically transformed to the WIPO XML schema via an XSL Transformation (XSLT).

The WIPO XML Standard was last updated in 2001.  It may be desirable to extend the standard to support the enhanced capabilities of patent-specific editors such as TeamPatent.  By tagging claim terms, part references, and callouts, USPTO examiners may automatically verify that formal requirements are addressed and comprehend documents more easily.  In addition, these elements may be used to trigger creation of search queries (automatically suggesting synonymous claim terminology).  Search results may be enhanced by displaying figures with emphasized callouts indicating features that match the query.

In particular, it may be of interest to add the following elements to the WIPO XML Application Body DTD (changes in bold):

• <!ELEMENT claim-term (#PCDATA) >
  # Validate support for claim terms and automatically drive examiner search functionality.
  • <!ATTLIST claim-term
    • id ID #REQUIRED
    • group CDATA #REQUIRED >
• <!ELEMENT part-reference (#PCDATA, reference-numeral) >
  # Track part references which contain both part name and reference numeral
  • <!ATTLIST part-reference
    • id ID #REQUIRED >
• <!ELEMENT reference-numeral (#PCDATA) >
  • <!ATTLIST reference-numeral
    • id ID #REQUIRED >
• <!ELEMENT figure (image, callout*) >
  # Extend preexisiting figure element by adding "callout" sub-elements
• <!ELEMENT callout (#PCDATA?, reference-numeral, annotation) >
  # Add callout elements which are link to reference numerals (and sometimes part names) in the specification.  Note, type and coordinates data types must be further defined.  It's desirable to extend this element's definition to support non-numeric labels such as block diagram contents, axes labels, and biotech figures (which are frequent although technically not in compliance)
  • <!ATTLIST callout
    • id ID #REQUIRED
    • type CDATA #REQUIRED
    • coordinates CDATA #REQUIRED >