Inventing Software : The Rise of "Computer-Related" Patents

Rating:
Summary: Practical explanations about how the law applies to software
Review: I liked this book because of its practitioner focus. It really explains the law and how it does (and doesn't!) apply to software. Kenneth Nichols also does a good job of "putting things in a universe," helping the reader to understand how the application of patent and copyright law to software has become so muddled.

I especially liked the chapter on "Software Patent Examples" where he discusses the vagaries of applying the law to various typical software products.

The book is also pleasingly short (169 pp.)--fits well in a briefcase as an airline read.

So many books on patent law are written by lawyers who aren't practicing software developers. As a developer and lawyer, Kenneth Nichols is uniquely positioned to comment on this subject. I see that Quorum Books, which I gather is a quality publisher of law titles, agreed.

Rating:
Summary: Many wrong statements about the patent law
Review: I liked this book because of its practitioner focus. It really explains the law and how it does (and doesn't!) apply to software. Kenneth Nichols also does a good job of "putting things in a universe," helping the reader to understand how the application of patent and copyright law to software has become so muddled.

I especially liked the chapter on "Software Patent Examples" where he discusses the vagaries of applying the law to various typical software products.

The book is also pleasingly short (169 pp.)--fits well in a briefcase as an airline read.

So many books on patent law are written by lawyers who aren't practicing software developers. As a developer and lawyer, Kenneth Nichols is uniquely positioned to comment on this subject. I see that Quorum Books, which I gather is a quality publisher of law titles, agreed.

Rating:
Summary: Every software developer should read this
Review: Kenneth Nichols is both a computer scientist and a lawyer. This gives him a fantastic grounding from which to write about software patents.

Why should YOU read this book?

Just as a literate programmer reads journal articles, design documents, and source code, so should he or she be able to evaluate software patents. This ability is fast becoming a competitive necessity, for economic as well as legal reasons. (page 55)

What's in this book?

Nichols first explains what the problem is. Why are software patents a problem? How can one enforce a software patent? In what ways does software not fit into the regular patent process? What exactly is a patent anyway?

Software patents are currently defined in terms of algorithms. But what exactly does the court system understand to be an algorithm, and how is that different from the viewpoint of a computer scientist? Answering this question is the subject of chapter two. Along the way, Nichols shows the problems with trying to patent (under the current system) several different programming paradigms such as self-modifying programs and distributed computing, imperative mode versus object-oriented mode versus functional and declarative paradigms. He also shows how software engineering techniques can help document the pieces needed in writing a software patent specification.

Chapter three defines some major terminology of the patent process and shows how it relates to software. For example, there is a distinction between 'novel' and 'nonobvious'. Also, a software patent must carefully delineate the 'scope' and 'claims' of the patent. To help make this book as practical as possible, this chapter examines (in depth), four actual software patents: a text-searching system; an object-oriented database; a 'C' source code blocker; and a special-purpose sorting method.

The next chapter takes on the debate of whether or not software patents are a good idea, and examines each side in detail including the practical concerns of enforcement and detection of infringement. After looking at this debate, Nichols presents the SDKR (named after the lastname initials of its authors: samuelson, Davis, Kapor, and Reichman). The SDKR is a proposal which ``advocates a special form of intellectual property for computer software'' to replace software patents by doing several things:

merge software copyright and software patent; focus on mass market software only;

preserve the software market and still foster software innovation;

create a clear set of legal rules specifically for software;

provide legal protection on a shorter length than current patents, acknowledging that the software lifecycle is very different from other patentable inventions;

provide protection to a program's behavior instead of just the exact implementation that produces a behavior; and

protect ``innovation'' of software instead of the stricter ``inventiveness'' required by current patent law.

Chapter six is chock full of practical advice for software developers who want to protect their software. The next two chapters are a summary and a look at the future of software programming. I highly recommend this book to anyone who plans to develop software as a livelihood... software patents can not only protect your investment of time, energy, and creativity in the programming process, but they can even earn you some extra money if others are forced to license your software from you in order not to violate your patent.

Rating:
Summary: Every software developer should read this
Review: Kenneth Nichols is both a computer scientist and a lawyer. This gives him a fantastic grounding from which to write about software patents.

Why should YOU read this book?

Just as a literate programmer reads journal articles, design documents, and source code, so should he or she be able to evaluate software patents. This ability is fast becoming a competitive necessity, for economic as well as legal reasons. (page 55)

What's in this book?

Nichols first explains what the problem is. Why are software patents a problem? How can one enforce a software patent? In what ways does software not fit into the regular patent process? What exactly is a patent anyway?

Software patents are currently defined in terms of algorithms. But what exactly does the court system understand to be an algorithm, and how is that different from the viewpoint of a computer scientist? Answering this question is the subject of chapter two. Along the way, Nichols shows the problems with trying to patent (under the current system) several different programming paradigms such as self-modifying programs and distributed computing, imperative mode versus object-oriented mode versus functional and declarative paradigms. He also shows how software engineering techniques can help document the pieces needed in writing a software patent specification.

Chapter three defines some major terminology of the patent process and shows how it relates to software. For example, there is a distinction between 'novel' and 'nonobvious'. Also, a software patent must carefully delineate the 'scope' and 'claims' of the patent. To help make this book as practical as possible, this chapter examines (in depth), four actual software patents: a text-searching system; an object-oriented database; a 'C' source code blocker; and a special-purpose sorting method.

The next chapter takes on the debate of whether or not software patents are a good idea, and examines each side in detail including the practical concerns of enforcement and detection of infringement. After looking at this debate, Nichols presents the SDKR (named after the lastname initials of its authors: samuelson, Davis, Kapor, and Reichman). The SDKR is a proposal which ``advocates a special form of intellectual property for computer software'' to replace software patents by doing several things:

merge software copyright and software patent; focus on mass market software only;

preserve the software market and still foster software innovation;

create a clear set of legal rules specifically for software;

provide legal protection on a shorter length than current patents, acknowledging that the software lifecycle is very different from other patentable inventions;

provide protection to a program's behavior instead of just the exact implementation that produces a behavior; and

protect ``innovation'' of software instead of the stricter ``inventiveness'' required by current patent law.

Chapter six is chock full of practical advice for software developers who want to protect their software. The next two chapters are a summary and a look at the future of software programming. I highly recommend this book to anyone who plans to develop software as a livelihood... software patents can not only protect your investment of time, energy, and creativity in the programming process, but they can even earn you some extra money if others are forced to license your software from you in order not to violate your patent.

Rating:
Summary: Many wrong statements about the patent law
Review: The book is full of errors and mistakes. The author apparently knows very little about the U.S. patent law. Many assertions of the book are simply wrong. If you want to learn something about patents, this is not the book for you. For example, the author boldly and wrongly declares that the U.S. patent grants 20 years of exclusive use. The author is completely unaware one of the most important terms in intepreting patent claims: "comprising" which means "including but not limited to" in patent law. As a consequence, the author mistakenly, but convincingly, explains in detail why a claim 2 is broader than a claim 1 when in fact the claim 1 is broader than the claim 2. Because the book is well written and easy to read (with interesting statistics and stories, etc.), it is even more dangerous for readers because it constantly declares wrong laws. A reader may be taught some patent myth instead of useful information. The author should have had someone with at least some patent law experience to review it and correct the misstatements before it was released to the public.