OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] New XML tool for improving data-processing performance

[ Lists Home | Date Index | Thread 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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS