top of page

Why Patent Applications are Hard to Write

In my last post, Why Patent Applications are Hard to Read, I gave half the story. The other half is that patents are hard to read because they are hard to write. When a writer’s thoughts don’t flow smoothly, the resultant text doesn’t flow smoothly either.

A good patent attorney must use the inventor’s explanation to understand both the idea and what is inventive about it. This requires understanding the technology of the invention and also the ‘prior art’.

Many inventors don’t explain their thinking very well. Some start their explanation in the middle, assuming that we already know enough about their field to understand the problem they solved. Others explain their invention so broadly that, after listening for an hour, I still don’t know what they did or how they intend to implement their ideas.

Other inventors come to us before they have made any kind of prototype, when their invention is still an unfinished idea. Because patent applications require both an explanation of the broad concept and a “reduction to practice” (at least one possible implementation), we need to know how the idea might be implemented in order to write up the patent application. This type of inventor cannot yet furnish us with this information, so we send them away until they have finished developing their idea.

Other inventors bury us in detail. Their product is fully designed, so they can give us the production drawings or the final design document or code. This is usually too much detail.

Production drawings, for example, include all the parts of a product and have lots of lines in them that obscure the invention. Similarly, for design documents or code – much of the information listed in them are details needed to make the product work, but have nothing to do with the inventive aspect of the product. For many software products, we ignore all the user interface issues and concentrate only on the relevant internal elements.

These issues all make finding the invention difficult, which makes writing a patent application difficult. Without the inventive idea, you don’t have a good “storyline” and without a good story, it is hard to organize your thoughts enough to write clearly.

One way to find the story is to create drawings. We begin with a drawing that shows the context of the invention or the problem the inventor came to solve. Then, we need a schematic drawing showing the solution. I say a “schematic” drawing, because the first drawing of the invention should be a general one showing the main elements of the invention. If the inventor has prepared drawings for a presentation to investors or venture capitalists, one of these drawings is usually general enough or can be easily cleaned up to show the inventive concept.

Production drawings usually are not useful for this because they provide too many details of the product and not of the invention. However, I had one client who, in order to explain the invention to me, took the production drawings and deleted all the external parts until all we could see were the parts participating in the inventive actions.

The figure showing the solution should include the invention in the context in which it will work. Thus, a patent application for an invention which transmits data to an external element needs a schematic drawing showing the external element with which the invention communicates, even though there is nothing inventive in the external element.

The remaining drawings should provide details of the elements in the schematic drawing. These figures are easy to generate as they are just details of elements already in one of the earlier drawings.

How do we work with our different types of inventors? When I don’t understand what an inventor is saying (either because he gave me too much detail or because she is not giving me an implementation), I usually start by sketching what I understand the invention to be, and how it works within its context. I usually draw with block diagrams of some sort. Invariably, I draw it wrong and the inventor then pulls the drawing from me and starts fixing it. This is when I get an explanation that makes sense to me, an initial drawing that I can work with and, usually, a good storyline!

For inventors who haven’t finished developing their idea, I point to the elements of my drawing that are unclear and tell them to come back with a drawing or an explanation for those elements. This is a surprisingly useful way to work, as my inventors come back with very good explanations afterward.

Once I have a set of drawings, they usually give me an initial storyline. Nonetheless, I usually still have trouble writing the application smoothly because the inventor forgot to explain some important piece of information, or the drawings aren’t quite correct or aren’t consistent with each other or I still don’t understand something about the invention.

What we need are tools to steer clients to give us the information we need, before we start writing the first draft. The fewer texts we produce, the smoother the process of working on the application is for the inventors who find it difficult to read and reread drafts.

I have one such tool, which I will be talking about in my Patent Writing Workshop in Tel Aviv, Israel on April 29, 2018.

Recent Posts
bottom of page