I agree with this. Average starting salaries for a PhD in CS will be higher than for a PhD in biology. This could matter during salary negotiation.

For BS and MS degrees, the name of the university is important, because there is generally no guarantee that you spent significant time with a faculty member. For a PhD, the name of your thesis adviser takes precedence over the name of the university, especially if the adviser has a respected name in the field. For these reasons, I would opt for the CS degree from the (lesser known?) European university rather than the Biology degree from the American Ivy League university.

The patent application didn't publish until Jul 13, 2006, four months before the release of the Wii to the public on Nov. 19, 2006. Nintendo would not have known about the patent application until after the publish date. (The original filing date is for the provisional patent, which is secret). The design of the Wii controller would have been locked down long before that, because developers need to have games ready at launch. According to Wikipedia, Nintendo settled on the controller design in 2005, though the design was not announced to the public. This timeline makes it seem possible that ThinkOptic submitted their provisional patent application when they heard rumors that Nintendo would use similar technology. (There was certainly a lot of speculation in 2005 about the novel controller that Nintendo was going to release.)

Note that this is a United States patent case. Under US patent law (unlike international patent law), patent rights are assigned by first to invent, not first to file. This means the case depends on how long Nintendo and ThinkOptic were working on the devices before filing. This makes for really messy patent fights. I'm really surprised that Nintendo wouldn't have previous patents related to this technology. Then again, they probably do, but those patents aren't mentioned in the article, which is written from the ThinkOptic perspective without a response from Nintendo.

I think you've correctly identified most of the requirements
1) requires minimal training
2) secure and reliable
3) provides point to point connection with verifiable delivery
To which I'd add:
4) backwards compatible with fax
Since everyone in an industry is not going to switch from fax at once, it'd be best if the same device could be used for remote document delivery, whether it be over fax or IP. It seems like there could be an opportunity for a combination of an internet service and firmware to be licensed by scanner/fax OEMs. The scanner/fax/printer would be plugged into both network and phone line (or perhaps use a a VOIP connection through some service, so then just plugged into network). You would enter the phone number or Machine ID you want to send your document to. If it's a phone number, the document is routed over the phone line (or VOIP) as a tradition fax. If it's a Machine ID, it contacts the central server of the internet service, which tracks machines using unique static registered IDs. If the requested machine is available to receive, then the server provides a tunnel from one machine to the other (machine makes outbound connections to the server to get around firewall issues). All data on the network between the two machines would be encrypted. The received document could be immediately printed (if the machine includes a printer) or logged as a pdf file. (There could be several options for getting the pdf to somewhere useful. e.g. machine could appear as a network drive, could locally email the document, or could allow it to be copied to a usb thumb drive.) The server could provide receipt confirmation. The advantage over traditional fax would be that a separate phone line would not be needed, and much high quality scans could be transmitted as fast as you can scan them (in color even). A disadvantage is that the internet service knows who is faxing whom (though wouldn't be able to decrypt what was faxed), which might raise privacy concerns. This all seems very feasible. The tricky part would be getting buy-in from the OEMs.

I've used both systems for small, medium, and large documents as well. For documents that are written by large numbers of authors in short amounts of time (like grant proposals), I like Word with Track Changes. I find the visual display of changes in the formatted document focuses attention and speeds up the writing process. I'm fine with non-WYSIWYG editing in general, but the visualization of changes is just really effective.

I know how to return clicks from xdvi and yap to an editor. But it's the coauthors' edits that I'm interested in, not just finding my place in the source file or identifying who wrote a particular line.

I've used versioning systems with latex documents as a single author as well as with coauthors. It worked great as a way to keep a centrally located authoritative version of the document. One thing I didn't like was that versioning systems often pay attention to whitespace, so trivial changes in the line wraps would be reported as large changes in the document. (This was with CVS. Perhaps newer systems understand text better.)

With latex documents for which someone else is the primary author, I often end up writing comments on a printout, scanning, and returning. This generally ends up being a better use of my time than trying to teach a coauthor (often not a programmer) about versioning systems.

The real magic of Word's Track Changes feature is the way it allows you to quickly see what's been changed and commented on in the *formatted* document. Marginal comments and changes pop out visually when you scroll through the document, and the displayed comments can be filtered based on the user who wrote them. This is an especially nice feature for giving feedback to the main author on collaborative writing projects. I can imagine a Latex package that would allow you to place comments in the margin with an arrow to some highlighted text with coloration based on, say, a username embedded in a field of the comment. A flag could optionally suppress the comments in the compiled document (so that the comments don't *have* to be removed.) If such a package existed, it would go a long way toward matching track changes (when combined with a versioning system). To my knowledge, there is nothing quite like this for latex at the moment?

Manufacturing is not R&D, but the employees at a $4billion semiconductor fab are not exactly low wage labor. A lot of highly skilled engineers are employed in manufacturing, especially high tech manufacturing. There are efficiencies to be gained by co-locating R&D and manufacturing, since they motivate one another, e.g. atomic force microscopy was developed at IBM to analyze flaws that were too small to resolve with SEM in chips coming off the line.

The separation between US R&D and China manufacturing persists because more of the qualified R&D workforce prefer to live in the US than in China. That won't necessarily always be the case.

I recommend reading the book "Getting to Yes". It's a fluffy business book, but by far the most useful such book that I've ever read. It presents a very nice way of understanding and approaching the process of negotiation. Basically it comes down to 1) identifying your personal interests and the mutual interests that you share with the negotiating party and 2) identifying your "Best Alternative to Fairly Negotiated Agreement (BAFNA), i.e. what your fallback plan is if the negotiation falls through. The negotiation process starts with a discussion of the various interests and possible arrangements that can satisfy the interests, while avoiding positional bargaining (I want this much. You can have this much. No, I want at least this much...) The strength of your negotiating position depends on the attractiveness of your BAFNA, (and the strength of the other party depends on their BAFNA). This may all sound like plain old common sense, but I find that this framework helps structure my thoughts and approach to negotiating, leading to more success and less pain...

Galois was significantly earlier than the study of symmetry of molecules.

If Chrome is suddently twice as fast on Google websites then all other browsers, then gives the combination of Chrome+Google websites a huge advantage.

Because the big bottleneck on the web is the time spent waiting for search results?

In the current corn process, you grow a whole stalk of corn, take off the ear, shell and mill the grains, break the starches down to sugar and then ferment. A lot of energy went into growing an 8ft tall, rigid plant, but you only take energy from the grain. In comparison, converting cellulose directly to a usable fuel could yield much more energy from a given plant. The plant body is very high in cellulose, giving it a rigid structure. Even for corn, there is more energy stored in the stalk than in the ear, but previous processes for converting cellulose to a usable fuel are too energy inefficient, using up more energy in processing than you get out in fuel. The goal of the recent biofuel research is to find an energy-cheap conversion from cellulose to fuel. That would improve the overall energy balance (energy in the fuel minus all energy used to produce the fuel) for biofuels. The more net positive this balance is, the more benefit from biofuels. Moreover, hardier crops such as switchgrass and sorghum could be grown for cellulose. These crops can be grown on poorer land with less fertilizer and less care and easier harvesting.