Last summer’s Supreme Court decision in Alice v. CLS Bank has had a dramatic effect on the patentability of business method and computer software inventions. In Alice, the Court declared that claims directed to abstract ideas must be analyzed under the framework for determining the patent subject matter it established in the Mayo  and Myriad cases.

The USPTO now has issued Interim Guidelines For Determining Patent Eligible Subject Matter as well as several examples to illuminate how the test will be applied by the Office. While the guidelines leave open as many questions as they answer, they do provide several useful guideposts upon which savvy applicants can hitch their wagons.

It is hard to imagine a more apropos case name than Alice around which to discuss abstract ideas. So, with a few select quotes from the Lewis Carroll himself, here is a breakdown of how you can use the PTO’s interim guidelines to draft patent eligible claims.

“If you don’t know where you’re going, any road can get you there.”

This line from the Cheshire cat is good advice in almost every situation: know your end goal. Our goal is patent eligible claims, and the road to patent eligibility is the PTO’s eligibility flowchart.

Subject Matter Eligibility Test
Original Image provided by The U.S. Patent and Trademark Office, Federal Register, Vol. 79, No. 241, p. 4.

“Begin at the beginning . . .”

With apologies to the King of Hearts, we will start at step 2A. The reasons are two-fold. First, if your claims cannot pass step 1 because they are not directed to a process, machine, manufacture or composition of matter, than you have bigger problems than Alice. More importantly, steps 2A and 2B each provide direct routes to patent eligibility. Your efforts should be focused there.

To pass muster under step 2A, your claims cannot be directed to an abstract idea. But what’s an abstract idea? There is no clear definition yet, but we do have some known culprits. Avoid the following:

  • mathematical algorithms;
  • methods of organizing human activities;
  • ideas themselves; and
  • fundamental economic and conventional business practices.

That doesn’t mean you can’t draft claims that touch on one or more of the above. Claims are not directed to abstract ideas if they provide a technical improvement or are rooted in a particular technological environment.

For example, a method for removing malicious code from an email is not abstract because it solves a problem that is inextricably tied to the computer technology. Nor is a system abstract when it provides users with a composite web page containing product-related elements of third party and visually perceptible elements of a host page, rather than redirecting the user to a third party page. (see DDR v. Hotels.com) Instead, it solves the business challenge of retaining website visitors, a problem unique to the Internet. In both cases, there is no brick-and-mortar equivalent.

Differentiating in the specification how your solution differs from its closest “real world” equivalent can be one trip straight to eligibility.

Differentiating in the specification how your solution differs from its closest “real world” equivalent can be one trip straight to eligibility.  Does your system involve multiple devices, such as mobile devices, servers and/or specialized devices that solve problems in a way for which there is no “conventional” parallel? Good, make that clear in your specification.

“. . . and go on . . .”

Even if you believe your claims are eligible under step 2A, you should take a boot-and-suspenders approach by building claims that also pass step 2B. To do so, you must show that your claims recite elements that add “significantly more” than the abstract idea. Claims add significantly more when they:

  • Improve the functioning of the computer itself, for example, by:
    • using less memory to store data;
    • reducing bandwith or otherwise transmitting data more effectively;
    • using less power;
    • accelerating computational time;
    • or the like.
  • Improve another technical field, such as:

Software has structure, data has structure. Often, these structures contribute to an improvement in the operation of the computer or another technical field. Think of the software as you would a mechanical device: how does the arrangement of its components contribute to a better whole? And make sure the structure and related improvements are set forth in your specification explicitly. Your path to eligibility may depend on it.

Software has structure, data has structure. Often, these structures contribute to an improvement in the operation of the computer or another technical field.

“. . .till you come to the end: then stop.”

You shouldn’t stop at the end of the flowchart. Sorry again, King. That’s because the guidelines also provide a streamlined eligibility test: claims are eligible if they do not seek to “tie up” an idea. Look at your claims objectively. Do they preempt others from using the idea in any context? If so, limit them in ways that will still read on competitors’ products but not claim the world.

“I knew who I was this morning, but I’ve changed several times since then.”

Coming soon: How you can apply the guidelines to secure the allowance of claims drafted under the pre-Alice framework.