Peer to Patent, Community Patent Review

APPLICATION LIST|ARCHIVED APPLICATIONS|US PATENT CLASSIFICATIONS

Home > Archived Applications > 20080059576 > Discussion

Pre-Grant Publication Number: 20080059576

Recommending contacts in a social network

Collaborate on the process of community review for this application. Posting will not be forwarded to the USPTO. Flagging a post as an ACTION ITEM signals further research. Flagging SPAM and ABUSE helps to manage discussion. Placing double brackets around a reference to a claim or prior art will create a hyperlink to the original ex. [[claim 1]] and [[prior art 2]].

Please review the Community Code of Conduct prior to posting

Discussion (11)

View: Date|Claims|Prior Art|Action Item|

Facilitator's Comment

Action Item

Show without Noise

Claude Baudoin (4 months ago)

Regarding Claim 00014, I don't get the silliness of specifying one particular hard number (6). Why not add 98 dependent claims with all numbers between 3 and 100? Does it mean that the author is sure that using 5 or 7 would be so less efficient than 6 that no one will want to implement it, so they don't need to be bothered protecting cases other than 6? Strange...

Claude Baudoin (4 months ago)

Regarding Claim 00010, I suspect, without having researched the details, that this is a classical problem in graph theory, which is a domain of mathematics (non-patentable) that has been explored decades ago and on which there was, at the time, abundant literature in "Communications of the ACM" and similar publications. A second point is that the method described does not avoid tying yourself up in knots recursively -- it fails to mention that when you go from A to its direct contacts, and then from those contacts to *their* contacts, you need to exclude A from the results list to avoid doing a lot of useless work.

Claude Baudoin (4 months ago)

Regarding Claim 00005, it is a trivial variant on Claim 00004, and in fact it is provably useless. The next claim implies that all that matters is that longer paths are rated less than shorter paths, so it is irrelevant which monotonically decreasing function of the length is chosen!

Claude Baudoin (4 months ago)

Regarding Claim 00002, first I don't see what it adds to Claim 1, and then this is the claim that is most trivially invalidated by existing social networks implementations, such as those in LinkedIn, Facebook (see Luis Benitez's comment). I think this also fails the "non-obvious" test.

Claude Baudoin (4 months ago)

Regarding Claim 00001, several parts of this claim should be invalidated by prior art, such as the LinkedIn professional network service, www.linkedin.com, which is based on an explicit declaration of each person's contacts (undoubtedly stored in a database) combined with (b) calculating the length of the various paths and the shortest path from A to B, and (c) a mechanism to forward contact requests from A to B through a selected path, so that A can contact B, if the intermediaries accept to forward the request, without the system disclosing to A any direct contact information for B.

Luis Benitez (4 months ago)

Are they trying to Patent the "People You May Know" feature of Facebook? I would have thought Facebook would've had a patent on this already. Additionally, as Reynout mentioned, Atlas has been used within our company for several years now. It works by analyzing my social data, contacts, chats, emails, etc, just as described in the Background section of this application. Doesn't seem like there's anything new here.

Reynout van Adrichem Boogaert (4 months ago)

IBM has social software called Lotus Connections. One of the components is called Atlas.
It has been running internally under the name Small Blue for several years. It also shows recommended path information based on buddy list, community membership and other information.

Kid Stevens (4 months ago)

Regarding Claim 00010 I personally have written several databases that do this. I see no new idea here and no real patentable idea. SQL databases do the gathering of contacts on a routine basis. Front end Databases then massage the data according to the users criteria pre programmed or criteria that can be modified on the fly. I vote no on another waste of paper and storage that already infringes on other non patented ideas.

Michael Sawchyn (6 months ago)

This idea is already being partially implemented on several applications. As mentioned, Facebook, Myspace, Vizster, and Google have all very similar ideas that would be affected by the patent if it is granted. The patent itself covers such a wide range of ideas and it is vague in implementation, therefore seeming to want to patent something that is already out there. Also, the weaknesses in the patent are strong enough that there would need to be revisions and clarifications before we recommend that this idea receive a patent. If it was made more specific and given limitations, and also if details were provided as to how it would be implemented and sustained, the idea would deserve another review.

Rebecca Richards (6 months ago)

With the growing popularity of social networks for both personal and professional use it is important to be able to sort and categorize contacts to determine viability of potential contacts. The claims made appear different enough from the substance to exsisting products by Vizster and internal to facebook. The substantive difference mainly focus on how the potential contacts are gathered. By adapting where information is selected from as well as being able to individually set the degree of seperation used to draw contact information this application indicates a new level of automation and awareness creating a new dynamic in recommending contacts for expanding a social network.

David Kumhyr (7 months ago)

Regarding Claim 00001 This seems quite like the "vizster" social networking demonstration of the Prefuse visualization toolkit by Jeffrey Heer. Located here: http://jheer.org/vizster/

It has a data store (a sql database) containing contact lists of users, a component that identifies from the data store contact paths and lengths of path, methods of ranking and filtering contacts (nodes) from the list. The one piece lacking is presenting a near node as a contact, though that would be obvious when looking at the connection visualization presented.

0 days left