Internet of Things Continued: Subject Matter Eligibility

In the first part of this three-part series on issues related to obtaining and enforcing patent protection issues in the IoT space, we touched on circumstances related to divided infringement, and subject matter eligibility.  In this second part, we continue the discussion related to subject matter eligibility, by providing some examples of how to structure claims to avoid invoking rejections based on claims directed to an abstract idea, and provide examples of strategies to potentially overcome close prior art references. 
            As an example, there may be cases where an examiner may deem an IoT-based concept patent-ineligible due to prior art in which a non-IoT sensor of sorts is utilized in some fashion to accomplish a similar goal as the stated goal of the IoT-based concept.  In other words, if a certain concept is already known that uses a non-IoT sensor, it may be challenging to assert novelty where an IoT-based concept accomplishes a similar goal as prior art using a non-IoT sensor.
Returning to the example of the autonomous vehicle mentioned in Part I of this series, consider a situation where it may be desirable to update a vehicle operating parameter (e.g. engine operating parameter, climate control parameter, vehicle sensor calibration, etc.), based on data retrieved from one or more IoT sensors.  In such an example, there may be prior art teaching the obtaining of such data from a source other than one or more IoT devices.  However, there may be significant advantage to obtaining data from one or more IoT devices, such as the data being more robust and accurate, the data being obtainable more frequently, the data providing significant improvements to safety features, the data providing significant enhancements to a lifetime of valuable vehicular components, etc.  So in this type of situation, how can claims be structured to differentiate from prior art?
One option may include structuring claims to base the acquiring of IoT data on relevant vehicle-operating parameters.  For instance, if IoT sensor data is being utilized for a diagnostic test of an autonomous vehicle, and the diagnostic would be enhanced by conditions including that the vehicle is not occupied and the engine is off, then it may be beneficial to structure claim language to state that the IoT data is retrieved responsive to an indication that the engine has been off for a predetermined duration, and further responsive to an indication that the vehicle is not occupied (e.g. via seat load cells, door sensing technology, etc.), to differentiate from prior art.  The examples provided are meant to be exemplary, but there may be numerous possibilities for tying-in the retrieval of IoT data with relevant vehicle-operating parameters.
Because IoT-based sensor data may be acquired in a fashion different from prior art (e.g. more frequently, crowd-sourced, geographically-based, etc.), there may be new opportunities for utilizing such data for various methodologies related to vehicular diagnostics, etc.  Thus, it may be important to identify what methodologies may be improved significantly by incorporating data obtained from IoT sources, and then to further identify what physical limitations can be introduced into a claim to set it apart from prior art, without invoking Alice rejections.
Another option along the same lines may include only acquiring and utilizing IoT data responsive to certain thresholds being met.  For example, are there novel aspects of what the IoT data will be utilized for that may be sensitive to particular vehicle operating parameters exceeding certain thresholds?  Examples may include (but are not limited to), only retrieving IoT data and adjusting a particular vehicle operating parameter (or parameters) subject to engine temperature below a threshold engine temperature threshold, responsive to an exhaust catalyst temperature above an exhaust catalyst temperature threshold, responsive to a fuel vapor storage canister concentration above a concentration threshold, etc.
Still another option may include setting tiers of confidence levels for particular IoT devices.  For example, a vehicle onboard navigation system may be utilized in conjunction with a means for communicating with IoT devices, to “learn” different sources of IoT data, and to associate confidence values with the different sources of IoT data.  Claims may thus be drafted to include language stating updating certain vehicle operating parameters based on confidence level of the IoT data source.  As an example, a particular vehicle operating parameter may only be updated, or a particular vehicle sensor calibrated, responsive to an indication that the IoT data comprises high confidence IoT data.  Such a limitation may not be available using prior art methodology.
For example, a particular vehicle operating parameter may not be updated via conventional sensors positioned external to the vehicle, for example, but may only be updated responsive to an indication that the data was crowd-sourced from a plurality of IoT data devices, and where the crowd-sourced data comprises high confidence data.  In other examples, one vehicle operating parameter may be adjustable responsive to low confidence IoT data, while another vehicle operating parameter may ignore such low confidence data.  Thus, distinguishing and defining the use of IoT data may in some examples be a way to overcome prior art issues.
In conclusion, drafting claims in the IoT patent space is challenging, but strong claims can be drafted and desired protection achieved by taking into consideration the points discussed in Parts I and II of this series.

Popular posts from this blog

Surprising Uses for Oobleck

Dispensing with the Formalities: Ex Parte Quayle Actions

Adaptive Headlight IP