Automating a Legal Workflow: Dealing with Patent Communications

Last time we looked at how certain legal processes could benefit from automation. Today we will identify some patent process examples.

This post (and the others in the series) may be useful for:

  • Patent attorneys wishing to automate their processes;
  • Software developers looking to develop legal products; or
  • Those who are interested in how patents work.

First let us have a look at a “vanilla” patent application. The process of applying for a patent looks something like this:

20131001-071717.jpg
The colour-coding is as follows:

  • Grey process blocks are performed in relation to a patent office (e.g. European Patent Office).
  • The blue documents are typically prepared by a patent attorney.
  • The green documents are prepared and issued by the patent office.

For now we will concentrate on the central blocks. Much of a patent attorney’s day-to-day work consists of reporting documents issued by patent offices and of preparing documents to file in response.

The search and each iteration of the examination go something like this:

20131002-184025.jpg

In my mind there are three areas in the above workflow where we could build an automated framework:

  • Initial brief review of objections by an attorney;
  • Detailed review of objections by attorney and development of a strategy to address the objections; and
  • The building of a response letter.

The reasons are:

  • To improve consistency, both for a single attorney and between attorneys;
  • To increase the chances of grant, by ensuring all outstanding objections are addressed;
  • To improve quality, by prompting an attorney for reasoning and basis;
  • To improve training, by embedding knowledge within the system and providing a guided path; and
  • To reduce stress, by providing a framework that ensures consistency and quality without requiring the attorney to remember to provide the framework; and
  • Last but not least, reduce attorney costs for clients by concentrating attorney time appropriately.

To start small, my aim is to build a web-based system for each of the three areas set out above. This system involves:

  • Creation of an XML document to store data;
  • Use of HTML forms to obtain data entered by an attorney;
  • Use of PHP to save obtained data as said XML document; and
  • Use of a letter-generation engine to generate letter text based on the XML document.

For example, a first stage may resemble the following flow diagram:

20131002-193447.jpg

The aim is that this should take no more than 10 minutes. Information is gathered that may serve as a framework for a detailed review. Also a brief review highlights anything that may need to be emphasised to an applicant (and avoids an attorney being negligent).

A web-form gathers data, which is stored as an XML document. A suggested DTD is as follows:

<!ELEMENT REVIEW (CASEREF, COMMUNICATION, COMM_DATE, OBJECTIONS)> <!-- ROOT ELEMENT-->
<!ELEMENT CASEREF (#PCDATA)>
<!ELEMENT COMMUNICATION (#PCDATA)>
<!ELEMEMT COMM_DATE (DATE)>
<!ELEMENT OBJECTIONS (OBJECTION*)>
<!ELEMENT OBJECTION (TYPE, COMMUNICATION, COMM_SECTION, APPLICATION_SECTION, LEGAL_PROVISION, REASON)>

<!ELEMENT COMM_SECTION (MAIN_NUMBER, PARA_NUMBER*)>

<!ELEMENT MAIN_NUMBER (NUMBER)>
<!ELEMENT PARA_NUMBER (NUMBER)>

<!ELEMENT APPLICATION_SECTION (CLAIM | DESCRIPTION)>

<!ELEMENT CLAIM (NUMBER)>
<!ELEMENT DESCRIPTION (PARAGRAPH+ | PORTION+)>
<!ELEMENT PORTION (START_LINE_NUMBER, END_LINE_NUMBER?, PAGE)>
<!ELEMENT START_LINE_NUMBER (NUMBER)>
<!ELEMENT END_LINE_NUMBER (NUMBER)>
<!ELEMENT PAGE (NUMBER)>

<!ELEMENT DATE (DAY, MONTH, YEAR)>
<!ELEMENT DAY (NUMBER)>
<!ELEMENT MONTH (NUMBER)>
<!ELEMENT YEAR (NUMBER)>

<!ELEMENT NUMBER (#PCDATA)>
<!ELEMENT REASON (#PCDATA)>
<!ELEMENT PARAGRAPH (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>

This results in an XML document similar to this:

<?xml version="1.0"?>
<review>
  <caseref>130929Test7</caseref>
  <communication>Article 94(3) EPC</communication>
  <comm_date>2013-09-29</comm_date>
  <objections>
    <objection entered="True">
      <type>unity</type>
      <comm_section>O</comm_section>
      <application_section>O</application_section>
      <legal_provision>O</legal_provision>
      <reason>Claims 1 and 5 do not share special technical features.<reason/>
    </objection>
    <objection entered="True">
      <type>sufficiency</type>
      <comm_section/>
      <application_section/>
      <legal_provision/>
      <reason/>
    </objection>
  </objections>
</review>

(Both are works in progress so forgive any inaccuracies.)

This generated XML document can then be used to produce a short sentence or two for a reporting letter or email. For example, something like:

The Examiner raises [No. of <objection> tags] objections: [list <objection><type> for each <objection>].

Under [first <objection><type>] ([<objection><legal_provision>]), the Examiner objections to [<objection><application_section>] on the grounds of [<objection><reason>].

Etc.

If and when instructions are received to review the communication in more detail, the XML document can be extended during the process below:
Detailed Review

Finally, the extended XML document can be processed by a letter generation engine (e.g. something built in PHP or Python) to generate text for a response letter:
Letter Generation

This is all a work in progress so I will update you as I develop more. Any additional ideas or comments, please add them below.

(PS: if you like the charts see my previous post – Drawing Patent Figures on the iPad – they were drawn quickly in Grafio while giving the kids breakfast.)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s