Patent Illustrates Five Different Problems with Software Patents

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.