Sure, but the business is using the software for the purpose of selling a modified version. If the license hugely impacts what can be sold, then it also impacts how and why the business might use it.
Incorrect. Party B has made no promises whatsoever towards Party A.
Look - I'll give you four reasons why every software license, including the GPL, is a contract:
1) The obligations are entirely mutual; each party has
Party A promises not to sue Party B for activities that are permitted by the license (use of the software, copying, etc.)
Party B promises to use Party A's open-sourced software only as permitted by the license (attribution, indemnification of Party A for liability from redistributed software, etc.)
2) The benefits are also plainly mutual:
Party B gets to use the software.
Party A gets the assurance of being attributed in redistributions, of having the original license and source code distributed with redistributions, etc.
3) You attempt to make much of the "unilateral" nature of the contract. There's a whole body of contracts called "unilateral contracts," where an offer is made to the entire public, and anyone may take advantage of it. Commercial advertisements, for instance - the newspaper ad offering "three cans of peaches for $1" is an offer to accept the contract; you do so by showing up at the store and carrying three cans of peaches to the cash register.
4) If there's a violation of a license, what body of law do you use? There is no body of law called "license law." There is a very large body of law called "contract law," and the cause of action for breach of contract covers all of the elements of this transaction. You might also file it as a violation of your copyright, but that would be a much more circuitous and difficult cause of action, and would foreclose some remedies that you might want (breaches of contract can lead to restitution, an accounting, an order for specific performance, etc.; copyright violations are usually relieved only with damages or injunctions.)
that lower courts found unacceptable the line between software and actual patentable inventions, and that lower courts REVERSED the Supreme Court ruling and reasoning on the subject.
Incorrect.
The holding in Diamond v. Diehr was a (quite straightforward) reaffirmation of the timeworn concept that "laws of nature, natural phenomena, and abstract ideas" were not patentable, while "the use of [an] equation in conjunction with all of the other steps in [a] claimed process" was a patentable method. State Street Bank & Trust cited this exact same standard of patentability, and reached the exact same conclusion: that the use of a set of mathematical equations in a specific, applied context is a patentable method, regardless of how that method might be implemented.
In so holding, the Court of Appeals for the Federal Circuit did not "REVERSE" the Supreme Court. They applied the exact rule that the Supreme Court had affirmed, in the same conceptual context. And the Supreme Court must not have vociferously disagreed with them, as it denied certiorari for appeal (525 US 1093 [1999]).
The Suprme Court explicitly stated that the key to the patenability of a process was the physical transformation of an article or material into a different state or thing.
Incorrect.
The physicality was a clear feature of Diehr's method that rendered it patentable - it was one way of showing that an invention is not solely "abstract." It is not the only way; it was not "the key to patentability."
When the Court distinguished Diehr's patentable method from Benson's and Flook's unpatentable algorithms, it did not contrast Diehr's as "physical." It noted that Diehr's had an applied context - a utility - while Benson's and Flook's were merely "formulae." Note:
In Benson, we held unpatentable claims for an algorithm used to convert binary code decimal numbers to equivalent pure binary numbers. The sole practical application of the algorithm was in connection with the programming of a general purpose digital computer. We defined "algorithm" as a "procedure for solving a given type of mathematical problem," and we concluded that such an algorithm, or mathematical formula, is like a law of nature, which cannot be the subject of a patent. (9)"
Notice the phrase "such an algorithm," i.e., algorithms used solely for "solving a mathematical problem." This implies that other algorithms are patentable.
This interpretation becomes even less disputable based on the majority opinion's Footnote 9, attached to this passage. The majority that Diamond, in arguing against patentability for Diehr's invention, had argued that the Court had previously ruled as unpatentable any "algorithm" that was a "fixed step-by-step procedure for accomplishing a given result..." - which would includes any purely software invention. But the majority expressly rejected this position:
This definition is significantly broader than the definition this Court employed in Benson and Flook. Our previous decisions regarding hte patentability of "algorithms" are necessarily limited to the more narrow definition employed by hte Court, and we do not pass judgment on whether proceses falling outside the definition previously used by this Court, but within the definition offered by the petitioner, would be patentable subject matter.
The Supreme Court Stated that insignifigant [physical] post solution activity could not magically convert nonpatentable software into a patentable process.
Sure - you can't make unpatentable software patentable by dressing it up with unrelated facts. What about patentable software? I'm not being slippery - I mean that exactly as written... and so did the Supreme Court. You can't just take a bare mathematical formula and indicate that the output is used in an insignificant way. But if you take a mathematical formula and apply it in a useful context, then it is patentable.
By definition, a license is a contract. A contract is just an exchange of rights. In the case of a software license, you are
...and violations of it fall under (federal) copyright law, not contract law...
They fall under both. First, your violation of the license (which, again, is a contract) creates liability under copyright law. Second, since you no longer have permission to use the copy of the software in your possession, you are in violation of federal copyright law, which creates private liability to the licensor... precisely as I wrote in my parent post.
...he's talking about needing to report your IP ownership under Sarbanes-Oxely, and both failing to report that and lying in it are violations of (federal) securities law.
In the portion that I quoted, he vaguely referenced "federal law" for violating a license. I was listing the kinds of laws that typically come into play in licensing disputes - which usually do not include any kind of federal securities law.
Next, I discussed how the Sarbanes-Oxley provision might apply, and why I didn't think that it did.
Helpful tip: You can find all of that stuff in my original post. Hust click your left mouse button on that little scrollbar on the right side of this window, and drag it upward a bit.
You said that you can't be a commercial vendor of GPL software because anybody can take it and redistribute it. But if that is true, that "competitor" can't be a commercial vendor either!
No - they're still "commercial" vendors, but they're just bound by the same anti-"commercial" obligations under the GPL. The "commercial" value of the software is inversely proportional to the number of people who have copies.
This is because whatever reason you cannot be a commercial vendor also applies to them, they may also have competitors who will rerelease the software.
Correct. Hence, no one can realistically sell the software in a commercial context. Hence, "the GPL is largely antithetical to commercial software."
Only you have the right to sell a copy that can be used in closed source.
If we're talking about software that you developed based on other GPLed software - then, no, you can't do that. In that case, you cannot sell the software to someone to use in a closed-source context - because the obligations to keep open the original GPLed code flow down through you to your licensee.
IF we're talking about software that you developed not based on other GPLed software - then, sure, you can license it to a closed-source developer under a non-GPL license. But now we're no longer talking about the GPL at all. Hence, I maintain my statement: "The GPL is largely antithetical to commercial software."
You can of course just distribute your code with no license, so it is covered by copyright.
My license goes much further: it includes a large bundle of rights for the downstream user (granted freely and without restriction) that would not be permitted under a tacit copyright distribution. About the only right offered by GPL and other open-source licenses, but withheld by my license, is the right to use it in a commercial context.
Do what you want to do with your own IP; that's cool. It's your right. But you are misrepresenting yourself if you claim what you're distributing is open source. Can you identify the license you used on the list of Open Source licenses? No? Then why are you calling it Open Source?
That's funny. Several licenses on the "list of Open Source licenses" limit the commercial use of the "open-source software," particularly as it pertains to the licensee's ability to charge fees. This prompted the following interesting exercise:
The Adaptive Public License:
"A Distributor may charge a fee for the physical act of transferring a copy [of the Licensed Work or any portion thereof], which charge shall be no more than the cost of physically performing source distribution."
The Artistic License:
"5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself." ("Package" is defined as the software being provided under the license.)
Computer Associates Trusted Open Source License:
"This License is intended to facilitate the commercial distribution of the Program by any Contributor. However, Contributors may only charge Recipients a one-time, upfront fee for the distribution of the Program. Contributors may not charge Recipients any recurring charge, license fee, or any ongoing royalty for the Recipients exercise of its rights under this License to the Program. Contributors shall make the source code for the Contributor Version they distribute available at a cost, if any, equal to the cost to the Contributor to physically copy and distribute the work. It is not the intent of this License to prohibit a Contributor from charging fees for any service or maintenance that a Contributor may charge to a Recipient, so long as such fees are not an attempt to circumvent the foregoing restrictions on charging royalties or other recurring fees for the Program itself."
Motosoto Open Source License:
"If you sublicense the Licensed Product or Derivative Works, you may charge fees for warranty or support, or for accepting indemnity or liability obligations to your customers. You cannot charge for the Source Code."
OCLC Research Public License:
"The Program must be distributed without charge beyond the costs of physically transferring the files to the recipient."
Open Group Test Suite License:
"You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself."
Reciprocal Public License:
"Under the terms of this License You may not: Charge for the Source Code to the Licensed Software, or Your Extensions, other than a nominal fee not to exceed Your cost for reproduction and distribution where such reproduction and distribution involve physical media."
It looks like a fair number of licenses blessed as "open-source licenses" attempt to control the commercial use of the downstream software. It shouldn't be contestible that businesses develop products for the purpose of charging an arbitrary price for them. By limiting the amounts that those businesses can charge for products based on GPLed code, these licenses certainly "discrimination" against the use of this software in the "field of endeavor" known as business.
Ah, but this too falls down. The GPL does not govern use, it governs distribution.
It's not directly covered, but it's indirectly covered to an almost complete extent.
You're correct that the GPL disavows having any impact on whether or not a user is allowed to "run" the program:
"Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program)."
...but if you give a copy of the program to anyone, you cannot block their right to distribute copies to world+dog with permission to run it. (They could charge any price, including $0, for extending the right to run the software to third parties.) That's why the GPL is largely antithetical to commercial software: every customer can become a competing vendor of your software simply by acquiring one copy from you.
(I have released a good amount of software under an open-source license, but not the GPL. I require that no one can make commercial use of my software. I'm giving it away freely for other people to use, not for making a profit from it - e.g., by selling it outright!)
This is only for violations of the GPL, not for just using the software.
But I don't know how "violation of the GPL" really connects with "ownership of IP."
From TFA:
"According to the study, the problem lies with the requirements of the Sarbanes-Oxley Act that companies disclose ownership of intellectual property to their shareholders. The study indicates that dozens of companies are discovered each year to have violated the terms of GPL, and if they are public companies, they are violating Sarbanes-Oxley."
Huh? Taking this statement at its face value: A company that receives software under the GPL does not "own" any "IP." They merely have a license to use the IP embedded in the software. Whether or not they violate that license has no bearing on "ownership" of IP... and if they don't "own" any IP in the GPLed software, then they haven't violated Sarbanes-Oxley by failing to "reporting" any kind of ownership.
"Linux is a powerful operating system," says Jay Michaelson, an author of the study and Wasabi Systems' General Counsel. "But if companies violate the license, the consequences can be more severe than they think. If companies are violating the GPL, they don't have the right to use that software. And if they don't have the right to use the software, they're violating federal law if they claim that they do."
Huh? Last I checked, the GPL was a private license. If they violate a private license in any way, then they are liable for breach of contract, which is in no way "federal law." The only "federal laws" they are violating are federal IP laws - but again, those laws only create private causes of action by the IP owners. License violations do not create liability to the federal government (unless the federal government actually owns the IP.)
As best I can tell from TFA, this gentleman means that companies are modifying GPLed code and then reporting it to shareholders as their "owned" IP - but that this claim of IP "ownership" is incorrect and fraudulent, since their violation of the GPL precludes them from "owning" their modifications. But TFA is way too light on details to be confident of this interpretation... and I'm not completely sure that the GPL works that way, anyway.
Just because our economy is dependent on something, does not make it right.
We can argue all day about whether or not it's right. But our government cares more about protecting America's interests (including its economy) than it does about "doing the right thing." If you agree (1) that IP is an important part of our economy, and (2) that eliminating that component would eliminate part of our economy - then unless you can suggest a kind of business that would supplant the role of IP in our economy, the discussion is over... or at least, better left to those unconcerned with geographical, political, and economic reality.
Here's a link to the USPTO's current fee schedule. A regular applicant must pay $300 to have the application filed, $500 for the USPTO to conduct a search, and $200 to conduct an examination. If the patent is allowable, the applicant must pay $1,400 to have the application issue as a patent and $300 to have it published. Then he must pay $900, $2,300, and $3,800 at the 3.5-, 7.5-, and 11.5-year marks (as measured from the date of issuance) to keep the patent alive.
In other words, for a regular applicant to file and receive a basic patent application and own a patent for the full term, he/she/it must pay the USPTO at minimum $9,700. (A "small entity," including a sole inventor, receives a 50% break on these fees - for a paltry minimum fee of $4,850.) This minimum fee does not include:
The cost of having the patent prepared and prosecuted by a patent agent or attorney - which typically costs over $10,000. (The alternative is to skimp on the prosecution costs: spend inordinate amounts of time learning about claim drafting, filing deadlines, and prior art, and spend a long time drafting and prosecuting the patent application - only to run a very large risk of having an invalid or unenforceable patent.)
Additional application fees depending on its length and claim style.
Fees for other USPTO filings: continued prosecution refilings, certificates of correction, reissue, fees for extensions of time to respond to complicated office actions, etc.
Fees for having incorrect examiner decisions resolved by the Board of Patent Appeals and Interferences, or to the court system.
Fees for shoring up the patent from outside attack, e.g., reexamination and interference proceedings.
Fees for detecting and enforcing the patent, including (worst of all) litigation.
Fees for obtaining patents for the same invention in other countries.
Patenting is already a grossly expensive exercise. And you want to raise the rates? You must be taking a page from the conservative playbook: if we can't kill the system, let's make it completely unusable!
Your comments about Arizona's licensing agencies are right on point: administrative fees for government-issued rights (licenses, patents, IDs, whatever) should be almost exclusively used for the costs of issuing those rights. Drainage is simply an insidious mechanism for overcharging applicants and draining away the quality of service of the agency in order to fund unpopular projects. It's antithetical to democracy.
The current application fee doesn't cover the cost of the PTO researching a patent now, which is the biggest reason so many obvious things slip through.
I don't see how you can draw that conclusion, or even estimate it, since a large portion of the application fee doesn't help the USPTO in any way - it gets channeled into other federal projects (*cough* Iraq.)
If you had written, "The portion of the current application fee that Congress allows the USPTO to retain doesn't cover the cost fo the PTO researching a patent now," I would wholeheartedly agree. I would also propose that the first step should be to remove the nonsensical encumbrance on the USPTO's financial resources.
f someone, or a company had to fork up the $10K (USD) up front, as the application fee, instead of after approval, there would be less stupid applications.
I can't imagine a more effective way of further reducing patent quality.
Your rule would limit patents to large corporations - those that can afford to throw away money to cement their positions. Is the financial well-being of a patent applicant a good predictor of the quality of its patent application?
Do a search sometime for patents by Microsoft, or General Motors, or any large company. You'll find a wide range of patents with unhelpful titles and incomprehensible specifications. These companies typically throw barrels of money at the USPTO to garner a range of vague, obfuscated patents of indeterminate breadth - because those patents make a better patent arsenal.
On the other hand, small entities and sole inventors have central interests in achieving patents that are clear, specific, and obviously valuable. Their goal is different: they're not trying to ward off competitors with hazy threats; they're trying to secure their most critical IP assets, attract investment, and promote licensing or a buyout. Basically, small entities don't have resources to waste on patenting; they have to be highly selective, and their patents have to be meaningful.
The USPTO could cover their costs (personell) better...
Instead, why not let the USPTO keep the fees that it already receives? One very serious problem with our current system is that Congress steals a lot of the money that the USPTO reaps from applicants. (It has to fund the Iraq war and its ultra-wealthy tax cuts somehow, right?) If the USPTO were allowed to apply 100% of its fees to strengthening its infrastructure, we'd see a marked improvement in its performance.
patents on UI and other software concepts should be limited to 5 years, not 20...
First, it sometimes takes five years just to get the patent. Many software patents filed in 2001 are still awaiting their first office action from the USPTO.
Second, we settled on 20 years because it's an international standard. We'd have to get every country with a patent office to agree to change the patent term. If you want to see just how difficult this is, try studying the history of the Patent Cooperation Treaty - getting many nations to agree to certain patent concepts is really like herding cats.
Third, as noted elsewhere in this thread, it is conceptually impossible to differentiate "software patents" from other kinds of patents, in order to apply different patent terms.
would this imply that even if your congress would fully understand the problem and would be willing to kill software patents (hypotethical situation), such a decision would be prevented by all the cash flows that are based upon it?
That's an awfully large hypothetical, since I don't see that the best solution to the problem is to "kill software patents." But I'll afford you this immense concession for the purpose of this hypothetical.
Our federal government is interested in technology, in "promoting the progress of the useful arts," in the pursuit of knowledge, etc. But at the end of the day, those things don't put food on American tables. Its much greater concern - perhaps its greatest concern of all - is maintaining the American economy. It's not going to take any action that eviscerates the economy unless there's a damn good reason. "Freeing software" is a vastly insufficient rationale. Our government has to live in the real world - it can't play The Sims with the American people, risking actual daily concerns for academic principles. That would be a dereliction of its duty.
(Of course, our current government seems to have derailed, but the Americans who voted them all into office will only realize and rue their mistakes in retrospect.)
Just goes to prove that switching from a tangibles based true wealth creation economy like we used to have was a *very* bad idea.
One has nothing to do with the other. We didn't abandon tangible goods in favor of intangible goods. Rather, we lost tangible goods because manufacturing costs were too high. Evironmental compliance, minimum wage, unemployment, workers' compensation - these are costs that business must pay to manufacture within the U.S., but not abroad.
(This is in no way a criticism of the U.S. for that result. I harbor much enmity for foreign countries that are willing to sell out their populations in order to attract corporations. The growth of democracy across the world might help to level the playing field, but it'll take a century.)
In short - the tangible goods market collapsed all on its own. If anything, intangible markets have been used to fill the void. So I maintain: if you want the U.S. to cannibalize its global IP stance and dominance, then you're going to have to propose some other kind of economy to fill in the void.
The proponents have had-by admission- "decades" now to prove their point that the "new economy" would make us all richer somehow, and the results are as you see it, record deficits, record bankruptcies,a severe lessening of national security, an overly inflated currency (so bad they are going to stop reporting most of the M3 stats), and decent jobs that paid well with benefits being replaced with lesser paying jobs with little or no benefits.
We certainly have a host of economic problems. I think that many of them are very directly connected with (1) our wastrel federal government spending and (2) employers' widespread breach of the social contract with employees. I don't think that any of this has to do with what kinds of goods our economy is producing.
Do you have any evidence that modern corporations producing tangible goods treat their employees any better than corporations producing intangible goods? If not, then your argument linking intangible goods with our downtrodden employment market is spurious.
If software companies everywhere in the world except the US can disregard software patents then this will mean:
Software development in the US will be more expensive, and/or
Software sold in the US will be more expensive
Alternatively, you might expect to find more startup companies in the U.S. organized around a novel software product. That is exactly what has transpired. The U.S. continues to be the leader in software development - especially in novel software concepts.
History review: The U.S. experienced a large software-based tech boom in the late 1990's. We also experienced a large bust in 2000, mostly because investors went bonkers, forgot that software is a business like any other business, and neglected to tie their investments to a valuation of business merit. We're now seeing a slow but steady buildup of our software market - fueled in part by (surprise!) small startups with novel software concepts.
Consider this: When it comes to the software patent game, Microsoft is 0/2 - having taken big losses to Stac Electronics ($39 million) and once to Eolas ($521 million). Yet Microsoft is a huge proponent of software patents. Microsoft is also shifting its business increasingly toward acquiring small startups with novel software concepts (e.g., its acquisition of Connectix.) Reason: Microsoft's mainstay products have stagnated, and it needs fresh software ideas... which are most easily acquired (exclusively) from small startups. Notice a trend here?
IMO, it's unfortunate, but the current US patent law favors issuing a patent if there's any real room for doubt. It basically says to apply for a patent, you have to sign an affidavit saying that as far as you know, this is really your own invention.
In fact, this duty goes much further: applicants are required (1) to have conducted at least a minimal search, (2) to disclose all known prior art that might be relevant, and (3) to assert their reasonable belief that the invention is still patentable in light of this prior art.
Unfortunately, very often, applicants wildly shirk this responsibility. One of the damning factors of current software patent practice is that for many issuing patents - including junk like scrollbars - the applicants disclosed no prior art. You have applicants filing claims for inventions like "selling products over the Internet" and disclosing fewer than three prior art references - as if they simply don't know of many businesses selling products over the Internet. It's deplorable.
This is one of the best suggestions for fixing the USPTO's examination system: start enforcing Rule 56 sanctions, i.e., start punishing applicants (and patent practitioners) who fail to satisfy their due-diligence research and disclosure duties. A few sanctions, including patent license suspension, would prompt a rapid and marked reduction in the number of patent applications being filed, and in the quality of those patent applications.
If software companies everywhere in the world except the US can disregard software patents then this will mean:
Software development in the US will be more expensive, and/or
Software sold in the US will be more expensive
Alternatively, you might expect to find more startup companies in the U.S. organized around a novel software product. That is exactly what has transpired. The U.S. continues to be the leader in software development - especially in novel software concepts.
History review: The U.S. experienced a large software-based tech boom in the late 1990's. We also experienced a large bust in 2000, mostly because investors went bonkers, forgot that software is a business like any other business, and neglected to tie their investments to a valuation of business merit. We're now seeing a slow but steady buildup of our software market - fueled in part by (surprise!) small startups with novel software concepts.
Consider this: When it comes to the software patent game, Microsoft is 0/2 - having taken big losses to Stac Electronics ($39 million) and once to Eolas ($521 million). Yet Microsoft is a huge proponent of software patents. Microsoft is also shifting its business increasingly toward acquiring small startups with novel software concepts (e.g., its acquisition of Connectix.) Reason: Microsoft's mainstay products have stagnated, and it needs fresh software ideas... which are most easily acquired (exclusively) from small startups. Notice a trend here?
In either case, the USPTO is incompetant and incapable of doing its job. It should stop issuing patents immediately.
:shrug: Good luck with that argument.
Over the last five decades, the U.S. economy has moved steadily away from physical goods and toward intangible goods - services, culture, music, movies, etc. This includes the development of intellectual property. It is a cornerstone of our economy. That's why the U.S. Congress has steadily increased its support of intellectual property protection. Accordingly, the courts have read federal IP legislation with broadening scope, since this is the plain intention of Congress.
So if you're arguing for the dismissal of U.S. patent legislation, you'll have to suggest a way of recapturing the huge share of our GDP attributable to the export of patent-based intellectual property. Since our trade deficit is already deep in the red, you might not find your state Congresscritters to be very receptive.
oftware patents are already (technically) not permitted here, and yet crazy inconsistencies and loopholes are allowing people to patent whatever they want.
Presuming that "here" = Europe, I think that you're not understanding the full meaning of the European Articles in question. It's a common misconception.
You have to read both Article 52(2) (which prohibits patents on "software" and "methods of doing business") and Article 52(3) (which, specifically and literally, limits the exclusion in 52(2) to patents for software and business methods "as such.") In other words, you cannot patent software, but you can patent some other kind of invention - e.g., a useful method - that is capable of expression in the form of software, or that is applicable in business.
This is neither a loophole nor an inconsistency. It is a clear set of patentability standards, expressing a very plain and straightforward intentions of its legislators - to which the EPO has admirably conformed. You can criticize its application or consequences, but you cannot logically construe its exercise as some kind of abuse of the European patent laws.
One would draw the line where you yourself have very nicely drawn it and disallow claim #3.
You're missing the point. Claim #3 doesn't mention "software." It could be embodied as software, or as a circuit, or as the moving parts of the toaster. It is claimed solely as a "method," and is protected no matter how it is implemented. At the end of the day, it's just a method.
For many years, U.S. courts tried exactly what you propose: disallowing patents for "software" methods, but allowing patents for "other" methods. They concocted increasingly bizarre rules for determining whether a method was "software" or was not "software." It became an exercise in futility. State Street Bank & Trust, the pivotal case allowing patents for software, was the culminating finding that there isn't any logical test for a "software" method vs. a "non-software" method.
I fail to see how you can make a distinction between pure research in physics and pure research in mathematics.
You can't, of course. But that's completely irrelevant, as the delineation is between pure research and applied research. The relevant question is: Is this invention "useful" in a pragmatic sense? Does it have an applied context? Is it part of a technical advance, like the development of a commercial device or a chemical process, or is it a pure scientific discovery with unknown application?
This is the critical question to patentability. You can't patent the law of gravity, or equations to measure it in the abstract. But you can patent a method of using gravity in some novel way during a particular industrial process. That's the heart of the patent system. It's also the basis for the term "utility patents."
Sir, here at the USPTO we take pride in granting patents without consideration of trifling concepts such as; gross obviousness, unoriginality and indeed patentability itself.
To be fair, when it comes to software, the USPTO has struggled under two logistical problems:
It's really tough to find prior art on a lot of software inventions. Sure, patents like Amazon's OneClick method and Compton's "embedding multimedia on a CD-ROM" method are evidence of obviously deficient examination - prior art should have been easy to find. But consider, say, an algorithm embodying a specific video codec - the only instances of prior art might be embodied in closed-source, commercial video players. Short of decompiling and reverse-engineering a bunch of complex software, the examiner is incapable of demonstrating prior art - especially in light of the USPTO's examiner productivity metrics, which severely limit the examiner's time frame for searching and finding prior art.
The USPTO has been really abused by Congress. They appoint patent administration officers not on the basis of patent experience, but as political favors. Worse, Congress views the USPTO as a cash cow and siphons off its excess funding - thereby depriving the USPTO of funding to improve its examination process (e.g., hiring more examiners.)
It's true that the USPTO could have done better with the resources at its disposal. But it's possible that it just hasn't been given enough resources to meet its responsibilities.
He seems to have been talking about law rather than practice. The EPO seems to be breaking the law, but it would take determination and money to bring that before the relevant court(s), if it's even possible. (IANAL, and I can't be bothered to wade through the treaties to establish jurisdiction and procedures).
I don't blame you for not wanting to tread through the law - it's pretty marshy and unpleasant. Even IP professionals consider this to be a rather painful trawl through conflicting jurisprudence. However, the end result is quite clear - and quite clearly not "breaking the law."
The "law" that European patent offices are allegedly "breaking" by issuing software patents is European Article 52(2)(c), which precludes patents for "programs for computers," as well as "schemes, rules and methods for performing mental acts, playing games, or doing business."
However, efforts to seize on this language as a preclusion of software patents in any form is ignorant of European Article 52(3), which reads: "The provisions of paragraph 2 shall exclude patentability of the subject matter or activities referred to in that provision only to the extent to which a European patent application or European patent related to such subject matter or activities as such."
That seems like a pretty vague and unhelpful statement - what does it mean? It means that patent offices cannot issue patents for inventions claimed as "programs," "methods of doing business," etc. In other words, Article 52(2) does not preclude patents on methods that can be embodied as these classes. A method is a method; a method is not de facto a computer program. A method invention is to be judged for patentability on that basis - it cannot be rejected solely because it could be embodied as a computer program, or because it could be used as a business method.
This standard is very close to the U.S. rule. The only difference is that we also do not expressly ban patents for "computer programs." Rather, the U.S. patent examiner looks through the claim language and judges the patent on the basis of novelty and non-obviousness*. As long as the invention is claimed within the "statutory classes" of 35 USC 101, the invention is potentially patentable subject matter.
* It's undeniably true that the USPTO has not done a perfect job of asssessing novelty and non-obviousness. But that's a matter of effective implementation - it's not relevant to how the law should be structured.
The difference between a toaster (which would be patentable if it was a new invention) and software is that the toaster isn't implementing a mathematical algorithm.
It's not?
From a patent perspective, a toaster could be claimed as:
A device comprising:
A container;
A toasting surface disposed within the container for holding at least one food item;
At least one heating element disposed near the surface;
A timing device connected to the heating element; and
A user control for controlling the timing device.
A method for toasting food items, comprising:
Providing a device as described in claim 1;
Placing at least one food item on the toasting surface;
Activating the timer by manipulating the user control, thereby activating the heating element;
Waiting until the timer expires and deactivates the heating element; and
Withdrawing the at least one food item from the container.
A method for controlling a toaster device as described in claim 1, comprising:
Upon detecting the manipulation of the user control, activating the timer and the heating element; and
Upon expiration of the timer, deactivating the heating element.
It's a pretty straightforward stepwise progression from claim style #1 to claim style #3. Yet, the method claimed in claim style #3 could be embodied in software. How do you draw a line of patentability between claim style #1 and claim style #3? More importantly, why would you?
Software is patentable as a method of controlling a device, possibly but not necessarily including some form of user interaction. It's very difficult to draw a conceptual distinction between the device and the software algorithm. And that difficulty is the very reason why the Court of Appeals for the Federal Circuit made a stepwise progression from denying software patents (Gottschalk v. Benson) to allowing some software patents (Diamond v. Diehr) to abandoning "is it software?" as a relevant factor for patentability (State Street Bank & Trust Co. v. Signature Financial Systems.)
A method is a method - it can be embodied as a circuit, or as a chemical process, or as a machine with moving parts, or as software. It's still the same method. EEs and MEs and CSs have recognized this as a scientific truism for decades. It's kind of odd that when it comes to patents, people want to start gerrymandering.
Slashdot Mirror
Sure, but the business is using the software for the purpose of selling a modified version. If the license hugely impacts what can be sold, then it also impacts how and why the business might use it.
- David Stein
Look - I'll give you four reasons why every software license, including the GPL, is a contract:
1) The obligations are entirely mutual; each party has
2) The benefits are also plainly mutual:
3) You attempt to make much of the "unilateral" nature of the contract. There's a whole body of contracts called "unilateral contracts," where an offer is made to the entire public, and anyone may take advantage of it. Commercial advertisements, for instance - the newspaper ad offering "three cans of peaches for $1" is an offer to accept the contract; you do so by showing up at the store and carrying three cans of peaches to the cash register.
4) If there's a violation of a license, what body of law do you use? There is no body of law called "license law." There is a very large body of law called "contract law," and the cause of action for breach of contract covers all of the elements of this transaction. You might also file it as a violation of your copyright, but that would be a much more circuitous and difficult cause of action, and would foreclose some remedies that you might want (breaches of contract can lead to restitution, an accounting, an order for specific performance, etc.; copyright violations are usually relieved only with damages or injunctions.)
- David Stein
Incorrect.
The holding in Diamond v. Diehr was a (quite straightforward) reaffirmation of the timeworn concept that "laws of nature, natural phenomena, and abstract ideas" were not patentable, while "the use of [an] equation in conjunction with all of the other steps in [a] claimed process" was a patentable method. State Street Bank & Trust cited this exact same standard of patentability, and reached the exact same conclusion: that the use of a set of mathematical equations in a specific, applied context is a patentable method, regardless of how that method might be implemented.
In so holding, the Court of Appeals for the Federal Circuit did not "REVERSE" the Supreme Court. They applied the exact rule that the Supreme Court had affirmed, in the same conceptual context. And the Supreme Court must not have vociferously disagreed with them, as it denied certiorari for appeal (525 US 1093 [1999]).
The Suprme Court explicitly stated that the key to the patenability of a process was the physical transformation of an article or material into a different state or thing.
Incorrect.
The physicality was a clear feature of Diehr's method that rendered it patentable - it was one way of showing that an invention is not solely "abstract." It is not the only way; it was not "the key to patentability."
When the Court distinguished Diehr's patentable method from Benson's and Flook's unpatentable algorithms, it did not contrast Diehr's as "physical." It noted that Diehr's had an applied context - a utility - while Benson's and Flook's were merely "formulae." Note:
Notice the phrase "such an algorithm," i.e., algorithms used solely for "solving a mathematical problem." This implies that other algorithms are patentable.
This interpretation becomes even less disputable based on the majority opinion's Footnote 9, attached to this passage. The majority that Diamond, in arguing against patentability for Diehr's invention, had argued that the Court had previously ruled as unpatentable any "algorithm" that was a "fixed step-by-step procedure for accomplishing a given result..." - which would includes any purely software invention. But the majority expressly rejected this position:
The Supreme Court Stated that insignifigant [physical] post solution activity could not magically convert nonpatentable software into a patentable process.
Sure - you can't make unpatentable software patentable by dressing it up with unrelated facts. What about patentable software? I'm not being slippery - I mean that exactly as written... and so did the Supreme Court. You can't just take a bare mathematical formula and indicate that the output is used in an insignificant way. But if you take a mathematical formula and apply it in a useful context, then it is patentable.
By definition, a license is a contract. A contract is just an exchange of rights. In the case of a software license, you are
They fall under both. First, your violation of the license (which, again, is a contract) creates liability under copyright law. Second, since you no longer have permission to use the copy of the software in your possession, you are in violation of federal copyright law, which creates private liability to the licensor... precisely as I wrote in my parent post.
In the portion that I quoted, he vaguely referenced "federal law" for violating a license. I was listing the kinds of laws that typically come into play in licensing disputes - which usually do not include any kind of federal securities law.
Next, I discussed how the Sarbanes-Oxley provision might apply, and why I didn't think that it did.
Helpful tip: You can find all of that stuff in my original post. Hust click your left mouse button on that little scrollbar on the right side of this window, and drag it upward a bit.
- David Stein
No - they're still "commercial" vendors, but they're just bound by the same anti-"commercial" obligations under the GPL. The "commercial" value of the software is inversely proportional to the number of people who have copies.
This is because whatever reason you cannot be a commercial vendor also applies to them, they may also have competitors who will rerelease the software.
Correct. Hence, no one can realistically sell the software in a commercial context. Hence, "the GPL is largely antithetical to commercial software."
Only you have the right to sell a copy that can be used in closed source.
If we're talking about software that you developed based on other GPLed software - then, no, you can't do that. In that case, you cannot sell the software to someone to use in a closed-source context - because the obligations to keep open the original GPLed code flow down through you to your licensee.
IF we're talking about software that you developed not based on other GPLed software - then, sure, you can license it to a closed-source developer under a non-GPL license. But now we're no longer talking about the GPL at all. Hence, I maintain my statement: "The GPL is largely antithetical to commercial software."
You can of course just distribute your code with no license, so it is covered by copyright.
My license goes much further: it includes a large bundle of rights for the downstream user (granted freely and without restriction) that would not be permitted under a tacit copyright distribution. About the only right offered by GPL and other open-source licenses, but withheld by my license, is the right to use it in a commercial context.
- David Stein
That's funny. Several licenses on the "list of Open Source licenses" limit the commercial use of the "open-source software," particularly as it pertains to the licensee's ability to charge fees. This prompted the following interesting exercise:
"A Distributor may charge a fee for the physical act of transferring a copy [of the Licensed Work or any portion thereof], which charge shall be no more than the cost of physically performing source distribution."
"5. You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself." ("Package" is defined as the software being provided under the license.)
"This License is intended to facilitate the commercial distribution of the Program by any Contributor. However, Contributors may only charge Recipients a one-time, upfront fee for the distribution of the Program. Contributors may not charge Recipients any recurring charge, license fee, or any ongoing royalty for the Recipients exercise of its rights under this License to the Program. Contributors shall make the source code for the Contributor Version they distribute available at a cost, if any, equal to the cost to the Contributor to physically copy and distribute the work. It is not the intent of this License to prohibit a Contributor from charging fees for any service or maintenance that a Contributor may charge to a Recipient, so long as such fees are not an attempt to circumvent the foregoing restrictions on charging royalties or other recurring fees for the Program itself."
"If you sublicense the Licensed Product or Derivative Works, you may charge fees for warranty or support, or for accepting indemnity or liability obligations to your customers. You cannot charge for the Source Code."
"The Program must be distributed without charge beyond the costs of physically transferring the files to the recipient."
"You may charge a reasonable copying fee for any distribution of this Package. You may charge any fee you choose for support of this Package. You may not charge a fee for this Package itself."
"Under the terms of this License You may not: Charge for the Source Code to the Licensed Software, or Your Extensions, other than a nominal fee not to exceed Your cost for reproduction and distribution where such reproduction and distribution involve physical media."
It looks like a fair number of licenses blessed as "open-source licenses" attempt to control the commercial use of the downstream software. It shouldn't be contestible that businesses develop products for the purpose of charging an arbitrary price for them. By limiting the amounts that those businesses can charge for products based on GPLed code, these licenses certainly "discrimination" against the use of this software in the "field of endeavor" known as business.
- David Stein
It's not directly covered, but it's indirectly covered to an almost complete extent.
You're correct that the GPL disavows having any impact on whether or not a user is allowed to "run" the program:
(I have released a good amount of software under an open-source license, but not the GPL. I require that no one can make commercial use of my software. I'm giving it away freely for other people to use, not for making a profit from it - e.g., by selling it outright!)
- David Stein
But I don't know how "violation of the GPL" really connects with "ownership of IP."
From TFA:
"According to the study, the problem lies with the requirements of the Sarbanes-Oxley Act that companies disclose ownership of intellectual property to their shareholders. The study indicates that dozens of companies are discovered each year to have violated the terms of GPL, and if they are public companies, they are violating Sarbanes-Oxley."
Huh? Taking this statement at its face value: A company that receives software under the GPL does not "own" any "IP." They merely have a license to use the IP embedded in the software. Whether or not they violate that license has no bearing on "ownership" of IP... and if they don't "own" any IP in the GPLed software, then they haven't violated Sarbanes-Oxley by failing to "reporting" any kind of ownership.
"Linux is a powerful operating system," says Jay Michaelson, an author of the study and Wasabi Systems' General Counsel. "But if companies violate the license, the consequences can be more severe than they think. If companies are violating the GPL, they don't have the right to use that software. And if they don't have the right to use the software, they're violating federal law if they claim that they do."
Huh? Last I checked, the GPL was a private license. If they violate a private license in any way, then they are liable for breach of contract, which is in no way "federal law." The only "federal laws" they are violating are federal IP laws - but again, those laws only create private causes of action by the IP owners. License violations do not create liability to the federal government (unless the federal government actually owns the IP.)
As best I can tell from TFA, this gentleman means that companies are modifying GPLed code and then reporting it to shareholders as their "owned" IP - but that this claim of IP "ownership" is incorrect and fraudulent, since their violation of the GPL precludes them from "owning" their modifications. But TFA is way too light on details to be confident of this interpretation... and I'm not completely sure that the GPL works that way, anyway.
- David Stein
We can argue all day about whether or not it's right. But our government cares more about protecting America's interests (including its economy) than it does about "doing the right thing." If you agree (1) that IP is an important part of our economy, and (2) that eliminating that component would eliminate part of our economy - then unless you can suggest a kind of business that would supplant the role of IP in our economy, the discussion is over... or at least, better left to those unconcerned with geographical, political, and economic reality.
- David Stein
In other words, for a regular applicant to file and receive a basic patent application and own a patent for the full term, he/she/it must pay the USPTO at minimum $9,700. (A "small entity," including a sole inventor, receives a 50% break on these fees - for a paltry minimum fee of $4,850.) This minimum fee does not include:
Patenting is already a grossly expensive exercise. And you want to raise the rates? You must be taking a page from the conservative playbook: if we can't kill the system, let's make it completely unusable!
Your comments about Arizona's licensing agencies are right on point: administrative fees for government-issued rights (licenses, patents, IDs, whatever) should be almost exclusively used for the costs of issuing those rights. Drainage is simply an insidious mechanism for overcharging applicants and draining away the quality of service of the agency in order to fund unpopular projects. It's antithetical to democracy.
- David Stein
I don't see how you can draw that conclusion, or even estimate it, since a large portion of the application fee doesn't help the USPTO in any way - it gets channeled into other federal projects (*cough* Iraq.)
If you had written, "The portion of the current application fee that Congress allows the USPTO to retain doesn't cover the cost fo the PTO researching a patent now," I would wholeheartedly agree. I would also propose that the first step should be to remove the nonsensical encumbrance on the USPTO's financial resources.
- David Stein
You've forgotten about the biggest software patentee of them all. IBM's software patent practice just dwarfs those of Microsoft and Sun combined.
- David Stein
I can't imagine a more effective way of further reducing patent quality.
Your rule would limit patents to large corporations - those that can afford to throw away money to cement their positions. Is the financial well-being of a patent applicant a good predictor of the quality of its patent application?
Do a search sometime for patents by Microsoft, or General Motors, or any large company. You'll find a wide range of patents with unhelpful titles and incomprehensible specifications. These companies typically throw barrels of money at the USPTO to garner a range of vague, obfuscated patents of indeterminate breadth - because those patents make a better patent arsenal.
On the other hand, small entities and sole inventors have central interests in achieving patents that are clear, specific, and obviously valuable. Their goal is different: they're not trying to ward off competitors with hazy threats; they're trying to secure their most critical IP assets, attract investment, and promote licensing or a buyout. Basically, small entities don't have resources to waste on patenting; they have to be highly selective, and their patents have to be meaningful.
The USPTO could cover their costs (personell) better...
Instead, why not let the USPTO keep the fees that it already receives? One very serious problem with our current system is that Congress steals a lot of the money that the USPTO reaps from applicants. (It has to fund the Iraq war and its ultra-wealthy tax cuts somehow, right?) If the USPTO were allowed to apply 100% of its fees to strengthening its infrastructure, we'd see a marked improvement in its performance.
patents on UI and other software concepts should be limited to 5 years, not 20...
First, it sometimes takes five years just to get the patent. Many software patents filed in 2001 are still awaiting their first office action from the USPTO.
Second, we settled on 20 years because it's an international standard. We'd have to get every country with a patent office to agree to change the patent term. If you want to see just how difficult this is, try studying the history of the Patent Cooperation Treaty - getting many nations to agree to certain patent concepts is really like herding cats.
Third, as noted elsewhere in this thread, it is conceptually impossible to differentiate "software patents" from other kinds of patents, in order to apply different patent terms.
- David Stein
That's an awfully large hypothetical, since I don't see that the best solution to the problem is to "kill software patents." But I'll afford you this immense concession for the purpose of this hypothetical.
Our federal government is interested in technology, in "promoting the progress of the useful arts," in the pursuit of knowledge, etc. But at the end of the day, those things don't put food on American tables. Its much greater concern - perhaps its greatest concern of all - is maintaining the American economy. It's not going to take any action that eviscerates the economy unless there's a damn good reason. "Freeing software" is a vastly insufficient rationale. Our government has to live in the real world - it can't play The Sims with the American people, risking actual daily concerns for academic principles. That would be a dereliction of its duty.
(Of course, our current government seems to have derailed, but the Americans who voted them all into office will only realize and rue their mistakes in retrospect.)
- David Stein
One has nothing to do with the other. We didn't abandon tangible goods in favor of intangible goods. Rather, we lost tangible goods because manufacturing costs were too high. Evironmental compliance, minimum wage, unemployment, workers' compensation - these are costs that business must pay to manufacture within the U.S., but not abroad.
(This is in no way a criticism of the U.S. for that result. I harbor much enmity for foreign countries that are willing to sell out their populations in order to attract corporations. The growth of democracy across the world might help to level the playing field, but it'll take a century.)
In short - the tangible goods market collapsed all on its own. If anything, intangible markets have been used to fill the void. So I maintain: if you want the U.S. to cannibalize its global IP stance and dominance, then you're going to have to propose some other kind of economy to fill in the void.
The proponents have had-by admission- "decades" now to prove their point that the "new economy" would make us all richer somehow, and the results are as you see it, record deficits, record bankruptcies,a severe lessening of national security, an overly inflated currency (so bad they are going to stop reporting most of the M3 stats), and decent jobs that paid well with benefits being replaced with lesser paying jobs with little or no benefits.
We certainly have a host of economic problems. I think that many of them are very directly connected with (1) our wastrel federal government spending and (2) employers' widespread breach of the social contract with employees. I don't think that any of this has to do with what kinds of goods our economy is producing.
Do you have any evidence that modern corporations producing tangible goods treat their employees any better than corporations producing intangible goods? If not, then your argument linking intangible goods with our downtrodden employment market is spurious.
- David Stein
- Software development in the US will be more expensive, and/or
- Software sold in the US will be more expensive
Alternatively, you might expect to find more startup companies in the U.S. organized around a novel software product. That is exactly what has transpired. The U.S. continues to be the leader in software development - especially in novel software concepts.History review: The U.S. experienced a large software-based tech boom in the late 1990's. We also experienced a large bust in 2000, mostly because investors went bonkers, forgot that software is a business like any other business, and neglected to tie their investments to a valuation of business merit. We're now seeing a slow but steady buildup of our software market - fueled in part by (surprise!) small startups with novel software concepts.
Consider this: When it comes to the software patent game, Microsoft is 0/2 - having taken big losses to Stac Electronics ($39 million) and once to Eolas ($521 million). Yet Microsoft is a huge proponent of software patents. Microsoft is also shifting its business increasingly toward acquiring small startups with novel software concepts (e.g., its acquisition of Connectix.) Reason: Microsoft's mainstay products have stagnated, and it needs fresh software ideas... which are most easily acquired (exclusively) from small startups. Notice a trend here?
- David Stein
In fact, this duty goes much further: applicants are required (1) to have conducted at least a minimal search, (2) to disclose all known prior art that might be relevant, and (3) to assert their reasonable belief that the invention is still patentable in light of this prior art.
Unfortunately, very often, applicants wildly shirk this responsibility. One of the damning factors of current software patent practice is that for many issuing patents - including junk like scrollbars - the applicants disclosed no prior art. You have applicants filing claims for inventions like "selling products over the Internet" and disclosing fewer than three prior art references - as if they simply don't know of many businesses selling products over the Internet. It's deplorable.
This is one of the best suggestions for fixing the USPTO's examination system: start enforcing Rule 56 sanctions, i.e., start punishing applicants (and patent practitioners) who fail to satisfy their due-diligence research and disclosure duties. A few sanctions, including patent license suspension, would prompt a rapid and marked reduction in the number of patent applications being filed, and in the quality of those patent applications.
- David Stein
Alternatively, you might expect to find more startup companies in the U.S. organized around a novel software product. That is exactly what has transpired. The U.S. continues to be the leader in software development - especially in novel software concepts.
History review: The U.S. experienced a large software-based tech boom in the late 1990's. We also experienced a large bust in 2000, mostly because investors went bonkers, forgot that software is a business like any other business, and neglected to tie their investments to a valuation of business merit. We're now seeing a slow but steady buildup of our software market - fueled in part by (surprise!) small startups with novel software concepts.
Consider this: When it comes to the software patent game, Microsoft is 0/2 - having taken big losses to Stac Electronics ($39 million) and once to Eolas ($521 million). Yet Microsoft is a huge proponent of software patents. Microsoft is also shifting its business increasingly toward acquiring small startups with novel software concepts (e.g., its acquisition of Connectix.) Reason: Microsoft's mainstay products have stagnated, and it needs fresh software ideas... which are most easily acquired (exclusively) from small startups. Notice a trend here?
- David Stein
Over the last five decades, the U.S. economy has moved steadily away from physical goods and toward intangible goods - services, culture, music, movies, etc. This includes the development of intellectual property. It is a cornerstone of our economy. That's why the U.S. Congress has steadily increased its support of intellectual property protection. Accordingly, the courts have read federal IP legislation with broadening scope, since this is the plain intention of Congress.
So if you're arguing for the dismissal of U.S. patent legislation, you'll have to suggest a way of recapturing the huge share of our GDP attributable to the export of patent-based intellectual property. Since our trade deficit is already deep in the red, you might not find your state Congresscritters to be very receptive.
- David Stein
Presuming that "here" = Europe, I think that you're not understanding the full meaning of the European Articles in question. It's a common misconception.
You have to read both Article 52(2) (which prohibits patents on "software" and "methods of doing business") and Article 52(3) (which, specifically and literally, limits the exclusion in 52(2) to patents for software and business methods "as such.") In other words, you cannot patent software, but you can patent some other kind of invention - e.g., a useful method - that is capable of expression in the form of software, or that is applicable in business.
This is neither a loophole nor an inconsistency. It is a clear set of patentability standards, expressing a very plain and straightforward intentions of its legislators - to which the EPO has admirably conformed. You can criticize its application or consequences, but you cannot logically construe its exercise as some kind of abuse of the European patent laws.
- David Stein
You're missing the point. Claim #3 doesn't mention "software." It could be embodied as software, or as a circuit, or as the moving parts of the toaster. It is claimed solely as a "method," and is protected no matter how it is implemented. At the end of the day, it's just a method.
For many years, U.S. courts tried exactly what you propose: disallowing patents for "software" methods, but allowing patents for "other" methods. They concocted increasingly bizarre rules for determining whether a method was "software" or was not "software." It became an exercise in futility. State Street Bank & Trust, the pivotal case allowing patents for software, was the culminating finding that there isn't any logical test for a "software" method vs. a "non-software" method.
- David Stein
You can't, of course. But that's completely irrelevant, as the delineation is between pure research and applied research. The relevant question is: Is this invention "useful" in a pragmatic sense? Does it have an applied context? Is it part of a technical advance, like the development of a commercial device or a chemical process, or is it a pure scientific discovery with unknown application?
This is the critical question to patentability. You can't patent the law of gravity, or equations to measure it in the abstract. But you can patent a method of using gravity in some novel way during a particular industrial process. That's the heart of the patent system. It's also the basis for the term "utility patents."
- David Stein
To be fair, when it comes to software, the USPTO has struggled under two logistical problems:
It's true that the USPTO could have done better with the resources at its disposal. But it's possible that it just hasn't been given enough resources to meet its responsibilities.
- David Stein
I don't blame you for not wanting to tread through the law - it's pretty marshy and unpleasant. Even IP professionals consider this to be a rather painful trawl through conflicting jurisprudence. However, the end result is quite clear - and quite clearly not "breaking the law."
The "law" that European patent offices are allegedly "breaking" by issuing software patents is European Article 52(2)(c), which precludes patents for "programs for computers," as well as "schemes, rules and methods for performing mental acts, playing games, or doing business."
However, efforts to seize on this language as a preclusion of software patents in any form is ignorant of European Article 52(3), which reads: "The provisions of paragraph 2 shall exclude patentability of the subject matter or activities referred to in that provision only to the extent to which a European patent application or European patent related to such subject matter or activities as such."
That seems like a pretty vague and unhelpful statement - what does it mean? It means that patent offices cannot issue patents for inventions claimed as "programs," "methods of doing business," etc. In other words, Article 52(2) does not preclude patents on methods that can be embodied as these classes. A method is a method; a method is not de facto a computer program. A method invention is to be judged for patentability on that basis - it cannot be rejected solely because it could be embodied as a computer program, or because it could be used as a business method.
This standard is very close to the U.S. rule. The only difference is that we also do not expressly ban patents for "computer programs." Rather, the U.S. patent examiner looks through the claim language and judges the patent on the basis of novelty and non-obviousness*. As long as the invention is claimed within the "statutory classes" of 35 USC 101, the invention is potentially patentable subject matter.
* It's undeniably true that the USPTO has not done a perfect job of asssessing novelty and non-obviousness. But that's a matter of effective implementation - it's not relevant to how the law should be structured.
- David Stein
It's not?
From a patent perspective, a toaster could be claimed as:
It's a pretty straightforward stepwise progression from claim style #1 to claim style #3. Yet, the method claimed in claim style #3 could be embodied in software. How do you draw a line of patentability between claim style #1 and claim style #3? More importantly, why would you?
Software is patentable as a method of controlling a device, possibly but not necessarily including some form of user interaction. It's very difficult to draw a conceptual distinction between the device and the software algorithm. And that difficulty is the very reason why the Court of Appeals for the Federal Circuit made a stepwise progression from denying software patents (Gottschalk v. Benson) to allowing some software patents (Diamond v. Diehr) to abandoning "is it software?" as a relevant factor for patentability (State Street Bank & Trust Co. v. Signature Financial Systems.)
A method is a method - it can be embodied as a circuit, or as a chemical process, or as a machine with moving parts, or as software. It's still the same method. EEs and MEs and CSs have recognized this as a scientific truism for decades. It's kind of odd that when it comes to patents, people want to start gerrymandering.
- David Stein