App Vendors, Fear Not the Troll or In-App Upgrade: Lodsys Patent Can Be Circumvented

As usual the tech world is frothing over software patents. In case you haven't heard, a number of sites have reported a select number of iPhone app developers have been hit by Lodsys with the claim they are infringing on one (or more of their patents). And, also as usual, the nature of the threat is overstated. This time the general consensus seems to be Lodsys have patents covering the in-app purchase mechanism and that, in troll like fashion, rather than take on Apple, they are going for the small guy, small software houses who have published apps to the AppStore.

I'm always amazed at how often tech articles about patents make generalisations, without reference to the only really significant piece of information, which is there on the web, for all to see; The patent document itself and the legally significant claims therin. Indeed out of the claims, one is most usually more important than all the rest and that is the first one. The first independent claim (independent claims are so called because they stand on their own and don't reference other claims) usually pretty much sets an umbrella over the scope of the patent. Having said that, especially in the US where the patent may contain a family of independent claims that are due to be broken out into a family of separate related patents - it's always safest to read each and every independent claim to gain a quick assessment of if the patent is troublesome. The independent claims are easy to spot, because they don't reference any other claims within the first sentence.

So I've scanned the claims of the Lodsys patents (US5999908, US7133834, US7222078, US7620565) and one of them immediately stands out as likely to be troubling to software vendors offering in-app purchase. Bear in mind, I'm not a patent lawyer, or making any claim over the quality of my reading and can take no responsibility if you take any actions based on what I am saying here (your own judgement and on your own head be it, etc, etc.) I do however have some experience with reading patent claims, so allow me to draw your focus to this one in particular, as listed on the USPTO website:

And here below, is the first independent claim. As annoying as software patents may be, put your annoyance to one side for a moment and think of it as like a linguistic puzzle. At first it will appear shockingly general, especially to technologists used to standard and well understood technology nomenclatures. But patent claims are a very carefully considered mixture of the precise with the general. When drafted properly, every particular of the phraseology makes a meaningful contribution to what is covered. Indeed read a few and most technologists soon start to appreciate the precision and care with which they are constructed.

1. A unit, comprising: a memory; a transmitter; and a processor, coupled to the memory and to the transmitter, configured to: monitor a product for an occurrence in the product of a trigger event of a predefined plurality of trigger events, increment a counter corresponding to the trigger event upon detection of the occurrence of the trigger event, cause the display of a user interface, configured to probe for information regarding a use of the product, if the counter exceeds a threshold, cause the memory to store an input received from the user interface, and cause the transmitter to transmit the input to a server.

In general the claim is the definition of a unit which displays a user interface and asks (or rather "probes" - it's always dangerous to paraphrase patent claims) the user for information regarding use of a product (and remember even a single bit response "yes" or "no" is information - remember what I said about the language, it is highly precise in it's generality) but that this occurs on detection of a trigger event and this in turn "corresponds" (deliberately vague) to a counter. So this appears to cover very generally replying to a question about the use of a product so that a server has information, presumably and most obviously to be able to take a further action such as provide an app update or additional feature (e.g, in-app upgrade).

Here the thing that stands out for me is use of the terms "increment a counter" and "trigger event". As is typical of patent claims, the phrase "increment a counter" has been carefully drafted to sound almost contingent to the detection of this "trigger event." But the very fact it is there means it is likely not to be entirely meaningless. For a start, to infringe this patent, the owner must have something that increments a counter that corresponds with a "trigger event" and if having a counter was merely an entirely contingent piece of frippery - the patent would be pretty useless. Therefore the inclusion of the phrase does effectively limit the patent. It limits by letting anything off the hook that doesn't include a counter that is in some meaningful way corresponding to the trigger event. So the use of the rather vague term "corresponds" is just that, vague; but not meaningless in terms of the legal scope of the patent. Patent lawyers always go for maximum generality whilst including only the tiniest bit of specificity required to make the "invention" stand out as distinct and novel and (importantly) as something that possesses technical effect. However it does mean that to infringe this patent, the vendor must be supplying a solution that has a trigger for the display of a user interface, with an increment counter that is in some way conducive to the triggering and indeed - as we read further - we see that the triggering is "if the counter exceeds a threshold" (though be careful, the threshold number isn't specified so may, of course, be no more than 1).

In other words, on my reading, in the context of in-app purchases, this only practically relates to solutions where the purchase is suggested as a product of the user trying to use a feature (whether entering it, exiting it, whatever) and that use being in some way counted (if only once) and then triggering a prompt (most obviously useful for prompting the user to make a purchase of the feature) when the count exceeds a threshold value.

Whilst this still appears to be highly general and very troubling, and whilst I personally suspect it may not stand-up as distinct over prior art if subject to a carefully exercise in object decomposition, it is most surely not the same thing as in-app purchase full stop. As usual the tech press reaction to this has been one of headline grabbing overreaction. Albeit a rather large indignant reaction is still in my view somewhat justified even for this more narrow case. However accuracy is important if we are to claim authority.

Practically speaking any vendors worried about Lodsys might want to consider avoiding tying the prompt for making an in-app purchase to the user's attempt to use a feature. Though I also think it is arguable that this patent doesn't cover an immediate prompt the instant a user attempts to use or exit a feature if that prompt is invoked based on a simple symbolic logic rather than through observing if a counter passes a threshold value.

I suspect - though I haven't yet investigated the apps from the vendors hit by Lodsys - they will be apps that allow the user to access a feature a number of times before prompt the user to purchase that feature if the user wishes to continue to use it. If that's the case, the easiest course of action for them to take is to stop the prompt being contingent on use of a counter and either make it a much more basic in-app purchase available somewhere in the app, or make it the product of simple logic which doesn't rely on storing or indexing a counter (though that may not for those unlucky enough to have been hit by Lodsys, prevent them suing for damages - it may help others). Note, in this latter case - even if a counter is used and the threshold set to 1 - it would be almost impossible to show clearly that the prompt is dependent on a counter without reviewing the source code (or executing costly reverse engineering), because such apparent behavior may also be achieved using a hard coded logical "if-then" condition.

Unfortunately, if my analysis is correct, it may mean Apple will decline to get involved. Though the patent is troubling, I believe it isn't one that effectively blocks the in-app purchase mechanism. I would love to see Apple hit back at Lodsys with a request for a declarative judgement. And who knows, they may take it as an opportunity to be seen to be backing the small guy and the myriad small business partners who help support their ecoysystem, as the very FUD patents like this create will surely have an impact on their business. And also they may feel they have an opportunity to make up in a small way for some of the lost goodwill over the way they have treated some businesses wishing to supply subscription content

[Edit: I've been thinking about his some more, and now I'm wondering if it is possible to entirely circumvent the Patent by implementing a logic that doesn't implement a pure counter. If the prompt to purchase a feature is triggered according to some other measurable factor, such as data volume, it might be entirely arguable, even if the data volume happens to correspond to a count - that the prompt is no longer contingent on the use of a counter. I'm fairly sure there is case law around deliberate implementation of complex features where that complexity is purely a means to avoid an obvious and more direct implementation covered by patent claims (I would certainly recommend you ask a patent lawyer if you are and app vendor thinking of taking this line), but still, it would be interesting to see if any developers can come up with useful and meaningful alternatives, especially if they are meaningful for reasons other than simply because they allow you to say "it's not a counter"]