'portable personal terminal for use in a system for handling transactions'
I kind of agree that the case will boil down to this statement, but not because it's too vague. Since patents are granted only for specific solutions to specific problems (at least in theory), it's likely that the courts will find that PDAs are not covered by this patent. The patents clearly identify handling financial transactions as what the cliamed device does. PDAs are not devices for handling financial transactions, but rather, general purpose computers, so the the patent should not apply.
For example, if you had a patent on a hammer (a deviced for banging in nails), and I produce general purpose borg cubes of cast iron which may be used for many things, including banging in nails, I have not violated your patent.
But then again, I'm no lawyer.
Why would a battlebot type mobot (as opposed to robot) need an OS? Call me old-fashioned, but I think a microprocessor based control system for something that's essentially a fancy remote controlled car is serious overkill. This is right up there with M$ wanting your toaster to run Windows CE!!
Now the right:) way to do it would be to give each part of the bot a simpler controller (ROM-register, or even analog design). For example, the chainsaw system would be independent of the propulsion system. Advantages would be:
No central 'brain' to take out. Chainsaw would still be useful if the bot was sitting in one place because the propulsion got smashed.
Simple controllers would be robust and allow redundancy.
Greatly reduced power requirements. This means power could be redirected to lugging around heavier arms and armor.
Cheaper. This means money could be redirected to bigger and better arms and armor.
This may allow the use of the coolest anti-bot weapon of them all: EMP. Crack the armor, pulse, and your opponent is disabled, or at least reset. Since your simple analog designs are basically EMP-proof, and simpler digital designs are easier to shield if they need it, you come out on top.
The only disadvantage I can see is:
Need to know how to design closer to the hardware. We're talking about circuit design and control theory as opposed to C programming. EE background as opposed to CS background.
Come to think of it, this would be a cool way to design a real robot, too.
Most of the responses so far seem to have assumed that "IT professional" and "programmer" can be used interchangably. While I don't pretend to know anything about shortages of programmers and CS majors, I do know that my PhD program is full of foreign students. For example, we currently don't have a single US citizen in my research group of about ten to fifteen CS/EE PhD students. This despite the fact that we try very hard to recruit Americans, since funding them is easier. I wouldn't be surprised if over 80% of the PhD's in my field (speech recognition) graduating in the US were foreign.
The US has a long tradition of stealing the best and the brightest from other countries. After all, it's way cheaper for the US taxpayer to have its highly skilled labor trained by the Indian government... If America's goal is to continue this tradition, while making sure that companies don't abuse the H1B mechanism, the INS would have to be given funding to properly screen IT H1B applications. If the goal is to fill IT research positions with Americans exclusively, the schools need to make their sweatshops, I mean PhD programs more attractive to US students.
Or mount a few mic's on the steering wheel and dashboard, and then beamform to pickup only the sound coming from where the driver's head is supposed to be. This would eliminate a bunch of the engine noise too.
Most recognizers DO know the difference between, asay, 'The Maple Leafs scored in the first period of the playoff.' and 'I like hockey PERIOD' (where PERIOD is '.') Once slashdot is in the recognizer's vocabulary, and it has seen it a few times to be able to tell what context it occurs in, it will learn the difference.
Likewise with non-native speech. It's mainly a case of collecting enough training data. I've seen reasonably good research systems that work with Spanish-accented and Chinese-accented English.
How about a phone interface to a desktop computer? I'd like to be able to access both my calendar and email which sit at my desk at work. Forwarding email to a GSM phone just isn't a good solution. For example: Me: New mail? Computer: New mail from John, Fred, and Scott Me: What does Scott say? Computer: Me: Set up appointment with Scott at 4:00pm today. Computer: OK Me: email to scott Computer: go ahead. Me: Scott, I can meet you at 4. send this. Computer: ok This is doable, and IMHO, useful.
Actually, the formula accounts for noise, so actual rate does not get worse when noise is PRESENT. Rather, it gets worse because the spectral and statistical characteristics of actual noise is different from noise models used during system design.
Despite the Librarian's comments, the Library of Congress is a sponsor of the National Science Foundation's Digital Libraries Project. Although the project doesn't attempt to provide all of LOC digitally, it does attempt to address the technological issues of a Stephensonesque `library.' Currently, this is done mainly through providing small online libraries on special topics. It's pretty cool, since it doesn't limit itself to text.
Slashdot Mirror
I kind of agree that the case will boil down to this statement, but not because it's too vague. Since patents are granted only for specific solutions to specific problems (at least in theory), it's likely that the courts will find that PDAs are not covered by this patent. The patents clearly identify handling financial transactions as what the cliamed device does. PDAs are not devices for handling financial transactions, but rather, general purpose computers, so the the patent should not apply.
For example, if you had a patent on a hammer (a deviced for banging in nails), and I produce general purpose borg cubes of cast iron which may be used for many things, including banging in nails, I have not violated your patent. But then again, I'm no lawyer.
Now the right :) way to do it would be to give each part of the bot a simpler controller (ROM-register, or even analog design). For example, the chainsaw system would be independent of the propulsion system. Advantages would be:
- No central 'brain' to take out. Chainsaw would still be useful if the bot was sitting in one place because the propulsion got smashed.
- Simple controllers would be robust and allow redundancy.
- Greatly reduced power requirements. This means power could be redirected to lugging around heavier arms and armor.
- Cheaper. This means money could be redirected to bigger and better arms and armor.
- This may allow the use of the coolest anti-bot weapon of them all: EMP. Crack the armor, pulse, and your opponent is disabled, or at least reset. Since your simple analog designs are basically EMP-proof, and simpler digital designs are easier to shield if they need it, you come out on top.
The only disadvantage I can see is:- Need to know how to design closer to the hardware. We're talking about circuit design and control theory as opposed to C programming. EE background as opposed to CS background.
Come to think of it, this would be a cool way to design a real robot, too.The US has a long tradition of stealing the best and the brightest from other countries. After all, it's way cheaper for the US taxpayer to have its highly skilled labor trained by the Indian government... If America's goal is to continue this tradition, while making sure that companies don't abuse the H1B mechanism, the INS would have to be given funding to properly screen IT H1B applications. If the goal is to fill IT research positions with Americans exclusively, the schools need to make their sweatshops, I mean PhD programs more attractive to US students.
Or mount a few mic's on the steering wheel and dashboard, and then beamform to pickup only the sound coming from where the driver's head is supposed to be. This would eliminate a bunch of the engine noise too.
Likewise with non-native speech. It's mainly a case of collecting enough training data. I've seen reasonably good research systems that work with Spanish-accented and Chinese-accented English.
How about a phone interface to a desktop computer? I'd like to be able to access both my calendar and email which sit at my desk at work. Forwarding email to a GSM phone just isn't a good solution. For example: Me: New mail? Computer: New mail from John, Fred, and Scott Me: What does Scott say? Computer: Me: Set up appointment with Scott at 4:00pm today. Computer: OK Me: email to scott Computer: go ahead. Me: Scott, I can meet you at 4. send this. Computer: ok This is doable, and IMHO, useful.
grammar nazi sez: I still believe that humans make analog thoughts, even if our brain is just one big circuit. Can I use our brain tonight?
Actually, the formula accounts for noise, so actual rate does not get worse when noise is PRESENT. Rather, it gets worse because the spectral and statistical characteristics of actual noise is different from noise models used during system design.
Despite the Librarian's comments, the Library of Congress is a sponsor of the National Science Foundation's Digital Libraries Project. Although the project doesn't attempt to provide all of LOC digitally, it does attempt to address the technological issues of a Stephensonesque `library.' Currently, this is done mainly through providing small online libraries on special topics. It's pretty cool, since it doesn't limit itself to text.