One of the things that makes protecting computer related inventions tricky is that first you have to define the invention, and defining the invention is not something that is altogether easy when the invention is a computer process or relates to software. Sure, it is easy enough to define a list of desired functionality, and if you have some computer programming skills it is easy enough (after investing the requisite time) to write the code that will enable the functionality, but that which can be protected via patent lies somewhere between the desired functionality and the code, making the defining of the invention rather elusive.
As I wrote in a blog post a couple weeks ago titled Writing Software Patent Applications, a patent does not have to be a blueprint, but it must direct. What this means is that you do not have to provide micro-level details, but rather you need to be able to describe how a computer programmer would be able to get from point A to point B, with point A being a list of desired functionality and point B being the code that enables the functionality. So that which is patented is not found either at point A or at point B, but in between. The exclusive rights that will flow from a patent that protects computer processes will describe the journey from point A to point B.
Anyone who had written computer code will know that there are an infinite number of ways to actually write the code, and likely a list of computer languages that could be used to write the code. The code itself and how it is written is protected via copyright, if at all, not through a patent. So when you are trying to define the invention so that it can be described adequately in a patent application you do not need to detail every language that could be used, and you do not need to provide an outline of the routines or subroutines, but what you do need to provide is enough information so that the computer programmer could translate your description into code, so you want to provide enough to allow the computer programmer to create the outline themselves, understanding that the actual approach employed by the computer programmer will be as unique as they are. So you do not protect the creativity that will ultimately be expressed in code form, you protect that logic that underlies the journey from functionality to code.
As an inventor of a computer process what you want to do is first figure out the desired functionality. That is the easy part and the exercise that virtually everyone focuses on. Next, however, you need to figure out all the various paths that could be followed as one navigates through a particular task. Let me use a simple example. Lets say that you have purchased a season pass to an amusement park. Lets say that this amusement park issues passes that have a magnetic strip on the back of the pass to be read by an appropriate scanner at the park entrance. So you have the pass and want to gain entry to the park. You approach the entrance and what could happen? You could swipe the card and the gate opens and you enter, but what if the card has become demagnetized? You will be denied entry. What happens next? What process must be followed? You paid for the pass so the fact that the card has somehow become deactivated should not prevent you from entering the park, but the employee at the park entrance is not going to let you in because your pass doesn’t work. You have a problem.
Actually, you do not have a problem, you just have to do some kind of additional task(s) prior to being able to enter the park. So what you have encountered is a trigger. If your pass were not demagnetized you would have entered, but because it was demagnetized you need to follow a slightly altered route to gain access to the park. This is simple enough to understand, but this is the single largest problem I deal with when working with inventors who have a computer process related invention. So many folks simply describe their process as A to B to C to D to E. Software never has a linear path though. There are always questions and calcuations. So software needs to take into account what occurs in the event that something doesn’t happen according to plan, and so does your description of the invention.
Not only do you need to take into account imperfection in the process, but frequently users will be allowed to enter different information that will then be reviewed and based on what information is collected you will take one path or the other. A good example of this would be at the airport where if you are a First Class Elite member you show your ticket and then go to the front of the line, where as the rest of us just stand in a hopelessly long line wishing were were special enough to be First Class Elite members.
As far as I am concerned the thing that inventors need to figure out first is the flow chart. With this in mind, take a look at US Patent No. 4,862,357. I want to draw your attention to the flow charts in particular. Notice the detail and the multiple paths that account for the various things that can happen. This is what you need to focus on creating. Once you have the flow charts to demonstrate the logic of the software then you have everything you need to start writing.