Remember that patents consist of several claims, some dependent on others. I believe the court can reaffirm or mark invalid each claim individually (as the examiner does when issuing a patent), such that the "broad" claims are "killed" but the dependent claims remain. When reading a patent, you you notice the claims start at the most general and work their way up to the most complex. When attempting to see what "reads" against a patent, you need to pay attention to all claims in the patent.
http://en.wikipedia.org/wiki/Claim_(patent) <http://en.wikipedia.org/wiki/Claim_(patent)>My wife works at the patent office, so patent law is rather intriguing to me. In any case I must refrain from any statement other than pointing folks to the facts. - Josh On Mon, Aug 16, 2010 at 11:49 AM, Reinier Zwitserloot <reini...@gmail.com>wrote: > If folks would rather keep discussion to the existing threads, let me > know. > > Here's a post by a JRuby engineer about the actual meat of the 7 > patents Oracle is suing Google with. He basically concludes that > Oracle doesn't have a leg to stand on, but that this doesn't > necessarily mean that google will simply go to court and win the case: > > http://blog.headius.com/2010/08/my-thoughts-on-oracle-v-google.html > > One of Gosling's own is in there, as well as a patent or two that do > not seem to apply. One is a patent that seems to apply only insofar > that android is based on linux and linux uses forking to spawn new > processes. The patent was filed in 2003, which means that either (A) a > judge rules this isn't quite that all-encompassing, or (B) he does, in > which case it'll be thrown out immediately for prior art. A second one > involves mixed mode VMs which is probably the most meaty patent in the > set, but its just not something android actually does. > > The remaining 5 seems as ridiculous as one-click, but, you know, its > the US patent system. Reason and Sanity have no place there. Example: > Compressing many small files not on a file-by-file basis but by > looking at all of them. The only reason this won't be thrown out based > on prior art (tar cvfz anyone?) on day 1 is that it makes explicit > references to class files, i.e. executable code. In fact, this one is > IMO the scariest of all of them, but that's mostly a comment on how > weak the other 6 are. > > NB: His opinion that the nuclear option can't happen does not mention > that Ellison and Jobs are big friends, but nevertheless, killing > android, severely harming java-the-language in the process? Did Jobs > save ellison's life 5 times over or something? So, yeah, that remains > unlikely. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
