KPN is a Dutch telecom company that owns a U.S. patent for detecting errors in data transmission. Last year, the U.S. District Court for the District of Delaware invalidated the patent as ineligible subject matter, but on Friday, a panel of the U.S. Court of Appeals for the Federal Circuit (CAFC) reversed. So, let’s look at what the CAFC said about this data-processing patent.
Check data methods
Anytime you send data, there is a possibility that some of the data gets garbled. One way to check for transmission errors uses “check data.” Check data methods are good at detecting random errors in data, but traditional check data methods can fail to detect some non-random, systematic errors. KPN’s patent discloses the improvement of a check data method that succeeds in detecting systematic errors.
So, what is check data? Computers represent a block of data as a binary number, a long string of 1’s and 0’s that stands for the texts, photos, and payments we send electronically. Check data is a smaller number — i.e., a shorter string of 1’s and 0’s — that is computed from the block of data.
When a device sends a block of data, it also sends the check data for that block. Then, when another device receives the data, the receiving device recomputes the check data. If the receiving device gets a different answer than the sending device told it to expect, there was an error in the data transmission.
Check data methods are good at detecting most random errors. But some errors slip through because sometimes a particular change to the data does not change the check data computed on it. In that case, when the receiving device computes the check data, it gets the answer it was told to expect, and the error goes unnoticed.
If the errors are random, that will not happen too often. But if the undetected error is a non-random, repeating, systematic error, then the check data methods will miss it every time. Enter KPN’s patent.
The ’662 Patent
In U.S. Patent No. 6,212,662, KPN improves check data methods by varying the function that generates the check data. Though a systematic error might escape one check data function, it won’t escape every check data function. So, by changing the check data function, the receiver will eventually notice the systematic error.
The ’662 patent makes four claims, though only claims 2-4 were preserved for appeal.
- A device for producing error checking based on original data provided in blocks with each block having plural bits in a particular ordered sequence, comprising: a generating device configured to generate check data; and a varying device configured to vary original data prior to supplying said original data to the generating device as varied data; wherein said varying device includes a permutating device configured to perform a permutation bit position relative to said particular ordered sequence for at least some of the bits in each of said blocks making up said original data without reordering any blocks of original data.
- The device according to claim 1, wherein the varying device is further configured to modify the permutation in time.
- The device according to claim 2, wherein the varying is further configured to modify the permutation based on original data.
- The device according to claim 3, wherein the permuting device includes a table in which subsequent permutations are stored.
The ’662 Patent is a device patent. The device of claim 1 comprises a generating device and a varying device. The varying device permutes the data block — alters the order of the 1’s and 0’s — before computing the check data. Claim 2 explains that the varying device permutes data blocks differently at different times. Claim 3 describes modifying the permutation based on the original data. And Claim 4 further explains storing permutations in a table.
District Court: ’662 Patent is abstract and fails Alice
The District Court held that the ’662 Patent attempts to claim an “abstract idea” with no inventive concept, but under the Supreme Court’s guidance in Alice, claims that are directed to abstract ideas are not patent-eligible, unless the claims contain a saving inventive concept. So, the District Court invalidated all claims of the ’662 Patent.
Specifically, the District Court found that the claims were directed to “the abstract idea of reordering data and generating additional data.” The claims were abstract because they do not tell “how data is reordered, how to use the reordered data, how to generate additional data, that any data is transmitted [or] how the permutations are modified in time or modified based on the data.”
Having decided that the claims were abstract, the District Court then looked for an inventive concept. Interestingly, the District Court thought that the specification might have disclosed such an inventive concept. But, it concluded that even if so, the inventive concept was “not captured in the claims.”
Federal Circuit: ’662 Patent is not even abstract
The CAFC, on the other hand, never reached the question of inventive concept. The court decided claims 2-4 were not directed to an abstract idea in the first place. Instead, the ’662 patent is a “non-abstract improvement in an existing technological process.”
Specifically, the court read the claims as a non-abstract improvement in error checking with data transmissions. The court drew parallels with last year’s decision in Finjan Inc. v. Blue Coat Systems.
The Finjan patent had claimed a method of providing computer security by identifying potentially dangerous operations. It improved on earlier methods that only identified known dangerous operations. The court affirmed the validity of the patent. Its claims were not abstract, because they were a concrete improvement of a computer security system.
In Finjan’s wake, the court reversed the District Court’s holding of invalidity. It reasoned that the claims were also directed to a non-abstract improvement over the prior art because they “employ a new way of generating check data that enables the detection of persistent systematic errors in data transmissions that prior art systems were previously not equipped to detect.”
In reaching its decision, the court leaned heavily on the specification. One argument against the patents was that “the specification does not mention any technological benefit of using permutations to generate check data.” But the court did find the benefits by tying together passages columns apart. The court did not quite go so far as to require that specifications discuss a technological benefit, but it was helpful to KPN that theirs did.
Though the bar for software and related patents remains high, the CAFC’s opinion offers a few pointers.
First, spend the time to flesh out the specification. The claims, not the specification, largely define the scope of the patent. Consequently, we tend to devote effort to get claims into eligible shape, but the court leaned on the specification for two important factors in its decision that the claims were not abstract.
The specification established that the claims were an “improvement in an existing technological process.” The specification gave a good picture of the prior art and the existing error checking processes. The court cited the specification — not the claim itself — for the fact that claim 2 “improves the ability of prior art error detection systems to detect systematic errors.”
The specification also established the technological benefit of the matter claimed. Again, the court did not hold that specifications must discuss a technological benefit, but the appellees argued as much. KPN is probably relieved that the specification did clearly express the benefit of the permutation of claim 1. That saved the court the trouble of a difficult legal decision.
Second, take care that the claims recite a specific implementation. For KPN, this meant specifically reciting the last application step: that the varying device be configured to “vary original data prior to supplying said original data to the generating device”; that the original data is varied by a “permuting device configured to perform a permutation”; and that the generating device “generate check data.”
But keep in mind that a claim of improvements to a tool “that is part of an existing system … does not necessarily need to recite how that tool is applied in the overall system.” Instead, it should be enough to claim a specific means or method. Still, it will be best — if not exactly required — for at least the specification to describe how the improved tool is used in the existing system. Doing so goes along with the first point above to flesh out the specification.