Steven's concurrence is actually a dissent in part. He goes on for 40+ pages about why business methods should not be patentable under 101, and three other justices joined Stevens. Regardless of whether he label his writing a concurrence or dissent, the opinion is split. There is a 5-4 majority opinion in favor of business method patents.
Practically speaking, this means that the Court is one vote away from making business methods non-patentable.
Software patents are still good. The court seems to unanimously agree to maintain the status quo that software methods are patentable subject matter.
Business method patents are still good, but just barely. The opinion is split 5-4 in favor of business method patents, but puts some rather vague restrictions on them (e.g., must not be abstract ideas).
My read is that the justices seem to be ok with software patents in principle but are leery of business method patents that are not tied to a device or that do not incorporate some form of technology.
They seemed to struggle with how much of a "machine" needs to be added to an abstract business method before it becomes patentable subject matter.
In other news, Roberts appears to be confused about the difference between patentable subject matter and obviousness.
The cellular providers are very wary of applications that could consume loads of precious RF bandwidth or spread viruses throughout their networks. These are very real threats that are hard to mitigate without control over the apps themselves.
The other reason is that ISPs in general are afraid of becoming "fat pipes" where they cannot differentiate themsevles from other ISPs except for having tighter operations. Tight operations requires business and technical discipline that few large organizations seem capable of attaining.
Looks like RFC 3261 on SIP could be relevant prior art. Also, FTP has been exchanging IP addresses between devices for some time in a slightly different context. Also it depends on how liberally one can interpret "point-to-point" protocol" Is it just PPP or broader than that.
Regardless, I think the asserter of this patent has a long road ahead.
Some lab ran a protocol tester against some ISAKMP implementations and found a few issues. No reason to panic as long as the vendors fix it. It is pretty common to fix these sorts of bugs it complicated protocols like ISAKMP.
Mobile Ipv6 may actually get rolled because it can reduce cost and backhaul latencies for wireless VoIP providers. MIPv4 doesn't allow route optimization, so it doesn't quite solve the problem as cleanly and required either more capex or opex to support. Whether or not this happens depends if the cost can be justified vs. router upgrades, staff training, and service outages due to new technology and misunderstandings of new technology.
Having said that I don't see a landline ISP moving to IPv6 until at least one of the following occurs:
1) Government mandate for v6 2) v6 reduces cost somehow (see above) 3) Everyone else is doing it
Its unlikely that 3G will jump the shark because the tellcos are bent on moving all voice traffic to VOIP over 3G. The current EVDO is just the first step.
EVDO uses a highspeed downlink and a low speed uplink. In fact, the uplink is the first generation of 3G CDMA, called 1xRTT, and it capped at about 144Kbps. So it you're getting 100 on the uplink that is pretty decent for wireless.
So this is not Verizon's choice, it is a limitation of the technology and equipment. The next version o EVDO will have higher uplink speeds.
My interpretation of the claims is that the patent is fairly narrow. It's broadest claim outlines a process consisting of many steps, all of which must be performed in order for the patent to be infringed.
You have to read the clauses of the claim as logical AND statements.
There is only one set of independent claims. Usually that means that there were other sets ruled unpatentable by the PTO, which may later find their way (in a more limited form) to a continuation patent.
I try to keep mine current, revving them after peer reviews, low level designs, test plan reviews and customer discussions. I also try to be as complete as possible, within reason, so that the outcome (i.e., what the product actually does) is predictable. A hard thing to do is maintain traceability between requirements and the resulting software and test plans, and I've not seen good tools to do so (I've seen lots of tools, but they all seem to require too much overhead).
Once I have a solid design doc for a feature that is released and dpeloyed, I turn the doc into an Interface Control Doc or incorporate it into an existing one, which is then kept current with subsequent changes.
None of this is perfect but it seems to work and is fairly low-overhead if everyone buys into the process.
The difference is that Bittorrent is out there and works, whereas v6 (which works) is not widely deployed...yet. But this could be solved easily with bittorrent over v6. v6 uses local scope multicast for a lot of stuff but wide area multicast requires more coordination by the service providers and has proven difficult to manage in native form. OTOH overlay multicast, like the 6bone works ok.
Slashdot Mirror
Steven's concurrence is actually a dissent in part. He goes on for 40+ pages about why business methods should not be patentable under 101, and three other justices joined Stevens. Regardless of whether he label his writing a concurrence or dissent, the opinion is split. There is a 5-4 majority opinion in favor of business method patents.
Practically speaking, this means that the Court is one vote away from making business methods non-patentable.
Software patents are still good. The court seems to unanimously agree to maintain the status quo that software methods are patentable subject matter.
Business method patents are still good, but just barely. The opinion is split 5-4 in favor of business method patents, but puts some rather vague restrictions on them (e.g., must not be abstract ideas).
My read is that the justices seem to be ok with software patents in principle but are leery of business method patents that are not tied to a device or that do not incorporate some form of technology.
They seemed to struggle with how much of a "machine" needs to be added to an abstract business method before it becomes patentable subject matter.
In other news, Roberts appears to be confused about the difference between patentable subject matter and obviousness.
The cellular providers are very wary of applications that could consume loads of precious RF bandwidth or spread viruses throughout their networks. These are very real threats that are hard to mitigate without control over the apps themselves.
The other reason is that ISPs in general are afraid of becoming "fat pipes" where they cannot differentiate themsevles from other ISPs except for having tighter operations. Tight operations requires business and technical discipline that few large organizations seem capable of attaining.
Looks like RFC 3261 on SIP could be relevant prior art. Also, FTP has been exchanging IP addresses between devices for some time in a slightly different context. Also it depends on how liberally one can interpret "point-to-point" protocol" Is it just PPP or broader than that.
Regardless, I think the asserter of this patent has a long road ahead.
This is a patent application, not an issued patent.
The application traces back to 2004, well after emoticons were in use. So there's a bit of prior art.
The application claims methods of providing / using emoticons on wireless devices. If it gets issued, the claims may be narrowed by the PTO.
Not much to see here...move along...
TCP/IP Illustrated is a classic but is out of date (CIDR anyone)?
This book is pretty good. I'll be using it to teach a class in the spring. Its not perfect but the best I've found.
They are going from code complete to commercial release in under 4 months? The final test cycle will have to be able 15 weeks. Riiiight....
Some lab ran a protocol tester against some ISAKMP implementations and found a few issues. No reason to panic as long as the vendors fix it. It is pretty common to fix these sorts of bugs it complicated protocols like ISAKMP.
Mobile Ipv6 may actually get rolled because it can reduce cost and backhaul latencies for wireless VoIP providers. MIPv4 doesn't allow route optimization, so it doesn't quite solve the problem as cleanly and required either more capex or opex to support. Whether or not this happens depends if the cost can be justified vs. router upgrades, staff training, and service outages due to new technology and misunderstandings of new technology.
Having said that I don't see a landline ISP moving to IPv6 until at least one of the following occurs:
1) Government mandate for v6
2) v6 reduces cost somehow (see above)
3) Everyone else is doing it
Its unlikely that 3G will jump the shark because the tellcos are bent on moving all voice traffic to VOIP over 3G. The current EVDO is just the first step.
EVDO uses a highspeed downlink and a low speed uplink. In fact, the uplink is the first generation of 3G CDMA, called 1xRTT, and it capped at about 144Kbps. So it you're getting 100 on the uplink that is pretty decent for wireless.
So this is not Verizon's choice, it is a limitation of the technology and equipment. The next version o EVDO will have higher uplink speeds.
I'm perfectly happy with the generic cheap-o $4.99 optical mouse I bought at the local store.
My interpretation of the claims is that the patent is fairly narrow. It's broadest claim outlines a process consisting of many steps, all of which must be performed in order for the patent to be infringed.
You have to read the clauses of the claim as logical AND statements.
Seconded. Emusic is a great service and has an awesome selection. (I'm not affiliated, blah blah blah...)
There is only one set of independent claims. Usually that means that there were other sets ruled unpatentable by the PTO, which may later find their way (in a more limited form) to a continuation patent.
I try to keep mine current, revving them after peer reviews, low level designs, test plan reviews and customer discussions. I also try to be as complete as possible, within reason, so that the outcome (i.e., what the product actually does) is predictable. A hard thing to do is maintain traceability between requirements and the resulting software and test plans, and I've not seen good tools to do so (I've seen lots of tools, but they all seem to require too much overhead).
Once I have a solid design doc for a feature that is released and dpeloyed, I turn the doc into an Interface Control Doc or incorporate it into an existing one, which is then kept current with subsequent changes.
None of this is perfect but it seems to work and is fairly low-overhead if everyone buys into the process.
The difference is that Bittorrent is out there and works, whereas v6 (which works) is not widely deployed...yet. But this could be solved easily with bittorrent over v6. v6 uses local scope multicast for a lot of stuff but wide area multicast requires more coordination by the service providers and has proven difficult to manage in native form. OTOH overlay multicast, like the 6bone works ok.
Unfortunately, this plugin seems to block a neat little wordpress feature that allows you to automatically create a blog entry with a link to a site.
http://www.faqs.org/rfcs/rfc1971.html
The claims may be more valid for IPv4 autoconfiguration where the host chooses one an address range in the 169.254/16 range.
The prior art for v6 is very strong and obviously pre-dates this application.