Source: https://www.ipwatchdog.com/2019/01/09/software-patent-drafting-lessons-key-lighthouse-cases/id=104874/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Ipwatchdog+%28IPWatchdog.com%29
Timestamp: 2019-04-22 20:29:21+00:00

Document:
Obtaining a software patent today is easier than it was just a year ago in most Art Units at the United States Patent and Trademark Office (USPTO), thanks to the Federal Circuit’s decision in Berkheimer v. HP Inc., 881 F.3d 1360 (Fed. Cir. 2018) and the USPTO’s guidance to patent examiners on the Berkheimer decision. Still, obtaining a software patent is more difficult than it was five years ago, and much more difficult than it was ten years ago. The patent laws relating to software have been in a state of near constant flux over the last decade.
In order to have the best chance at obtaining a software patent, and at having that patent survive any post grant challenges after it is issued, it is critically important that the description of the invention be as complete as possible at the time of filing the first patent application. This means the description must clearly identify the invention as of day one, even if you file a provisional patent application, since a provisional patent application must completely articulate the invention with enough detail to satisfy 35 U.S.C. 112 in order to provide priority.
This is easy enough to say, but what does it really mean? Over the last several years we have learned from a variety of cases what type of information the Federal Circuit will look to in order to be persuaded that the claimed invention is truly innovative and is either not an abstract idea, or—if it is an abstract idea at its core—has enough accoutrements surrounding it so that it does, in fact, define an invention.
In order to adequately identify and describe a software-related invention (also known as a computer-implemented invention) consider the lessons from the following cases. These are the cases you want the Federal Circuit to apply and analogize to your claimed invention because, when they do, the claims are patent eligible. This makes these cases “lighthouse” cases with critical lessons for drafters.
The key to obtaining a software patent is to thoroughly describe the system and processes from a technological level. As Judge Chen explained in DDR Holdings, in order for software patent claims to be patent eligible they must not “merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet.” To be patent eligible, claims to software must be “rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks.” To have a realistic chance of being patented, the computer method must be tied to a particular computer technology in a meaningful and substantial way. Said another way, the method really needs to be performed by and through a concrete and tangible system, where the system and processes are painstakingly described.
In Enfish LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), the Federal Circuit explained that the Supreme Court suggested in Alice that claims that improve the functioning of a computer might not succumb to the abstract idea exception. The Federal Circuit relied on this important caveat because, according to the panel, the claims at issue in Enfish plainly focused on improvements to computer functionality. This led the panel to unanimously conclude that “the claims at issue in this appeal are not directed to an abstract idea within the meaning of Alice. Rather, they are directed to a specific improvement to the way computers operate, embodied in the self-referential table.” Therefore, it is extremely important to describe the invention as an improvement, with at least some time in the specification spent explaining exactly what the invention provides that is superior compared with the prior art (obviously being careful not to run afoul of KSR concerns).
In Thales Visionix Inc. v. U.S., 850 F.3d 1343 (Fed. Cir. 2017), the Federal Circuit was faced with an invention relating to an inertial tracking system for tracking the motion of an object relative to a moving reference frame. The claims provide a method that eliminates many “complications” inherent in previous solutions for determining position and orientation of an object on a moving platform, with multiple advantages disclosed over the prior art in the specification. The panel found the “claims directed to a new and useful technique for using sensors to more efficiently track an object on a moving platform.” While this is certainly the type of invention that can be patented, the claims were a bit weaker than ideal. With a different panel, it would be easy to see this case going another way. What likely saved the claims was the specification explaining that the inertial sensors do not use a conventional approach with respect to measuring inertial changes relative to the earth, which allowed the panel to follow Enfish. Still, it would have been preferable to draft the claims to incorporate that core uniqueness in the claims.
Can you read into the specification from the claims? Absolutely! The law says you cannot impermissibly read into the claims from the specification, so there must be a time and place when it is permissible. It is permissible with respect to definitions and disclosure of technologies. The whole point of the specification is to be the glossary for the claims and to facilitate in understanding what is in the claims. There is no better example of this than Finjan, Inc. v. Blue Coat Systems, 879 F.3d 1299 (Fed. Cir. 2018). At first glance, the claims are very short—even cryptic. But there are terms repeatedly used throughout the claims that are discussed and defined in the specification. And the specification defines a revolutionary computer virus scanning technology that was pioneered by Finjan. Judge Dyk, writing for the panel, explained the “method of claim 1 employs a new kind of file that enables a computer security system to do things it could not do before.” This is significant because Judge Dyk, until recently, has seemed reluctant to find software patent eligible. So, the lesson here is simple: If your client is a pioneer and the innovation is important, make sure the specification explains that! Of course, don’t just say it; really explain the difference a la Enfish.
Graphical user interfaces can receive design patents, but they can also receive utility patents. See Core Wireless Licensing S.A.R.L. v. LG Electronics, 880 F.3d. 1356 (2018). The claims disclosed a specific manner of displaying a limited set of information to the user, rather than using conventional user interface methods to display a generic index on a computer. Like the improved systems claimed in Enfish, Thales, Visual Memory, and Finjan, these claims recite a specific improvement over prior systems. Judge Moore explained the speed of a user’s navigation through various views and windows can be improved because it “saves the user from navigating to the required application, opening it up, and then navigating within that application to enable the data of interest to be seen or a function of interest to be activated.” Of course, to matter, the specification needed to adequately define the improvement in the aforementioned functioning of computers.
If the importance of a thorough description defining the core uniqueness of the innovation in the specification hasn’t shone through yet, the Federal Circuit’s recent decision in Ancora Technologies, Inc. v. HTC America, Inc. (Fed. Cir. 2018) should help cut through the fog. Relying on Enfish, Judge Taranto, joined by Judges Dyk and Wallach, found that the claims at issue covered “a concrete assignment of specified functions among a computer’s components to improve computer security.” The patent itself explained the claimed invention did this by relying on specific and unique characteristics not previously used in the way now claimed. Judge Taranto explained that the Court lacked any basis for disputing what was said in the patent itself, and what was said is reinforced by the prosecution history, including the examiner’s stated reasons for allowance. Thus, the take-away lesson here is again the importance of describing the technology fully and clearly, including asserting its uniqueness, while obviously paying careful attention to not walk into obviousness rejections.
Those CAFC decisions are not Alice compliant.
Alice is not Congress-written statutory law compliant.
My process was rooted in computer technology, that is where the problem exists (McRO). My process was not even accomplished by humans (EVER). In McRO lip sync was accomplished by human but not computers and received a patent when performed by computers. Yet I put my process was “never” achieved by experts and professionals, I put the process on a computer and it is rejected? Illogical. That is where the problem existed, in their computer network.
My process improved their computer network, it stops the mistakes. Their administrative network or computer network could not stop the oversights when done manually for decades or by computer for decades. Again my solution was rejected.
In DDR Holdings, in order for software patent claims to be patent eligible they must not “merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet.” My process was never done on the face of the Earth, pre-internet or post internet. Rejected again.
Having a patent examiner that follows their own memos, their own MPEP, the actual law, what these lighthouse court cases really say, and the hard evidence would be a plus for me.
I am holding my breathe whether the examiners will follow the new 101 guidelines of “practical application”, another way of saying concrete steps that solve a real problem beyond the reach of experts and professionals are patent eligible. It may be just another dis-regarded “official” memo.

References: v. 
 v. 
 v. 
 v. 
 v. 
 v.