Understanding software patents

David Ng
12 years ago

NFC and Google Wallet. Most people have heard of one, or the other. Some even tried it before. And there are the very few that actually use it in their daily lives.

When a person uses Google Wallet to pay for purchases at a McDonald’s or a 7-Eleven, the tapping motion and the payment are not the most important aspects of the invention in the eyes of the law. It is what happens during the brief moment between those two actions, detailed within valuable documents. However, it is not simply just what happens when you tap to pay, but what happens when it does not work. Some examples to elaborate on this are: What if your account cannot be verified? What if your account balance is insufficient? What if in the process of paying, the power goes out – on your device, or in the store? What if your account balance is deducted, but the store’s system says you have not paid? What happens next? What is the process that takes place?

Welcome to software patent 101.

Patent eligibility

There is no such thing as a software patent. It is a term defined a few years ago by a non-profit organization from Munich, Germany called the Foundation for a Free Information Infrastructure. Their purpose is to establish a free market in information technology by removing barriers to competition. What they were actually defining is “a patent on any performance of a computer realized by means of a computer program.” In other words, the term ‘software patent’ as we all know today is actually a computer related invention filed as a patent.

As with all patents, the definition of the invention is crucial. For software patents, this goes beyond just the desired functionality and the codes that enable it. The protected patent is the invisible magic that lies between them.

To make matters worse, the law of patent eligibility in the United States has been on a roller coaster ride and is still unsettled in parts. However, the portion that affects software and business methods have been mostly agreed upon thanks to the case of Bilski v. Kappos, which was decided by the United States Supreme Court. This case left the industry with the “machine or transformation” test for patent eligibility, which requires a process to be tied to a particular machine or apparatus, or transform an article into a different state of thing, in order to be patentable subject matter. Basically, if the invention passes the test, then you have a patentable invention. If it does not pass the test, then you may have a patentable invention, because like every law out there, there is always room for maybes. Unfortunately, till this date, there has not been a computer related process that has failed the test and still found to be patentable.

The test is asking whether the claimed process is tied to a particular machine or apparatus. In the machine-prong test, the machine must impose a “meaningful limit” on the process claim’s scope, and the use of the machine must involve “more than insignificant extra-solution activity.” Therefore, the claimed process must be more than “for use with a machine,” and must truly require implementation of the method steps by and through a machine. “Extra-solution activity” is an activity that is not central to the purpose of the method invented. So, if the machine is only present in a step that is deemed to be insignificant extra-solution activity, the claim fails the test. An example of this is, a method untied to a machine would fail the test if the only link to a machine were to send you a text message at the end of the process about the end of the process.

It all comes down to the point where if you truly have a software product and you rigorously, thoroughly, completely, fairly, and fully describe the invention you will not have a problem meeting patent eligibility, as long as your application is done to the tune of Bilski.

Code – Ain’t nobody got time for that

Something that most people do not know is that the law does not require a single line of code to be written before you can patent software. This is especially frustrating for programmers that believe in computer codes being the quintessential element of software program. Unfortunately, that is not only false in the eyes of the law, but also real life. Computer code is a language and thus is more like instructions to explain what and how something needs to be done. Directions cannot be the core of a computer program, much like that included piece of paper with numbers and pictures is not the Ikea furniture you just bought.

To illustrate this further, let us bring in the other conflicting word this side of the law: copyright. Copyrights as most people know work to protect a word or a phrase from being used by others (see: iPhone/iFone – Brazil/Mexico lawsuits). In that same fashion, copyrights can also be applied to computer codes. But unlike patents, copyrights only protect the exact way said code is written. Thus, if you change one element of that code, you cannot be prosecuted by the owner of the original copyrighted code. This is why patents are a much more valuable asset. Software patents will not protect the specific code, but the actual functionality of those codes. This is crucial for those needing to protect their proprietary efforts. The real core of a computer program is the design of the system. The computer code merely implements the vision, the requirements of the desired design in language that a computer can understand. The invention according to patent law is the mental conception relating to the design of the system, the architecture and road map set forth for the various processes, computations and manipulations of information that is acted upon. It is this portion of the software that ultimately leads to a protected invention. Make no mistake about it, code is still relevant. Written code will be helpful, especially to the system engineer, but the entire system design is the real invention here. Therefore, when software related inventions are protected, it is not linked to the actual code.

All roads lead to flowcharts!

After all that background knowledge, you can now go and create your own software patents! Just one more thing about two things…

For an inventor of a computer process, there are two things that must be figured out beforehand. The first and sexier part of the two, is the desired functionality – what it ultimately does. The second is the entire jumble of processes and paths that could happen when the task is started. Referring back to the example in the beginning, this second part is all those questions and then some. A proper software patent application will include the overall architecture of the system within which software will exist, a single flowchart that depicts the overall working of the software, and a series of death-defying detailed flowcharts that encompasses every routine and subroutine that works together in reaching the desired functionality by the software.

A patent does not have to be a blueprint of micro-details, but simply be able to describe how a computer programmer would be able to get from X to Y, where X is the desired functionality and Y is the code enabling that. Therefore, what is actually included in the software patent is what happens between X and Y. That journey of described computer processes is what becomes protected under a software patent.

With all that in mind, did it match your own definition of a software patent? And are you one of the very few that buys Big Macs with your phone?

[To see how software patents are affected by the new America Invents Act since March 16, check out this previous article]