Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Cloud computing and patent trolls: How to prepare now

David Taber | Feb. 22, 2011
Cloud computing, like any hot technology, has caught the eye of the patent trolls. Your developers need to avoid their day (or month, or year) in court with them.

So what was the problem, anyway? Your team developed the hash algorithm on their own. Sure, but that doesn't matter: you don't have to copy IP to infringe on a patent. All you have to do is use the same "novel method" that is protected by somebody's patent. Even though you have the ultimate "clean room" implementation — you don't even know about the patent you're infringing — the rent will come due if the patent holder finds out about it. And of course, it's not just hash calculations: lots of ideas and methods are patentable.

With software you're writing entirely for internal use, there's not much risk of somebody external discovering at infringement. But in the cloud, the whole point is to allow your web services to be used by others. You build an API based on a hash algorithm, and then you publish it to the world. Now the trolls can find you. And the more external parties use your clever little hash algorithm, the larger the royalties and damages can become. Lovely.

Of course, hash algorithms and protocols and business process automation mechanisms are commonplace in advanced business software. It's not like you can stop using them just because you're doing work in the cloud. But what you can do is buy, rather than build, these externally-visible components. When you buy them, though, the whole point is to get indemnification from IP infringement. Grabbing something from Sourceforge won't cut it — there's no indemnification unless you've got a contract with a vendor who will stand behind it.

If you can't or don't want to buy these components, then you must have an internal coding standard that requires the developers to document the prior art that they based the clever externally-visible parts of their software on. Whether it's a commercial product or your own internal development, you need to have documentation of when the "original" work was first brought to market (because the prior-art argument only holds if the IP was in public view at the time the patent was filed, not years later when it was granted). If there are textbooks or articles that refer to the techniques your team used, cite them in the footnotes. Although this chore will likely irritate your developers, only they can research the provenance of the IP you use. Once that task is done, the project manager or documentation team can do the actual write-ups and annotations.


Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.