The asserted Helferich Patents do not “cover” the MMS messaging standard.

On August 14, 2013, Helferich Patent Licensing, LLC’s patent infringement litigation was dismissed on the basis of the doctrine of patent exhaustion. On August 29th, 2013, HPL stated their intention to appeal the decision. In case you still have reservations about using SMS with links then you should consider sending your links in an MMS instead. I will explain to you why sending an MMS message does not infringe on their asserted patents.

Similar to IMAP email headers, an MMS notification message contains the message subject and other information in it. The Helferich patents are limited to notifications where the content is not included in the message. The reason an MMS notification contains the “subject” field is so that if the mobile device is not setup to automatically fetch the MMS content (or the data service is turned off) this allows the MMS device client to present the message information to the end user without the device retrieving the message. The end user would see the From, Subject and Timestamp but not the message. The end user can then decide whether to download the MMS content.

MMS operates the exact same way as your IMAP email client works today and has worked since IMAP was invented in 1988. I am purposefully emphasizing the date and the spec because it predates the HPL patents priority date of 1997 and the technology was released freely to the world by the hundreds of collaborators who actually invented it. It is prior art. Lets go over the IMAP process real quick. First your email device registers with the email server. The email server pushes the message headers to the email client first with headers and identifiers so it can fetch the whole message later. Next your email client (manually or automatically) tells the email server which identifiers it wants to download and retrieves the email message content.

The creators of the 3GPP MMS standard based MMS on the Email spec to prevent patent exploitation and because it was so widely used and successful. Today, MMS routing between two carriers is done through email and MMS uses the same multi-part mime formatting within the message body so it can be transported through email without any issues. MMS and EMAIL are fundamentally the same thing only is presented a different way on the device (MMS uses SMIL vs. Email uses HTML).

I digress…

Sending an MMS does not infringe on their asserted patents for the following reasons:

1) The HPL patents are limited to selective call signals where the signal does not contain the content. MMS messaging notifications, or MM1 notifications contain a subject, as well as other “flags”. The subject in the notification IS ALSO contained in the content file or body. The flags MAY ALSO be contained in the content file. In other words, the subject is in the notification and in the body. The content is therefore in the message notification and therefore not infringing.

2) The HPL patents are limited to a selective call signal. While an MMS message notification can be delivered in a single selective call signal they are often broken up into multiple selective call signals in order to deliver the full notification payload. The reason it may or may not be able to deliver the full payload in a single selective call signal is that the information IS contained in it. An SMS is limited to 160 characters so mobile network operators use message concatenation to break up the notification and merge it again at the device.

3) MMS messages are delivered by a mobile network operator, not by the advertiser, brand, service provider. So unless you are a mobile network operator actually delivering an MMS message then your company is a “downstream user” for this technology. In other words, the asserted patented method is entirely performed by the mobile network operator. There is also no way for a downstream user to know whether or not the mobile network operator is infringing since they are neither sending the selective call signal, adding information to the call signal, hosting the link or hosting the content.

….and many more