Fenix
All articles

Patent Drafting Protocol

One of the foundations of modern telecommunications is called the protocol stack. A protocol is a set of standards about how information is passed from one “layer” to another. Having a clear protocol enables information to be passed cleanly between layers.

Protocol isn’t just useful for telecommunications. Here I want to describe a protocol for a patent preparation process based on an automated patent preparation tool. The reason for the protocol is that in this model, the work of patent preparation is divided into a number of distinct phases, and those phases need to work together seamlessly to create the final product.

Patent Preparation Phases

First, the patent preparation process is broken up into four phases:

  1. Claims
  2. Technical Description
  3. Automation
  4. Narrative

They fit together like this:

Patent Preparation Process

The protocol defines what the input and output look like for each stage. Here we will assume that we can’t really control the disclosure, although there are circumstances where that is possible, and when it is, it can make the process more efficient.

Claims

Since I am not assuming anything in particular about the disclosure, for the claim drafting protocol I will just focus on how to create structured claims that are more easily input into an automation system.

Every patent practitioner understands a few things about claim structure:

  1. Every claim is either a dependent claim or an independent claim.
  2. Every claim has a “class” (i.e., method or apparatus) that (for dependent claims) is inherited from its parent claim.
  3. Claims are broken down into pieces called “features” or “limitations”

One of the first things I learned about claim drafting is that it is quite common to take a claim from one class (usually a method class) and make another claim out of it in a very routine way. For example, imagine I have the following method claim:

A method of communication comprising:
receiving a message;
processing the message; and
sending a response.

This can easily be converted into the following apparatus claim:

An apparatus for communication comprising:
a processor, and a memory, wherein the processor is configured to:
receive a message;
process the message; and
send a response.

There are a variety of ways to do this, but they basically amount to taking a method and dressing it up as an apparatus. The key here is that although the second claim has an apparatus class, the substantive limitations are actually method steps. An automation system should make the process of converting a method claim into this kind of apparatus claim relatively easy.

Part of a claim drafting protocol might actually involve refraining from drafting repetitive claims (because the system might do it automatically, and including them might result in unwanted repetition). In other words, if your invention is expressed as a method, just write down the method and let the system do the rest.

Now, here is another version of the same claim:

An apparatus for communication comprising:
a receiver configured to receive a message;
a processor configured to process the message; and
a transmitter configured to send a response.

Notice that in order to convert the method version into this version, an automation system needs some additional information. Namely, it needs to know which steps are performed by which components. And this, my friend, brings us to the first rule of the claim drafting protocol:

<Every feature needs to be associated with a component>

Whether it is done right off the bat, or later on in the process, every step of every claim (even method claims) needs to have both a function (or in some cases, a description) and a corresponding component. This correlation between functions and components not only enables method claims to be converted into a more sophisticated apparatus claim, it allows a subsequent automation system to generate more substantial description for flowcharts and diagrams.

The next thing I want to mention about claim drafting is that the features (and not just the claims themselves) need to be properly layered in a tree structure. What do I mean by this? We mentioned previously that claims are written with a tree structure where each claim can have dependent claim stemming from it. However, in addition to this overarching structure, there is a more subtle structure among the individual features.

Consider the following two claims:

The method of claim 1, further comprising:
receiving an acknowledgement for the response.

and

The method of claim 1, wherein processing the message further comprises:
decoding the message;
generating the response; and
encoding the generated response.

The first example dependent claim extends the overall process of communication. Thus, it has a “horizontal” relationship to the features of the independent claim. The second example dependent claim drills down into the details of one of the features of the independent claim, so it has a “vertical” relationship. Specifically, the three features can be viewed as nodes that are located below the “processing” step of the independent claim. This brings us to the second aspect of the claim drafting protocol:

<Every claim needs to have a clear position in the claim tree, and every feature needs to have a clear position in a corresponding feature tree>

Doing this will make certain things easier. The preamble for dependent claims of the second type can be automatically generated. A nested structure can be inferred for automatically generated block diagrams. The relationship between different diagrams and flowcharts can be automatically described.

As will be discussed later, there is yet another tree structure that can be composed on structural elements, which can be different from the structure imposed on the features (i.e., because a component can perform more than one function). Depending on the sophistication of your automation system, you may want to impose constraints such as:

There are a few other things I should mention before moving on from claims. First, features that don’t add an active step (or additional component in the case of apparatus claims) also need to be in the tree. You know, these are the ones that start with “wherein” instead of “further comprising” like:

The method of claim 1,wherein:
the message is encoded using an error correction code.

This one could be placed in the feature tree either under the receiving or processing step.

Second, some features in apparatus claims have a description that doesn’t look like a function, or even none at all:

An apparatus for communication comprising:
a receiver;
an antenna connected to the receiver; and
a processor configured to process a message.

In this case, the role of the phrase “connected to the receiver” is pretty similar to the role of the phrase “configured to process a message” and an automation system may or may not make a big deal of the distinction. But the receiver doesn’t really have any function or description associated with it. That’s okay, it just means that not every apparatus claim can be converted to a meaningful method claim (setting aside method of manufacturing claims, which can be easily generated by tacking on the word “providing” in front of each apparatus feature).

Finally, it is usually not a big deal if a method claim includes two steps performed by the same component, but it will impact how a method claim is converted to an apparatus claim.

Technical Description

As with the claims, the technical description phase cannot generally assume any kind of structure on the input. So instead we will again focus on the output. And there are two main considerations when converting disclosure material into a technical description:

  1. how is the content described?
  2. how is the content organized?

The first issue has to do with converting disclosure content into language suitable for a patent. This involves removing “patent profanity” such as limiting language and admissions of prior art, and modifying the grammar to conform to a consistent style. It also might include converting equations and tables into a desired format.

At some point, aspects of this process may be automated (believe me, I’m trying). But for now, this is largely a human activity designed to prepare material that will easily be inserted into the automation process.

I didn’t separate this step out, but you could also consider the process of generating custom black and white line drawings as part of the technical description process. But as we will discuss later, many of the basic block diagrams and flowcharts (and the numbering) may be automatically generated later on.

With respect to the organization part, in a perfect world, the organization of the technical description would be one and the same with the organization of the claims. All content, whether it will be included in the claims or otherwise will be structured into one giant tree of content.

But, this takes a lot of effort and typically it isn’t worth it to try and organize every little piece of information in to the same degree as we would the claims. Plus, we generally want the claims to be drafted by an experienced patent practitioner and it is often more efficient to have a less expensive colleague help with the technical description. So, instead of trying to generate one giant tree of information, we want to find some compromise.

Because the technical description might be prepared concurrently (and by a different person) than the claims, a reconciliation process may need to after both of them are prepared and ready to be used as input for an automation system.

When I am training a new technical writer, I focus almost exclusively on getting the right kind of content, and leave the organization for later. Or maybe I will require some very minimal level of organization, like including headers that let me know what sections of content are about.

But at some point, all of this content is going to put into a patent document, and patent documents have a few sections that usually need to be populated with technical details: the background, an introduction to the detailed description (optional, but I like to clarify a problem-solution style description here), and, most importantly, in the description of the drawings.

I consider the background and introduction sections to be primarily narrative elements which I distinguish from the purely technical description. Plus, they are the parts most likely to be read by a casual reader, so I prefer them to have a nice flow. So, for the purposes of the technical description we are mostly interested in dividing technical content which figure description it will be included in.

Thus, the most basic protocol for organizing a technical description is:

<Each paragraph of a technical description should be associated with a figure>

So, in order to nicely divide content according to the figure where it should be included, we also need to know what figures are going to be included. To do this, it helps to have a categorization of the different kinds of figures. And just like claims have two fundamental types (method and apparatus), figures also have two basic types: diagrams and flowcharts. The main difference is that diagrams have numbered components and flowcharts have numbered steps.

The connection between claims and figures should be obvious. And sometimes, there is a direct correspondence between certain claims and certain figures. That is, a flowchart might include the exact same set of steps as a method claim, and a diagram might include the exact same set of structural elements as an apparatus claim.

Of course, not all figures correspond directly to claims. There are a few reasons for this, but one that I would like to point out is that patent practitioners prefer to draft claims in a way that avoids what we call “split infringement”. This means, we want claims that include steps that are all performed by the same entity, and in many cases, by the same device. So, in many cases it is very useful for a diagram or flowchart to depict contextual elements that would be harmful to include in a claim.

In any case, the reason I mention this is that it is possible to think of figures in terms of a tree structure, starting with the big picture and then either extending or drilling down into details. However, the highest level overview figures often correspond to a system diagram or a process overview that is at a higher level, or includes additional elements, that aren’t included in the claims.

In any case, another protocol for organizing technical material is:

<Diagrams are organized into a diagram tree, and flowcharts are organized into a flowchart tree>

I have some basic progressions that I like to include for each. For example, for a typical computer implemented invention I prefer to include a diagram showing the whole system including multiple devices and network components, then I like to include a diagram showing each primary apparatus, and then I include custom figures and detailed diagrams as appropriate for a given invention. But it is nice to start with a pretty systematic progression.

Also, sometimes it is useful to alternative between diagrams and flowcharts in the figure order. For example, you might start out with a high level diagram, then a high level flowchart…then maybe a lower level diagram and the corresponding level of flowchart, and then proceed to the next level of detail.

Before moving on, I should mention a few other things. First, in addition to identifying which figures you want, you will also want to determine what steps or components are going to go in each figure. You may or may not want to specify which paragraphs are associated with specific steps/components at this point.

Second, in some cases, it may be useful to distinguish between different kinds elements in a diagram. For example, you might differentiate between “factors” and “components” where factors are things like the inputs and outputs between components.

Finally, an automation system is generally going to provide some automatically generated diagrams and flowcharts based on the claims and other structural inputs. Since the claims aren’t always available when the technical description is being written, you don’t necessarily know exactly what figures you are going to include.

There are a few ways around this. One way is to at least provide the technical writer with a rough draft of the main claims. Another is to divide the figures into two types: those that will be determined prior to claim drafting and those that will be generated automatically after the claims are input into an automation system.

So the technical writer can organize content according some predetermined figures they know are going to exist. For example, they might know in advance to include an overall system diagram of a certain type, and an overall process flowchart, and certain other figures might be obvious to include based on the disclosure material. Then leave the rest of the figures until later on when both claims and technical content will be input into an automation system.

Automation

If you have nicely formatted claims, and your technical description is nicely organized according figures (and, potentially, individual components) the automation process is pretty simple. Just input the claims and the figures into the system and out pops your templates.

However, as mentioned above, in some cases you might have a hybrid system where the technical writer doesn’t know everything that will be included in the claims. So certain figures might be determined at the input time (and, in fact, they might be generated automatically, or with some level of assistance).

Here is an example of the steps for inputting content into an automation system:

  1. Upload the claims
  2. Make the identification between claim features and component elements
  3. Input custom figures (and associated components/steps)
  4. Automatically generate additional figures based on the claims
  5. Input content associated with each figure
  6. Print drawings and specification

Of course, these steps will vary depending on the system. But in the end, the automation system should output an intermediate template that includes the claims, summary, brief description, and detailed description of the drawings. In some cases, the technical content may be merged with the template after generation of the template, although there are disadvantages to doing so (e.g., then the system won’t be able to perform automatic numbering on components in the technical description).

Another aspect which may or may not be part of the automation process is the generation of a glossary. That is, an automation system may have some means of identifying (or facilitating the identification) of all the key elements in a patent document and making sure they are properly defined.

The basic organization of the documents at this point should be pretty familiar to any patent practitioner, so there is no need to go into too much detail regarding the usual protocol for patent documents imposed by the USPTO. However, at least in my system, there are a few pieces missing at this point which I call the narrative.

Narrative

Once a set of templates have been produced that include the claims, support for the claims, and the technical content from the disclosure, the patent documents are almost, but not quite done. The final step is to add the glue that helps them fit together as a cohesive whole and help a casual reader understand what is going on.

For me, there are three main steps in the narrative process:

  1. Write the background
  2. Write the introduction
  3. Review and modify the rest of the detailed description to fill in any gaps

As most patent practitioners are aware, the background of a patent is a pretty strange animal. On the one hand, it is often one of the first things a reader will see, so you want it to be clear and help set the stage for what will come. On the other hand, pretty much anything you put in there is like admitting prior art so you want to keep it brief, and in some cases, vague. So I consider the drafting of a background section something that requires a bit of experience and should be done by a skilled practitioner. It isn’t necessarily a hard thing, but it is high visibility and can easily go very, very wrong.

I put an introduction section prior to my description of FIG. 1 in the detailed description. For me, this is an opportunity to describe the problem in more detail than is appropriate in the background (although again, being careful not to admit prior art) and to introduce the solution in a clear, human readable way that doesn’t sound like footnotes section (which is one way to think of the description of the figures). Like the background, the introduction doesn’t have to be long, but it should be well written and can be very important if you ever expect anyone to read your patent.

Finally, the narrative step includes reviewing the document as a whole and making sure it all fits together, including additional details or transitions where necessary, filling in holes, moving things that seem out of context, etc. The key here, though, is to trust that the document already has most of what it needs to satisfy its legal objectives and requirements. This part of the process is primarily to make it readable.

One final note that I would like to make about the narrative step is that just as important as making some sections readable, it is important to let other portions of the document remain in a less polished form. If you try to make every section of the patent perfect, and merge narrative elements and support/technical elements perfectly, you will lose the time savings you gained by the automation and division of labor. This leads us to the final element of our patent drafting protocol:

<distinguish between narrative and support sections of a patent, and focus the final review on making the narrative elements readable, and the support elements acceptable>

Summary

So there you have an overview of the Fenix patent drafting protocol. The basic idea is that the process of drafting the claims can be separated from preparing the rest of the technical content, and that both of these processes can be performed in a way that enables them to be easily reconciled and entered into a patent automation system. Once all the pieces are in place, and the draft documents are spit out and the final product is filled out in a few places and polished all over so that it reads like a cohesive document.