Why your company can be sued for using SD-WAN

And a lawsuit is the last thing you want to factor into your IT budgets.

08 lawsuit
Thinkstock

When you buy your SD-WAN, or for that matter any WAN technology, you sort of assume that the vendor has the legal right to sell it to you.

But what happens if they don’t? What happens if you’ve built your WAN on an illegally acquired technology?

The question is not just theoretical. Last week, FatPipe sent me a press release pointing out how United States PTO Patent Court upheld a signature claim to its U.S. patent (number 6,775,235) for load balancing across disparate networks. Load balancing is a critical component of all SD-WAN products. As such, FatPipe could, in theory, claim licensing fees from SD-WAN players and their users.

It’s a claim that anyone looking at SD-WAN cannot simply ignore. Back in the '90s, the Token Ring market was in part stymied because the inventor, Olof Soderblum, charged licensing fees for the technology, raising Token Ring costs. Vendors will use patent claims to deter competitors.

Riverbed did as much in the WAN optimization market. Are we headed for a similar fall out in the SD-WAN market? (I’d like to hear what you think. Leave a comment for me here.)

Is this real?

I’m not a lawyer, but I have spent a fair amount of time involved with intellectual property law. At one time, I ran Fabulous Footage, a licensor of motion picture stock footage, before selling to Getty Images. Another company where I managed intellectual property, One Zero Media, was the exclusive entertainment content provider to AltaVista.

All totaled I negotiated over 150 licensing agreements at those companies.  I also took a course at Harvard Law School on the Intellectual Property and Digital Millennium Copyright Act (DMCA).  In the process of working with clients and their attorneys on licensing and service agreements, I have collected a breadth of real world experience with these agreements.  

And in looking through the patent, it looks pretty cut-and-dry to me. But it’s not.

I just spoke with the patent counsel for Talari and in his word’s Fatpipe’s press release is not correct. The patent office has not proven that the claim is valid.

FatPipe has sued multiple parties on two of its patents (U.S. Patent 7,406,048 and U.S. Patent 6,775,235) including 36 claims against Talari Networks. Those cases were stayed so that the U.S. Patent Office could review FatPipe’s patents. Last week, the U.S. Patent Office issued two separate decisions against FatPipe. 

The first decision held that all 24 claims of FatPipe’s ‘048 patent were unpatentable. (See IPR2016-00977 FD FINAL.pdf). The second decision held that all but one of the 12 challenged claims of FatPipe’s ‘235 patent were unpatentable. (See IPR2016-00976 FD FINAL.pdf). The single remaining claim was not, as was suggested by FatPipe, ruled to be valid and in fact is still being challenged in other proceedings, including by Cisco and Talari.

So FatPipe lost 35 of 36 claims before its cases even got warm and tried to sell it as good news. That’s good news for SD-WAN users who are unlikely to have to worry about FatPipe coming after them any time soon.

What you should do

Patent infringement cases come and go in the networking industry. Enterprises can and should protect themselves to avoid any problem.

It’s not that difficult.

Make sure contracts have an indemnification clause. It’s standard for all of the vendor contracts we negotiate for our customers and your supplier should be doing the same. Basically, the clause has the vendor warranting they legally own the technology and in the case of a problem, will cover any third-party claims against the customer. Remember that vendor contracts are designed to protect them, not you.

No matter what you do, don’t dismiss the issue. A lawsuit is the last thing you want to factor into your IT budgets.

This article is published as part of the IDG Contributor Network. Want to Join?

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.
Now read: Getting grounded in IoT