Cloud Computing and Patent Trolls: How To Prepare Now

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.

1 2 Page 2
Page 2 of 2

Avoiding the Hash Problem in the First Place

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.

Finally, the indemnification and documentation won't do you any good unless they're easily accessible and hard to miss. Filing copies of the artifacts along with the source files in your code control system is one good step. Filing duplicates with your firm's legal department is another. Unfortunately, this is a cost of doing business that wont go away any time soon.

David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.

Follow everything from CIO.com on Twitter @CIOonline.

Related:

Copyright © 2011 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
The CIO Fall digital issue is here! Learn how CIO100 award-winning organizations are reimagining products and services for a new era of customer and employee engagement.