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."
How many Apple engineers does it take to duplicate a PARC engineer's effort?
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.
The web browser which solves this problem? And I quote Daring Fireball since I agree:
"They solved the problem of Chrome having a nice, simple, minimalist interface."
I have to wonder how much RM *really* do for the user, compared to Chrome with various Facebook extensions.
Beware: In C++, your friends can see your privates!
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.
I have genius ideas around 3 times a day. Nobody gives a damn, ideas are plenty everywhere.
Are we really going to start nitpicking that someone had the idea of one or the other successful product someone else made successful?
Facebook did something people enjoy and long for with it. Good for them. The guy that thought of it first obviously failed with that for about 7 years.
I know, it's just random trolling on the front page, but it irks me.
Disclaimer: I don't have a Facebook account, nor am I very found of them. I don't own an Apple device or product either.
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.
You seem to have left out one-button mice and homosexuality in your tired Apple troll, anonymous coward.
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.
Are you out of your mind?
Visual Age Smalltalk never went anywhere and never provided anything like NeXTstep/Openstep/Cocoa
http://www-01.ibm.com/software/awdtools/smalltalk/
NeXT's UI was very innovative and was widely and poorly copied by Windows 95 and CDE.
Objective-C is a cross between Smalltalk and ANSI C and was created to enable smalltalk style object oriented programming while preserving compatibility with millions of lines of C code. I argue that more people are programming today with the smalltalk part of Objective-C than ever programmed with smalltalk directly. That is exactly because of the C compatibility.
Mach was created at Carnegie Mellon and achieved wide success including as the basis of the Open Software Foundation (OSF 1) http://en.wikipedia.org/wiki/Open_Software_Foundation. One of the creators of Mach, Avie Tevanian, retired from Apple as executive VP for software after having previously been an executive at NeXT. You would criticize NeXT for adopting a widely supported open operating system foundation?
Display Postscript delivered a WYSIWYG get 2D graphics system with bezier paths, alpha transparency, floating point coordinate system, network transparent client server architecture, etc. at a time when both Mac and Windows used 16 bit integer coordinates and 256 color palette modes. Furthermore, Display Postscript was also used by Sun Microsystems' NeWS in 1986.
NeXT were brilliant at selecting the right technologies to integrate into a system. Mach, BSD Unix, Display Postscript, Objective-C, the precursor to Cocoa frameworks, ... It was and remains a dream come true software development environment.
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.
You would criticize NeXT for adopting a widely supported open operating system foundation?
I didn't "criticize" NeXT for adopting any of these technologies. I pointed out that most of them didn't come from NeXT to begin with. If IBM had wanted those technologies, it could have gotten them elsewhere, but they actually had better technologies.
Visual Age Smalltalk never went anywhere and never provided anything like NeXTstep/Openstep/Cocoa
VisualAge Smalltalk did something much better: it gave people a good environment to develop custom apps that actually ran on Windows. It always remained a niche player, but so did NeXT. IBM then switched to Java and has been spectacularly successful with it in the corporate market.
NeXT were brilliant at selecting the right technologies to integrate into a system. Mach, BSD Unix, Display Postscript, Objective-C, the precursor to Cocoa frameworks, ... It was and remains a dream come true software development environment.
NeXT was a failing company when Apple bought them; IBM betting on them would have been madness and IBM would have gotten screwed.
And NeXT didn't select "the right technologies" at all. DisplayPostscript was a total failure, not just at NeXT, but also at IBM and Sun (all of which tried it); Apple got rid of it. Objective-C never caught on as a mainstream language until Apple shoved it down their developers' throats. Mach's microkernel approach was an architectural disaster and Apple just rewrote it and turned it into a monolithic kernel.
Are you out of your mind?
No, I just know what's going on, unlike you apparently.
When I was designing the CAKE protocol [cakem.net] in 2003 I already had the idea of doing this. It was 'Key Addressed Crypto Encapsulation' for a reason. The idea was to choose whichever transport method was handy for the message.
A friend's interest has got me working on this again. Hopefully I can get a working system together soon so other people can play with it.
Need a Python, C++, Unix, Linux develop