Why Patents Should Be More Practical
NicelyDoneGaming.com – Casino gaming design & development services
NicelyDoneDefense.com – Casino gaming expert witness services
During a recent cross-examination, counsel asked me how often game development teams used my patents for game design guidance.
The exchange went something like this:
Counsel: How many of your patents have been used to build a product?
me: Zero times, as far as I am aware.
Counsel: None of your 180 plus patents were ever turned into a game?
me: Quite a few of my patents were implemented, however, I cannot think of a single instance where a product specification included a utility patent filing.
Counsel: Why is that? Don’t these patents contain important information useful for the development staff?
me: That is a qualified “yes”. Yes, my patents all contain detailed descriptions of the components and functionality incorporated in the invention, however, this information is organized and expressed in such a way as to typically make it less-than-useless to development teams.
Counsel: “Less than useless?” -- why is that?
me: It is challenging to create a game design document that developers will continually follow as a specification instead of just scanning it once as general background info.
Patents are written for lawyers, examiners, and judges – not designers, content creators, engineers, project managers, etc. The inclusion of all or part of a patent filing in a game design doc increases the risk of team members ignoring the entire document with little to no countervailing benefit.
Whenever I testify in court or for a deposition, I try to identify and record the lessons learned for future reference. This usually includes writing down the most challenging questions posed to me and corresponding best responses – sometimes what I said, many other times, what I wish I had said. I didn’t write down this particular question because it struck me as such an irrelevant one-off.
However, a few weeks later, a related thought came to mind. Specifically, why are patents so useless for providing design & development guidance?
There are a few reasons I consider patents to be less-than-useful for would-be developers. The formal language is usually hard to follow. Game screen illustrations are often plastered with excessively verbose text never meant for a commercial product. Implementation details are often split between boiler-plate language in one section, and scattered, hap-hazard references elsewhere.
Is there a value in having patent specifications be so developer unfriendly? Not that I would ever imagine patents ever substituting for a GDD, but I do see some advantages to making patents easier to follow.
First off, the more human-readable the specification, the easier it should be for the patent examiner and future attorneys to understand what is supposed to be going on. Beyond simply providing the required support for the claims, there are innumerable ways the specification can be crafted. For example, I’ve started adding a definition section at the start of my specifications to both ease the reader into the key phrases and to provide ongoing clarification for all future uses.
Another advantage of making the patent specification more like a game design document is that it increases the likelihood that game designers will be more involved in the prosecution process of their own patent. Getting the game inventor(s) to write an initial draft, in a game design doc fashion, means that many useful commercialization details will be communicated to the world (including examiners and attorneys) and will greatly increase subsequent inventor review participation.
Finally, there is the potential issue of functional claiming (35 U.S.C, section 112, paragraph 6). I spent a great deal of time investigating Functional claiming issues during my Konami Gaming, Inc. v. High 5 Games, LLC engagement. It scared a few cat lives out of me.
My two biggest takeaways for my next green-field patent:
1) My patent attorney will need to explain in slow, clear detail, why the claims could never be construed as functional
2) My specification will be written such that it will hopefully be able to survive a §112, para 6 attack anyway
Now with my newfound insight, I have a third item for the list:
3) Write the specification more like a game design document, and less like an inscrutable tome from an ancient mystery religion
NicelyDoneGaming.com/casino-gaming-topics/complex-patent-vs-game-design-doc.html
other gaming topics: NicelyDoneGaming.com/casino-gaming-topics.html
Copyright 2020 Mark C. Nicely. All rights reserved.