“There is a difference between engineering requirements and the dogmas of patent prosecution. However, the gap between legal patent requirements and engineering practice in the United States, especially in computer implemented inventions, has become so large as to be irrational and unsupported by scientific facts.”

As an independent inventor, I am greatly concerned about the new proposed Section 112(f) wording related to “functional claiming” that was put forward as part of the fix for patent eligibility law. While the bill is on the back burner for now, lawmakers have stated their desire to revive it. In my mind it is part of a continuing effort to prevent inventors of computer-implemented inventions from experiencing smooth sailing in patent prosecution and patent assertion.

A description of what computers do and how they “logically” work has a close relationship with its physical structure. These aspects are closely interwoven and largely equivalent. Executing a computer operation means that physical circuits are activated. A computer operation or function is not a disembodied occurrence. An instruction executed by a computer is a rapid configuration/activation of one or more (usually electrical) circuits.

Technical Background

In the early 1950s, the use of Boolean algebra in circuit design as proposed by Claude Shannon became dominant in computer design. Two eminent computer designers, Dr. “Gerry” Blaauw and Dr. Fred Brooks of IBM formalized the relation between what a computer user experiences and what the hardware is. A design of a computer, they say, has three levels:

a) Architecture; (What the user sees or experiences, the user in their view being a system programmer. One can easily expand to application programmers.) b) Logic implementation (the logic design, usually in terms of a Boolean algebra); and c) Realization (the physical structure).

(Drs. Blaauw and Brooks with Dr. Amdahl were the original architects of the legendary IBM System/360 series of machines, so their writings and ideas have considerable weight).

Design levels describe the same structure, but in different terms. For instance, a machine may perform on an architectural level a fixed-point addition (a+b)-radix n. An end-user may describe this as an integer addition by a computer. On a logical implementation level, the combining may be described by a carry-ripple structure or a faster carry-predict structure. On a realization level, the structure may be realized as relay switches, in TTL components, in CMOS based circuitry, in optical circuits or in any circuit that is characterized by the logical implementation and thus by the architecture. All generate the same result.

Combining two numbers by a digital machine into a sum is not merely a functional description, it inherently has a physical realization. For illustrative purposes a calculation operation is used as example. But all computer operations are captured by this approach.

Actual Cases

I work with a computer function called “an addition over a finite field GF(n=2p).” This function is realized by XOR devices that bitwise process two words of bits. This is a known physical device and is not merely a mathematical concept. It is used in encryption (in the Advanced Encryption Standard AES) and in hashing (such as the Secure Hashing Algorithm versions). As logical implementation, the function represents physical states of a device based on a switching table (truth-table), which can be realized as data stored on a memory or as a combinational circuit.

I invented a way to modify the computer device so that it maintains major properties, but behaves differently. (If you are interested how this works you can find extensive descriptions on ternarylogic.com.)

The result is a modified computer device that replaces the classical addition over GF(n=2p) with a novel equivalent but different device. Inventions in these cases are on a spectrum of implementation and architecture. The modification of switching functions are best characterized in terms of logical implementation. On an architectural level the modified functions are used in repeat application in what one may call “exponentiation.” On an end-user level, modified functions are applied to customize known cryptographic methods like AES, SHA, RSA and Diffie-Hellman.

One result is a fantastic number (in the order of factorial N) of potential modifications of known cryptographic methods. (for AES for instance over 10100 modifications.) The inventions provide a quantified advantage and integration in a practical application. So, home free, one expects. Not so fast: a rejection as functional claiming is now on the horizon.

In Computers: Function = Structure

Switching behavior can be described on an architectural level in terms of mathematics, and in implementation by Boolean logic, but ultimately these descriptions are labels for physical structure. Consequently, a digital machine doing something is not merely functional but also structural and inherently so. If the machine cannot perform in accordance with the claimed function then it does not have a required structure. And when a machine can perform a claimed function then it automatically has a corresponding structure.

The description of what a computer does, thus necessarily should be interpreted in terms of the machine and the machine structure, and not in terms of what a human can do. That is why computer-implemented inventions are not directed to an abstract idea such as Boolean algebra.

I did (expectedly) run into Section 101 rejections. I give credit to examiners who were convinced during an interview that the description pertained to a physical structure (rather than mathematics) and once convinced they were very helpful. However, this depended on the specification disclosing the structural aspects, not because of the arguments per se. For instance, it was alleged that an XOR function is functional, not structural. I had to show in the spec where an XOR was designated a device. However, an XOR function performed by a computer is a structural device, no matter if I say that explicitly or not. There is no software in the world that can execute an XOR function without having access to a physical XOR device.

The current Section 112(f) reads:

(f)Element in Claim for a Combination.— An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.

The new Section 112(f) language would read as follows:

(f) Functional Claim Elements — An element in a claim expressed as a specified function without the recital of structure, material, or acts in support thereof shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.

I believe that under this language, rejections will move from “abstract” to “functional”. Basically, they will reflect the current issues in merely another form. The patent on RSA encryption that would now survive an Alice challenge, would probably be rejected as claiming functional language under new 112(f) rules.

There is a difference between engineering requirements and the dogmas of patent prosecution. However, the gap between legal patent requirements and engineering practice in the United States, especially in computer implemented inventions, has become so large as to be irrational and unsupported by scientific facts. “Reasonable people” would and should be able to come up with a compromise on acceptable use of functional language. The history of Alice has demonstrated that reliance by inventors on “reason” in courts and the USPTO is very much detrimental to obtaining valuable patents.

Prosecution of computer implemented inventions, certainly in light of their economic significance, reflects an irrational way of thinking that persists and has infected other types of inventions.

Let Them Prove It Isn’t So

It was stunning how easily a new 112(f) requirement was thrown into the mix of solving Section 101 issues. I believe that, in response, inventors of computer-implemented inventions should present some demands of their own on functional claiming. So, here it goes:

1) Generic terms such as processing instructions with a processor, storing and retrieving data from memory or storage, transmitting and receiving data (through a network) with transmitters and receivers are known in the art as being based on physical structures. There should be no further requirement in a patent on detailing these aspects.

2) Applicants should be allowed to import elements from incorporated references into the specification after allowance/issuance to overcome post-allowance “functional claiming” issues. Invalidating a patent because of failure to explicitly disclose a structure, while referring to those structures in an incorporated reference should no longer happen. Teaching for instance a digital filter by incorporation by reference, or a GPS receiver, adequately teaches such structures when claimed. Teaching a single instance of a structure should be enough to cover the generic structure.

3) Sufficiency of disclosure of a structure should be determined by the USPTO. If the specification is deemed to not sufficiently disclose a structure, an applicant should be able to amend the specification to include structures found in incorporated references. An applicant should be able to rely on the USPTO for this. Once a patent is issued, no court should be able to invalidate a patent on functional claiming. The Courts may blame the USPTO for sloppy work and even remand (which would be novel), but not invalidate a patent on that basis. When an examiner understands an invention, who is a judge to say that it has no structure.

4) Executable programs (source code) teach structure and should be accepted as proof of structure.

5) There are different interpretations if patents that are declared invalid should be eligible for re-issue. An invalidated patent should be automatically entitled to at least a continuation. A patent should not be a one-chance crapshoot that may or may not survive a challenge. Infringers are given plenty opportunities to invalidate a patent. It is about time inventors should have equal opportunities to correct issues.

Image Source: Deposit Photos

Image ID: 61369901

Copyright: iqoncept