Non-Patentable Software Architecture
I was working at Rational Software when IBM bought it almost 10 years ago. After the acquisition, we got emails and trainings encouraging us to file patent disclosures. As you may have known, IBM has been the top patent holder in the USA, maybe worldwide as well. At that time, I coined the term “non-patentable software architecture.”
Pattern system was invented to protect and encourage innovations. There are three criteria for a valid pattern: novelty, usefulness, and non-obviousness. Those are all in relative terms. As I can tell, there is rarely anything that is totally novel. Most, if not all, of the patents are built on top of something else with incremental innovations.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
Anyway, the purpose of this article is not to discuss the patent itself, but one of the requirements: non-obviousness. It means that a patent has to be not obvious. In other words, if something is obvious then it cannot be a patent.
Like other innovations, software is protected by patent laws as well. We can find many patents around new methods/approaches in algorithm, data format, even software process.
When it comes to software architecture, things become a little tricky. My take is that software architecture should NEVER be patentable. Why? Software architecture should ALWAYS be obvious therefore violates the non-obviousness requirement. If you are a software architect and want to patent your work, good luck!
I do have seen many architects coming up with patentable architectures however. You see nice diagrams with layers over layers and with long arrows going here and there. In the end, none of them work.
To understand why architecture should not be patentable, it’s important to understand why architecture is needed and serving what purpose.
First of all, architectural diagrams are optional because it’s NOT part of the final deliverable even though the idea is embodied there. You can skip it if you have thought it through your mind in one person project. In a team project, however, you got to communicate it over to others. Therefore it’s better to document it in some way, mostly with diagrams and a written document.
The architectural documentation not only keep everyone in the same page but also force the team to go through a high level exercise on what to build and how to build it. Although an architect is responsible for architecture but it really need everyone’s involvement and buy-in.
As you can see, the more obvious the architecture the easier and faster it can be communicated and followed. If architecture is not understood, it cannot be followed through the development cycle. With that in mind, you can see the value to make the architecture non-patentable.