The Laboratorium : Yahoo! Patents Drag-and-Drop?

If they get their way, some variations of drag-and-drop, at least. The EFF’s Jason Schultz noticed that Yahoo has a pending patent application for “Smart drag-and-drop.” He picked it up on Peer-to-Patent site, which invites the public in to provide feedback and prior art on pending patent applications, with the hope of separating the worthwhile sheep from the unpatentable goats. Those of us concerned about goat patents hope that Peer-to-Patent, by adding the public’s knowledge to the Patent Office’s more limited resources, will help keep overly broad claims from getting through.

Yahoo!’s “Smart drag-and-drop” application has a page up at the Peer-to-Patent site, but so far it hasn’t gotten a lot of close attention. Perhaps I can help out a bit. Here’s a claim-by-claim breakdown of just what Yahoo! has “invented.” I’ll divide important groups of claims with horizontal lines like this one:

Claim 1

A computer-implemented method for manipulating objects in a user interface, comprising: providing the user interface including a first interface object operable to be selected and moved within the user interface; and in response to selection and movement of the first interface object in the user interface, presenting at least one additional interface object in the user interface in proximity of the first interface object, each additional interface object representing a drop target with which the first interface object may be associated.

The “computer-implemented method for manipulating objects in a user interface” is broad preamble. Ignore it. Similarly, ignore the “user interface” references in the body of the claim; that’s trivial, given everything else. With similar paring, I get the following structure:

providing … a first interface object [let’s call it the “payload”]
- operable to be selected and moved …;
- and in response to selection and movement of the [payload], presenting
at least one additional interface object [let’s call them “targets”]
- in proximity of the [payload],
- each [target] representing a drop target with which the [payload] may be associated

This isn’t quite just drag-and-drop. The first element here describes a draggable object, the payload; the second element describes drop targets you could “associate” the payload with. The targets are “presented” in response to dragging the payload, and “in proximity” of it. I think that association is a standard elements of most drag-and-drop schemes, and proximity is going to be satisfied by almost anything in a sensible place on the screen. “Presenting” is a more interesting term; the examples in the specification of the patent seem to suggest that it means something like showing—the target appears when you start dragging.

One other point. The application uses the phrase “drop target” to refer not to the actual interface items, but to underlying actions. Thus, the trash can icon is an “additional interface object,” whereas the actual code that deletes an item is the “drop target.”

The other 19 claims are inside the fold.

Claim 2

The method of Claim 1 wherein the first interface object represents any of a data file, a shortcut, an executable, a contact, and a message.

Here’s the broken-out version:

The method of Claim 1 wherein …
- the first interface object represents any of
  - a data file,
  - a shortcut,
  - an executable,
  - a contact,
  - and a message.

This is a “dependent” claim. It’s a narrowing of claim 1. It covers only those things that are (a) covered by claim 1, AND (b) satisfy the additional restrictions it mentions. Thus, even if claim 1 is rejected, claims dependent on it could survive. That could happen if a piece of prior art anticipates claim 1 but not the the narrower case that claim 2 describes.

This is also a claim with a bunch of options stated disjunctively. Thus, if I’m reading it correctly, it claims drag-and-dropping data files, and it also claims drag-and-dropping shortcuts, and so on.

Claim 3

The method of Claim 1 wherein each additional interface object corresponds to a current interface object present in the user interface prior to the selection and movement of the first interface object, each current interface object representing the drop target to which the corresponding additional interface object corresponds.

Note that this claim goes back to claim 1. Thus, we don’t care about the restrictions in claim 2 any more. This is a completely orthogonal restriction.

There’s also an important new concept in here: the current interface object. Let’s call those objects “destinations.” Here’s the claim broken down logically:

The method of Claim 1 wherein …
- each [target] corresponds to a [destination],
- present in the user interface prior to the selection and movement of the [payload],
- each [destination] representing the drop target to which the corresponding [target] corresponds.

Thus, claim 3 requires that our destinations be present in the interface before the dragging starts. Available targets then appear, as proxies for those destinations. Think of the “destinations” as folders; when you start dragging, big versions of the folders pop up to give you something easier to drop into.

Claim 4

The method of Claim 3 wherein the at least one additional interface object is presented closer to the first interface object than the corresponding current interface object.

In boiled-down form:

The method of Claim 3 wherein …
- the [target] is presented closer to the [payload] than the corresponding [destination]

Note that this is a further restriction of claim 3. Now we’re dealing not just with a proxy for a drag destination, but with a proxy that’s moved closer to where you are so you can drag for a shorter distance.

Claim 5

The method of Claim 4 wherein the at least one additional interface object is presented in the user interface instead of the corresponding current interface object.

In boiled-down form:

The method of Claim 4 wherein …
- the [target] is presented in the user interface instead of the [destination]

This is just like claim 3, except the original destination vanishes. Or, if you prefer, the destinations move closer to where you’re dragging to make it easier for you. Got any Soviet Russia examples of drag-and-drop? (“In the United States, you go to drop target. In Soviet Russia, drop target comes to you!”) Those would defeat claim 5, and with it claim 4 and claim 3 (since 5 is a special case of 4, which is a special case of 3.)

Claim 6

The method of Claim 4 wherein the at least one additional interface object is presented in the user interface simultaneously with the corresponding current interface object.

Boiled down:

The method of Claim 4 wherein …
- the [target] is presented in the user interface simultaneously with the corresponding [destination.

And look! This is the other half of claim 4—the half in which the destination doesn’t vanish. This covers the cases in which the helpful hint is another option for your dragging convenience, but the original stays right where it is. This one also doesn’t seem too obscure; it describes interfaces where you get helpful proxies for already-available destinations as soon as you start dragging.

Claim 7

The method of Claim 1 further comprising, prior to presenting the at least one additional interface object, identifying the at least one additional interface object with reference to at least one of a parameter associated with the first interface object, at least one currently instantiated object in the user interface, previous user interaction with the drop target, a user preference, a speed of movement of the first interface object in the user interface, a direction of movement of the first interface object in the user interface, a position of the first interface object in the user interface, and a position of a preexisting drop target in the user interface.

Boiled down:

The method of Claim 1 further comprising …
- prior to presenting the [target], identifying the [target] with reference to:
  - at least one of a parameter associated with the [payload],
  - at least one currently instantiated object …,
  - previous user interaction with the drop target,
  - a user preference,
  - a speed of movement of the [payload] …,
  - a direction of movement of the [payload] … ,
  - a position of the [payload] … ,
  - and a position of a preexisting drop target … .

We’re done with the claims (3)-(6) that describe implementations that use only preexisting destinations. This next one is all about showing only some possible targets, and picking which targets based to show on all sorts of stuff. Now because of the placement of the commas, I read this claim as requiring that the choice be made with reference to ALL of those factors. (I could be wrong—I’m not a claim drafting expert.)

Some of these factors are obvious—of course you might have a user-settable preference that affects drag-and-drop. Others are a little more surprising to me; looking at the velocity vector of the dragging in instantiating new drop targets seems like an interesting idea. There may be prior art out there on it, but it’s not something I’d thought of before reading this application. This may be the heart of the application—the system that Yahoo! actually implemented—and everything else just a patent drafter’s attempt to find additional uses and cover all the bases.

Claim 8

The method of Claim 1 further comprising facilitating association of the first interface object with the drop target represented by a selected one of the at least one additional interface object.

Boiled down:

The method of Claim 1 further comprising …
- facilitating association of the [payload] with the drop target represented by a selected [target].

Back to claim 1 again. This claim is fairly generic, but it kicks of a run of dependent claims that represent increasingly specific version of it. Let’s call that whole phrase “facilitating the association.”

This is a slightly odd claim. Claim 1 described drop targets as things with which the payload could be associated. Claim 8 seems to add only the idea that you actually do go ahead and make the association.

Claim 9

The method of Claim 8 wherein facilitating association of the first interface object with the drop target represented by the selected additional interface object comprises associating the first interface object with the drop target in response to the first interface object being dragged over and dropped on the selected additional interface object.

Boiled down:

The method of Claim 8 wherein …
- [facilitating the association] comprises …
  - associating the [payload] with the drop target in response to the [payload] being dragged over and dropped on the selected [target].

Well, gosh, surprise surprise. We drop something on a possible target, and wouldn’t you know it, we associate the payload with the thing the target represents. I fail to see the novelty here (and thus fail to see the novelty in claims 8 and 1), but perhaps someone else can interpret this in another way that says something interesting.

Claim 10

The method of Claim 8 wherein the drop target corresponds to a first portion of a file system, and wherein facilitating association of the first interface object with the drop target represented by the selected additional interface object comprises associating the first interface element with the first portion of the file system.

Boiled down:

The method of Claim 8 wherein …
- the drop target corresponds to a first portion of a file system
- and wherein [facilitating the association] comprises associating the [payload] with the first portion of the file system.

Another snoozer based on claim 8, and also obvious if the general idea of smart drag-and-drop interfaces is obvious. Dropping something on the popped-up folder icon moves a file to that folder—and other inane file management tasks of that sort.

Claim 11

The method of Claim 10 further comprising facilitating navigation of a second portion of the file system related to the first portion of the file system by presenting at least one further additional interface object representing at least one further drop target associated with the second portion of the file system.

Boiled down:

The method of Claim 10 further comprising …
- facilitating navigation of a second portion of the file system related to the first portion of the file system by
  - presenting at least one further [target] representing at least one further drop target associated with the second portion of the file system.

This is slightly more interesting, but only slightly. It’s about recursive drag-and-drop, no? First I navigate to one part of the filesystem, and then I use another drag-and-drop to navigate to another part.

Indeed, this sounds almost exactly like the spring-loaded folders in Apple’s OS X Finder. Drag over a folder and the folder pops open a new window That sounds like an “additional interface object” to me, one “representing” a “drop target” “associated” with a “portion of the file system.” Continue to drag, over another folder, and you can repeat the process to get a second “additional interface object,” and so on. (The only difference I can see is that in OS X, you don’t “drop” until the final destination, whereas claim 9 describes “being dragged over and dropped on.” Still, wouldn’t an ordinarily skilled computer programmer immediately see that dropping at each stage is an option, too? Indeed, OS X lets you drop after each stage and start a fresh drag.)

Claim 12

The method of Claim 1 wherein the user interface is provided on a display associated with any of a personal computer, a media computing platform, a wireless device, a telecommunications device, and a handheld computing device.

Boiled down:

The method of Claim 1 wherein …
- the user interface is provided on a display associated with any of
  - a personal computer,
  - a media computing platform,
  - a wireless device,
  - a telecommunications device,
  - and a handheld computing device.

This is an “any of … and” claim, much like claim 2. I don’t really think that any of these devices are all that surprising. Really, if you can drag and drop on the desktop of your desktop, why wouldn’t you also want to drag and drop on a handheld device?

Claim 13

The method of Claim 1 wherein the user interface is associated with any of a web application, an operating system, a client application, and a messaging application.

Boiled down:

The method of Claim 1 wherein the user interface is associated with any of
- a web application,
- an operating system,
- a client application,
- and a messaging application.

Umm, yeah. Drag-and-drop in the OS. Drag-and-drop in AJAX. Drag-and-drop in your email program. This is just another prior art scavenger hunt, not anything surprising.

Claim 14

The method of Claim 1 wherein the at least one additional interface object comprises a plurality of additional interface objects in a configuration relative to the first interface object.

Boiled down:

The method of Claim 1 wherein …
- the [target] comprises a plurality of [targets] in a configuration relative to the first interface object.

“Plurality” is patent-speak for “more than one.” This is the idea of showing you a bunch of targets at once, in one of various pretty shapes.

Claim 15

The method of Claim 14 wherein the configuration of the additional interface objects is determined with reference to at least one of a number of the additional interface objects, a speed of movement of the first interface object in the user interface, a direction of movement of the first interface object in the user interface, and a position of the first interface object in the user interface.

Boiled down:

The method of Claim 14 wherein …
- the configuration of the [targets] is determined with reference to at least one of
  - a number of the [targets],
  - a speed of movement of the [payload] …,
  - a direction of movement of the [payload] …,
  - and a position of the [payload] in the user interface.

And guess what? We design the layout based on how many of them there are (trivial, as a line of four things is a different “configuration” than a line of five things) and how the user is dragging the payload around (more interesting). Again, I think we’re getting closer to the heart of what Yahoo! has actually done; some mixture of this and claim 7, which involved selecting which targets to show based on these and other factors.

Claim 16

A device comprising a processor, memory, and a display, the processor and memory being configured to: provide a user interface on the display including a first interface object operable to be selected and moved within the user interface; and present at least one additional interface object in the user interface in proximity of the first interface object in response to selection and movement of the first interface object in the user interface, each additional interface object representing a drop target with which the first interface object may be associated.

There’s an important break here. This is a second independent claim. But it has e a very familiar structure. There’s a preamble—“A device comprising a processor, memory, and a display”—and then a transition—“the processor and memory being configured to”—and then, look what we have here:

provide … a [payload]
- operable to be selected and moved …;
- and in response to selection and movement of the [payload], present
at least one [target]
- in proximity of the [payload],
- each [target] representing a drop target with which the [payload] may be associated

This is basically just claim 1, except that instead of describing a method, this claim is directed towards the computer on which that method operates. It’s just an alternative framework for claiming software patents; Yahoo! is trying to hedge its bets.

Claim 17

The device of Claim 16 wherein the device comprises one of a personal computer, a media computing platform, a wireless device, a telecommunications device, and a handheld computing device.

Claim 17 is to claim 16 as claim 12 is to claim 1. Put perhaps more clearly, Yahoo! loved claim 12 so much that they repeated it to work with claim 16—in case claim 1 failed.

Claim 18

The device of Claim 16 wherein the user interface is associated with any of a web application, an operating system, a client application, and a messaging application.

Similarly, this is just claim 13 making a repeat appearance.

Claim 19

A computing platform comprising at least one processor and memory configured to provide a user interface on a remote device in communication with the computing platform, the user interface including a first interface object operable to be selected and moved within the user interface, the user interface being operable to present at least one additional interface object in the user interface in proximity of the first interface object in response to selection and movement of the first interface object in the user interface, each additional interface object representing a drop target with which the first interface object may be associated.

This is a variation of claim 16; instead of describing one computer, it describes access over a network. The highlighted premable is the only part that deviates from what should be the familiar formula of claim 1.

Claim 20

A computer program product comprising at least one computer-readable medium having computer program instructions stored therein which are operable to cause a computing device to: provide a user interface including a first interface object operable to be selected and moved within the user interface; and present at least one additional interface object in the user interface in proximity of the first interface object in response to selection and movement of the first interface object in the user interface, each additional interface object representing a drop target with which the first interface object may be associated.

And one last bite at the apple, this time claiming not the computer, but the medium on which the program is distributed. In terms of actual interface elements, nothing in claims 16-20 deviates from the model set in claim 1. They’re all just alternative ways of describing more or less the same thing; if claim 1 fails because it’s obvious, 16-20 will almost certainly fail as well.

Bottom line: there’s an awful lot in here that strikes me as incremental at best What it describes may technically never have been done, but is almost never a significant advance over things that have been well-known for a long time. In the depths of the deepest darkest dependent claims, there may be some nonobvious material—and Yahoo! might be able to come back and and make its claims more specific to match more closely what they’ve actually implemented. But on the whole, this does not strike me as the sort of patent application that ought to be granted.