The smartphone platform, with its built-in sensors, processing power, display, and portability, opened up a whole world of new software tools that now impact our daily lives. Through apps, a smartphone becomes a level, a voice recorder, an alarm clock, an airline boarding ticket, and on and on. Most people today use hundreds of apps without ever thinking twice.
But can one use utility patents to protect new and non-obvious features encapsulated in a smartphone app? According to various sources on the internet, the resounding answer is “YES” (with the usual caveats). And in theory, this answer is correct. But, in practice, the road to patent protection is generally difficult and fraught with dead ends due to the Abstract Idea exception in US patent law. The Abstract Idea framework used by the USPTO follows a two-pronged test:
(1) Does the claim recite an abstract idea?
(2) And if so, does the claim have additional elements that integrate the abstract idea into a practical application (i.e., is the claim directed to an abstract idea or a practical application?
Simple enough, but of course these words do not mean what one would think they mean. Under Prong 1, three key concepts are dubbed abstract ideas: (a) mathematical concepts, (b) methods of organizing human activity, and (c) mental processes. Who would claim a mental process? Well no one, but of course the USPTO ignores elements that require processors and the like to enable abstract idea rejections.
In Prong 2, the USPTO then considers the claim in its entirety in terms of whether it is directed to an abstract idea, including whether the claims integrate the abstract idea into a practical application. But a substantial limitation here is that any improvement to the abstract idea itself (even what one might think are technical aspects) does not qualify for Prong 2.
As may be apparent, the generally vague rules and special definitions often enable the Abstract Idea exception to swallow the rule of patentability, particularly when applied to a smartphone app. To see how this works in practice, we consider a recent PTAB appeal. Appeal 2023-001325, Application 15/752,647.
The invention relates to a smartphone app that monitors sounds made by a sleeping person in order to identify sleep disorder breathing events automatically while the user sleeps. Claim 1 on appeal is reproduced below:
1. A method for detecting sleep disordered breathing of a user, the method comprising:
receiving, in a processor, an input audio signal that comprises data samples of a signal generated by a microphone, the input audio signal representing sounds of the user during a period of sleep;
determining, in the processor, from the received input audio signal, at least one reliable respiration epoch (RRE), wherein a period of the received input audio signal is classified as RRE based on whether the period includes a plurality of sections respectively satisfying a start section criteria and a middle section criteria, the middle section criteria comprising a period of audible breathing, wherein to determine the at least one RRE, each frame of a plurality of frames of the input audio signal is analysed to determine whether audio signal levels of a current frame commenced after a predetermined number of seconds of repetitive and uninterrupted signal types determined from audio signals of one or more preceding frames, and that such signal types continued in subsequent frames;
detecting, in the processor and based on data in at least one determined RRE, presence of a sleep disordered breathing event;
outputting on a display of a screening device, from the processor, an indicator of the detected sleep disordered breathing event that is based on data in at least one determined RRE; and
transmitting, via a transmitter, (a) the indicator of the detected sleep disordered breathing event that is based on data in at least one determined RRE, or (b) data in at least one determined RRE, to a database for a subsequent analysis to help the user with further diagnosis for treatment of sleep disordered breathing by a respiratory therapy device.
The applicant here explained in the specification how the particular way in which the sound data was processed (with the defined periods, frames, etc.) with a particular signal processing algorithm reliably identified the disordered breathing event. The identified events are then output to a database for diagnosis.
The only rejection on appeal was under Section 101 (Abstract Idea), meaning that the USPTO had not identified any prior art that would render claim 1 anticipated (lack of novelty) or obvious. Thus, in this analysis, claim 1 is presumed novel and inventive over the state of the art. Nevertheless, the PTAB confirmed the examiner’s rejection as claim 1 was merely an Abstract idea.
The details of the reasoning are typical of most abstract idea rejections. The USPTO breaks down the claim by identifying the abstract idea (which includes the details of the claimed method for identifying the disordered breathing events). These aspects are easy to bin as events that can all be performed in the human mind, and/or are merely a mathematical algorithm. Thus, under Prong 1, the claim recites an abstract idea.
Moving to Prong 2, the PTAB summarizes the claim as reciting the following:
What is left beyond this abstract idea is then mere extra solution activity (e.g., the processor, the database, etc.). But what about all of the elements ignored via the “…”? Those features seem to provide substantial technical detail that make the system actually able to do the detection. Well, according to the PTAB, those merely improve the abstract idea itself – i.e., “[no] matter how much of an advance in the field of sleep monitoring that the claims recite, the advance lies entirely in the realm of abstract ideas, with no plausibly alleged innovation in the non-abstract application realm.”
This approach generally works for any smartphone application, and indeed the PTAB admits as much. The following quotes from this particular PTAB decision are typical:
… Generously construed, Appellant’s invention is just a smart phone app that can forward diagnostic data via conventional telecommunication means integral to a conventional smart phone. … It appears that Appellant’s method can be performed using nothing more than a conventional smart phone or tablet that has an integrated microphone. … Essentially, all Appellant has done here is create a smart phone app that uses the phone’s internal microphone to receive breathing sounds and then uses an algorithm in the smart phone app to analyze the breathing sounds and then output the results on the smart phone display screen. This is quintessentially receiving information, analyzing it, and then outputting the results of the collection and analysis. …”
The PTAB’s disdain for patent applications trying to protect smartphone apps is not hidden. From the general statements in the PTAB’s decision quoted above, it should be clear that patenting a smartphone app, even if it is novel and inventive, can be an uphill battle. In this way, many well-drafted patent applications, such as 15/752,647, meet their end via an Abstract Idea rejection.
Developing a successful strategy to overcome the Abstract Idea hurdles can require some outside the box thinking, particularly when trying to protect aspects of a smartphone app. One possible approach relates to the idea of improving the operation of the processor (even a generic one). In the decision above, the PTAB notes that no such approach was argued: “[the invention] does not purport to improve the operation of a smart phone.” While it is true that the applicant did not present arguments (linked to claim elements) as to how the operation of the smartphone itself was improved, there was some evidence in the record pointing in this direction. For example, the specification explained how the audio data was sampled and processed, including how the data was transformed to the frequency domain and then the data binned by frequency. Certain frequency bins were used in the diagnosis, while others were not. This binning technique thus avoided processing of certain frequencies not only enables increased processing speed, but reduces the likelihood that irrelevant sounds in the data would mask the sounds of interest to the diagnosis. Further details in the specification go on to give various other aspects that may relate to improving the functioning of the smartphone itself (as opposed to merely improving the abstract idea). These aspects (that were included in various dependent claims) illustrate ways in which one might be able to successfully navigate through the USPTO in order to protect an invention that is “merely” a smartphone app.
So, if you are seeking protection of your smartphone app, know that the path will be difficult. If you do embark on it, consider how the buttress your application with technical details that can help address rejections and analysis like that in SN xxx.