Many inventions in our world today utilize user inputs. From our phones to our dishwashers, we have modern amenities that used to be the stuff of science fiction novels. Protecting those innovations through patents is vital to ensure our society continues to have such new and improved amenities.

However, there are many pitfalls in obtaining patent protection when user inputs are involved, not the least of which is the issue of divided infringement. While not the subject of this post, there are many other resources discussing how to draft claims to reduce the impact of requiring the user to obtain direct infringement.  Instead, this post focuses on patent drafting tips related to another, little discussed, issue that relates to providing backstops against overly-broad interpretations (under the USPTO's Broadest Reasonable Interpretation doctrine) of claim terms related to receiving a user input.

Often a key differentiation in some interactive inventions is the ability to enable the user to have only the information they need at a given time and then receive user inputs to help direct future displays or future feedback to the user. Unfortunately, some patent drafting simply refers to user inputs generally as it is often understood implicitly what is intended. For anyone experienced with Examiner interpretations, this approach should immediately cause concern - one can never rely on common sense or implicit meanings with an Examiner bent on rejecting an application.

A common problem in this regard is Examiners interpreting anything caused by a user to be a user input. Consider a room where a user is sitting - an Examiner can allege that a temperature sensor in the room is a user input because the user's body causes the room temperature to increase slightly.  Further, such an input is constantly present so the Examiner can argue that such an input occurs at every instance. 

Therefore, when drafting a patent application where user interactions are an important aspect, it is prudent to spend some time describing various examples of the user input, including when there is not user input (see previous post on negative limitations here and here and here). Further, the drafter should try to anticipate all of the sensed parameters users may affect and distinguish them from the desired scope of the relevant user input (for example via more specific non-limiting examples in the specification). Claims can still be initially filed that are generic in the hopes of reasonable interpretations, knowing that additional support is available in the specification should it be necessary during prosecution.