|
Authored by: Wol on Thursday, July 19 2012 @ 05:35 PM EDT |
"disclose the functions".
Well, presuming they mean functions in the programming (or mathematical) sense,
that instantly places them in prior art (cf Diehr? - the software is
automatically prior art?).
And if they mean it in the other sense - the function as in "what does it
do", then that is vague and not a clear disclosure - patenting the problem
not the solution.
Cheers,
Wol[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, July 19 2012 @ 05:41 PM EDT |
Source code and flow charts are not required.
I
didn't mention source code, flow charts or any of the other dozens of tools
available to document what a program does.
I simply said:
If you wish
to get a patent on your secret sauce, you must disclose so someone else can make
the secret sauce!
Perhaps I misunderstood the context of the thread parent
when s/he said:
Many companies would avoid patenting their true
secret sauce because they would have to provide too many
details.
Perhaps the individual meant to say "if they had to put
too much effort in filing for a patent, they wouldn't file at all".
To
prove I don't disagree with your statement relative to Fonar, I'll highlight a
very specific part that was in my post:
full, clear, concise,
and exact terms as to enable any person skilled in the
art
It seems to me your point on Fonar:
A: Confirms the
level of detail that must be supplied is sufficient for one skilled in the art
to duplicate the invention
B: Confirms my point that you must disclose
in order to get a patent - no disclosure, no patent
RAS[ Reply to This | Parent | # ]
|
|
Authored by: mbouckaert on Thursday, July 19 2012 @ 06:41 PM EDT |
Let's move the clock back a little.
If I read this well, it is not necessary to disclose the
contents of the punched cards that are the actual software,
because translating from flowcharts to Assembly
language/FORTRAN/COBOL statements does not require undue
testing and further experimentation, etc.
Does this mean that the flowcharts didn't need to be
disclosed, then ? And, if so, how many abstractions up the
ladder can be held secret "because they do not require..." ?
Technology has changed since, and there are no flowcharts to
derive from. There are other expression modes (IDEs) so the
parts that do not require iterations, imagination, etc
(i.e., inventiveness) are now handled by the machines
themselves.
IMHO this still reads that the *object* code does not need
to be disclosed; but the blueprints still should.
IANAL, tho
---
bck[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Thursday, July 19 2012 @ 11:43 PM EDT |
Interesting, thanks.
This strikes me as nowhere near specific enough. Does "functions"
mean the software interface description (functions, the arguments to the
functions, and the return values)? Or just a description of what the software
accomplishes for the user or for the rest of the machine? (e.g., the software
functions to enable one-click buying in the browser.)
Anyone can come up with great software "functions" but the rubber hits
the road when you actually create a specific implementation of those functions.
The functions (as the interface description) don't strike me as ever patentable
since they reveal no secret sauce whatsoever.
For a patent I would expect either pseudocode or a description of data
structures and the sequence of operations on those data structures.
[ Reply to This | Parent | # ]
|
|
Authored by: Ian Al on Friday, July 20 2012 @ 06:49 AM EDT |
As a general rule, where software constitutes part of a best mode of
carrying out an invention, description of such a best mode is satisfied by a
disclosure of the functions of the software. This is because, normally, writing
code for such software is within the skill of the art, not requiring undue
experimentation, once its functions have been disclosed.
It
applies when software is only a part of carrying out an invention and the
functions delivered by the software is not the inventive concept. The disclosed
functions are supposed to make the software easy for a competent coder to
produce.
In other words, the inventive concept cannot be in the
software for this general rule to apply.
In my auto gearbox analogy, I
explain that it is the functions applied to the gearbox that might constitute
the statutory machine. The functions would be the mechanical waggling of the
gearbox mechanics. Using an embedded computer with algorithms to apply the
functions to the gearbox via electrical actuators is
nonstatutory.
--- Regards
Ian Al
Software Patents: It's the disclosed functions in the patent, stupid! [ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Friday, July 20 2012 @ 06:05 PM EDT |
Any judge worth his salt would simply state that. It has no value as precedent. [ Reply to This | Parent | # ]
|
|
|
|
|