Skip to Content
News & Insights

Alice-Proofing Your Patent Specifications

Jun 18, 2018 | General

Four years after the U.S. Supreme Court shook the patent world with its string of subject matter eligibility cases, the U.S. patent system still lacks firm footing on what constitutes patent eligible subject matter. While the court’s decision in Alice Corp. Pty. Ltd. v. CLS Bank International[1] gave rise to the two-part test for subject matter eligibility, the actual implementation of this test, and guidance on how to meet it, was left to the U.S. Court of Appeals for the Federal Circuit.

In numerous cases, the Federal Circuit has addressed this issue. However, instead of focusing solely on the claims, the court has developed a pattern that equally relies on the teachings of the specifications. Specifically, Federal Circuit cases finding claims subject matter eligible feature a clear recitation of the problem in the art, the solution posed by the claimed invention, and the benefit derived by the claimed invention, as shown in the table below:

Alice Proofing Table, Drew Schulte
The Methodology

With this pattern in mind, specifications should be drafted to clearly describe the problem, solution and benefit of the claimed invention. While simple in theory, to avoid conclusory statements, failing to describe the technical solution, or properly rooting the solution in computer technology, a methodology should be used that focuses on systematically identifying the following components:

    1. The abstract problem
    2. The solution to the abstract problem
    3. The technical problem
    4. The solution to the technical problem
    5. The benefit of the claimed invention

As a brief aside, in order to ensure that the described methodology is not itself too abstract, these problems, solutions, and benefits will be discussed in relation to a hypothetical invention. The hypothetical invention is a social media application that delays the delivery of a message based on the sender being in an earlier time zone than the recipient. For example, if the sender, located on the East Coast of the United States, sends a message at 9 a.m. EST, the recipient, located on the West Coast of the United States, receives the message at 9 a.m. PST (instead of 6 a.m. PST, when the message was sent). In this hypothetical, the prior art consists of social media applications and computers that transmit messages instantaneously.

Finally, to provide additional guidance on implementing this methodology, the discussion of each component also includes a suggested placement in the specification. While the placement of the five components may vary, it may be helpful to adopt a standard format to ensure that components are not missed and are clearly described.

Application of the Methodology

When applying this methodology, the five components should be identified prior to beginning to draft an application. This is particularly important in that one or more components may need to be fleshed out with the inventor, or a prior art search may need to be performed to determine how “conventional” systems operate.

The specification should begin with a discussion of the abstract problem. The abstract problem may be an economic problem (e.g., how to retain customers, how to increase profits, etc.), a social problem (e.g., how to enable people to better communicate, how to increase a user’s experience, etc.), or an otherwise high-level description. For example, in the hypothetical, the abstract problem may be, “how to improve communications between users at remote locations.” Notably, this problem is not tied to computer technology. That is, the problem existed before computers and still exists today.

Ideally, only the abstract problem should be discussed in the background section of the specification with the remaining components introduced in the summary section (as discussed below) to limit the admissions regarding the state of the prior art, and any motivations that could be derived therefrom, that may be used against the claimed invention. The background section should then conclude by directly stating the abstract problem.

The solution to the abstract problem should describe the specific way that the abstract problem is addressed. The solution to the abstract problem is essentially the novel idea behind the claimed invention. For example, in the hypothetical, the solution to the abstract problem could be “delaying delivery of messages received from users in earlier time zones.”

The solution to the abstract problem should be stated in the topic sentence of the summary, and introduce the medium upon which your claimed invention is implemented (e.g., mobile device, social media application, etc.). For example, in the hypothetical, the first sentence of the summary may state, “Methods and Systems are disclosed herein for a social media application that improves communications between users at remote locations by delaying messages sent from users in earlier time zones.” Notably, it is the implementation of the solution to the abstract problem in this medium (e.g., “a social media application”) that creates the technical problem.

The technical problem is the novel computer-related problem that must be overcome to provide the solution to the abstract problem. That is, it is a problem first identified by the inventor when the inventor attempted to use “conventional” computer systems to implement the solution to the abstract problem. For example, in the hypothetical, the prior art computer systems immediately deliver (i.e., there is no delay based on time zones) messages between users. The technical problem is therefore that conventional computer systems have no mechanism for delaying messages based on time zones. Accordingly, the second sentence of the summary should state, “For example, conventional computer systems have no mechanism for delaying messages based on time zones.” The solution to the technical problem should then be described in the subsequent paragraphs.

The solution to the technical problem is the improvement to “conventional” computer systems used to provide the solution to the abstract problem. That is, the solution to the technical problem is the series of steps, and the computer structure for performing those steps, used to overcome the technical problem. These steps and computer structure form an embodiment of the invention and as such should be reflected by the limitations of the claimed invention. For example, the solution to the technical problem of the hypothetical should discuss the mechanisms, in claim language, used to implement the delay of messages based on time zones (e.g., retrieving time zone information from user profiles of both users, comparing the time zone information to determine whether or not to delay, storing a delayed message in memory, etc.).

The specification should then describe how each limitation in the claims contributes to the solution to the technical problem. For example, a hypothetical claim limitation (e.g., comparing time zone information to determine whether or not to delay a message) may contribute to the solution of the technical problem by ensuring that the mechanism for delaying messages based on time zones does not unduly delay messages sent/received in the same time zone. By describing the contributions provided by each limitation, the limitations are less likely to be considered a generic component and/or performing generic computer functionality. For example, if the mechanism was specifically created to overcome the technical problem, and the technical problem was unknown prior to the inventor inventing the solution to the abstract problem, the mechanism can be neither generic nor perform generic computer functionality.

Finally, the specification should describe the benefit of the claimed invention. This benefit may not be obvious and should not simply state that the abstract problem is solved (i.e., “communications are now improved”). Instead, the benefit (or benefits) should describe the ways in which the situation of those people or things affected by the abstract problem has improved as a result of the solution to the abstract problem. Notably, the benefit is a chance to “sell” the claimed invention and to clearly recite why the claimed invention is worthy of patent protection.

For example, the hypothetical benefit of the claimed invention could be that the claimed invention improves communications between users at remote locations (i.e., time zones) by creating an environment in which users experience each other’s messages under similar circumstances. For example, if an East Coast user sent a message, complaining about the morning commute, at 9 a.m. EST to a West Coast user, the West Coast user would receive the message at 6 a.m. PST, while sleeping. However, by delaying the message to 9 a.m. PST, when the West Coast user is experiencing the same circumstance (i.e., the morning commute), the West Coast user is better able to commiserate over their shared experience — improving the communications between the users.

In conclusion, practitioners should know that ensuring a patent is subject matter eligible requires careful drafting of both the specification and the claims. However, by following the methodology above, practitioners should have the tools necessary for Alice-proofing their patent specifications.

Written by Drew J. Schulte.

Originally published on Law360.com.

[1] Alice Corp. Pty. Ltd. v. CLS Bank Int’l, 134 S. Ct. 2347 (2014).