An Antic Disposition

You are here: Home / 2009 / Archives for August 2009

Archives for August 2009

A Standard I Would Use: Auto Unsubscribe

By 8 Comments

I don’t get a lot of spam, at least not in the traditional sense of “unsolicited commercial email”. But I do get a lot of solicitations from online retailers with whom I have done business. As we all know, even a single order can trigger weekly emails. Multiply that by all places I do business with, and I end up with a lot of unwanted emails.

Certainly, the vast majority of these companies offer an unsubscribe option, with instructions clearly marked at the bottom of the email. These instructions tend to have a URL which I click and one of three things happen:

  1. Link automatically unsubscribes me
  2. Link takes me to a web page that asks for confirmation and maybe a little survey, or a list of mailings which I can opt-in or out of.
  3. Link takes me to a login page, where I need to remember my login id, navigate to a profile and perform several other steps before I can unsubscribe. I have some mailing lists that I have never been able to unsubscribe to at all. I end up defining inbox rules to delete the mailings altogether.

The idea for a standard is this: Can we encode these unsubscribe mechanisms, or at least the first two mechanisms, in a standard way in the mail message itself, so that an email client can allow the user to simply push a button and activate the unsubscribe procedure? If done right, I could even be in my inbox view and select several emails and unsubscribe to those lists all at once. Ideally no further user interaction would be required. And certainly I want to avoid the requirement to hunt through an email for the unsubscribe link.

Since emails can come in a variety of formats, from text, to HTML to RTF, it might make sense to handle this in the mail headers rather than the email body itself.

Of course, we want this to be simple and declarative and not require general-purpose scripting support, for simplicity and security reasons.

I think this would be a relatively simple standard to create. We just need some conventions for an email to declare a RESTful API for unsubscribing to a list.

Of course, maybe there is something like this already out there?

How Not to Read a Patent

By 11 Comments

There is perhaps no occasion where one can observe such profound ignorance, coupled with reckless profligacy, as when a software patent is discussed on the web. Note the recurring pattern, which is repeated every two weeks or so. A patent issues, or a patent application is published or patent infringement suit is brought, and within minutes the web is full of instant pundits, telling us what the patent covers, how it should not have been granted, how it is entirely obvious, or how it applies to everything in the world, and how it presages a self-induced mutually assured destruction that now leads us on to the plains of Armageddon. If I had a nickel for every time this happens…

By way of disclaimer, I am not a lawyer, but I am blessed that my self-avowed ignorance in this area is coupled with a certain knowledge of the limits of my understanding, a handicap seemingly not shared by many other commentators. I know what I do not know, and know when to seek an expert.

In the past few days we have had a bumper crop of pontification on the significance of two XML-related patents, one newly issued to Microsoft (7,571,169), and another older one (5,787,449) owned by i4i, whose infringement has resulted in a large judgment and injunction against Microsoft. I’ve found the web coverage of both patents to be an unmitigated muddle.

I’m not going to comment on the merits of either one of these patents, but I’d like to make a few basic observations that may be of some assistance to those who comment on future patent issues.

  1. A patent has a description known as the “specification”. And it has a list of numbered “claims”. Although the specification can define terms that are then referred to in the claims, it is the granted claims that define the scope of the patent, not the specification.
  2. If all you do is read the abstract and the first few paragraphs of a patent, then you may know the general topic of the patent, but you do not really know its scope. If you then go off and cry, “Oi vey, this patent covers XHTML, SVG, RDF, Pringles and Obama Healthcare Plan” then you do your readers a disservice. You must parse the very specific and often obtuse language of the claims in order to understand exactly what a patent covers. There is no short cut. This is not like a book where you can understand the plot by reading the back cover. But over and over again, I see people who just read the abstract, maybe glanced at a diagram, and then feel equipped to hold forth at length on the substance of the patent.
  3. When you try to understand patent claims, you will encounter a dense form of legal English. Claims are not written for a layperson and do not presume that you will understand it easily. The drafting of patent claims is a black art, like writing device drivers, and if you are not versed in its intricacies, then your statements on any given patent are apt to be wide of the mark. Claims are full of magic words. Know what you do not know. If you do not recognize at sight and know the interpretation requirements of a means-plus-function claim (which is key in the ‘449 patent), or you are not crystal clear on the distinction between the verbs “consist” and “comprise”, then you probably should not be the first (or loudest) person to speak on what a patent claims.
  4. If you are reading an application, know that during the “prosecution” of that patent, when it is reviewed by the USPTO, some of the claims of the patent may be thrown out, for any of several reasons, including prior art identified by the examiners. However, the specification of the patent is unlikely to change much. So an issued patent often has a very broadly-written specification, that covers the entirety of the originally claimed invention, though the the issued patent might have only a subset of the original claims allowed. So if you are have an issued patent and you look at only the specification, you can easily be fooled into thinking it covers far more than it does. For example, the ‘169 patent from Microsoft had half the original claims thrown out in the prosecution. If you don’t know that and are reading only the specification, not the granted claims, then you will incorrectly think the patent is far broader than it actually is.
  5. Know what a priority date is, and how that is affected by a continuation. I’ve read all sorts of nonsense based on not appreciating that. Take a look at the ‘169 patent, for example. It says it was filed in 2004. But if you look closely you see it was a continuation of a 2002 application. You can moan and groan all you want about prior art, but if you don’t get your dates right you’re off to a bad start in your analysis.
  6. In an infringement suit, like with the ‘449 patent, be sure to look at the actual court record. Typically there is a Markman (claim construction) hearing, where the court will determine the meaning of terms used in the patent claims. If you have not read the court’s claims construction opinion in the i4i versus Microsoft case, then your commentary is uninformed by probably the most important document in this case (well, next to the patent itself).

Well, that’s enough for tonight. Repent. Sleep on it. And realize that making sense of a complex patent takes time, if you’re going to do it right. Ergo, the first impressions you read from the instant pundits on the web will tend to be shallow, imperfectly informed and often wrong. Heck, even everything I said in this post may be wrong.