(Besides, algorithms cannot be patented in the EU, so it is impossible that this code violates any patent.)
(Besides, algorithms cannot be patented in the EU, so it is impossible that this code violates any patent.)
The UK practice had substantially changed since I left (after Macrossan, http://en.wikipedia.org/wiki/Aerotel_v_Telco_and_Macrossan%2...), the UK Patents Act has harmonising terms such that various sections are interpreted to match EPC articles. In the EU software patents were ruled out "as such" and traditionally the loophole was that as long as a "technical effect" (beyond that expected from mere computerisation) was demonstrated in the application of a patent then the software patent was allowed.
Generally the EPC and UKIPO treatments have differed as software patents were actually ruled out "per se" in UK Patents Act 1977 S1(1)(d) referencing 1(2)(c) and UK has been stricter in interpreting this (see Macrossan).
UK law also states that [pure] business methods and mathematical algorithms are unpatentable (again Section 1; see examiners manual - http://www.ipo.gov.uk/practice-sec-001.pdf) amongst other things.
However historical quirks meant that compression algos were allowed in certain areas (imaging) that wouldn't be allowed unless they were couched in the right way (that's my interpretation, I couldn't understand why they were granted).
The Macrossan tests are spelt out clearly in the above Patent Examiner's manual link as is the UK practice (but this can be amended by court decisions).
http://en.wikipedia.org/wiki/Software_patents_under_the_Euro... and the corresponding UK page appear to be thorough treatments for those that wish to read more.
Implementations can vary in trivial ways (eg. different variable names), substantial ways (eg. different languages), in representation choices (eg. a graph as a list of arcs; as a matrix of connections; as pointers/references from data structure to data structure; using "pointers" that are indices into an array etc); in execution choices (recursive; iterative; immutable; mutable); in a million details that are non-significant for the algorithm. Ask two people to implement Dijkstra's algorithm; they're unlikely to produce identical code. (Although, when marking at uni, assignments were often strikingly similar - not always due to cheating, since one of them was almost identical to code I'd written, and no one had seen it. There are often only a few obvious ways to approach a problem and convention dictates the other decisions. But I digress.)
Now, there still a problem. Hcho said that while programs could not be patented, algorithms could. So, imagine you patent some algorithm, and later I write and commercially use a program that implements that algorithm.
How the hell could my particular use of your algorithm not infringe your patent? Yet it is my understanding that it doesn't, on the grounds that software is somewhat immune from patent infringement.
Either I missed something, or something is amiss.
I think Hcho meant that when you draft the patent, you draft it in terms of an algorithm - though I also think he was speaking tongue in cheek. You could draft a patent that was specifically of one particular implementation, but it wouldn't give you much protection. Sometimes, people will describe the algorithm, and also supply a particular implementation (to prove that it really works). A long time ago, it was actually a requirement to supply a working model with each patent, and there's a museum of them somewhere.
Aside: Actually, pure algorithms aren't patentable, because they are too abstract. For a software patent to be valid, it has to be inventive (non-obvious to one skilled in its field) with respect to the state-of-the-art (at that time it was invented). Bilski, the recent (US) patent case, held that you have to assess this inventiveness of the algorithm and its application to a problem as a whole. It's not enough to apply an algorithm in an obvious way (no amount of "post-solution activity" helps, if it's not inventive). I think this distinction of algorithm vs application is similar to product vs market. An algorithm is a solution, but it's not patentable unless it is a solution to a problem - and that taken together, is not obvious.
A famous patent law case (whose name escapes me) involved a well-known chemical that was patented as a fertilizer. It wasn't previously realized that it could be used as a fertilizer - this was a non-obvious application of a known thing.
OK, I'm sure that was more than you wanted.
Algorithm:
Algorithm Maximum
Input: Two numbers M and N.
Output: The largest number of M and N.
if M > N, then return M
else return N
Software: // Returns the largest of m and n.
int Maximum(int m, int n) {
if (m > n) return n;
else return n;
}
There. Clear?Does your algorithm automatically become software at the time of completion of my compiler?
Or does it become software only when its compiled down to machine code?
Do you have something more substantial?
Meta: funny how this comment is doing karma oscillation (so far: + - - + -). But I would've like people tell me why 3 of them thought I have "crossed the line".
I'm pretty sure Deestan is being facetious here.
Maybe I should add a sarcasm tag or something in the future.
Anyway, I think we have a "sarcasm bias". Meaning, when I mean a sarcasm, it's obvious and anyone who doesn't see it is an idiot; and when you mean a sarcasm, you'd better put the sarcasm tag, or we can't perceive your tone, you idiot.
(Just to be sure: The tone here is sarcastic, but I think the bias I speak of is real.)
Patent Trolls LLC
It is a very lame example, IMO.
BTW, you should get carefull since the above piece of software is probably copyrighted in the US, with other patents pending for the rest of the know universe. Oh wait, can you hear the patent police knocking at your door ? Too late mate.
Now, I'd like you to explain to me how your way of sorting integers is not a program. Or how your program is not a way of sorting integer.
No matter how I squeeze my brain, I still fail to see a difference between an algorithm and a program. To me, that's only different labels for the same thing.
For a real lif example: http://en.wikipedia.org/wiki/T_258/03
I don't see any actual difference between a program and an algorithm. If you do, please define both, and show me that those definitions aren't equivalent.
Now, if there isn't any actual difference, I wonder how regulators managed to forge a legal one. That would be silly. Anyway, if they did make a legal difference, I'd love to have specific references.
1. Parse HTTP Headers into map of header -> value
2. Check to see if "Cookie" exists in map
3. If it does, and it's value is X load record X
from database table N
4. Otherwise, insert a new record in table N and
create a "Set-Cookie" header in the response
Is this a sexy algorithm? Not at all, but is it still an algorithm? Yes. An algorithm is just a set of things that make up a process.What patentese means by inventive technical step is changes to or creation of algorithms.
"schemes, rules and methods for performing mental acts, playing games or doing business," and programs for computers;
This how the patent lawyers interpret this clause. Companies I worked for pays £xxxx to their employees for patents. I've sat in some of the commitees which decides a patent is worth pursuing. My experience is the inventive step almost always involves some tweaking in existing algorithms.