Is there a comment of mine caught in the spam filter?

Wayne

the chesire cat in me grins at your post.

I’m wondering out loud if it would shock some of these anti-software judges
if we could point out to them that, “Your honor, you yourself are software.
In the past 10 years almost every molecule in your body has been replaced.

http://skeptics.stackexchange.com/questions/7837/are-all-cells-of-the-human-body-completely-replaced-every-seven-to-ten-years

The only thing of you that remains “you” is your pattern where the latter is mostly established by your DNA and by your neurological connectome, in other words, basically by your software. To assert that software is not real is to assert that you yourself are not real.”

Then rather than showing in painstaking detail the various routines and subroutines that need to occur what I do is I describe in words the following: the simplest approach that can be thought of to accomplish a particular step in the master flow (or its supplements), the approach that will most likely be actually implement, and then the most sophisticated approach that we are currently aware of or that might be available soon.

My goal is to make sure that at least the first two above are “instructionally” enabled.

I find that this structured approach works better in words than in flow diagrams.

Am I missing something or are you talking about more sophisticated software than I typically work on and therefore what you consider a master flow needs to be “chunked” down to the point that you can do what I describe above? Or, do you choose to implement in flow diagrams the structured options that I implement in words?

Mark

PA to PA… I’m not entirely sure. I do think it is possible that in hindsight we will look back in years to come and make that observation.

I personally think it is far more likely that the algorithm line of cases will be extended outward beyond the means-plus-function context.

Sadly, we are in for some difficult years as we continue to have judges who simply don’t understand software. This is compounded by the so many in the software community that themselves refuse to ignore that software is really a series of instructions directed toward computer (or machine) operation.

-Gene

So patent attorney (pa) to pa what are you saying?

What is claimed is:
1. A non-abstract and non-ephemerally-transient machine comprising:
(a) a first programmatically configurable machine part configured to perform a first function of ….
(b) a second ……; and
(z) an Nth programmatically configurable machine part configured to perform ….
wherein portions of said machine parts can overlap in physical space while not overlapping in temporal space.

Are we back to this in the “enlightened” 21st century?

This article is primarily intended for those who are approaching a software project and wanting to get a patent, but who are new to the area and are trying to figure out what they need to know to get the ball rolling. It might also be useful to know that typically my clients are starting out, maybe have some code or pseudo code written, but are at the beginning of a project.

Also, I titled this “A Guide to Patenting Software: —–” specifically with the intent to make it a series. There will be others in the series that will address specific issues more in depth and take a look at various cases and what we can pull from them.

Before getting into my response… I think we are unfortunately hamstrung by the fact that the cases we see in this space so far are inventions that suffer from an infirmity of one kind or another. That is not to malign the attorneys. Pre-Bilski patent applications are a challenge in many cases because the inventions were written in an intellectually honest way acknowledging that the method was the unique innovation. Increasingly we are heading back to the 1970s where the machine needs to be treated like it is the unique inventive contribution even thought that is simply not true.

In terms of “software engineer” and how that differs from a programmer… in my practice experience those who are programmers will not stop and think about the overall system and what it needs to accomplish both in the macro and micro scale. What they do is write code, so they jump in writing code. The only documentation they will frequently have is within the code itself. While documenting within the code is essential, that doesn’t create a design document that can be followed and means that the attorney might have to sift through hundreds of thousands of lines (or more) of code. That isn’t a recipe for successful patent drafting. In my experience with code writing it isn’t the right course to pursue if one wants a successful project either. The project needs planning. Just sitting down and writing code without thinking through what you want to accomplish is no different than writing a patent application without an idea of what the invention is to start. So I stress to my clients the importance of considering things from both a macro and micro perspective.

In terms of the machine, I understand your position. What you raise seems to be what some examiners in certain Art Units are raising as well. I think this is missing what machine-or-transformation means. MOT requires a tethering of the process to a machine and extra solution activity is not enough to satisfy. I don’t know how the computer can be extra solution activity if the process as defined in the claims won’t work absent a machine. I have seen examiners databases are extra solution activity, which is absurd. Without the database the process won’t work, so the process that includes storing and retrieving information from a database, performing calculations and then restoring to a database, for example, has to satisfy machine-or-transformation. If there needs to be something unique about the computer structures then software is no longer patentable and we have to simply pretend that the hardware is what makes things different, when we know that not to be the case.

In terms of the contingencies, I don’t know that one has to absolutely consider them, but if they are not being considered at the drafting stage then I do think there is a big mistake. In order for the system to work once coded it has to have all kinds of contingencies. Delivering a system that returns an error code every time it is not used exactly as designed doesn’t create a very useful system. If the person or people who are designing the software/system want to be the inventors they need to explain to the code writer what needs to happen in all the various situations, otherwise the code writer is the one making the choices. If those choices wind up being important for a claim limitation then the code writer is an inventor.

I also think that the more contingencies that we can get a client to articulate the more likely we are to see things that contribute to patentability. If A then B is the type of static event that doesn’t necessarily help patentability, but dynamic rules make a system more complex, and that in turn makes it far more likely to be unique (i.e., novel and nonobvious), and the complexity then also should contribute to satisfying the machine or transformation test (i.e., the more complex the more integral the machine in order to accomplish the task/functions).

-Gene

No, I don’t think this article needs to wait for CLS Bank. As a “getting started” article it is intended to explain to those who are embarking on the path to protect their innovation what they need to do. Whatever the decision in CLS Bank these types of inventions will still be patentable. The initial steps to discovering and defining what the invention is will remain the same from a practical standpoint (i.e., behind the scenes). Flow charts will never go out of style. Although it went beyond the scope of this article, flow chart are really one of the best ways (if not the best way) to satisfy the algorithm cases. I suspect that strict disclosure requirement from the algorithm cases will ultimately wind up being the rule of the day even when means plus function is not employed.

-Gene

“falsifiability”

. . . which event is not the core . . .

. . . Footwear Engineer. Lewis . . .

Sorry. Eyesight not so good today.

Tifoso

Interesting but there are a few minor points on which the topic could be expanded.

When satisfying the machine-or-transformation test, is it sufficient to state that the computer is a von Neumann machine? (One can see the SCt puzzling over that one, considering the mess CJ Rehnquist made of “falsifiability in Daubert v. Merrell Dow Pharmaceuticals, Inc.) The von Neumann machine is the “overall architecture” of the vast majority of all computers that have been produced since the time of UNI’VAC I. If that is sufficient, does that render the machine-or-transformation test a virtual nullity? Any wise practitioner will have a boilerplate statement that the machine is a von Neumann machine or has the overall architecture of a von Neumann machine. Or must the description get into issues such as interrupt processing vs. polling, caching, overlapped fetch and store, word vs. byte, etc.? The topic can become deeply muddled if we consider the issue of programs as abstractions, that is, divorced from the hardware.

You refer to including a description of what the software does when some event occurs which event it not the core functionality of the software (my words). You are referring to “contingency handling”. The rule of thumb is that 90% of the code covers the 10% that is contingency handling. Is it sufficient to state that if some “unintended event” occurs, the system responds with an error message, e.g., “404 error” or must there be some more “graceful degradation” of the system? Isn’t that really a design choice rather than a mandatory? Does the invention lie in the contingency handling or in how the mainline functions deal with input? Where is the inventive step in rejecting input that is malformed?

You refer to a “software engineer”. How does an SE differ from a systems analyst or programmer?
This term seems to have come from the engineering schools which would label a bootblack a Footwear Engineer Lewis Carroll (or his character Humpty Dumpty) would have had much fun with this.

Might it be better stated that a copyright covers a particular implementation of a system design? The same system can be implemented in COBOL, Fortran, C, C++, PROLOG, or any of the other inhabitants of Jean Sammet’s Tower of Babel and still be patentable.

Again, not disagreeing with you, Gene. Just fleshing out some parts.

Tifoso