The “Background” section of a patent application seems so innocuous and straightforward. What could more simple than the background of the invention? Unfortunately, a lot of things can be less important and strategic than the background. Cases sometimes come down to how something is characterized in the background.

There are various thoughts on how to approach backgrounds in patent applications. One approach is to completely avoid them. Neither the MPEP nor the CFR actually require a background and so it is certainly possible to write and prosecute successful patent applications without any background section. Another approach is to say almost nothing, but at least set the stage for the particular area of the invention. Still another approach utilizes the background to help tell a story and introduce the problem-solution structure supporting the invention. Depending on the situation, client objectives, etc., a skilled practitioner selects from among these and other options to draft the patent application. The background, or lack thereof, can have implications across a wide range of rejections and the PTAB very often cites the background, for better or worse, when explaining its decisions, particularly with regard to Section 101.

Today we review and IBM application that the PTAB found invalid as an abstract idea under 35 USC Section 101. The invention relates to a system and method of using product profiling to maximize transportation capacity while meeting other business objectives, e.g., profitability (SN 14/029,959). The application is relatively short including only one generic computer block diagram, and two relatively simple flow charts.

The PTAB walks through the background and summary of the invention, pointing out that the conventional approach for shipping boxes uses a cubing algorithm. IBM had explained in their background section that the problem with the cubing algorithm is that the known algorithms only focus on the properties of the package, without regard to the actual product or associated cost of manufacturing, etc. The solution presented by IBM was to modify the cubing algorithm to take into account the product information, thus leading to more efficient loading of packages in a transport vessel and thus more efficient shipping.

The examiner alleged that the claims were directed to the abstract idea of load scheduling, and the PTAB concluded that even under the new guidelines, the claims were not patentable. The PTAB was unable to find any real technical problem other than the abstract idea. The applicant’s background was unhelpful here, even though it did lay out what looked like a technical problem - the inability of the cubing algorithm to address other factors. The problem was that the solution could be carried out in the human mind, at least according to the PTAB.

From their decision:

Although claim 1 recites the use of a CPU, a computer readable memory, and a computer readable storage media, the underlying processes recited in the claim, including (1) receiving information, i.e., product profiles, product information, and a break point; and (2) analyzing the information to identify products for shipment, which maximize profitability, are acts that, as the Examiner observes, could be performed by a human, e.g., mentally and/or manually, using pen and paper, with the use of a computer or any other machine. Simply put, claim 1 is directed to concepts that can be performed in the human mind, i.e., mental processes, and mathematical formulas, i.e., mathematical concepts, and, therefore, to an abstract idea. See 2019 REVISED PA TENT SUBJECT MATTER ELIGIBILITY GUIDANCE, 84 Fed. Reg. 50, 52 (Jan. 7, 2019) ("Revised Guidance").

One problem with this “human mind” or “pen and paper” exception is that, at some level, every algorithm implement by a computer could be carried out by pencil and paper, given enough pencils and papers and infinite time. But we will leave that issue for another day.

So, in drafting a background in the software arts, if a problem-solution approach is taken, it may be helpful to describe more technical problems with implementing algorithms rather than merely improved business operation.