Skip to main content




Patent Busting Project
An EFF Initiative To Protect Innovation and Free Expression


Crimes Against the Public Domain

  • Patent uses basic natural language processing techniques taught in introductory computer science courses
  • Firepond is aggressively threatening and filing suit against companies in the natural language processing software space, thus making it difficult for developers in the field to create new products that are related to customer service or email
  • Filed suit against California company Banter for infringement, eventually strongarming Banter into licensing Firepond's patents

Prior Art Description

The Firepond/Polaris Patent on Automatic Message Interpretation
U.S. Patent No. 6,411,947

Latest Date That Material Can Qualify as Prior Art: April 3, 1997

I. General Description of the Invention

The Firepond patent claims a method for (1) telling whether or not an incoming message (e.g., an email) is a simple, standard request that can be answered automatically, and (2) if so, for answering it. The method processes incoming messages by consulting two databases: a database of IF-THEN rules, and another database of previously classified messages (cases).

It combines the results from these databases to determine whether the message can be answered automatically, or must instead be forwarded to a human being. For example, in one implementation, the two databases are consulted one after another. When a message arrives, it is processed in two stages. First, the rules in the rules database are applied to its contents. An example of such a rule is: "If the body of the message is blank Then classify the message as 'automatically answerable'." If the rules succeed in classifying the message—as "automatically answerable" or "not automatically answerable"—the method terminates. If not, the method proceeds to its second stage. In this stage, it consults its database of cases. This database stores messages that have been received in the past, and records how they were classified. The method searches for the stored message that is most like the new one, and applies its classification to the new message.

Finally, if the method finds that the incoming message can be automatically answered, it finds an appropriate answer in a third database, tweaks it to answer the incoming message, and sends it out.

II. The Claims at Issue

The Firepond patent has five independent claims and sixty-one dependent claims that add additional elements. Each claim in a patent is a separate "invention" that can be used to threaten or sue someone. As their names imply, independent claims stand alone; their descriptions list all their necessary elements. Dependent claims, on the other hand, refer back to another claim's elements and then add additional ones to the mix. We are most interested in busting Claims 1, 25, and 26, which cover key variants of the patent. We believe that if these three fall, it will have a significant impact on the enforceability of the remaining claims and thus the patentee's ability to make inappropriate threats.

A. Claim 1

Claim 1 covers a method for automatically processing electronic messages. These electronic messages could be emails, but they could be other things, too. For instance, data submitted through a web form would qualify, and so would messages automatically generated by other computers.

Claim 1 includes the following steps:

  1. Receiving an electronic message;
  2. Interpreting it with the help of a database of rules and another database of cases; and
  3. Classifying it as either "automatically answerable" or "not automatically answerable."

B. Claim 25

Claim 25 applies specifically to emails. It is like Claim 1 except that, when the email is classified as "automatically answerable," it includes the following additional steps:

  1. Finding a predetermined response from a third database;
  2. Tweaking this response to create a reply to the original email; and
  3. Sending the response to the person who sent the original email.

C. Claim 26

Claim 26 is, roughly speaking, a mixture of Claims 1 and 25. Like Claim 1, it deals with electronic messages generally, not just emails. Like Claim 25, it includes the step of responding to the message. Unlike both, however, it does not include the step of classifying the message as "automatically answerable" or not. Specifically, Claim 26 includes the following steps:

  1. Receiving an electronic message
  2. Interpreting it with the help of a database of rules and another database of cases; and
  3. Finding a response in a third database and automatically sending it out.

III. Description of the Prior Art Needed to Bust this Patent

A preliminary application for this patent was filed on April 3, 1997, so EFF is looking for prior art that was publicly available before that date. Prior art can be: a product, a published patent, a conference paper, or a printed publication (web page, newsgroup post, article, technical paper, etc.). To bust the entire patent, we must find one or more pieces of prior art for every claim, but eliminating even one or two of the claims will narrow and weaken the patent.

Ideally, each piece of prior art will include all of the elements (or steps) of the claim it is going to bust. That kind of art would show that the patented method was not novel when the application was filed and render the patent invalid. Next best is prior art that describes almost all of the elements (or steps) of the claim it is going to bust. That kind of art might show that the patented method was obvious when the application was filed. This would also make the patent invalid.

Claim 1

Model prior art for Claim 1 would describe an algorithm that:

  1. processes incoming electronic messages;
  2. by some process that includes consulting a rules database and a case database;
  3. in order to determine whether it can be answered automatically or not.

Next best prior art would be an algorithm that describes any two of these three steps. For example, art describes the following would be very useful:

  1. An algorithm that uses databases of rules and cases to classify incoming electronic messages in some other way—say by subject-matter, or as "high" and "low" priority;
  2. An algorithm that uses databases of rules and cases to tell whether some other sort of document—say a text document—is automatically answerable; or
  3. An algorithm that determines whether an incoming electronic message is automatically answerable or not, but does so by consulting a database of rules only or a database of cases only.

Finally, it is also helpful to collect prior art that describes using databases of rules and cases to perform some obviously related task, such as general document classification.

Claim 25

Model prior art for Claim 25 would be a system that includes all the elements (or steps) of Claim 1 (as specifically applied to email), and in addition, when an incoming email has been classified as "automatically answerable":

  1. Finds a predetermined response to the email;
  2. Tweaks it to be responsive to the email; and
  3. Sends it to the person who sent the email.

Also very helpful would be prior art that includes at least some of the elements (or steps) of Claim 1 (that, at least, classifies incoming messages in some way), and some or all of the additional elements of Claim 25. In particular, art that responds to emails—especially if the responses are constructed on the fly or by modification of some canonical response—would be useful.

Claim 26

Unlike Claims 1 and 25, Claim 26 does not involve the step of distinguishing electronic messages that can be responded to automatically from those that cannot. For that reason, it should be easier to bust.

In particular, model prior art for Claim 26 would be a system that:

  1. processes an kind of incoming electronic messages;
  2. by some process that includes consulting a rules database and a case database;
  3. and then sends some kind of a response.

Unlike with Claims 1 and 25, the field of server software seems a good place to look for art to bust Claim 26. A server system would work if it: (a) communicates back and forth with clients, and (b) does some sort of rule-based and case-based reasoning on the messages.

Ideally, such a system would use separate databases of rules and cases. However, systems that apply sequences of hard-coded rules might also be useful. In particular, the use of a sequence of hard-coded regular expressions (e.g. in a Perl script) might satisfy the rule-based reasoning requirement.

IV. Where to find Prior Art

We anticipate that a lot of useful prior art for Claims 1 and 25 will lie in the area of helpdesk automation or customer service automation. Fertile sources of prior art may be:

  1. Helpdesk automation systems that automatically respond to user queries;
  2. Systems that help customer service operatives identify solutions to user problems by means of both rule and case databases. For example, it would be useful to find systems that maintain databases of prior problems (a case database) and use these together with if-then rules to help operatives identify solutions to recurring problems.

We anticipate that useful prior art for Claim 26 will be found in the field of server software.

Back to top

JavaScript license information