So I think you are in part correct that the simple site isn't living up to its name--it takes a lot of effort to dumb stuff down. However, when you look at the "advanced" pages you start to realize how certain material gets categorized that way: scientific words and pages with primarily people of place names.

The other problem is that it's doing it based on volume of pages. The simple site actually has relatively few number of pages in total thereby more heavily increasing the "advanced" pages.

Finally, just to be clear, it doesn't seem to be computing the percentage of content, but rather what percentage of pages (in total) fall into one or the other category.

I am a lawyer, but not your lawyer. It seems to me that order would matter.

If you assign your copyright first, then there is no GPL issue. The GPL simply wouldn't apply. The assignee (i.e., the new owner) did not need the license to use the software. And even if GPL did apply, they are under no obligation to continue distributing it and you have given up your right to do so (e.g., you sold all your rights to them).

If you make a GPL transfer first, and the assign second, you could have a copy of the software that could subsequently be transfered under the GPL. The real obvious issue is that a properly prepared assignment reps against this scenario. You are likely going to be in breach of the assignment.

I use a product X, of which is infringing upon product y, I am not liable for uses of product X. The patent system doesn't support 3rd party liability. it's just distributors buckling under legal threats.

You would be very, very wrong. Your use of an infringing product still makes you an infringer. (35 U.S.C. Sec. 271(a))("whoever without authority makes, uses, offers to sell, or sells any patented invention...). Now, there are default rules that say that a purchaser of a good is "indemnified" from claims of infringement by the seller. (See UCC Art. 2 Sec. 312) This is typically how end user avoid litigation.

In addition, you're also wrong to think that the patent system doesn't support third party liability. It does. One party's can be sued for another person's direct infringement. It's called "indirect infringement." (35 U.S.C. Sec. 271 (b) and(c)). The rules on when this apply are stated in the statute and are not always so easy to discern. One way to think about it: a party cannot escape liability by simply knowing moving the infringement downstream.

And, just so that you know, it is a somewhat common strategy that a patent owner sues the end user, direct infringer. There is nothing worse as a supplier than receiving about 30 letters from angry customers seeking indemnification from the infringement suit. This is a great technique to annoy the party with deep pockets and drive home the advantages of settling early.

Huh? US Patents don't last 28 years. New patents have a term of 20 years from the earliest filing date. Patents filed before June 8, 1995 have a term that is the longer of (i) 20 years from the earliest filing date; or (ii) 17 years from the date of issue.

Sort of? If you mean the lower court by "the court," the answer is largely no it is not precedent because the lower court's rulings were overturned on appeal.

However, the settlement came after an appeal to the Federal Circuit. The appeal resulted in a vacated judgment and the case was remanded to the lower court. The opinion of the appellate case, found here, will be precedential and binding on all federal courts. This settlement ends the "further proceedings" part of the case. As a result, there is no final decision by the court, but there is a final appellate decision.

No offense, but you clearly didn't RTFP. In order to be good prior art (anticipating art), the relevant art must include all of the elements of a claim. You can make an obviousness argument if you can find all of the elements in two or more references. To help you out, I've broken down the first independent claim into manageable pieces. You'll quickly notice that neither of your examples are even close:

1. A system for providing financial information about a target entity in response to a user request, comprising:

[ ]one or more computers configured to provide a user interface including:

[ ] a main chart for showing a graph of financial data over

        [ ] a first time period;

[ ] a second chart displayed concurrently with the main chart, and

        [ ] for showing a graph of financial data over a second time period that

        [ ] includes the first time period; and

[ ] a user-adjustable viewing window displayed on the second chart,

[ ] wherein the first time period of the main chart is defined by placement of the user-adjustable viewing window on the second chart.

IAAL. I work with technology contracts. I think that the only reason a lawyer will be scratching his head is because of the genuine unlikelihood that the customer could actually prove a fraud case against a vendor. That's not to say it's impossible, just so unlikely. What's clear is that this was not a contract case. If it was merely a contract case, it would have looked to the four corners of the agreement. The plaintiffs (the customer) had to work extra hard (i.e., $40M in legal fees hard) to prove the fraud.

Customer-clients regularly come to me with contracts that have:
1. no objective criteria to measure success/failure
2. all of the liability for delays, failure to perform, etc. allocated to the Customer
3. do not have sufficient input from the technical people that will actually be working on the project.
4. no contractual remedies for failure.
5. no change management process.

Point #1 is the most important. In this case, if there were objective criteria to measure success, then the breach of contract case is simple to prove. It is like engaging in the design/plan phase of development before you even sign the contract. If a customer can't figure out what objective criteria it needs, it's probably not a good time to enter a $40M contract. Take for example, the objective criteria that the EDS software will meet the minimum process per second with 150 active users. Easy, does it do? If not, see points 2 and 4.

Point #2 is often overlooked. Customers regularly sign contracts that permit a vendor to deliver something non-conforming on the delivery date and not be in breach. The contracts are also usually written so that the additional time spent correcting the non-conforming deliverables are paid by the Customer. These are usually sneakily inserted under the "right to cure" a breach provision. At some point, the vendor (not the customer) should be paying.

Point #3 is necessary in order to establish point #1 and point #2. Management has this idea: oh we need ___ system. Let's find a vendor of ___ system. However, it is the technical people that need to set the objective criteria and then be able to test that it was met.

Point #4 is the stick with which you beat the Vendor into meeting those requirements. Every customer should be asking, "what happens if they don't deliver?" I say, "show me the money." Of course, you can customize however you see fit. Customers however don't usually ask.

Finally, point #5 is so painful its hard to write about. A lot of time and money is lost because the customer does not have a good internal change management process. In addition, the customer does not put that change management process in writing with the vendor. Any change management process should be coordinated through a project manager. The process should require 1. estimates of cost and 2. affect on time line. These should require signature of someone higher up the chain than the project manager if there is a big impact on price or time--what constitutes a "big impact" should be spelled out (e.g., more than $10,000 or more than a 1 week).

As a last tidbit: technology people need to STOP SIGNING AGREEMENTS WITHOUT A REAL LEGAL REVIEW. This includes the stupid little EULAs that you click ok to. That includes the purchase of off the shelf software. That includes signing up a third party for professional services. Those words mean things. Spending $1-3K now saves a boat load on the backend.

At the outset, it can be true. This can and does happen: mickey mouse, indiana jones, james bond, sherlock holmes, etc. But that doesn't make much difference. You can have lots of people using the same trademark. The easiest example, think Delta (faucet, airline, dental, etc.).

The problem, as I see it, with the case at issue:
1. Few people (or no one) would think that the author, publisher or estate would make the association with the Nexus One.

2. The book and the Nexus-One operate in entirely different markets.

There is no likelihood of confusion, there is no issue.

There's no inconsistency. If you are the first to apply for a FEDERAL trademark but there are other users of the mark, your FEDERAL rights may be restricted, canceled, or otherwise narrowed.

You can apply for a Federal mark if you use or intend to use a mark in inter-state commerce (i.e., in more than one state). Otherwise you are limited to common law rights OR state rights.

You get trademark (or service mark) rights simply by using a mark to identify the source of a product in commerce; no registration is required. However, the scope of your rights will be limited to the territory in which you had actual use. For instance, if you have a Pizza shop (pizza analogy guy where are you?) in California under the name, "Cheezy Mushroom" or something, you would automatically start accruing rights in that mark the moment you started selling pizza. Your right to prevent other Cheezy Mushroom pizzas is limited by your geographic reach. This is called a COMMON LAW trademark.

If you started selling out of California, presto, you can apply for Federal protection and get Federal rights that gives you protection throughout the country.

Patents will be the death of innovation if the system continues in this way, particularly if the US judgements are assessed at insane levels of cost. If Microsoft had known about this patent when starting the development they'd have bought the company for less than this judgement.

Uh, they did know: http://blog.seattlepi.com/microsoft/archives/178682.asp

Back in 2001, two companies now locked in a nasty legal battle were working together to develop software for the U.S. government. Microsoft Corp. needed a third-party developer, i4i Inc., to incorporate custom XML functionality into Word.

Well, on the one hand, the patent gives i4i the right to exclude others from practicing the claimed invention. The court has already told MS that Word is infringing, therefore selling Word would violate the patent rights. MS could simply removing the infringing feature and it could continue selling Word. MS is in control of this aspect.

On the other hand, at the moment, i4i has very little incentive to offer MS any sort of license. i4i won at the lower court and on appeal. Plus, I believe the story goes that they approached MS and MS sent them away and then went ahead and implemented it anyway. They will be able to demand infringement-sized royalties the closer it gets to January 11.

I would have far less of a problem with software patents if they actually disclosed fully functional source code with the patent

Some patents do include source code. But the law has pretty much made this non-essential. This has happened for the same reason that most electronic patents no longer include the diagrams with elaborate gating, switches, etc. Courts and the PTO have more or less made the enablement requirement assume that one of ordinary skill (including reasonably skilled programmers) could put together the source code if given the high level steps. You don't need the source code if you know the steps.

In addition, source code has a serious flaw: not all source code is created the same. It would be of little help if the source code is obfuscated, in a language few remember of know (my favorite that comes up from time to time in MHR is MIIS), or if certain functions relevant to the invention are taken out of context of the rest of the system. Filing 1000+ pages of source code is not going to make the system better. It will probably make it worse.