Pre-Grant Publication Number: 20080059576
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)
  Facilitator's Comment     Action Item
  Show without Noise
CLAIM 00001

<claim-text> A system for recommending potential contacts for a target user, comprising:<claim-text>a data store containing contact lists of users, including a contact list for the target user;</claim-text><claim-text>a component that identifies, from the contact lists, contact paths from the target user to other users that are within a maximum contact path length;</claim-text><claim-text>a component that ranks users on the identified contact paths based on path lengths of the contact paths;</claim-text><claim-text>a component that filters out users on the identified contact paths who do not satisfy a recommendation criterion; and</claim-text><claim-text>a component that presents to the target user an indication of the ranking of the non-filtered-out users as recommendations for potential contacts.</claim-text></claim-text>

Comments
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.
more...
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. more...

CLAIM 00002

<claim-text> The system of <claim-ref idref='CLM-00001'>claim 1</claim-ref> wherein the component that identifies contact paths traverses a social network formed by the contact lists starting at the contact list of the target user.</claim-text>

Comments
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. more...

CLAIM 00005

<claim-text> The system of <claim-ref idref='CLM-00003'>claim 3</claim-ref> wherein the path score for a contact path decreases exponentially as the path length of the contact path increases.</claim-text>

Comments
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! more...

CLAIM 00010

<claim-text> A system for identifying a social path between a first user and a second user, the social path being within a maximum social path length, comprising:<claim-text>a data store containing contact lists of users, including a contact list for the first user and a contact list for the second user;</claim-text><claim-text>a component that identifies, from the contact lists, contact paths from the first user to other users that are within a first maximum contact path length and contact paths from the second user to other users that are within a second maximum contact path length, wherein the sum of the first maximum contact path length and the second maximum contact path length equals the maximum social path length; and</claim-text><claim-text>a component that, when there is a contact path from the first user to another user and a contact path from the second user to that same other user, indicates that a social path exists from the first user to the second user.</claim-text></claim-text>

Comments
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. more...
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. more...

CLAIM 00014

<claim-text> The system of <claim-ref idref='CLM-00010'>claim 10</claim-ref> wherein the maximum social path length is six.</claim-text>

Comments
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... more...