Friday, July 20, 2012

Munich court to decide on Apple's overscroll bounce patent in Motorola case on August 9

Yesterday I attended a second hearing, tantamount to a trial, on an Apple v. Motorola Mobility lawsuit at the Munich I Regional Court. At the first hearing in April, Motorola had virtually admitted to the infringement of Apple's "overscroll bounce", or "rubber-banding", patent (EP2126678 on "list scrolling and document translation, scaling, and rotation on a touch-screen display", the European equivalent of U.S. Patent No. 7,469,381, which I once dubbed "Apple's favorite make-Android-awkward patent"). Instead, the Google subsidiary focused its defense on its invalidity contentions.

At yesterday's trial, the judge presiding over the case, Judge Dr. Peter Guntz, indicated in his introductory remarks that a couple of non-infringement arguments made by Motorola Mobility were unpersuasive. Motorola's counsel didn't even address this part of the case yesterday.

As Judge Dr. Guntz noted, the overscroll bounce patent is related to the photo gallery page-flipping patent that his court already held infringed by the Android photo gallery in its "zoomed-in" mode. That patent is a narrower derivative of the overscroll bounce patent.

The prior art reference discussed at yesterday's trial was LaunchTile, a study sponsored by Microsoft in the middle of the last decade. I found a LaunchTile video on YouTube, the second half of which shows the part that Motorola in this action and other Android device makers in other actions refer to. This could be the video that Apple recognized as eligible prior art. There are also some LaunchTile videos that were published only after the priority date of Apple's relevant patent application. The most important LaunchTile prior art reference in this case is an article that was published in 2005.

While Judge Dr. Guntz said a decision on whether to grant Apple an injunction or stay the case pending an opposition proceeding at the European Patent Office (which may or may not result in the invalidation or narrowing of this patent) would be a close call one way or the other, I think Apple is more likely than not to win. The hurdle for a stay is that the court believes there is a high probability (80% or more) of invalidation. In my view, LaunchTile falls far short of that. It's just that a different panel of judges at the same court denied Apple a preliminary injunction against two Samsung Galaxy products earlier this year because it thought that the patent was too likely to be invalidated. Decisions on preliminary injunctions are, however, much less persuasive than decisions at the end of a full-blown proceeding, and Apple argued that there had been misconceptions, which is plausible. By the way, Judge Koh in the Northern District of California was not convinced that the overscroll bounce patent is likely invalid. She denied Apple an injunction over that patent only for considerations related to irreparable harm and the balance of hardships, factors that won't play any role in this German lawsuit.

Basically, the element of the overscroll bounce patent that LaunchTile describes is what I would simply call "snapping": just like objects can snap to a grid in a drawing program, or like computer games typically let objects snap into predefined places (for example, if you construct a building in a strategy game, especially older games), LaunchTile is about the snapping of objects on a touchscreen to the closest position. Not only does this make it more of a touchscreen user interface story but Motorola also tries to benefit from the fact that this was a research project and research papers frequently make vague reference to different technical options of the what-might-be kind.

But snapping to the nearest position isn't the same as the outside-the-box thinking behind the overscroll bounce patent. Apple's brilliant idea (I'll explain further below why I personally still think it shouldn't be patentable, for a different reason than what those Android device makers claim) was to let the screen content follow the movement of the user's finger and then bounce back when that movement comes to an end, which it will do, at the very latest, when the edge of the physical screen is hit. This makes it more intuitive. LaunchTile isn't really about that. Based on what the judges said yesterday, I believe the court is probably not going to be convinced of LaunchTile invalidating the overscroll bounce patent if the documents available to it show that the movement of objects on the LaunchTile screen relates to an entire "carpet" of objects (whose relative positions to each other are always the same), given that Apple's patent relates to scrolling the content of a single object.

The court will decide on August 9, 2012. That's pretty soon, but this is a relatively simple patent.

While I'm unconvinced of the LaunchTile argument, I think there's a different reason for which this patent, even though it covers a truly brilliant user interface idea, should never have been granted in the first place. It simply doesn't constitute any meaningful technological progress. It's just a cool idea, but its implementation is child's play.

Obviously, the patent describes elements that are not child's play: a touchscreen, for example. But the way to evaluate the contribution that a given patent makes to "the progress of science and the useful arts" (that's the way the United States Constitution describes the purpose of patents) is to look at its technical contribution: what does the patent add on top of the prior art? A touchscreen, for example, existed long before this patent. So did snapping techniques. So did graphical user interfaces displaying documents. What's really there that this patent does that pre-existing technologies did not do? Next to nothing.

Years ago I programmed, among many other things, custom user interface controls under Windows, meaning I wrote code that did all of the drawing of the content of an object (including scrollable text, such as a chat display) and evaluated all of the user's interactions (mouse movement, mouse clicks etc.). So I know a thing or two about what the inner workings of the program code that makes such UI elements work look like.

What Apple added to the state of the art was simply

  1. to eliminate the code that would stop a scrolling operation when the end of a document is hit (this is, per se, a simplification);

  2. to fill any parts of the display area below the document with a background color (black, white, whatever); and

  3. to trigger a bounce-back animation when the scrolling operation in a given direction ends.

The structure of the program code that makes such scrollable UI controls work is that there are UI events (a change of position requested by the user) that trigger a redraw of the object upon every change of position. The code that redraws the object always knows the relative position of the visible area within a document that is larger than the screen content. It just has to determine, through a couple of extremely simple addition and subtraction operations, which rectangle to draw and at which screen coordinate to start. That's not what Apple invented -- it existed long before. In order to make the first part of rubber-banding work (filling the unused screen space with a background color), it just takes another simple addition and subtraction operation to calculate the dimensions of the rectangle to be drawn in the background color. The top left position of that rectangle is even easier: it's the leftmost coordinate in the first row below the part that shows actual content. A reasonably skilled programmer can put all of those subtraction and addition operations into the same line of program code that immediately calls a drawRectangle kind of function. If one wants the code to be more legible (only one operation per line), it may take a handful of lines of code.

Detecting an end of the scrolling operation is easy if there's a change of direction (you compare the new direction to the previous one); it's not much harder if you have a timer after the expiration of which you determine that the user has paused too long. Even this is not really a new idea of the patent in question. All touchscreen interfaces must be able to detect the end of a movement. The only new thing that's needed for the overscroll bounce is to react to an end of the operation by triggering the bounceback animation: a timered operation (typically on a parallel thread) that gradually adjusts the offset (a simple addition/subtraction correlation between the position within the overall document that should appear at the topmost position of the display area) until there's an alignment. This, again, can be done in a very few lines of program code.

So the merit of the patent is a matter of perspective. If you believe that even a great user interface idea in the realm of psychology (the realization that users instinctively press harder if the screen content stops following their fingers, so it's better to keep moving and bounce back later) should be protected by a patent, then this patent has unquestionable merit, and LaunchTile simply does not anticipate it or even come reasonably close to it. If, however, you believe that patents are meant to protect technological innovation and further technical progress, then this patent doesn't offer even a tiny fraction of what would justify a government-granted 20-year monopoly because it covers a few lines of simple addition and subtraction operations.

If you'd like to be updated on the smartphone patent disputes and other intellectual property matters I cover, please subscribe to my RSS feed (in the right-hand column) and/or follow me on Twitter @FOSSpatents and Google+.

Share with other professionals via LinkedIn: