How to avoid a really big US Software patent headache

Patent examiners may object to US Software patent applications, alleging an “abstract idea”, following the US Supreme Court Alice decision [1], although there is no blanket ban of US software patents, as such.

This post is useful for any one, but especially non US patent attorneys, who have an interest in getting a US patent for a software or computer implemented invention (By way of background, you may wish to read about the 2-step Alice “abstract idea” analysis here).

I think it is fair to say that when Alice was decided, confusion reigned.  Everyone was unsure when an Alice objection should issue (including patent examiners) and how to respond (including Patent attorneys). No one knew how to draft a patent specification to dodge an “abstract idea” objection.

Some time has now passed since Alice. Attorneys have tested different response strategies, the lower US courts have given some guidance on the limits of an “abstract idea”, and the United State Patent and Trade Mark Office has issued relevant examination guidelines. There is less confusion, but still the relevant approach is often not known, especially outside of the US.

Some common response strategies by attorneys are emerging, and there are ways to draft patent applications that would have a better chance of passing examination.  I’ve summarised some of these below.

Drafting Tips post Alice

Ron Schoenbaum and Russel Jeide, from the US firm Knobbe Martens, shared their views in a webinar today and gave tips on drafting software patent applications for the US.

Both Ron and Russell stressed the need to de-emphasis business or commercial language, especially in the title, abstract and claims, least the application fall into the black hole of a “commerce art unit” for examination.

If the application is drafted so that it is assigned to a computer architecture, networks, or communications art unit, the application is much more likely to be allowed.

They also suggested that the background section of any software patent application should emphasis a technical problem that needs solving, and de-emphasis commercial problems.

Some further drafting tips include:

  • Include detailed technical disclosure
  • Draft the specification so that the invention only makes sense in a technical environment, and can not be done in a person’s head, and draft claims that are inextricably tied to computer technology, for example the internet, network applications and devices, IP addressed etc.
  • Include novel user interfaces, that improve the way a computer displays information or communicates with the device
  • Include non standard computing components, for example GPS units and card readers
  • Argue that the improvement is to the computer itself
  • Where appropriate, argue that the invention involves processing of data representing something physical
  • Claim processes and methods that can not be performed outside of a computer
  • Describe the invention running on a machine that is not a general purpose computer (e.g. medical device, slot machine etc)
  • Include low level processes not normally performed by a human e.g. conversion of gray scale images. 

In my opinion, these drafting tips are also very good for other jurisdictions, for example Europe and Australia.

Responding to an “abstract idea” objection post Alice

Ron and Russell provided the following advice when responding to “abstract idea” type objections.  They suggested:

  • Look to the USPTO examples of eligible computer software inventions and redraft the claims to be analogous
  • Argue that the claims are not directed to an abstract idea
  • Argue that the claims are directed to significantly more than the alleged abstract idea
  • Redraft the claims to make them inextricably tried to computer technology, especially the internet

Some other very useful tips regarding responding to an “abstract idea” objection are in this article by Christopher M. Hall.  I believe the main thrust of the outlined approach is to use examination procedures to force them to articulate reasons in support of the objection.  If they can’t articulate the reasons, they should withdraw the objection.

Christopher’s approach goes something like this.  First, identify the distinguishing features and argue that they are not in the cited prior art, they are not generally known, routine or conventional, and not found in the alleged abstract idea.

Consequently, it can be argued that the claimed invention involves “significantly more” than the abstract idea.  Furthermore, if possible argue that the claimed invention improves a technology, and that such improvement is not shown in the the abstract idea or the cited art.

Christopher suggests that if resistance is encountered, then it can be argued that the examiner is unresponsive to factual findings.  The resistance may be challenged for “lacking proper official notice”, or “not being properly based upon common knowledge,” as set out in the examination manual ar MPEP 2144.03.

[1] Alice Corp. v. CLS Bank Int’ll, 134 S. Ct. 2347, 2355 (2014)

1 thought on “How to avoid a really big US Software patent headache”

Leave a Reply

Your email address will not be published. Required fields are marked *