Abstract:
An apparatus, system and method for interfacing social networking application and provider is disclosed. The present invention provides capabilities for social networking, implemented by one or more subsystems. Subsystems exist for generating inferred social value metrics; collecting participants&#39; input for the purposes of interacting with the present apparatus and respectively with other participants; data storage and layout; presentation and display of the quantities described hereinabove to a person or a computer system.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
       [0001]    This application claims priority from U.S. provisional patent application No. 61/510,270 filed Jul. 21, 2011 
     
    
     FIELD OF THE INVENTION 
       [0002]    This invention relates to techniques for enabling a social networking application to provide a user thereof with a way to access the most famous and potentially the most socially compatible and socially valuable eventual interlocutors for the not necessarily single purpose of filtering out quality content postings thereof from noise. 
       BACKGROUND OF THE INVENTION 
       [0003]    Due to their inherent nature, people need to communicate with each other, be it for personal and leisure purposes, e.g. finding a compatible mate, friend, colleague; be it for commercial purposes, whereby for example a corporation wishes to advertise itself to its potentital stakeholders. 
         [0004]    With the advent of the world wide web, social networking websites have arisen into prominence—dating sites, classmate databases, forum communities etc. However those introduce problems such as when a dating site is being browsed for potential mates, or a forum community—for quality content postings, much of the results are being noise, which is sought to be eliminated. 
         [0005]    A plurality of social networking websites have attempted to solve problems, in the most cases have failed and likewise have introduced problems of their own. In addition, the problem of finding the most famous and agreed-upon mate is difficult to solve and thus need arises for a central provider, an operator of the present invention, to solve that problem for them—for economic reasons. 
         [0006]    No prior art of this scope is known as of this moment. 
       SUMMARY 
       [0007]    The present invention provides for a social networking service a way for it to submit subject relationship data to an external provider of the present invention; to collect subjects&#39; respective degrees of famousness, social value and agreed-upon-ness for the purpose of storing them and/or displaying them to the subject itself. 
         [0008]    The extent to which a person is famous in a network may be displayed in numerical fashion, normalized or not. 
         [0009]    Additional aspects, applications and advantages are provided by the following description and associated figures. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]      FIG. 1  describes the core subject and inter-subject data structures 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0011]    Anyone with ordinary skills in computer programming and database administration should comprehend this document. 
         [0012]    The term “database” in will herein mean an abstract computer storage system, comprising one or more physical servers (or a server farm) provisioned with appropriate software packages, such as relational database management systems, nosql database systems, or whatever necessary means for storing data. 
         [0013]    “Entity” will herein mean a record in a relational database or its equivalent in non-relational or any kind of databases; with or without any of its related entities. Every definition, having a Long id field, is an entity definition, unless having a composite key. The reverse is also true. 
         [0014]    “Persist” will herein mean storing an entity into a database, via execution of the respective subroutine of that database. 
         [0015]    “Remove” will herein mean removing an entity from a database, via execution of the respective subroutine of that database. 
         [0016]    An “application” or “community” will herein mean any community software package (or a particular deployment instance thereof), client or server, related to and developed in compliance with this apparatus&#39; standard application programming interface. 
         [0017]    “Standard channel” means either of TCP/IP, OSI, RESTful or nonRESTful telecommunication channel, or any other networking standard. 
         [0018]    A social networking application (a community) uses this invention by means of a provider and its respective application programming interface. 
         [0019]      FIG. 1  describes the core subject entities. Each subject is a anyone or anything using the apparatus by means of graphical user interface, or application programming interface. Each subject may be using the apparatus via the respective community GUI, or another native interface type. Each subject may have different results generated by this apparatus in different context communities. 
         [0020]    The following description relates to the data storage and layout subsystem. 
         [0021]    For each subject in the context of a community, there is a single CommunityMembershipResult  1 . 
         [0000]    It has a communityId  1 A, memberId  1 B, result  1 C. 
         [0022]    For each vector of subjects, in the context of a community, there is a single or none CommunityPointer  2 . 
         [0000]    It has a communityId  2 A, institutorId  2 B, targetId  2 C. 
         [0023]    A directed CommunityPointer  2  can be instituted by one subject to another, via a toggle control on the latter&#39;s profile on the social networking application&#39;s GUI. 
         [0024]    A CommunityPointer  2  designates the binary willingness of the institutor to socially support the CommunityPointer target with id  2 C, pertaining to a particular community—e.g. one can support another as a dentist, but may wish not to—as a carpenter. 
         [0025]    For each subject, based on the CommunityPointer  2  graph, an eigenvector centrality measure is calculated iteratively and indefinitely until when sorted by centrality, the subjects reach monotonically increasing centrality measures at maximum of the points. Then the whole sorted set of subjects by the centrality measure is considered in a descending manner. Then for each subject, a normalized social score S can be displayed after being calculated as follows and is persisted in the database, in the form of a CommunityMembershipResult  1 :
   c=total subjects count in this community   i=the zero-based array index of the subject in the sorted set of descending centrality measures   
 
         [0000]        S= ceil[(1− i/c )*100]
 
         [0028]    The method of interfacing is hereinbelow described: 
         [0029]    The entire interfacing telecommunication is done via a standard channel. 
         [0000]    Any submit is followed by a persist.
 
This method may have multiple embodiments and its function is independent of its implementation, which can be in hardware, software, or other means.
 
         [0030]    Upon the application and provider integration, the former submits the prior asymmetric social relationship data, and thus prepopulates the CommunityPointer  2  set with respect to the given community (application). This step is done once for each community. 
         [0031]    Then the application becomes in ‘online’ state—available for public access. 
         [0032]    From now on, the application, on behalf of its users, on a current basis, submits or removes CommunityPointer  2  data. 
         [0033]    Also, on a current basis, the provider considers the set of CommunityPointer  2  data, pertaining to the community instance, after creating an empty logical graph. 
         [0000]    For each datum, the graph&#39;s vertices set is checked for containment of each of the datum&#39;s institutor ids  2 B and target ids  2 C. If negative then a graph vertex is created with that id. Finally the datum is added to the graph as an edge. 
         [0034]    Then, the S metric is calculated and persisted in the CommunityMembershipResult  1  entity for each of the graph&#39;s vertices—in the result field  1 C. 
         [0035]    Also, on a current basis, the application retrieves the CommunityMembershipResult  1 , by key of  1 A and  1 B combined, via single or bulk requests—depending on the usage context, and then eventually retransmits the result  1 C to the respective community member/user. 
         [0036]    This invention does not necessarily relate to the S metric and does not require the result field  1 C to contain instances of necessarily the S metric. Any other graph-based centrality and/or other kind of metric can be transmitted to an application via this interface, subject of the current document. 
         [0037]    In addition, data layout described hereinabove is mentioned as an example embodiment, an for illustration of the functionality of the present invention, but there may exist embodiments that implement a functionality that still fulfills the requirements of usefulness and the purpose of the present invention.