Lists Home |
Date Index |
Shigeru Yoshida wrote:
>Since I have not known prior art for this kinds of CSV compation, the pior
>art is just what I want to know.
Well, of course you would. To me, this particular patent underscores
some of the numerous faults in the US patent system, particularly with
regards to software patents.
For one thing, I hope you realize the absurdity of your position - that
of getting a patent, and then asking the question in a public forum, as
to whether anyone knows of prior art. Now the public bears the burden
of refuting your patent, rather than you bearing the burden of proving
your patent. For one thing, the fact that you are only asking _now_ in
a public forum as to whether this is new, rather than before the patent
was granted, suggests that you didn't perform enough "due diligence" to
find prior art, as you left out at least one apparently logical place to
ask the relevant questions. As to another issue, according to the USPTO
web site, they allow patenting of processes, yet you seem to have as
part of your patent a claim to a file format, but patents ought not, or
should not be for file formats in-and-of themselves. It seems to me
that you could argue that your process of converting XML to CSV values,
in that context, is not particularly innovative, as you clearly declare
the use of XSLT.
If someone were to have a patent on XSLT (which nobody has come forward
to collect on - yet!), then I would guess that that such a patent would
be rather broad in scope - something along the lines of a process
wherein XML + scripted XML declarations yields a transform to an
arbitrary text (and possibly binary) format. Your patent would clearly
fall under the aegis of such a pre-existing patent. Thus any claims
that you might have as to the actual process of transformation within
your XSLT would be the only patentable part, but the original patent
would likely have cast a wide enough net to "capture" such a use.
Apparently, by current USPTO standards, you don't have to prove that
your patent falls outside the scope of the intent of the authors of
XSLT, merely that it is an innovative use of XSLT. Alas, since such a
preexisting patent doesn't (seem to) exist, ironically, it is all that
much harder to find prior art that someone has done exactly what you
have done, and thus it would is patentable. In fact, I'm almost certain
that you are not the first to use XSLT to convert XML to CSV, likely so
that such data could be imported into spreadsheets, but many of those
projects were likely one-off, in-house projects done by some junior
engineer who never even thought to look at the USPTO web site, or would
have laughed if someone suggested what they were doing was patentable.
In a sense, you are "stealing" from the public domain, by taking a
solution that would _not_ be patentable if a patent on XSLT existed, and
patenting it merely because you can, because there are no _legal_ claims
built into the XSLT specification about the possible scope of its
In the concrete, physical world, should I come up with a new way to use
a capacitor - for example, a variable speed windshield wiper, or a
temporary power source for a hand-held computer when the battery is
removed, the new uses are patentable, and possible well deserved. The
analog in the computer world, however, wherein a process "X" takes input
"A", and produces output "B" is much less clear-cut. If I merely change
the input from "A" to "C", and get output "D", it may not be
particularly obvious, but it certainly _isn't_ novel (and its utility
remains to be determined), in that all you have done conceptually is
rename your variables, which you were free to do at any time. Due to
the flexibility of computers, it is also equally possible to hold the
inputs constant, and change the process (think function pointers in
C/C++, or a state machine design pattern), again coming up with
something which may not be obvious, but again isn't novel.
Unfortunately, since computers can freely alter the processes by which
the same inputs are processed (as part of a larger process, I might
add), the idea that you can patent new "processes" which take the same
inputs, or vice versa is absurd - you are merely following the same
design patterns that computer scientists (and peons like myself) have
been using for decades. If you were to go the extra step, and change
both the inputs and the processes at the same time, I might grant you a
well deserved patent, however, it would only be deserved if you could
show that the input, output, and process were in no way logically
analogous to existing inputs or processes. Unfortunately the USPTO
doesn't have my high standards.
Should I work on things that are patentable for my company, under the
current absurd system I think I have no choice but to recommend that the
company patent the technology. But I don't agree with the system, and I
think it fails the very premise it is meant to insure in the context of
software development, that of promoting the progress of the sciences and
arts, and instead stifles innovation, hinders creativity, and is an
economic NOOP at best, and a drag on software companies at worst.
Actually, I wonder whether anyone has research on how many "dot-bomb"
companies had patents in their profiles, as part of their supposed
"value" to their investors.
I could go on, but this isn't the right forum.