Patent protection for software

Software has always been a bit of a spooky beast from the standpoint of the US patent office.  Although hundreds of thousands of software patents have been granted, software can often blur the distinction between "device" and "method", and patent regulations, often written in an earlier era of gears, physical devices, and distinct chemicals, have occasionally been a bit ambiguous in this area. 

What is patentable anyway? 

According to US patent regulations, under 35 USC 101, "Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title."

The patent office usually understands new processes as "method" patents, machine, manufacture, or composition of matter as "utility" patents (and occasionally design patents), and usually tries to assign improvements into the "method" or "utility" bucket. 

There has been another category, business method patents, that has tended to be a bit on the line in this area.  In a widely known court case, called re Bilski, the federal circuit court (one step down from the Supreme Court) essentially depreciated this type of patent, and ruled that to be eligible for patent protection, a patent must be (1) tied to a particular machine or apparatus, or (2) transforms a particular article into a different state or thing.

From the standpoint of software patents, this can have some practical implications.  In particular, the Bilski decision means that it is a bit dangerous to be too abstract.  Many software experts and programmers come from a mathematics cultural background that rewards abstract thinking, and frowns on anything that is too specific.  They may falsely think that it is best to be as general as possible, and resist trying to put in specific "real world" examples where simple and understandable useful results can be obtained, and also resist giving real world examples of the machines that can run their software and algorithms.

As you can see from the above, however, applications that are too abstract will run into real problems if they are not (1) tied to a particular machine or apparatus, or (2) transforms a particular article into a different state or thing.

As a result, if you are a software developer trying to obtain a patent, or a manager of software developers, it will be important to unlearn some of the mathematics cultural values.  Although you may indeed include a generalized discussion in your patent application, you should also "lose status and guru points" by explaining, in as simple language as possible, exactly what the real world useful applications for your great invention are.  Also explain, again in as simple language as possible, what sort of real world machines - computers networks, etc. you envision your invention running on. 

Remember also that your application will be examined by an examiner with an undergraduate degree.  The examiner sees a lot of "bogus" patent applications, and thus will be highly skeptical.  If he or she does not quickly see why the invention would be useful and quickly understand what is really unique about the invention, the application will be rejected.  An examiner that thinks that you are trying to "snow" him or her is not an examiner that will give you an allowance.

The Supreme Court

The US Supreme Court is presently reviewing the re Bilksi case, and in the next few months, will issue their decision.  Although attempting to guess what ruling they will make is a bit like reading tea leaves, their questioning during the oral hearings suggests that they may be skeptical of business method patents as a class.  If so, then it is unlikely that the rules for software patenting will be made any easier. 

As a general rule, the patent office does not grant patents for pure math, and recent court cases show that it is important to write software patents that are 1) tied to a particular machine or apparatus, or (2) transforms a particular article into a different state or thing. 

When you are thinking of writing a software patent application, remember the Bilski decision.  Additionally, give at least some specific examples, and discuss at least some specific equipment.  Finally, please give your poor overworked patent examiner a break, and write in clear language that can be read by an intelligent non-expert.