Priority on a patent such as this which isn't a continuation patent is based on filing date, there is a year's lee-way if you have already filed in another jurisdiction but that's it. The patent was filed in 1996, anything that infringes the patent that pre-exists 1996 is prior art.
Every awk script ever written infringes claim 15. Are you saying that Apple invented data detectors before 1977? That would be a neat trick.
I use awk regularly at work, as well as piping grep results as parameters and so on, but that doesn't seem very similar to claim 15 to me, since I have to define context myself there - context being application or data type, not a regular expression pattern. This clearly applies to GUIs and presenting interactive action options, which isn't awk at all.
That doesn't really make a hair of difference though - not to the state of prior art, or even to the obviousness question. Just because a lot of people weren't doing something doesn't mean nobody had, or that it hadn't occurred to people.
It wasn't related to pieces of paper with dabs of glue attached, it was related to the very specific chemistry of the glue used. They may have added other patents around it later, and no doubt trade-marks on the name & style of sheet - perhaps even design patents covering the colour and shape of the pads - but the key patent wasn't something that was as trivial as your counter-example.
I believe 3M also had a patent on the manufacturing process (i.e. how to get the glue on every sheet). Not 100% sure (sure was a long time ago!).
Ridiculous is probably the wrong word, but there are lots of problems with software patents.
I would start by admitting that there are a few very good software patents in areas like cryptography and compression that describe extremely specific algorithms. In those instances, reading the patent is enough to implement the system, the amount of code required is tiny - and the idea is likely non-obvious, especially as most of the obvious algorithms were invented back in the 60s.
So what are the problems?
Specificity:
One problem is that far too many software patents do something analogous to patenting the idea of compression itself rather than of a particular algorithm for achieving it. There's no way to innovate around these patents, if you want to solve the same problem - you are caught within their claim.
Duration:
Software patents run for around 20 years, but 20 years is an eternity in software. If Visicalc had been granted a patent we would only have had a few years of free competition in spreadsheets - perhaps not even that if they'd managed to delay the filing date or use a continuation patent.
Numbers:
A big part of the problem is just scale. There are 32,000 chemical engineers working in the US according to the department of labour, there are around 700,000 software engineers. There simply too much creation going on for patents to be a viable way of doling it out. They evolved in an era when invention was rare, but now anybody with a computer has the means for it.
Crazy problem domain:
Maybe people from other disciplines would disagree, but I think software engineers would claim that they have the largest problem domain of any discipline, and not only is it huge but it is continuously shifting and growing both as hardware provides us more power and as the world around us changes. The sheer size of the problem domain means that it's rather backwards - rather than exploring a large solution space of a small number of problems we're busy trying to apply the smallest possible set of solutions to the largest possible set of problems.
Just because something wasn't done for years doesn't mean that the solution wasn't obvious, in software it may simply have meant that the problem hadn't yet occurred or hardware hadn't yet permitted it to be implemented.
That 3-M patent is a great example of how a chemist stumbled upon a solution to a problem and then went looking for a problem to apply it to. In software we are for more likely to have stumbled onto a good problem, and then gone looking for a solution.
Because much of the time they are granted for trivial developments, things that would have been created by numerous people or companies due to an obvious need or recognized market, but awarded to a single entity instead only because they got there first. That can impede creativity and development, and thus be detrimental to consumers, in a couple of different ways.
As perhaps a poor but still illustrative example, let's assume that rather than license their software patents on basic services to Apple, Nokia had taken a hard line (if permitted*) and refused to license. Instead they advised the ITC they wanted all of Apple's offending products removed from the market. Nokia decided they wanted the smartphone market to themselves since, after-all, they'd made a big investment in development. So would Apple need to create other standards for use with the iPhone or just discontinue a smartphone product? Would an investment of months/years and who knows how much money make sense as a business decision? And if so, how does that benefit the market having multiple standards in use that require additional infrastructure, support and investment, and introduce probable incompatibility with other systems and inconvenience to buyers?
And then consider that even if they take the time and spend the money to recreate the wheel, there's still no guarantee that someone else doesn't already have a software patent vague enough to be used against their new invention to claim another round of infringement?
That doesn't really make a hair of difference though - not to the state of prior art, or even to the obviousness question. Just because a lot of people weren't doing something doesn't mean nobody had, or that it hadn't occurred to people...
I am giving examples showing the non-obviousness.
It is your turn to show actual, not potential or possible, but actual incidences of prior art or obviousness. Could have, should have, would have, might have, don't count. Only "did" counts. If it was possible in AWK, but no one did it, it doesn't count either. Ball in your court, awaiting your next volley.
And with the post-it example if you'll notice it was the glue company that I said might have argued prior art (or scotch tape), since they both already made sticky stuff. And follow on companies, could emulate the solution, but they had to find their own sticky stuff, even though at that point sticky stuff was obvious. You want make sticky stuff that only sticks when you want it to, find a new material. It is not a perfect example, but it does have salient points.
I use awk regularly at work, as well as piping grep results as parameters and so on, but that doesn't seem very similar to claim 15 to me, since I have to define context myself there - context being application or data type, not a regular expression pattern. This clearly applies to GUIs and presenting interactive action options, which isn't awk at all.
just curious, where do you work and what do you still use awk for?
Those posters here who are patent lawyers please raise your hands. Otherwise you are pontificating about something you know nothing about and your statements about things like patent law, prior art, licensing, lawsuits, et al, are nothing more than missives of the clueless. This is all part of the legal system now and we just have to sit back and watch what happens. Our personal biases can assign motives to Apple or its competitors but that's meaningless too, sort of like arguing about whether Casey Anthony is guilty or not.
In software we are for more likely to have stumbled onto a good problem, and then gone looking for a solution.
Precisely. Really good philosophy finds really good questions, not really good answers (I can unpack that further if anyone want to hear an explanation of exactly what I mean). Once the problem is correctly framed, the answers become obvious, so almost all the argument is about how to frame the problem.
I think it's rather analogous when a software designer frames a problem the right way: "How do we automatically mark-up data in unstructured personal communication and documents so that the user doesn't have to fiddle with it themselves?" The answer is simple, of course; all that's novel is framing this as a problem. Up to that point, the framing was usually "how do we implement mark-up structure while composing documents and personal communications?" and thus putting the burden on the data source to implement some targeted standard. I think people just assumed that non-structured, non-normalized data would be too hairy to be useful (I probably would have, back in my early data-wrangling days) until they saw though example that there are a number of kinds of data that are both easily identifiable and useful.
And suddenly, it was obvious.
Granted, I think there's a good argument to be made that the patent is too broad and it needs to be limited, or something along those lines. In fact, that sort of thing does happen fairly frequently, and I expect something like that will happen here. Will it be narrowed to the point where the Android implementation will no longer infringe? I suspect not, though only with about 60/40 confidence.
One might also say that such stumblings shouldn't be protected by the patent system, as they don't really reward R&D effort so much as luck. I think there's a case to be made there, as well, but I admit that I've never been a UI designer (I hardly use the UI for my own product because I find the simplicity of scripts and consoles controls a lot of variables and so reduces the time to localize problem sources), so I don't really know what "R&D" really means for UI features. The closest I can think of is WebOS' technique for forcing garbage collection based on interface events so that the interface isn't likely to stutter. That took a fair amount of examination of use patterns and some clever timing techniques: it was a non-trivial effort, despite all it involved was forcing an intrinsic java operation at convenient times. I can only imagine what the patent on it looks like, and how broadly phrased it must be. And it's not that obvious, because Android hadn't implemented it last time I looked (in 2.2) despite also being java-based. iOS probably achieves something very similar, but they don't implement automatic garbage collection in objective C for iOS, and so don't face the same problem. If HP wanted to sue Android (that is, some Android-related entity) for copying their approach, it would seem to me that they have a case even though the specifics of implementation are either so general as to be meaningless (i.e. all java allows for forcing garbage collection) or too specific to infringe unambiguously (because the events on which garbage collection gets forced would be different in Android vs WebOS.)
Anyway, I don't think your position is crazy or biased, but I tentatively disagree.
What absolute hyperbole and nonsense. Linux can indeed "be touched."
A lot has been done to ensure that Linux is not patent encumbered, but it's just a copy of Unix after all, not an original OS, ....
False, false, false. Linux is a reimplementation of some of Unix ideas, but definitely not a copy. In any case, a copy would be a copyright violation, not a patent violation. Much of Unix was never patented -- the idea of a software patent had not been determined in 1970, when Unix was developed. The US Supreme Court did not rule that software was patentable until 1981 in Diamond v Diehr.
I really don't want to see Android hobbled by patents but at the same time patents must be honored. Google and the handset makers must share their profits rather the steal technology at others expense (i.e. Apple, Microsoft, and Oracle).
just curious, where do you work and what do you still use awk for?
I'd rather not identify my employer, but I can say I'm the test lead for a system composed of linux software controlling custom hardware and post-processing the data stream it produces.
One obvious use for awk is to pull ICD commands out of log files and feed them to command consoles. Ditto pulling file names out of find or ls results to feed to utilities. Sometimes I just use it to normalize data for diff, though if I can get away with using just cut/sort I prefer to avoid awk's peccadillos. Basically, the normal stuff for which awk tends to get used (in my experience, anyway).
It is your turn to show actual, not potential or possible, but actual incidences of prior art or obviousness. Could have, should have, would have, might have, don't count. Only "did" counts. If it was possible in AWK, but no one did it, it doesn't count either. Ball in your court, awaiting your next volley.
If your issue is that AWK doesn't contain a UI with user actions then I would suggest emacs folding mode, which came into existence around 1991
Folding mode detects places in code where it can be 'folded' and then by user interaction you can fold or enter the code at that point. The way to determine the fold location is stored as a string map within the .el file and is configurable so that it can be set to a string that is convenient for the language. Some patterns come supplied.
Folding mode could be run at the same time as font-lock mode which would highlight, so I think that essentially covers all the aspects of the patent.
Emacs as it existed back in the early 90s constitutes a system that infringes this patent.
Precisely. Really good philosophy finds really good questions, not really good answers (I can unpack that further if anyone want to hear an explanation of exactly what I mean). Once the problem is correctly framed, the answers become obvious, so almost all the argument is about how to frame the problem.
I think that's very true of academia, but I don't think it's a good use for the patent system. If an academic poses a problem in a very clear way that is definitely original research and worthy of citation - but it doesn't give them a head-lock on further research.
Patents didn't begin as ways to protect problems, they began as a way to protect solutions. Now there is a case that there should be a way to protect 'framing the problem', perhaps for a much shorter period of time, say 3-5 years. Apple certainly 'reframed the problem' of what a phone was for, or what a tablet was for.
The patent is a 500 year old concept that is simply not suitable for rewarding innovation in the software world. In an ideal world Apple would be rewarded for that innovation in a way that didn't entail them having to claim ownership of such a basic concept as a parser coupled to a UI.
Quote:
I think it's rather analogous when a software designer frames a problem the right way: "How do we automatically mark-up data in unstructured personal communication and documents so that the user doesn't have to fiddle with it themselves?" The answer is simple, of course; all that's novel is framing this as a problem. Up to that point, the framing was usually "how do we implement mark-up structure while composing documents and personal communications?" and thus putting the burden on the data source to implement some targeted standard. I think people just assumed that non-structured, non-normalized data would be too hairy to be useful (I probably would have, back in my early data-wrangling days) until they saw though example that there are a number of kinds of data that are both easily identifiable and useful.
Well first off it's not like they're detecting unstructured data, they're finding very structured strings in an unstructured stream and that was never terribly hard, even in the 80s - it's the entire purpose of a regexp after all, Also I think we need to keep bearing in mind what the patent actually says rather than what we might like it to say. It doesn't limit itself to just non mark-up'ed data, it would apply just as well to detection of a keyword in an IDE text-window with a right-click to bring up a man page.
The use-case where the patent is applied to phone numbers and whatnot is just the embodiment, you can't get caught up in that. The claims are the issue.
Did you read the patents? The '647 patent prevents (amongst other things) a competing platform from recognising phone numbers in a text message, or URLs. That's a pretty basic piece of functionality, there's no way to 'innovate around it' - android would have to simply not provide the feature. The patent doesn't specify a particular method of doing this, essentially any method that does it will fall foul of the patent.
Read the actual patents, read the actual claims and see how broadly they're phrased, then you will understand why it's frequently impossible to just 'innovate around' a software patent - and why professional software developers both fear and loathe them.
Not disagreeing with you but just on your last point, surely professional software developers only fear and loathe them when they are someone else's while they love them when they have them on something they developed.
The patent is a 500 year old concept that is simply not suitable for rewarding innovation in the software world. In an ideal world Apple would be rewarded for that innovation in a way that didn't entail them having to claim ownership of such a basic concept as a parser coupled to a UI.
Well first off it's not like they're detecting unstructured data, they're finding very structured strings in an unstructured stream and that was never terribly hard, even in the 80s - it's the entire purpose of a regexp after all, Also I think we need to keep bearing in mind what the patent actually says rather than what we might like it to say. It doesn't limit itself to just non mark-up'ed data, it would apply just as well to detection of a keyword in an IDE text-window with a right-click to bring up a man page.
The use-case where the patent is applied to phone numbers and whatnot is just the embodiment, you can't get caught up in that. The claims are the issue.
As you say, it's a method for using structured data in an unstructured stream to provide interactive choices. Not at all what awk offers, and even your emacs folding example is a very specific application that really only offers one interactive choice: fold, or don't.
Nevertheless, I have to grant that the patent system treating this kind of thing in the same way as it would specific algorithms and whatnot seems poorly matched. I would rather that there be, to use something like your suggestion, a sort of derived implementation patent that lasts much less than 20 years*. That would have protected Apple's embodiment for a few years but let the rest of the field implement it within a product cycle or two. Thus, companies would still have plenty of incentives to innovate in obvious-after-the-fact ways, but not so that they can lock things down forever.
In Apple's shoes, I would totally use the patent, but I have to agree that it would be insane to apply this patent to two decades of smartphone implementations starting in 2007. I feel like there has to be something that recognizes the work that Apple, Palm, and Microsoft did to approach user-interface problems in a novel way, without putting any clear best choices rigidly off-limits to competitors for what is an eternity in software.
*To elaborate a bit more, say the original 20 year patent grant still applies, but anyone wanting to use the approach to create specific embodiments only has to license for 3-5 years(and the holder can't refuse to license, though I've never understood how the court determines what a reasonable license fee is), or if the patent-holder uses it, they can only keep exclusivity for 3-5 years.
Therefore, this will only be applicable for 3 more years.
How do you figure that?
In the US, the life span of a patent is calculated using the filing date and not the issuance date. But the '647 patent was filed on Feb 1, 1996 and issued on Aug 31, 1999. Whichever date you use, the patent is good well past the next 3 years, if I am not mistaken. Perhaps we are talking about different patents?
Comments
Priority on a patent such as this which isn't a continuation patent is based on filing date, there is a year's lee-way if you have already filed in another jurisdiction but that's it. The patent was filed in 1996, anything that infringes the patent that pre-exists 1996 is prior art.
Every awk script ever written infringes claim 15. Are you saying that Apple invented data detectors before 1977? That would be a neat trick.
I use awk regularly at work, as well as piping grep results as parameters and so on, but that doesn't seem very similar to claim 15 to me, since I have to define context myself there - context being application or data type, not a regular expression pattern. This clearly applies to GUIs and presenting interactive action options, which isn't awk at all.
That doesn't really make a hair of difference though - not to the state of prior art, or even to the obviousness question. Just because a lot of people weren't doing something doesn't mean nobody had, or that it hadn't occurred to people.
The master patent for the post-it was I believe
http://patft.uspto.gov/netacgi/nph-P...y=PN%2F3691140
It wasn't related to pieces of paper with dabs of glue attached, it was related to the very specific chemistry of the glue used. They may have added other patents around it later, and no doubt trade-marks on the name & style of sheet - perhaps even design patents covering the colour and shape of the pads - but the key patent wasn't something that was as trivial as your counter-example.
I believe 3M also had a patent on the manufacturing process (i.e. how to get the glue on every sheet). Not 100% sure (sure was a long time ago!).
Why are software patents ridiculous?
Ridiculous is probably the wrong word, but there are lots of problems with software patents.
I would start by admitting that there are a few very good software patents in areas like cryptography and compression that describe extremely specific algorithms. In those instances, reading the patent is enough to implement the system, the amount of code required is tiny - and the idea is likely non-obvious, especially as most of the obvious algorithms were invented back in the 60s.
So what are the problems?
Specificity:
One problem is that far too many software patents do something analogous to patenting the idea of compression itself rather than of a particular algorithm for achieving it. There's no way to innovate around these patents, if you want to solve the same problem - you are caught within their claim.
Duration:
Software patents run for around 20 years, but 20 years is an eternity in software. If Visicalc had been granted a patent we would only have had a few years of free competition in spreadsheets - perhaps not even that if they'd managed to delay the filing date or use a continuation patent.
Numbers:
A big part of the problem is just scale. There are 32,000 chemical engineers working in the US according to the department of labour, there are around 700,000 software engineers. There simply too much creation going on for patents to be a viable way of doling it out. They evolved in an era when invention was rare, but now anybody with a computer has the means for it.
Crazy problem domain:
Maybe people from other disciplines would disagree, but I think software engineers would claim that they have the largest problem domain of any discipline, and not only is it huge but it is continuously shifting and growing both as hardware provides us more power and as the world around us changes. The sheer size of the problem domain means that it's rather backwards - rather than exploring a large solution space of a small number of problems we're busy trying to apply the smallest possible set of solutions to the largest possible set of problems.
Just because something wasn't done for years doesn't mean that the solution wasn't obvious, in software it may simply have meant that the problem hadn't yet occurred or hardware hadn't yet permitted it to be implemented.
That 3-M patent is a great example of how a chemist stumbled upon a solution to a problem and then went looking for a problem to apply it to. In software we are for more likely to have stumbled onto a good problem, and then gone looking for a solution.
Why are software patents ridiculous?
Because much of the time they are granted for trivial developments, things that would have been created by numerous people or companies due to an obvious need or recognized market, but awarded to a single entity instead only because they got there first. That can impede creativity and development, and thus be detrimental to consumers, in a couple of different ways.
As perhaps a poor but still illustrative example, let's assume that rather than license their software patents on basic services to Apple, Nokia had taken a hard line (if permitted*) and refused to license. Instead they advised the ITC they wanted all of Apple's offending products removed from the market. Nokia decided they wanted the smartphone market to themselves since, after-all, they'd made a big investment in development. So would Apple need to create other standards for use with the iPhone or just discontinue a smartphone product? Would an investment of months/years and who knows how much money make sense as a business decision? And if so, how does that benefit the market having multiple standards in use that require additional infrastructure, support and investment, and introduce probable incompatibility with other systems and inconvenience to buyers?
And then consider that even if they take the time and spend the money to recreate the wheel, there's still no guarantee that someone else doesn't already have a software patent vague enough to be used against their new invention to claim another round of infringement?
That doesn't really make a hair of difference though - not to the state of prior art, or even to the obviousness question. Just because a lot of people weren't doing something doesn't mean nobody had, or that it hadn't occurred to people...
I am giving examples showing the non-obviousness.
It is your turn to show actual, not potential or possible, but actual incidences of prior art or obviousness. Could have, should have, would have, might have, don't count. Only "did" counts. If it was possible in AWK, but no one did it, it doesn't count either. Ball in your court, awaiting your next volley.
And with the post-it example if you'll notice it was the glue company that I said might have argued prior art (or scotch tape), since they both already made sticky stuff. And follow on companies, could emulate the solution, but they had to find their own sticky stuff, even though at that point sticky stuff was obvious. You want make sticky stuff that only sticks when you want it to, find a new material. It is not a perfect example, but it does have salient points.
I use awk regularly at work, as well as piping grep results as parameters and so on, but that doesn't seem very similar to claim 15 to me, since I have to define context myself there - context being application or data type, not a regular expression pattern. This clearly applies to GUIs and presenting interactive action options, which isn't awk at all.
just curious, where do you work and what do you still use awk for?
Whatever their intentions may be, Apple has broken a golden rule in the telecom industry.
You know nothing about the telecom industry, absolutely nothing.
In software we are for more likely to have stumbled onto a good problem, and then gone looking for a solution.
Precisely. Really good philosophy finds really good questions, not really good answers (I can unpack that further if anyone want to hear an explanation of exactly what I mean). Once the problem is correctly framed, the answers become obvious, so almost all the argument is about how to frame the problem.
I think it's rather analogous when a software designer frames a problem the right way: "How do we automatically mark-up data in unstructured personal communication and documents so that the user doesn't have to fiddle with it themselves?" The answer is simple, of course; all that's novel is framing this as a problem. Up to that point, the framing was usually "how do we implement mark-up structure while composing documents and personal communications?" and thus putting the burden on the data source to implement some targeted standard. I think people just assumed that non-structured, non-normalized data would be too hairy to be useful (I probably would have, back in my early data-wrangling days) until they saw though example that there are a number of kinds of data that are both easily identifiable and useful.
And suddenly, it was obvious.
Granted, I think there's a good argument to be made that the patent is too broad and it needs to be limited, or something along those lines. In fact, that sort of thing does happen fairly frequently, and I expect something like that will happen here. Will it be narrowed to the point where the Android implementation will no longer infringe? I suspect not, though only with about 60/40 confidence.
One might also say that such stumblings shouldn't be protected by the patent system, as they don't really reward R&D effort so much as luck. I think there's a case to be made there, as well, but I admit that I've never been a UI designer (I hardly use the UI for my own product because I find the simplicity of scripts and consoles controls a lot of variables and so reduces the time to localize problem sources), so I don't really know what "R&D" really means for UI features. The closest I can think of is WebOS' technique for forcing garbage collection based on interface events so that the interface isn't likely to stutter. That took a fair amount of examination of use patterns and some clever timing techniques: it was a non-trivial effort, despite all it involved was forcing an intrinsic java operation at convenient times. I can only imagine what the patent on it looks like, and how broadly phrased it must be. And it's not that obvious, because Android hadn't implemented it last time I looked (in 2.2) despite also being java-based. iOS probably achieves something very similar, but they don't implement automatic garbage collection in objective C for iOS, and so don't face the same problem. If HP wanted to sue Android (that is, some Android-related entity) for copying their approach, it would seem to me that they have a case even though the specifics of implementation are either so general as to be meaningless (i.e. all java allows for forcing garbage collection) or too specific to infringe unambiguously (because the events on which garbage collection gets forced would be different in Android vs WebOS.)
Anyway, I don't think your position is crazy or biased, but I tentatively disagree.
What absolute hyperbole and nonsense. Linux can indeed "be touched."
A lot has been done to ensure that Linux is not patent encumbered, but it's just a copy of Unix after all, not an original OS, ....
False, false, false. Linux is a reimplementation of some of Unix ideas, but definitely not a copy. In any case, a copy would be a copyright violation, not a patent violation. Much of Unix was never patented -- the idea of a software patent had not been determined in 1970, when Unix was developed. The US Supreme Court did not rule that software was patentable until 1981 in Diamond v Diehr.
just curious, where do you work and what do you still use awk for?
I'd rather not identify my employer, but I can say I'm the test lead for a system composed of linux software controlling custom hardware and post-processing the data stream it produces.
One obvious use for awk is to pull ICD commands out of log files and feed them to command consoles. Ditto pulling file names out of find or ls results to feed to utilities. Sometimes I just use it to normalize data for diff, though if I can get away with using just cut/sort I prefer to avoid awk's peccadillos. Basically, the normal stuff for which awk tends to get used (in my experience, anyway).
I am giving examples showing the non-obviousness.
It is your turn to show actual, not potential or possible, but actual incidences of prior art or obviousness. Could have, should have, would have, might have, don't count. Only "did" counts. If it was possible in AWK, but no one did it, it doesn't count either. Ball in your court, awaiting your next volley.
If your issue is that AWK doesn't contain a UI with user actions then I would suggest emacs folding mode, which came into existence around 1991
Folding mode detects places in code where it can be 'folded' and then by user interaction you can fold or enter the code at that point. The way to determine the fold location is stored as a string map within the .el file and is configurable so that it can be set to a string that is convenient for the language. Some patterns come supplied.
Folding mode could be run at the same time as font-lock mode which would highlight, so I think that essentially covers all the aspects of the patent.
Emacs as it existed back in the early 90s constitutes a system that infringes this patent.
As much as I dislike Android and all the other iPhone knockoffs. It seems that Apple is becoming the big patent troll these days.
I would love to see all the android devices fall off the face of the earth, but not like this.
Have you considered that the only troll here is yourself?
Ha ha I just had to register because I think this quote is fantastic!
Precisely. Really good philosophy finds really good questions, not really good answers (I can unpack that further if anyone want to hear an explanation of exactly what I mean). Once the problem is correctly framed, the answers become obvious, so almost all the argument is about how to frame the problem.
I think that's very true of academia, but I don't think it's a good use for the patent system. If an academic poses a problem in a very clear way that is definitely original research and worthy of citation - but it doesn't give them a head-lock on further research.
Patents didn't begin as ways to protect problems, they began as a way to protect solutions. Now there is a case that there should be a way to protect 'framing the problem', perhaps for a much shorter period of time, say 3-5 years. Apple certainly 'reframed the problem' of what a phone was for, or what a tablet was for.
The patent is a 500 year old concept that is simply not suitable for rewarding innovation in the software world. In an ideal world Apple would be rewarded for that innovation in a way that didn't entail them having to claim ownership of such a basic concept as a parser coupled to a UI.
I think it's rather analogous when a software designer frames a problem the right way: "How do we automatically mark-up data in unstructured personal communication and documents so that the user doesn't have to fiddle with it themselves?" The answer is simple, of course; all that's novel is framing this as a problem. Up to that point, the framing was usually "how do we implement mark-up structure while composing documents and personal communications?" and thus putting the burden on the data source to implement some targeted standard. I think people just assumed that non-structured, non-normalized data would be too hairy to be useful (I probably would have, back in my early data-wrangling days) until they saw though example that there are a number of kinds of data that are both easily identifiable and useful.
Well first off it's not like they're detecting unstructured data, they're finding very structured strings in an unstructured stream and that was never terribly hard, even in the 80s - it's the entire purpose of a regexp after all, Also I think we need to keep bearing in mind what the patent actually says rather than what we might like it to say. It doesn't limit itself to just non mark-up'ed data, it would apply just as well to detection of a keyword in an IDE text-window with a right-click to bring up a man page.
The use-case where the patent is applied to phone numbers and whatnot is just the embodiment, you can't get caught up in that. The claims are the issue.
Did you read the patents? The '647 patent prevents (amongst other things) a competing platform from recognising phone numbers in a text message, or URLs. That's a pretty basic piece of functionality, there's no way to 'innovate around it' - android would have to simply not provide the feature. The patent doesn't specify a particular method of doing this, essentially any method that does it will fall foul of the patent.
Read the actual patents, read the actual claims and see how broadly they're phrased, then you will understand why it's frequently impossible to just 'innovate around' a software patent - and why professional software developers both fear and loathe them.
Not disagreeing with you but just on your last point, surely professional software developers only fear and loathe them when they are someone else's while they love them when they have them on something they developed.
This patent was granted 17 years ago.
Most patents's life is around 20 years.
Therefore, this will only be applicable for 3 more years.
That will cheer Google up I'm sure
The patent is a 500 year old concept that is simply not suitable for rewarding innovation in the software world. In an ideal world Apple would be rewarded for that innovation in a way that didn't entail them having to claim ownership of such a basic concept as a parser coupled to a UI.
Well first off it's not like they're detecting unstructured data, they're finding very structured strings in an unstructured stream and that was never terribly hard, even in the 80s - it's the entire purpose of a regexp after all, Also I think we need to keep bearing in mind what the patent actually says rather than what we might like it to say. It doesn't limit itself to just non mark-up'ed data, it would apply just as well to detection of a keyword in an IDE text-window with a right-click to bring up a man page.
The use-case where the patent is applied to phone numbers and whatnot is just the embodiment, you can't get caught up in that. The claims are the issue.
As you say, it's a method for using structured data in an unstructured stream to provide interactive choices. Not at all what awk offers, and even your emacs folding example is a very specific application that really only offers one interactive choice: fold, or don't.
Nevertheless, I have to grant that the patent system treating this kind of thing in the same way as it would specific algorithms and whatnot seems poorly matched. I would rather that there be, to use something like your suggestion, a sort of derived implementation patent that lasts much less than 20 years*. That would have protected Apple's embodiment for a few years but let the rest of the field implement it within a product cycle or two. Thus, companies would still have plenty of incentives to innovate in obvious-after-the-fact ways, but not so that they can lock things down forever.
In Apple's shoes, I would totally use the patent, but I have to agree that it would be insane to apply this patent to two decades of smartphone implementations starting in 2007. I feel like there has to be something that recognizes the work that Apple, Palm, and Microsoft did to approach user-interface problems in a novel way, without putting any clear best choices rigidly off-limits to competitors for what is an eternity in software.
*To elaborate a bit more, say the original 20 year patent grant still applies, but anyone wanting to use the approach to create specific embodiments only has to license for 3-5 years(and the holder can't refuse to license, though I've never understood how the court determines what a reasonable license fee is), or if the patent-holder uses it, they can only keep exclusivity for 3-5 years.
This patent was granted 17 years ago.
Most patents's life is around 20 years.
Therefore, this will only be applicable for 3 more years.
How do you figure that?
In the US, the life span of a patent is calculated using the filing date and not the issuance date. But the '647 patent was filed on Feb 1, 1996 and issued on Aug 31, 1999. Whichever date you use, the patent is good well past the next 3 years, if I am not mistaken. Perhaps we are talking about different patents?
You know nothing about the telecom industry, absolutely nothing.
Common refrain from someone lacking a proper counter-argument but not lacking in desire to be heard.