What Apple Patent #7,966,578 Really Means for Android

By Ryan Whitwam

The end of multi-touch this is not.

The tech media makes it a point to examine each and every Apple patent in search of clues to what the secretive company is up to. This level of attention also has the unintended consequence of occasionally blowing some patents out of proportion. So when patent #7,966,578 was granted the other day, a lot of media outlets reported that it covered everything multi-touch.

Was this the magical unicorn patent that Apple was going to use to put Android out of business? As it turns out, this patent is much more narrow than initially reported. While it isn't the end all, be all piece of intellectual property, it is interesting and could require companies like Google and Microsoft to take another look as how they do things. Let’s look at what patent #7,966,578 covers, and how other OS makers might get around it.

What is covered?

The wording in patent applications is famously nebulous and confusing at first glance. Every possible meaning and angle needs to be considered to ensure that future legal challenges relating to a patent can be defended based on what was granted. In this patent, we get a lot of dressed up language that gets at a few salient points relating to multi-touch and the handling of content, but not mult-itouch itself.

To be in violation of this patent, you need a few things. First, you have to be using a “portable multifunction device with one or more processors, memory, and a touch screen display.” For the sake of brevity, we’re going to rename that device, a ‘phone’. Innovative, right?

The next element is that the device displaying a web page, or portion of a web page in a “stationary window”. This is basically a full-screen application (we’re using web pages as an example, but it could be applied to other apps). That page contains some additional content in a frame, for instance, a JavaScript frame. All mobile platforms use the full screen paradigm for running apps, and many web pages have framed content, so we’re still on target.

The next part is where many people get thrown off. When talk of multiple finger input comes up, people jump back to 2009 when everyone was scared to death of Apple’s supposed multi-touch patents. This element of the patent says that a single finger input is interpreted as scrolling through the main page. The kicker is the final element, where “a translation gesture” is detected and interpreted by two inputs to manipulate only the framed content.

So what does that mean? This patent covers scrolling through a page with one finger, then using two fingers to interact with an embedded frame on that page without scrolling the page itself. Imagine a Google Map or embedded photo viewer on a site. Patent #7,966,578 covers the ability to zoom and scroll within such a frame on a larger page. If you aren’t doing that, you are not infringing the patent.

Does anything need to change?

The Google Maps API example

On Android, this behavior does exist, but not in quite the same way. You can check out Google’s Maps API examples to test it on your phone, or just find a page with embedded content. You scroll around as usual, and tapping on the frame will let you manipulate it. In Android, you just use one finger to interact with an embedded Google Map.

The way single input is handled is clever. If a page is actively scrolling (inertial scrolling), single input will always be seen as scrolling. If you stop, then press and drag in a frame, it activates and scrolls just the frame. There is no multi-touch zooming in stock Android within frames (as tested with Maps). Instead, the Android browser detects you are on a mobile device, and replaces the small mouse controls, with larger touch-friendly buttons.

We cannot vouch for all the technical details, but Android seems to have an alternate method of interacting with frames already. The way Apple described it is maybe the most elegant method, but if you add in another step, you might still be able to salvage the meat of the embedded frame experience they describe, improving it on Android.

One method would be to require a tap or a long-press on the frame to activate it. Before that, it would exist as a static panel that you could swipe over without altering it. This would not affect scrolling, and the multi-touch gestures would not be negatively impacted. Simply separating the scrolling behavior of the page from the frames content, essentially making two separate stationary elements out of them, should be enough.

If Google felt that the multi-touch gestures on framed content were too risky (even when that frame needed to be activated before hand), there are some similar alternatives. Frames could just pull up a larger frame over top of the web page when tapped. If this was done well, you could easily argue that it is another stationary app. Then you could add all the multi-touch magic you want and it wouldn’t even affect the scrolling of the page.

Perhaps the safest, and least appealing route would be to make frames non-live. Tapping on it would just launch the Maps app. This feels to us like an aggravating experience, though. It’s better to actually make use of the JavaScript running on the page.

So the bottom line is this; Apple has a patent on a neat use of multi-touch for interacting with in-page frames. Stock Android does not quite use the system as described. We don’t think Google is in violation, but some OEMs may handle the page differently and be infringing. But taking some ideas from this as described above could make the experience on Android better.

Should a company need to design around the patent, that is also doable. The sky is not falling, folks. It’s just another method to get something done. Apple may choose to interpret the patent more broadly at some point, but our feeling is that this is a more narrow technology than many have assumed.