Intellectual Property Forums (http://www.intelproplaw.com/Forum/Forum.cgi)

(Message started by: Jim Serra on Jun 6th, 2006, 3:54pm)

Title: sw-supported process patent
Post by Jim Serra on Jun 6th, 2006, 3:54pm
I have an invention that provides a huge time/quality improvements for development of certain software systems in a niche market/application. The invention contains several “minor inventions” for solving individual tasks, as well as several known techniques/methods, combined into an “overall concept” which provides an efficient and practical solution for solving a an important task in this niche market. The invention is implemented in software.

Now for the questions:
- Is it possible to patent a software-supported process? The input to the process is part of the overall invention.
- Would one patent application for the “overall concept” provide a stronger patent, or would several “minor” patents provide a stronger/more reliable patent protection? What are the pros/cons?
- Should existing techniques/methods be described in detail, or are references sufficient?
- Would a patent application be stronger if incorporating software code, or would a description of the software’s function be stronger?

Title: Re: sw-supported process patent
Post by JimIvey on Jun 6th, 2006, 4:52pm

on 06/06/06 at 15:54:31, Jim Serra wrote:
- Is it possible to patent a software-supported process? The input to the process is part of the overall invention.

Assuming the process is novel and non-obvious, yes.


on 06/06/06 at 15:54:31, Jim Serra wrote:
- Would one patent application for the “overall concept” provide a stronger patent, or would several “minor” patents provide a stronger/more reliable patent protection? What are the pros/cons?

I'm not sure what you mean by "stronger."  It's possible that the overall process and specific components of the process are covered by different claims such that you can cover both.  I tend to think of "stronger" as more impervious to challenge for invalidity, and that's impossible to say from your facts but not likely to be affected by the particular grouping of your innovations into respective patent applications.  Another possible interpretation of "stronger" is claim breadth -- how many things/actions covered as infringing.  That's also impossible to say from your facts and also not likely to be affected by the particular grouping of your innovations into respective patent applications -- except that redundant disclosure might be required to comply with the best mode requirement.

The bottom line is the claims, not the number of patents.  You can think of patents as claim buckets.  Whether your claims are carried in 1, 2, 3 or 57 buckets really doesn't matter.  What matters is what your claims cover.  There may be procedural benefits to filing more or fewer applications covering your various innovations; however, in the end, it really doesn't matter.  If you file too few, the Patent Office will force you to split them out.  If you file too many, the Patent Office will force you to link their fates (sort of -- combining them in a way).  Sometimes, they do both in an entirely inconsistent manner.

For what it's worth, a little careful strategizing on the grouping of your innovations into one or more patent applications can have significant benefits in getting through the Patent Office, keeping costs down, and managing costs if and when you file outside the US.


on 06/06/06 at 15:54:31, Jim Serra wrote:
- Should existing techniques/methods be described in detail, or are references sufficient?

References should be sufficient, generally speaking.  You may find yourself challenged re the sufficiency of your disclosure to enable one of ordinary skill in the relevant technology to make and use the invention, so be prepared to have widely available references handy to back up your assertion that these existing techniques are/were known and available to one of ordinary skill in the relevant technology.

In addition, if there's some advantage or benefit realized by using the existing technique/method in your particular new and non-obvious context, you should fully explore that synergy in your disclosure, even if it means rehashing stuff that's known.


on 06/06/06 at 15:54:31, Jim Serra wrote:
- Would a patent application be stronger if incorporating software code, or would a description of the software’s function be stronger?

I would certainly not exclude the latter.  However, inclusion of the former can make any significantly weaken any challenges of your failure to disclosure your "best mode" -- the inventor's/s' references with respect to implementation of the invention.

For what it's worth, inclusion of source code is fairly rare anymore, from what I understand.

Regards.

Title: Re: sw-supported process patent
Post by Jim Serra on Jun 6th, 2006, 5:58pm
Thank you for your reply.

Did you mean that including software code can provide an important "best mode" description? If source code is rare in patent applications these days, what is any "best practise" for showing "best mode"?  

If considering a patent for a software-assisted process, to what extent should process input (user input, file formats, etc) be made part of claims? Would file formats etc typically need to be detailed?

Title: Re: sw-supported process patent
Post by JimIvey on Jun 6th, 2006, 7:07pm

on 06/06/06 at 17:58:03, Jim Serra wrote:
Did you mean that including software code can provide an important "best mode" description? If source code is rare in patent applications these days, what is any "best practise" for showing "best mode"?  

It's pretty clear that "best mode" does not necessarily require disclosure of source code.  However, there's no penalty for disclosing too much, and disclosing source code can pretty much remove all doubt as to compliance with the best mode requirement.  

As for best practices, there really aren't any.  Each patent has its own set of circumstances.  Each applicant has their own IP strategy (or at least ought to).  A determination as to whether to include source code should be made on a case-by-case basis -- including risk assessment and cost/benefit analysis.  If you expect to assert your patent(s) against large, well-funded companies and demand hundreds of millions of dollars in damanges, be prepared for your own multi-million-dollar court battle and including source code may be cheap insurance.  However, if you'd like a patent with no apparent deficiencies and hope to ask for just enough settlement money to not provide a strong incentive to challenge in court (particularly attractive strategy if you have many potential licensees/infringers), source code may be unnecessary.


on 06/06/06 at 17:58:03, Jim Serra wrote:
If considering a patent for a software-assisted process, to what extent should process input (user input, file formats, etc) be made part of claims? Would file formats etc typically need to be detailed?

First of all, you have to realize that what ought to be included in a claim is very fact specific.  One of the reasons I don't mind giving full and complete answers here for free is that I know that the real answer as to what gets put in paper requires professional assistance.  There's nothing that I can post here that will give you an answer that you can take directly to the Patent Office.  It's just the nature of the beast -- no easy answers.

Having said that, let me give a decent attempt at a general answer.  When crafting your claims, think of things that you want to prevent others from doing.  Is it okay for them to use your exact system albeit with a different file format?  My guess is "no" -- so don't put that in your claim(s).  However, suppose your file format is the only thing that's different from conventional systems and provides a unique and valuable advantage.  Remember, your claims must recite something that's new and non-obvious.  In short, you can't craft your claims to stop people from doing conventional or even obvious things.  If your file format is the only novelty, you really have no reasonable choice but to include your file format -- at least the novel aspects of it -- in the claim(s).  

I think I need another FAQ or article for this next part....  There are two distinct (but related) parts to an application -- that which you give and that which you receive.  The Specification is your offer to the US -- publication of your technological advance.  The Claims are what you hope to receive in return -- defining exactly what you can exclude others from making, using, selling, or importing.  Enablement and best mode are requirements for the Specification.  Your Specification will have all sorts of details that do not affect the scope of your claims.  You patent covers what your claims say they cover -- that's the 98% answer.  

In essence, a patent says this:  Now that I've told you all this (the Specification's technical disclosure), I get that (the right to prevent others from making, using, selling, or importing anything described by your claims).

Don't confuse what must go in your Specification with what ought to be included in your Claims.  

Regards.

Title: Re: sw-supported process patent
Post by Isaac on Jun 6th, 2006, 7:52pm

on 06/06/06 at 19:07:05, JimIvey wrote:
It's pretty clear that "best mode" does not necessarily require disclosure of source code.  However, there's no penalty for disclosing too much, and disclosing source code can pretty much remove all doubt as to compliance with the best mode requirement.


While disclosing source code might answer some best mode questions regarding implementation issues, there is still the question of whether the inventor has even coded up what he considers to be the best mode for practicing the invention.   For most software based inventions the level of abstraction at which the invention activity occurs is so divorced from actual code that the term "software patent" seems almost inappropriate.

I don't have personal experience litigating, but I'm skeptical that providing source code is likely to help the patentee.  


Title: Re: sw-supported process patent
Post by JimIvey on Jun 6th, 2006, 11:26pm
I agree that disclosing source isn't a panacea, but I'd say that for many cases disclosing source code removes nearly all best mode issues.  In cases in which the inventor has made a mock-up demonstration (to illustrate a concept rather than to actually implement the invention) -- it's possible the source code is not accurately representative of currently contemplated best mode.  However, if developement is on-going and for its intended audience, the source code would most likely represent all implementation details that the inventor(s) prefer(s) at that time.  I think that things the inventor(s) might hope to implement later aren't subjectively preferred at the time of filing but are instead areas of intended further research.  If they were truly preferred, they'd be implemented.  Who intentionally writes crappy software in hopes of implementing it properly later?  Who has that kind of time for wasted effort?

I'll give an example to illustrate my point.  Suppose the invention requires (or is best with) some sort of data compression.  Suppose the current version uses some conventional compression technique, such as PKZIP, but the inventors believe that something else would be better.  That's not a problem unless the inventors actually know what is preferred, i.e., which other technique is best.  Typically, the reason they don't use the best compression technique for their particular application is because they haven't yet decided what the best technique is.  You're only required to disclose best mode if there is one.  

Now, sometimes Isaac's point is right on.  Suppose they know what compression technique they'd really like to use but it's not available for free and/or  they haven't taken the time to write it up.  Then, source code -- lacking that particular compression technique -- would possibly be insufficient to meet the best mode requirement.

However, for most of the cases in which the source code is in use by its intended audience or diligently on its way there, disclosing source code would most likely take care of all best mode issues.  This is particularly true if the developers are good about putting currently contemplated future plans in comments in the code.  I just think it's really tough to argue that the inventors had a different, preferred mode firmly in mind (no experimentation or further investigation needed) but chose to implement something inferior.  I don't think that believing that you'll eventually make the software better, despite not being sure exactly how, is at all fatal to having met the best mode requirement.

Regards.

Title: Re: sw-supported process patent
Post by Bill Richards on Jun 7th, 2006, 4:55am
I want to thank Jim and Isaac for their cogent remarks on this subject; I'm enjoying reading them and find them very educational.  So, in the interest of continuing to expand, let me offer this:
At least in my non-legal experience with system development, here's what happened.  A problem was defined that management wanted solved.  For example, "We need a payroll system."  The system designers would then develop the flow of the payroll system.  That is, how data would get into the system, how they would be stored, the general modules (e.g., tax calculations, SS deductions, etc.), the general relationships of those modules, reports, etc.  Then, the software developers (used to be called programmers) would take over and effect the system designed by the system designers.  The system designers were typically people with accounting backgrounds and very little programming background.  The software developers were generally not accountants.
Does this change the landscape (clarify, muddy), or am I just rambling?

Title: Re: sw-supported process patent
Post by Isaac on Jun 7th, 2006, 6:10am

on 06/07/06 at 04:55:29, Bill Richards wrote:
I want to thank Jim and Isaac for their cogent remarks on this subject; I'm enjoying reading them and find them very educational.  So, in the interest of continuing to expand, let me offer this:
At least in my non-legal experience with system development, here's what happened.  A problem was defined that management wanted solved.  For example, "We need a payroll system."  The system designers would then develop the flow of the payroll system.  That is, how data would get into the system, how they would be stored, the general modules (e.g., tax calculations, SS deductions, etc.), the general relationships of those modules, reports, etc.  Then, the software developers (used to be called programmers) would take over and effect the system designed by the system designers.  The system designers were typically people with accounting backgrounds and very little programming background.  The software developers were generally not accountants.
Does this change the landscape (clarify, muddy), or am I just rambling?


The question here might be who the inventor is.  If the inventor is someone who has not written any code, then the best mode might well have nothing to do with the code.  In fact, a patent application might well be viable before any code has been written.   On top of that the CAFC has said that the written description requirement for software inventions is generally satisfied with a description of functionaliy.  

I don't believe the general practice is to provide source code.  I don't recall a single instance of examining a patent application in which source code  was included (I examined computer networking technology which primarily involved software based inventions).  

I agree with Jim that in many cases the source code does encompass the best mode.   However it's also fairly settled  that failing to disclose the source code is not considered hiding the best mode.  Keeping the source code confidential might provide some business advantages without providing any significant weakness in the patent.

Title: Re: sw-supported process patent
Post by JimIvey on Jun 7th, 2006, 8:46am
The first concern that pops into my mind as I read the elaboration on the hypothetical software system is that it seems all conventional -- not novel or non-obvious.  From what I understand (and I'm no expert here), business processes like payroll are primarily defined by the surrounding legal environment (employee relations law, tax law, etc. -- not IP) and by conventional accounting practices.  What may make such a system unique (and therefore maybe novel) is that the company/client typically has legacy systems with specific file formats and APIs.  

For example, let's say that the point of novelty is that, rather than importing spreadsheet material in Excel, OpenOffice.org, CVS, or gnumeric file formats, your system imports spreadsheet material in SuperCalc and/or Quatro Pro file formats.  No other payroll system does that (hypothetically).  But, what would an ordinary software engineer working in the business operations software space do when faced with (i) a program that can import an OpenOffice.org spreadsheet (or an Excel spreadsheet if that's all you got) and (ii) SuperCalc spreadsheet that needs to be imported?  If we can't convince an examiner (not just any examiner, but the one examining your application) that the answer to that question is not obvious, you're not going to get a patent on that.

The good news is this:  your original post mentions "huge time/quality improvements for development of certain software systems."  That sounds non-obvious to me (assuming it's claimed right).  It doesn't sound like routine engineering to adapt a known process to a very similar process.

Just to be clear on where I stand on disclosing source code, I typically explain the pros and cons like I did here and let the client decide.  In the past 12 years or so, not one client has opted to include source code.  It's clearly not necessary and, for my clients thus far, any benefits haven't been perceived to outweigh the costs.

Regards.



Powered by YaBB 1 Gold - SP 1.3.2!
Forum software copyright © 2000-2004 Yet another Bulletin Board