There has been a lot of interest of late in a patent filed (by Google) back in 2009 for what is obviously a rendition of Android's notification bar system. There are a number of pretty (well, as pretty as black and white gets) figures in the patent showing the notification bar we all know and love, and lots of language about notification systems and the like.

As many of the Android-faithful know, Apple recently implemented as part of iOS 5 the "Notification Center," and it looks an awful lot like Android's in some respects. This immediately drew criticism from the Android community, with many claiming that Apple had essentially "ripped off" Google's implementation, and has been a sore subject ever since.

So when news of this notification patent started spreading, many were quick to hold it up as Android's newest weapon against Apple's legal onslaught. No doubt, it also bestowed a sense of vindication among Android fans - who's got the patents now, Apple? But it's just not that simple, and I'm going to show you why. But first, we need to talk a little about patents.

Claims, Claims, Claims

If you're not versed in how one goes about filing (or, as is said in the legal profession, prosecuting) a patent, you may not know how a patent is basically structured.

Essentially, you have:

  • The abstract: this is a brief summary of the invention.
  • Field of invention: the type of invention this is (mostly for filing organization purposes).
  • Figures: Pictures of the invention.
  • Prior art: Where you explain how your invention is not like and improves on problems with existing, related inventions in the field (if any).
  • Consistory clauses: An explanation of why and how this invention's claims are useful.
  • Specific description: An area where technical terms and concepts relating to how the invention functions in a more low-level, detailed, and scientific manner are explained.
  • What is claimed: This is what matters - this is where you state what your invention does, and in individual clauses called claims, the unique ways it does or can do those things. This is what the patent office and courts look at (primarily) when determining the scope and validity of a patent, as well as the liability of potential infringers.

Now, the specific description of the invention is generally important when determining how to actually interpret the claim language of a patent, and for figuring out if two similar inventions that accomplish similar tasks are actually, technically similar enough that one must be infringing the other. These kinds of questions are so technical and far beyond the average person's knowledge that they're often left to judges to decide in what are called "claim construction" hearings through the use of so-expensive-it-would-make-you-sick expert witnesses.

They're always a relevant issue, and always debated in patent lawsuits, especially in high-tech cases, but we'll only be looking at this section as it applies specifically to some of the claim language, and in a pretty simple way.

What we're here to talk about are claims, then.

When you are accused of infringing a patent, you aren't accused of infringing the whole patent. You're accused of infringing a claim (or multiple claims) therein. This makes it far easier for courts and juries to understand and narrow down what's really at issue in an infringement case, and it makes it simpler for the patent office to deconstruct what the patentee actually wants to patent. Claims are further made up of "elements," and in order to show infringement, every element of the claim in question must be infringed by the accused infringer.

The first claim of a patent will often be one that describes generally what the invention is and what it does, in a reasonably specific enough manner that isn't overbroad or vague. Subsequent claims will often be dependent on the first claim (or dependent on a claim that is dependent on the first claim), describing specific ways the first claim may be implemented. Being too broad or vague will result in a claim being invalidated (in court or on reexamination) or narrowed (during patent prosecution), while being too specific can limit your ability to protect the invention - it's a balancing act patent lawyers are constantly at odds with.

Basically, the claims need to sync up with what is described in the specific description section - if a claim could be interpreted to extend beyond the scope of the invention as described, it has to be narrowed or stricken from the patent.

Still with me? I know, it's getting complicated - but we're about to reach the meaty part of the discussion, and you probably need this primer to really understand what I'm about to explain.

So, What Does This Have To Do With The Notification Bar?

Everything. Let's talk about the claims in Google's patent application, shall we? US20090249247A1 (catchy name, eh?) was filed over 3 years ago - January 2009, by Erick Tseng, then a senior project manager for Android at Google (he now works for Facebook).

In this patent, titled "Notification of Mobile Device Events," I have identified what amount to three major claims of a total 22. Because this is only an application, Google's lawyers have drafted a "dream team" of claims. It's a common practice in patent law (and frankly, all types of law) to over-file to some extent, and then negotiate down to what's actually realistic.

Case-in-point is Google's 4th major claim, #21, which claims the following:

21. A computer-implemented notification system, comprising:

a wireless interface to receive data that includes messages for a user of a mobile device;

a notification manager, operable on a computer processor, to generate a notification message for a received message that includes information that describes the message; and

means for generating a display of information corresponding to the notification message on a graphical display.

Here, Google is attempting to claim, basically, the entire concept of a notification system. It seems possible, even likely, that this could be interpreted as covering Apple's (or even Palm's) older notification implementation, or any kind of pop-up notification. This one is a definite longshot.

But let's hop over to the first major claim. It seems likely to me, upon examining the language carefully, it would be infringed by Apple's Notification Center. Here's claim #1:

1. A computer-implemented user notification method, comprising:

displaying, in a status area near a perimeter of a graphical interface for a mobile device, a notification of a recent alert event for the mobile device, wherein the alert event corresponds to a change in status of an application operating on the mobile device or of an account associated with the mobile device;

receiving a selection in the status area by a user of the mobile device; and

in response to the receipt of the selection, displaying, in a central zone of the graphical interface, detail regarding a plurality of alert events for the mobile device, wherein at least some of the plurality of alert events correspond to messages received by the mobile device and the detail includes text from the messages.

You'll note that I've highlighted the phrase "in a status area." There's a good reason for this - this is what we call limiting language. Google has confined the definition of this claim to include only implementations of a notification event in the "status area." Of course, what is a status area? Google defines it earlier in the application as the following:

... a peripheral area at the edge of a display, such as a status area, or status bar, for the mobile device. The status bar is the area in which status indicators such as battery charge level and signal strength level are traditionally displayed—typically at the top of a display.

What is less clear is how the language "in a status area" would exactly be interpreted. Watch this video of a notification being received in iOS 5. The issue is that the iOS 5 notification does not go in the status area - it replaces the status area with an entirely different graphical element. And while locked, it doesn't go in the status area at all (it goes underneath the clock).

Compare the instant the notification arrives and how it appears in relation to the status bar.

Yes, such minute distinctions are actually relevant to the debate here, because it is undoubtedly a point Apple's legal counsel would hammer on when denying an accusation of infringement.

Google's implementation, on the other hand, merely clears the status bar of all battery, signal, and other information in order to display the notification - actually utilizing the status bar. At this point, I would probably call to a concept called the "doctrine of equivalents," which (to oversimplify it a bit) basically says that if one invention doesn't actually literally infringe on the language of a patent claim, if it works in essentially the same way to achieve essentially the same end goal, it's still infringing.

This kind of argument may come down to coding implementations or other technical details, though - so I won't delve into it further. But there is a reason that the first claim should be interpreted to include Apple's implementation. The second claim specifically encompasses the method by which Google provides notifications in Android:

2. The method of claim 1, wherein the notification is displayed in place of battery and signal elements in a status bar that comprises the status area of the graphical interface.

This would, by simple logic, mean that claim #1's definition of "in a status area" encompasses implementations beyond the one Google uses (placement in the actual status bar). At least, that's the argument I'd make.

The "selection in a status area" language merely means that the user provides some sort of input in the status area (where the notification immediately populates) to learn more about the notification - either a pull-down or a press (iOS does both, Android usually only does the pull-down method, except on tablets). iOS clearly infringes on this element.

The third clause about a "central zone" of the GUI displaying "text from the messages" refers to the whole notification center pull-down that aggregates notifications and, if applicable, makes some mention of their content. It's pretty obvious Apple's implementation infringes on that element of the claim, as well. Just compare to Android:

Note that both pull down via the status bar, both aggregate multiple notifications, and both display some of the content of messages.

Although obviously different aesthetically, the concept as defined in the above element from claim #1, without a doubt, describes both of these notification systems.

Another, broader claim by Google (though not as broad as #21) is #18:

18. A computer-implemented notification system, comprising:

a wireless interface to receive data for a user of a mobile computing device;

a notification manager to generate a notification message for a device event, including device events received through the wireless interface, where the notification message includes information that describes the device event;

a display manager, operable with a computer processor, to generate elements for a graphical display, to receive the notification message and to present the notification message in a first zone near a perimeter of the graphical display; and

an electronic input device to receive a user selection in the first zone, wherein in response to the user selection, the display manager displays, in a central zone of the graphical interface, detail information regarding a plurality of recent messaging events for the mobile device.

Based on the language here, I would say that this claim attempts to patent any system by which notifications are sent to a device, and that causes them to appear in or around a "status area" (a "first zone near a perimeter") which can than be selected to display a centralized list of notifications. This is definitely broader than claim #1, and almost certainly would be infringed on by iOS 5's Notification Center. But there's one big caveat I haven't mentioned yet about this whole patent.

Published vs. Issued: In Limbo

You'll notice that if you try to find this patent in the USPTO's public database, it's not there. That's because this patent is still in the process of prosecution, meaning language changes, potential removal of some claims, and amendments are probably all still being worked out between Google and the patent office.

Under US law, you can sue for damages caused during the published but yet-to-be-issued phase, but not until the patent is actually issued. This is why Google has yet to sue Apple, at least that's the case if we're assuming Google would want to sue Apple at all on this patent. In fact, we don't even know if Google will get this patent in the first place, prior art could very possibly kill it, and I'm sure Apple and others are working hard to generate all the prior art they can to make that happen.

At this point, we'll just have to wait and see how this patent looks when (and if) it comes out of the patent office, and it's hard to say when that could be - the average patent issuance wait is rapidly approaching 4 years for software. Expect it to be even longer for one that is likely to be as hotly disputed as this.