Incremental changes and software protection

As a start-up founder, you have a great idea for a software product that can solve a problem, fill a gap,  and (ideally) create value for your customers. You have invested time, money, and effort to develop your software, and you want to make sure that it is protected from competitors, copycats, and hackers.

But how do you protect your software? The main tools are copyright and patents. We’ve encountered three misconceptions here:

• a general misconception that software is not patentable
• coming from founders, who assume that novelty is enough for patentability;
• coming from lawyers and accountants, who might favor copyright over patenting because of the apparent costs.

Let’s see where you might get it wrong.

Legally speaking, software can be protected by either copyright or a patent

Software is not automatically excluded from either patent protection or copyright protection. Actually, in recent years both the US and the EU patent offices are becoming more accepting of software patenting.

There are business and legal reasons when opting for one of them

Yes, patents might turn out to be costly, and there are multiple variables here: consultants’ fees, registration & renewal costs, number of markets where you seek protection. There are many others. However, when thinking long-term, there might be scenarios when the patent route might pay off. A patent is an asset that can increase the value of your company.  A patent will certainly help you raise investment.  Last but not least, a patent can be a PR instrument.

Non-obviousness/Inventive step - a potential legal barrier on the patent route

For a software invention to be patent-protectable, it needs to fulfil the novelty, non-obviousness, and utility requirements.

Software generally evolves by incremental changes and improvements, which may be a problem because even though version 2.0 may be novel and useful, it may not include 'inventive' improvements over version 1.0.  In other words, the respective improvements may be obvious to a trained engineer.  If that is indeed the case, version 2.0 is theoretically unpatentable if version 1.0 is already on the market.

Hence, the key to successful patenting is to start the patent application process as early as possible during the R&D cycle.  The 'early bird' strategy increases the chances of obtaining a high value patent that protects a core idea or aspect of your technology or product.  Incremental patenting is still possible in principle, but chances are the resulting patent is relatively less valuable.

Originality – a lower barrier on the copyright route

Copyright is a form of intellectual property that protects the expression of an idea, not the idea itself.  For software, this means that the copyright protects source code and the object code (the executable version of the software), as opposed to its functionality.

Your software doesn’t necessarily need to be revolutionary or inventive to qualify for copyright. It might be possible for your software to even fulfil the same functions as others.

But it does need some degree of originality. In comparing two similar pieces of software, you can ask these questions:

• are there actual lines of code copied literally?
• going beyond the lines of code: is the overall structure similar ?
• does it emulate the functionality of an existing program, without copying the original code?
• is there any uniqueness in the way it processes commands, its user interfaces, and underlying algorithms?

A proper cost/benefit analysis should also look at infringement

When choosing between copyright and patenting, one should also understand the scope of protection offered by each of the options.  Patents protect functionality, while copyright protects the code itself.  Programmers know that the same function may be achieved in many ways, which means that in software, a patent typically offers much stronger protection than copyright.  Stated otherwise, if someone manages to write code in a substantially different way than you, but still achieve the same functionality, he/she will not infringe your copyrighted code but will infringe a patent on the respective functionality.

Also, how are you going to detect infringement?  Do you have access to your competitor's code to be able to compare it to your copyrighted code?  Conversely, is the functionality aspect protected by your patent detectable?

Takeaways

Lesson #1. Patenting a software shouldn’t necessarily be dismissed. There are success stories out there if you plan accordingly and ahead of time.

Lesson #2. Identifying the inventive step for patent protection can be a challenge, and most software programs will not involve an inventive step, due to incremental changes.

Lesson #3. Copyright protection for software is more flexible and might ultimately turn out to be more suitable than patent protection, but also less valuable than a patent in the long run.

Lesson #4. Checking other barriers before the cost barrier might make more sense.

Thanks to Ștefan Gheorghiu for reviewing and improving an earlier draft of this piece.