I recently looked at a patent issued last January in the area of
secure messaging,
US 8,625,805.
It uses the term “Digital Security Bubble” (the title of the
patent) to refer to a concept which, in my opinion, is no different
from the concept of digital envelope or enveloped data
found in
RFC 5652
(Cryptographic Message Syntax)
or the earlier
RFC 2315
(PKCS #7). I posed a
question
on
Ask Patents, asking
what could be done to challenge the patent short of obtaining a Post
Grant Review, which would cost $30,000 or more just in USPTO fees
(including a $12,000 request fee and a $18,000 post-institution fee for
challenging up to 15 claims, plus $250 for each additional claim being
challenged beyond 15).
Phoenix88
suggested
submitting
prior art under 37 CFR 1.501 and 35 USC 301, which requires no
fee. Following his advice, I studied the patent in detail and I have
submitted as prior art PKCS #7 as well as
RFC 1422, an RFC
related to Privacy Enhanced Mail (PEM) that PKCS #7 relies upon. If
the USPTO accepts the submission, it will be entered into the patent
file. In the meantime, it can be found
online on the Pomcor site.
But the reason I’m writing this post is that US patent 8,625,805 can
serve to identify and illustrate five different problems with software
patents, some well known, some that may not have been identified
before. Here are those five problems.
1. The Vocabulary Problem
Whereas disciplines such as medicine, biology, chemistry and the
various branches of engineering have developed mature and
well-established vocabularies for their subject matters, software
engineers like to invent their own fanciful vocabulary as they go.
Think for example of the invention of the term cookie by
Netscape to refer to a data item that stores server state in an HTTP
client.
Inventing a new term is justified when the term is applied to a new
concept, or when existing terminology is inadequate. But it is
deplorable when there exists adequate terminology for the same
concept.
Creation of unnecessary terminology may be due to ignorance of
existing terminology. But in
their
comments on prior art resources, which can be found in a
USPTO
web page, Public Knowledge, the Electronic Frontier Foundation and
Engine Advocacy have said that “applicants are able to use invented
terminology in order to avoid prior art.” Without judicial discovery
it is not possible to tell whether the term “digital security bubble”
was used in US 8,625,805 instead of “digital envelope” for the purpose
of obfuscation, or simply because the inventors were not familiar with
standard secure messaging terminology.
The lack of stable and broadly accepted terminology drastically
reduces the ability to find relevant documents by keyword search,
i.e. it reduces what is known as recall in information
retrieval. The patent file of US 8,625,805 includes a Search Strategy
entry (SRNT) showing that 13 out of 26 prior art search queries
contained the keyword “bubble”; the useless keyword “bubble” thus
took up 50% of the time and effort spent by the examiner on keyword
search. (The search strategy entry can be found using the Image
File Wrapper tab in the Public Patent Application Information
Retrieval tool —
Public PAIR
— of the USPTO.)
Besides poor recall, keyword searches of software literature also
suffer from the opposite problem, poor precision. This is due
to the fact that some popular words are used for many different
purposes. The word token, for example, has a large number of
different meanings. The combination of poor recall and poor precision
means that keyword search is not well suited to finding prior art
relevant to software patent applications.
The USPTO has launched a
Glossary
Pilot that provides incentives for applicants to include a
glossary section in the specification. While a glossary section may
be useful for other purposes, it does not prevent or discourage the
use of non-standard terminology.
2. The Search Corpus Problem
The second problem with software patents has to do with the databases
that examiners use to search for prior art.
Although the Search Notes entry (SRFW) in the patent file of US
8,625,805 indicates that the examiner did some Non-Patent Literature
(NPL) searching, all 26 queries documented in the Search Strategy
entry (SRNT) were run on patent literature databases. Since few
software patents were granted or applied for before the late nineties,
documentation of fundamental software inventions such as secure
messaging, cannot be found in the patent literature.
3. Lack of “Full, Clear, Concise and Exact” Descriptions
A patent is supposed to embody a quid pro quo: the inventor
gets a monopoly on the use of the invention, and in exchange discloses
the invention so that the public can use it once the patent has
expired. The inventor’s side of the bargain is codified in 35
USC 112(a):
The specification shall contain a written description of the
invention, and of the manner and process of making and using it, in
such full, clear, concise, and exact terms as to enable any person
skilled in the art to which it pertains, or with which it is most
nearly connected, to make and use the same, and shall set forth the
best mode contemplated by the inventor or joint inventor of carrying
out the invention.
But too often, software patents make claims without providing a “full,
clear, concise and exact description” of what is being claimed.
Claim 15 of US
8,625,805 is a good example. Here is the claim:
15. The system of claim 1 wherein the processor is configured to
perform the encapsulation at least in part by performing a spreading
function.
And here is what the specification has to say on what it means to “perform the
encapsulation at least in part by performing a spreading function”:
In some embodiments (e.g., as is shown in FIG. 5), a spreading
function is used to spread the encrypted symmetric keys inside the DSB
(as shown in region 512), by spreading the bits of the encrypted key
in a spreading function generated pattern, with the default function
being a sequential block or data. The spreading function also contains
the cryptographic hashed representation of the recipient usernames
that are used by the server to identify the recipients of the message
and to set the message waiting flag for each of them.
I don’t understand this at all, and
FIG. 5
does not help. If you understand it and would like to explain it in a
comment, I would appreciate it.
Lack of compliance with 35 USC 112(a) seems to be a common problem.
Software engineers often complain that software patents are
incomprehensible. Sometimes,
software
engineers do not even understand their own patents, written up by
patent attorneys:
Against my better judgement, I sat in a conference room with my
co-founders and a couple of patent attorneys and told them what we’d
created. They took notes and created nonsensical documents that I
still can’t make sense of.
A “person skilled in the art” of software is called a software
engineer or a software developer. Hence patents that are
incomprehensible to software engineers, by definition, do not comply
with 35 USC 112(a). Unfortunately, the USPTO does not seem to be keen
on enforcing compliance with 35 USC 112(a). Sometimes I wonder if
examiners read the patent specification at all, or only read the
claims.
4. The Means-or-Step-Plus-Function Problem for Security Claims
US 8,625,805 also illustrates a tricky problem specific to security
claims. Here is claim 16:
16. The system of claim 1 wherein only a designated recipient, having
a device with applicable device characteristics, is able to decrypt
the message.
I believe this claim is objectionable under 35 USC 112(b) because it
does not point out any subject matter. It should have been written in
means-plus-function form, e.g. “the system of claim 1, further
comprising a means of preventing the decryption of the message other
than by a designated recipient having a device with applicable
characteristics,” with “means” referring to the following portions of
the specification:
At 208, a device identifier (“deviceID”) is created from captured
hardware information. Examples of captured hardware information
include: hard drive identifiers, motherboard identifiers, CPU
identifiers, and MAC addresses for wireless, LAN, Bluetooth, and
optical cards. Combinations of information pertaining to device
characteristics, such as RAM, CACHE, controller cards, etc., can also
be used to uniquely identify the device. Some, or all, of the captured
hardware information is run through a cryptographic hash algorithm
such as SHA-256, to create a unique deviceID for the device. The
captured hardware information can also be used for other purposes,
such as to seed cryptographic functions.
…
FIG. 10
illustrates an example of a process for accessing a message included
inside a digital security bubble. In some embodiments, process 1000 is
performed on a client device, such as Bob’s client device 114. The
process begins at 1002 when a DSB is received. As one example, a DSB
is received at 1002 when app 138 contacts platform 102, determines a
flag associated with Bob’s account has been set, and downloads the DSB
from platform 102. In such circumstances, upon receipt of the DSB,
client 114 is configured to decrypt the DSB using Bob’s private key
(e.g., generated by Bob at 202 in process 200).
At 1004 (i.e., assuming the decryption was successful), hardware
binding parameters are checked. As one example, a determination is
made as to whether device information (i.e., collected from device
114) can be used to construct an identical hash to the one included in
the received DSB. If the hardware binding parameters fail the check
(i.e., an attempt is being made to access Alice’s message using Bob’s
keys on a device that is not Bob’s), contents of the DSB will be
inaccessible, preventing the decryption of Alice’s message. If the
hardware binding parameter check is successful, the device is
authorized to decrypt the symmetric key (i.e., using Bob’s private key
generated at 202) which can in turn be used to decrypt Alice’s message.
This is very vague, and I don’t think it qualifies as a full, clear,
concise, and exact description. But the gist of it seems to be that
an encrypted message is accompanied by a hash of hardware
parameters of a destination device. When the message is received, an
app checks whether the hash matches a hash of the hardware parameters
of the device where the app is running. If the check fails, the app
refuses to decrypt the message.
The point I really want to make, however, is that this method of
“hardware binding” does not work. An adversary who has Bob’s private
key is not prevented from decrypting the message on a device other
than Bob’s device just because an app on Bob’s device is
programmed to check the hash of hardware parameters. The adversary
can do anything he or she wants on his or her own device. The
adversary can, for example, use an app that behaves the same as the
app used by Bob except that it omits the check.
This illustrates an important point, specific to security claims, that
I have not seen discussed before. It is practically impossible to
verify that a means-or-step-plus-function claim is supported by the
specification, if the function being claimed is to achieve a security
goal. It may be easy to see that a claim like the above is NOT
supported. But establishing that a security claim IS supported would
require writing and verifying a mathematical proof that the security
goal is achieved based on a mathematical model of the a system
described in the specification, something which is theoretically
possible but not realistically achievable today. Furthermore the
statement of the goal would have to be probabilistic, since security
is rarely absolute.
This is important because allowing a security claim supported by a
description of a technique that does not work does a lot of damage.
Somebody else may later invent a technique that does work. Then the
person who has been granted a patent on the security claim based on
the technique that does not work will be able not only to prevent the
person who has found the technique that works from obtaining a patent,
but also to prevent everybody from using the technique that works.
5. A Loophole for Avoiding Third-Party Preissuance Submissions
The America Invents Act (AIA) has introduced
Preissuance
Submissions of Prior Art, which allow third parties to submit
prior art to the examiners, and the USPTO is keen on
crowdsourcing
access to prior art. This a is good thing. But US 8,625,805
avoided third-party scrutiny because the application underwent a
Prioritized, a.k.a. Track I, Examination and, like many Track I
applications, was not published until granted. (The fact that US
8,625,805 was a Track I patent was noted by
George
White in a comment on Ask Patents.)
Prioritized Examination, which requires an additional fee of $2,000
for a small entity, has the effect of shortening the waiting time
before an examiner takes up the application from years to a few
months. Before AIA this was already an extremely unfair and
undemocratic procedure, shortening the process for corporations and
rich inventors who could afford it while lengthening it for everybody
else. Now, after AIA, it can also be used as a loophole to shield
those who can afford the fee from third party submissions of prior
art, making it easier for them to obtain low quality and overly broad
patents which they can inflict on society.
A second loophole for preventing preissuance submission is simply for
the applicant to request non-publication of the application. This
loophole costs nothing, but it precludes filing in foreign countries
that require publication.
More generally, preissuance submission must take place after pre-grant
publication, so there can be no preissuance submission if there is no
pre-grant publication. The above loopholes prevent preissuance
submission by eliminating pre-grant publication. But pre-grant
publication may also fail to take place in the normal course of
business. By default, it takes place no earlier than 18 months after
the earliest benefit date. If the application does not claim the
benefit of any earlier application, in an ideal world the USPTO should
be able to examine it in less than 18 months, in which case there
would be no pre-grant publication, and hence no possibility of
preisssuance submission.
Since the 18 months delay in publication and the non-publication
request provision are statutory, allowing preissuance submission for
all applications requires a change in the law. Since preissuance
submission is essential for improving the quality of software patents,
such a change is badly needed. I would suggest introducing a minimum
3-month time period between publication and allowance. A request for
non-publication would hold publication in abeyance until the examiner
thinks the claims are allowable; but then the application would be
published and open to preissuance submission of prior art and comments
for three months before actual allowance.
While waiting for legislation to be enacted, the Post-Grant Review
fees should be drastically reduced, and the onerous requirements on
Post-Grant Review petitions should be simplified so that it is not
necessary to hire a patent lawyer to file a petition.
Conclusion
The problem of poor quality software patents is difficult and
multi-faceted, and many ideas have been proposed for addressing it.
Here I would just like to make a few suggestions related to the above
observations.
-
Prioritized Examination should be eliminated.
-
The Post Grant Review request fee should be no greater than the Appeal
Forwarding fee for a small entity ($1,000). There should be no
post-institution fee and no per-claim fee, and a refund of 50% of the
request fee should be given if the request is found to have merit and
the review is granted.
-
Examiners of software patents should be instructed to direct at least
half of their search efforts towards non-patent literature, and to
document the non-patent literature queries that they run. Some
searchable sources of non-patent literature have been suggested by
others in
comments
on prior art resources. I would add the collection of IETF RFCs
and Internet Drafts, which can be searched by restricting a web search
to the site datatracker.ietf.org.
-
In addition to crowdsourcing the search for prior art, the USPTO
should accept and encourage comments by persons skilled in the art,
such as software engineers in the case of software patents, on whether
specifications are comprehensible, provide a full, clear, concise, and
exact description of the invention, and support the claims.
-
The specification of every patent application containing one or more
means-or-step-plus-function claims should be required to contain a
separate section explaining in detail how each claimed function is
provided. This will not guarantee that every security goal asserted
by a means-or-step-plus-function claim is achieved by the invention,
but it will at least help third-party reviewers and examiners to
identify unsupported claims.
The
USPTO has requested comments on “The Use of Crowdsourcing and
Third-Party Preissuance Submissions To Identify Relevant Prior Art,”
and more generally on “ways the Office can use crowdsourcing to
improve the quality of examination.” They are due by April 25. We
are sending ours. Please consider sending yours.
