If you have followed my past postings, you will know I am often trying to explain issues involved in patenting software or computer business methods. Much of the controversy of the last several years has been whether the software or business method is actually patentable subject matter. This has involved discussions of Section 101 and whether the invention was merely an abstract idea. This posting highlights another wrinkle under Section 112, for patenting software. Do the claims and the specification provide enough information to a person skilled in the art that such person would be enabled to build or practice the invention based upon the claims and specification or, perhaps more fundamentally, did the inventor really possess the knowledge required to perform the invention? These are questions of “enablement” and “possession” under Section 112.
As you may recall, I have frequently suggested that an inventor consider filing his/her own provisional application for patent in the absence of paying a patent professional to draft and file an application. As I have preached, provisional applications for patent were expressly intended to provide patent protection for solo inventors, small entities and technology start-ups. The one essential requirement that must be met by a DIY patent application is that the description (patent specification and drawings) teach “enablement”. (See the “another wrinkle in patenting software” discussed in the first paragraph.)
Earlier this year, the Patent Trial and Appeal Board (PTAB) considered an applicant’s appeal after the application was rejected by the examiner. One topic that the PTAB considered was whether the subject matter of the invention, computer software used to verify legitimacy of insurance claims, was adequately disclosed in the application and rejected claims. Did the disclosure enable the person skilled in the art to replicate the invention. (I have heard attorneys suggest that the patent office rarely considers enablement in determining whether the application is patentable. The case discussed herein however did actively consider the issue.)
First, the claim is lengthy but must be considered:
- A method for verifying insurance claim submissions comprising:
(a) receiving, by a server computer coupled to a network and including a processor executing software instructions within a memory, an insurance claim incident data from a software application executing within a mobile computing device, the insurance claim incident data including a vehicle registration data, a driver identification data or an address data;
(b) executing, by the server computer, a query selecting a verified data stored within a database coupled to the network;
(c) comparing, by the server computer:
(i) a historical insurance data, within the verified data and associated with an operator of the mobile computing device, with the insurance claim incident data to identify a discrepancy including a missing data or an incorrect data within the insurance claim incident data; or
(ii) a second insurance claim incident data, within the verified data and received from a second mobile computing device operated by a second user, with the insurance claim data to identify the discrepancy;
(iii) flagging, by the server computer, the discrepancy, when identified, as inconsistent data between the insurance claim incident data and the historical insurance data or the second insurance claim incident data;
(iv) generating, by the server computer, a verification report, including an electronic document including:
(v) an insurance claim identifier; and
(vi) a calculated score indicating a degree of confidence in the insurance claim incident data according to the missing data or the incorrect data; and
(d) transmitting, by the server computer, the verification report to a second server computer operated by an insurance carrier.
Basically, the claim was for method steps of: (1) receiving insurance claim data, (2) comparing the data with stored historical data, (3) flagging discrepancies between claim data and historical data, (4) calculating a score of confidence based upon the discrepancies and (5) transmitting a verification report.
There is an issue of whether this is utilizing standard or generic computers to perform a function that can be (or historically has been) performed by individuals. However this is a Section 101 issue and will be discussed elsewhere.
The instant issue is whether the claim and specification disclosed enough information to enable a person skilled in the art to replicate the invention. The examiner said no. The examiner stated the claim only listed the intended result but did not disclose how this result was to be accomplished. The patent applicant appealed to the PTAB stating the invention was comparing claim data to historical data and no further explanation was required.
PTAB first made the assumption that a person skilled in computer programing would be able to write a program to discern discrepancies between claim and historical data. The PTAB however next considered whether the disclosure showed the applicant really possessed the invention. The specification must describe the claimed invention in a manner understandable to a person of ordinary skill in the art and that the inventor actually invented the claimed invention. To have “possession”, the specification must disclose at least one method of accomplishing the purpose of the invention.
An invention can be claimed by the function that the invention performs, but the disclosure must still describe at least one method of how the invention is achieved. For computer software, this failure of the description can occur when software algorithms or steps/procedures (what I call logic flow charts) for performing the computer function are not explained at all or not explained in sufficient detail. “In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed.”
Further, the PTAB repeated the MPEP 2161.01(1) stating “it is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement.”
Note that this is actually a similar but different standard from “enablement” since the PTAB is assuming a person skilled in the art could write a program to achieve the functional results. But the specification must also explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. In other words, did the inventor really possess the invention or was the inventors simply stating “use a computer” to achieve a desired function.
“For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of the computer hardware and software”. See MPEP 2161.01(1).
PTAB concluded that the applicant’s specification failed to show how to achieve the claimed functionality of identifying a discrepancy by comparing data. Absent from the specification is any discussion as to the particular steps, i.e., algorithm, necessary to perform the claimed functions. In the absence of an algorithm of sufficient detail, the specification failed to demonstrate to a person of ordinary skill in the art that the inventor possessed the invention including how to program the disclosed server computer to perform the claimed function.
Software or computer business methods must both (i) disclose sufficient information to enable the person skilled in the art how to perform the invention, and (ii) demonstrate the inventor really possessed the invention by demonstrating how the function of the invention was to be achieved. This is a level of detail that cannot be skipped over by superficial reliance that “a computer will perform the task”.
Copyright David McEwing, 2019