The Cloud Communication Platform Giant Twilio’s Patent US8738051 Can Get Invalidated
Less than a month ago, Twilio Inc. filed a suit against Telesign Corporation for willful patent infringement. According to the complaint by Twilio, Telesign was a previous customer, and its co-founder and vice-president of product strategy Stacy Stubblefield had a private Twilio account.
Twilio accused that Telesign’s engineers learned of the technology and API used by Twilio while they were still a customer, and later applied this learning to build its set of products, which infringed 7 of Twilio’s issued patents.
For those unaware, Twilio is a Cloud Communications company, known for its use of platform evangelism that allows developers to build and manage applications without the complexity of creating and maintaining the underlying structure. More specifically, it provides a cloud communication platform for developers to embed voice, messaging, video, and authentication capabilities into their application.
A most notable example of usage of this platform is Whatsapp and GroupMe. Other big corporations including the likes of Wal-Mart, Uber, eBay, Salesforce.com, Sprint, and Airbnb use Twilio products, to add communication capabilities to their applications.
With 47 US patents in its arsenal, it might seem that Twilio spent a lot of research efforts on getting their patents issued, but one among the seven patents in the case- patent US8738051B2– appears weak.
Handpicked Suggestion: How These 15 Claim Chart Mistakes Can Kill Your Chances To Win Litigation ( with Printable PDF)?
The given patent (which would be referred to as US’051 henceforth) has a priority date of July 26, 2012. But as per our analysis, the idea described in patent US’051 existed much before July 2012. Taking this cue, we conducted a preliminary analysis and found that there were really good chances of invalidating the patent.
But before we list the prior art hotspots, it is important to understand what ‘051 protects.
What is US’051 all about?
Belonging to the field of telephony messaging, US’051 claims to protect the method/system to select the best routing carrier for transmitting messages. The method comprising:
- sending a telephony message through a first channel using a first routing option;
- receiving a message delivery report through a second channel;
- the delivery report comprises feedback of the transmitted message and accordingly prioritizes the routing options.
- Selecting a more prioritized routing option for transmitting another message through a first channel.
Where we detected Prior Art ‘Hot-spots’ (prior to July 2012)?
- The idea of a delivery report containing the feedback of the transmission route was well known from 3GPP Multimedia Messaging Service (MMS) standard specification CR 23.140. This standard started developing during the period of 2000 – 2002. Below is the excerpt of the relevant section from a document related to this standard:
Delivery Report: feedback information provided to an originator of MM (MMS User Agent or VASP) by an MMS Relay/Server about the status of the delivery of an MM
7.1.11 MM4 forward routing failure
If the interworking between two MMS Relay/Servers fails and a MM can not be routed forward across MM4, the originator MMS UA should be notified. If the MMS UA is notified the procedures described in this section shall be followed.
In case the originator MMS UA has requested a delivery report to a MM that failed to be routed forward across MM4, the originator MMS Relay/Server shall generate and send a delivery report that informs the originator MMS UA about the error.
In case the originator MMS UA has not requested a delivery report to a MM that failed to be routed forward across MM4, the originator MMS Relay/Server may generate and send a MM that informs the originator MMS UA about the error.
[Text from C1-050962]
The routing of MMS can follow the scenario illustrated below. The MM4_forward.REQ message follows a different routing from the MM4-forward.RES message.
The above-quoted text provides an important lead. If more exploration is done in this standard, there are good chances to find a good prior-art.
- Standard Search: There’s a new dimension to search. During the examination of the patent US’501, it was seen that the examiner mostly relied on publications related to SMS standards and focused on patent literature, while the claims are nowhere limited to that.
In fact, the concept of message delivery report/notification existed in multiple communication standards like e-Mails, MMS, GSM, CDMA, and all 2g/3g related standards.
To give an example of few: IETF standards RFC 1891, RFC 3461, RFC 3462, RFC 3463 and RFC 3464 are related to electronic email discussing the delivery report service. Similarly, RFC 4356 and 3GPP standard CR 23.140 are related to MMS delivery report. Since the concept of delivery report notifying the routing error was there since 1996, exploring these standards seem to be a promising area for looking for a good prior-art.
- After performing a quick search, we observed that companies like Huawei, Lucent were closely working on the concept of “sending the message on the prioritized route based on the delivery reports”.
To give a few examples EP1998526A1 (published in Dec 2008) EP2007152A2 (Published in Dec 2008), US20090221310A1 (published in Sep 2009) from Huawei seems to be quite related to ‘051, more specifically EP’526. Below is the excerpt of the relevant section from this publication.
After sending the message and receiving a delivery report of message sending failure, the IP-SM-GW can perform the subsequent processing according to the received delivery report of message sending failure; in other words, when a message fails to be sent via a certain sending path, the IP-SM-GW should try to send the message according to the priority order of the other sending paths. For example, deceiving a delivery report of message sending failure returned by the S-CSCF, the IP-SM-GW re-sends the message to the SGSN according to the priority order of the sensing paths. In another example, after receiving a delivery report of message sending failure returned by the SGSN, the IP-SM-GW continues to send the message to the MSC according to the priority order of the message sending paths. If the IP-SM-GW still fails in sending the message after trying all the sending paths, the IP-SM-GW deletes its stored message, and forwards a delivery report of message sending failure to the traditional message routing entity.
Having had a look at the above pieces of evidence, we are certain that some good prior art could be found upon a deeper search. Invalidating this patent, we feel, is not a tough nut to crack.
Authored by: Nikhil Gupta, Manager, Search Team.
PS: We regularly conduct preliminary analysis to find whether a patent in question holds water or not. So if you want us to remind you of new analysis, consider subscribing to the alerts from the form below: