Slashdot Mirror
Did an Apple Engineer Invent FB Messages In 2003?
theodp writes "Q. How many Facebook engineers does it take in 2010 to duplicate a lone Apple engineer's 2003 effort? A. 15! On Nov. 15th, Facebook CEO Mark Zuckerberg introduced Facebook Messages, which uses whatever method of communication is appropriate at the time — e.g., email, IM, SMS. A day later, ex-Apple software engineer Jens Alfke was granted a patent for his 2003 invention of a Method and apparatus for processing electronic messages, which — you guessed it — employs the most appropriate messaging method — e.g., email, IM, SMS — for the job. Citing Apple's lack of passion for social software, Alfke left Apple in 2008. After a layover at Google, Alfke landed at startup Rockmelt, whose still-in-beta 'social web browser' also sports a pretty nifty communications platform."
ICQ isn't buzz compliant. Please rephrase your statement completely in terms of apple, facebook and twatter.
The Apple developer may have put forward the idea in 2003, but this same technology was a key plot point in the movie AntiTrust, which came out in 2001. And the concept wasn't new then. So, no, an Apple Engineer didn't invent the new FB messaging system, it's an old idea. FB just happens to have implemented it.
Ryan Howard already has this up and running...it's called Wuphf!
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
The main point of the patent's claims seems to be the selection of protocols based on a set of criteria. I'd wonder how many zillions of examples of "prior art" we can dig up for something that is basically keeping a list of alternative protocols/routes, and selecting one of them.
Thus, part of the "handshake" used in the venerable uucp system was a pair of messages, in which one end effectively says "I have the following protocol packages: X, Q, V1, V2, V3, R7, and C", the other end looks at the list, and send back a message saying "Let's use protocol package R7". The simplest implementation would simply pick the first name in the list that both have, but other versions would pick the fastest or cheapest or most reliable protocol.
The value of this is that it made for easy introduction of new protocols, typically when new hardware became available. Thus, when Ethernet came out, a bunch of people developed on a uucp package for it, and new releases of uucp would contain the Ethernet protocol. Whenever two ends found that they had an Ethernet route to each other, they could use it, but they could still talk to releases without Ethernet as they always had, using an older protocol. Eventually, uucp also had a TCP package, and it was fun watching uucp transfer data via TCP at speeds much faster than FTP or SMTP could. (I think this is probably no longer true, though.)
In any case, the idea of a comm-link setup routine choosing among a list of protocols (or drivers or hardware or however you like to think of it) is a lot older than the events in this story. I wouldn't be at all surprised to find such approaches that date back to the 1950s. After all, it really is something that should be obvious to any competent engineer who has even the simplest computer available to set up the connections.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
I know I don't speak for the world but I totally don't get the idea of "we'll get the message to them, somehow." I want to control the "somehow." If it's a short message that warrants interrupting whatever they're doing, I'll text. If I'm already sitting in front of a computer and a longer conversation is required, I'll IM. If it's more detailed and/or not time sensitive, I'll email, and furthermore, depending on what it is, I'll send it to their home address or their work address. Sometimes I want a conversation, sometimes I want a monologue. Not all mediums are equally good at or suitable for all types of communication.
Not every message requires an immediate response. Some messages very much don't need an immediate response. If I'm emailing someone and want them to look at something complex online, the last thing I want to do is have them get the message right this second while they're in the grocery store. I do, however, want to send it now because that's what I'm doing. If I'm on IM with someone and they're going to step away from their computer and start driving a car I very much do not want the conversation transparently shifting to SMS.
And finally, one-size-fits-all messaging becomes even less desirable as you move across time zones. It's bad enough that I work with people in another time zone and they always want to schedule "mid-morning" meetings that are actually in the middle of my lunch. I don't want my work or my friends following me everywhere I go. My life is cut up into chunks: work time, family time, friend time, me time. I like being able to enforce a little solitude and cut off any arbitrary group at any arbitrary time just based on where I am and what devices I'm near.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Steve Jobs in 1991: Somebody at IBM a few years ago saw our NextStep operating system as a potential diamond to solve their biggest and most profound problem, that of adding value to their computers with unique software. Unfortunately, as I learned, IBM is not a monolith. It is a very large place with lots of faces, and they all play musical chairs. Somewhere along the line this diamond got dropped in the mud, and now it's sitting on somebody's desk who thinks it's a dirt clod. Inside that dirt clod is still a diamond, but they don't see it.
None, since those engineers were hired by Apple, and Xerox engineers themselves have said Apple didn't rip them off. Did you know that the standard "File Edit View Window Help" menu layout originated at Apple? As did "cut-and-paste?"
Undeterred, the anonymous cabal of Apple-haters that has taken hold on Slashdot in the last six months will continue their efforts.
No he didn't. Check the assignee on the patent link.
If you're an employee of a company and you invent something within the scope of that company's business, they own it. Unless you've managed to negotiate a contract that says otherwise.
More specifically Xerox end of the deal was they opportunity to buy pre-IPO Apple stock. Something they couldn't have got otherwise. It's not theft if it's a deal - it's a transaction.
Sure, it was "a deal"; that's not the issue. That doesn't change that Apple has been wrongly claiming to have invented much of this technology, not just in their PR, but also in lawsuits. And it doesn't change the fact that Apple has a tendency to misrepresent where their ideas come from.
In fact, Apple simple doesn't have a research lab. They have good software developers, UI designers, and engineers. They get most of their idea either by copying others or by buying companies.
15! = 1,307,674,368,000. That's quite a bunch of engineers.
http://www.techdirt.com/articles/20101108/02464211754/us-patent-office-makes-it-harder-to-reject-patents-for-obviousness.shtml
Yeah, there was a big stink when that story first appeared on Slashdot, all because of people who didn't actually bother to read the USPTO guidelines. The Supreme Court described 7 tests for obviousness in KSR, back in 2006. Since then, there have been several dozen court cases. The new guidelines describe those cases to clarify the 7 tests. However, only 4 of the tests have been issues in the several dozen court cases, so in describing them, the new guidelines only talk about those 4. However, they state:
The decisions of the Federal Circuit discussed in this 2010 KSR Guidelines provide Office personnel as well as practitioners with additional examples of the law of obviousness. The purpose of the 2007 KSR Guidelines was, as stated above, to help Office personnel to determine when a claimed invention is not obvious, and to provide an appropriate supporting rationale when an obviousness rejection is appropriate. Now that a body of case law is available to guide Office personnel and practitioners as to the boundaries between obviousness and nonobviousness, it is possible in this 2010 KSR Guidelines Update to contrast situations in which the subject matter was found to have been obvious with those in which it was determined not to have been obvious. Thus, Office personnel may use this 2010 KSR Guidelines Update in conjunction with the 2007 KSR Guidelines (incorporated into MPEP 2141 and 2143) to provide a more complete view of the state of the law of obviousness.
Sheesh. Complaining that they're now not considering prior art as one of the tests of "obviousness" is like complaining that Apple isn't making laptops anymore, because you saw an ad that only shows a picture of the iPhone or iPad, regardless of the text at the bottom that discusses using an iPhone with your Apple Macbook laptop: not only are you wrong in your FUD-based interpretation, the thing you're citing says you're wrong.
When you grab a disk image or a disk in OS X, the trash can icon changes to an eject icon. I assume you're talking about OS X here, since you have joined this point with the restore button function. On OS 9 I can't remember exactly what the trashcan did when you grabbed a disk, since I tended to use the key combo for "put away" rather than using the mouse. I'd fire up the old 9600, but I can't remember where it is right now.
Plus means "bigger" so the window getting bigger seems like an accurate description of what the UI element does (maximise has never really been an Apple paradigm, so expecting it to do what it does on Windows and calling it bad UI is just a non-sequitur). A more salient criticism of that particular element, called the "restore" button is that it flips between two window states when you click it - so it can go from big to small, or small to big, all the while with a plus symbol that appears on hover. That is inconsistent/mislabelled UI and should be changed, but that's not what you were complaining about - your issue was that it got bigger when you clicked on it, and it is marked with a plus sign. I really can't see the issue here.
They are perfectly capable of putting a battery door on an mp3 player, and have given a sound engineering explanation for why they chose not to (using the extra space you save by not having a removal mechanism, battery bay, contacts, hinges and latches to increase the size of the battery itself, and to simplify the internal layout when you don;t have to consider where a battery would be inserted or removed). To simplify that down to "poor engineering because they can't figure it out" is a gross oversimplification and wilful ignorance of the design decisions behind the iPod and iPhone. You may not agree with it, but your conclusions about why they went that way just don't mesh with reality.
iTunes does need some rework. The fact that it is still a Carbon app in this day and age shows that is is hauling some cruft around with it. Not that it's worse than Cocoa, just that it has been technically deprecated by Apple themselves). I don't agree with the realignment of the window buttons - breaking Apple's own guidelines, and certain other UI elements in it.