The present invention relates to an interactive peer directory implemented on a digital computer. The directory provides for the online location of peers with expertise in a particular business or endeavor. Once qualified peers are located, connections to such peers can be requested for project, product and implementation advice and the like.
Various tools for arranging business introductions are known in the art. For example, J. Greenfield U.S. Patent Publication No. 2009/0018851 discloses a network that uses registration information of multiple parties along with a matching function to match two parties that have a business contact that both parties would benefit from if the parties were introduced. Procedures are provided to notify the parties of a potential match, and to facilitate communication between the parties if the introduction is accepted by the parties.
U.S. Pat. No. 7,454,433 to Ebert discloses a system for providing adaptive virtual communities. By determining a technical or business context of a particular user, the system is able to match that user with other users who are likely to be able to assist the user within that context.
U.S. Pat. No. 7,035,838 to Nelson et al. discloses methods and systems for organizing information stored within a computer network-based system. Documentation relating to a plurality of topics and a list of experts on a plurality of topics is stored in a centralized database. A user interface enables a user to search the database for a specific item of information by at least one of a work function, a functional category and a community.
Prior art systems, such as those referenced above, generally provide too many potential matches between a requester and available contacts. The requester will then have to sort through these many potential matches to attempt to find a match that will be most relevant. Such systems can waste the requester's time and may not result in the best match being found, since the requester may settle for a less relevant match instead of carefully considering each of the many potential matches presented. Moreover, once a match is selected by a requester, the individual associated with that match may not respond to a request by the requester to communicate. This can waste more time, as the requester may wait several days to hear back from the match, only to find that no response is ever received. The requester will then have to find another match, with no assurance that the individual associated with the new match will be likely to respond to a request to communicate.
It would be advantageous to provide improved apparatus and methods for searching for peers that can assist a user that requests a match (the “requester”) in solving a business or technical problem. It would be further advantageous if such apparatus and methods would provide more relevant matches to the requester, to increase the likelihood that a helpful peer will be more quickly and efficiently found. It would be still further advantageous if potential matches presented to the requester comprise peers that are more likely than not to respond to a request to communicate with the requester.
The present invention provides an interactive peer directory that enjoys the aforementioned and other advantages.
In accordance with the invention, a peer directory system is provided. The system is implemented on a digital computer network. A user interface enables user profile information to be entered and stored in a profiles database. A search engine is adapted to append tags to the user profile information. The search engine can comprise, for example, a computer processor and software to implement a search function. A search index is associated with the search engine for storing tagged user profile information in an indexed form. A peer relevancy algorithm is associated with the search engine to search for candidate peers among the indexed user profile information stored in the search index. The peer relevancy algorithm assigns weights to candidate peers based on different categories of the indexed user profile information, and selects peer matches based on the assigned weights.
In an illustrated embodiment, a first weight is assigned to candidate peers who have a best initiative match with a user searching for peers. The “initiative” can be, for example, a project or venture that the user is currently working on for an enterprise such as an employer. A second weight is assigned to candidate peers who have a best vendor/product match with the user searching for peers. A third weight is assigned to candidate peers who have a best primary operating system (OS) match (e.g., Windows, Mac OS X, SunOS, Linux, Unix, etc.) with the user searching for peers. A fourth weight is assigned to candidate peers who have a best industry match with the user searching for peers. A fifth weight is assigned to candidate peers who have a best firm size match (e.g., size of employer by number of employees, sales revenue, etc.) with the user searching for peers.
The first, second, third, fourth and fifth weights can be summed across all tags for the candidate peers in order to provide a composite weight for each candidate peer. The candidate peers can then be sorted by their composite weights.
In a preferred embodiment of the invention, the search index stores information indicative of past connection responses for candidate peers. Based on this information, the peer relevancy algorithm provides either (a) a negative bias to candidate peers that have poor past connection responses, or (b) a positive bias to candidate peers that have good past connection responses.
The user interface may comprise a display processor for providing display information indicative of best matched peers and allowing information about the best matched peers to be viewed and filtered by a user searching for peers.
The peer relevancy algorithm can be implemented such that it is responsive to a request entered via the user interface to select a peer match for a requester. In such an embodiment, the algorithm will return peer matches to the requester via the user interface. The user interface can be implemented to enable the requester to request connection to one or more peers identified by the peer matches. A communications processor, responsive to a peer connection requested by the requester, may be provided for (i) generating a connection request message to the applicable peer, (ii) receiving a reply from said applicable peer, (iii) if the applicable peer accepts the connection, sending a connection acceptance to the requester with contact information for the applicable peer, and (iv) if the applicable peer fails to accept the connection, sending a connection rejection to said requester.
In a preferred embodiment, the connection request message discloses at least one of the requester's company, industry, role or a personal message from the requester without disclosing the identity of the requester. Contact information for the requester is disclosed to the applicable peer only if the connection is accepted.
Various additional features of the invention include the ability of the user interface to allow a user to filter peer matches by at least one of industry, firm size, country, job role, vendor and product/service category. The weights assigned to the various candidate peers based on different categories of the indexed user profile information can be configurable to allow, e.g., for the tuning of the weights due to present or future circumstances. The negative and positive biases provided to candidate peers based on their past connection response history can also be configurable, e.g., to increase or decrease the significance of the bias in choosing peer matches for presentation (e.g., display) to a requester.
A method is disclosed for connecting peers having common interests. The method enables user profile information to be collected. Tags are appended to the user profile information. Tagged user profile information is stored in a profiles database in an indexed form. The profiles database is searched to identify candidate peers in response to a request for a peer match. The identification of candidate peers is based on correlations between a requester's user profile information and user profile information for the candidate peers. Weights are assigned to the candidate peers, and peer matches are selected based on the assigned weights.
In an illustrated embodiment, the weights assigned to candidate peers are based on at least one of best initiative match, best vendor match, best product match, best primary operating system (OS) match, best industry match and best firm size match. The weights assigned to candidate peers are summed for each such peer. The candidate peers are sorted by their composite weights.
Information indicative of past connection responses for candidate peers can be maintained. Based on this information, a negative bias can be provided to candidate peers that have poor past connection responses, and a positive bias can be provided to candidate peers that have good past connection responses.
Although the invention is described in connection with a preferred embodiment, it will be appreciated that numerous other embodiments and designs are possible as will be apparent to those skilled in the art.
In order to use the peer directory of the present invention, a user opts-in to the directory service via a user interface. The directory can reside on a server which is accessible via a network. Once the user is connected to the server, a user profile can be created, accessed and/or updated. The profile includes, for example, information relating to the product and/or vendor expertise of the user.
Once a profile is complete, a user can then use the inventive system to search the peer directory for peers with relevant product knowledge. Once suitable peers are found, a peer connection algorithm is used to initiate a connection to an identified peer through a network, such as via e-mail or the like. The connection may be made in an anonymous manner, through an intermediary. Bilateral consent to connect may be required, via the intermediary, prior to establishing communication between the user and the relevant peer(s).
The user's responses to the template are used to create a “peer profile” for the user. The peer profile for the user is stored, together with the profiles of other system users, in a profiles database 14. A search engine resident in server 16 maps the peer profile data for the user with metadata tags useful for searching the data. The tagged data is then stored in a peer profiles search index 16. The search index 16 can be implemented in another server or computer accessible to the server 12.
Another category of information that can be maintained for a user in the profiles database relates to products and services of interest to that user. For example, a user may be responsible for specifying, procuring and/or maintaining a business process management (BPM) suite and/or an enterprise search platform provided by a specific vendor, such as the Oracle Aqualogic suite or the Vivisimo Velocity search platform. This can be identified in the user's profile, together with pertinent information such as the vendor name, the user's involvement with the product, the primary operating system on which the suite is run and the user's recommendation for the product. Other categories of information can also be provided in the user's profile that will be useful in the search for a peer to assist the user in completing an assigned project.
The information in each user profile maintained in the profiles database 14 is transferred to a search engine (e.g., resident in server 16) that appends tag profile information to the user profile data. The tagged data is then stored in the peer profiles search index 16. In this manner, the search engine can search the tags stored in the peer profiles search index rather than searching all of the peer profile information itself in the profiles database. This design allows for much more efficient searching, higher relevancy and a quicker response when a requester queries the system for peer matches.
When a user requests to be matched with potential peers via the user interface, the search engine searches the peer profiles search index 16 using the peer relevancy algorithm. Matches are located by the peer relevancy algorithm based on the tags stored in the peer profiles search index and their values, and a list of suitable peers is returned to the application at server 12. Server 12 then passes the matched peers to the user 10 via the user interface. In a preferred embodiment, the peer matches are displayed to the user via a computer display. The user interface allows the user to view each of the peer matches and to drill down for further information relating to each peer match. After reviewing the peer matches in this manner, the user can decide which match(es) would potentially be most helpful, and commence a procedure for contacting each such match.
The flowchart of
At box 44, a second weight “B” is assigned to candidate peers who have a best vendor/product match with the requester. At box 45, third weight “C” is assigned to candidate peers who have a best primary operating system (OS) match (e.g., Windows, Mac OS X, SunOS, Linux, Unix, etc.) with the requester. A fourth weight “D” is assigned to candidate peers who have a best industry match with the requester, as indicated at box 46. At box 47, a fifth weight “E” is assigned to candidate peers who have a best firm size match (e.g., size of employer by number of employees, sales revenue, etc.) with the requester. Once all of the weights are assigned, they are summed across all tags based on matches of the keyword across the tags (box 48).
It should be appreciated that the categories of information to which weights are assigned at boxes 43-47 are not the only categories for which such weights can be assigned. Different categories of information can be added to or substituted for those shown, as will be apparent to those skilled in the art. Moreover, the system is flexible to change and/or add weights based on the needs of the business using the peer search system of the invention. In the illustrated embodiment, as shown at box 35 of
As an example of the weighting process, assume that a peer has the following profile:
When a user types in a keyword to search for peers the system will try to match on the Initiative, Vendor Name, Description, Primary Operating System, Product/Service Category, Product fields (a/k/a tags), Comments, etc. across all peers. Depending on where the match occurs a different weight might be given. For example, if a user types in the keyword “Application” matches will result on:
Once the weighting process is complete, each candidate peer will have a particular composite weight (the peer's “score”), and the peers are then sorted based on the composite weights as indicated at box 49. The sorted list of peers can then be presented to the requester. However, before presenting the list of peers to the requester, another series of steps can be provided to further increase the likelihood that a suitable match will be found.
Specifically, some users who have a good past connection history with peers may be more inclined to respond to a match request than others. The system can therefore keep track of the past history of users in responding to requests to connect to another user using the system. With this information, the system can provide a pre-defined negative bias to users that have poor connection responses, as indicated at box 52, and provide a pre-defined positive bias to users who have good past connection responses, as indicated at box 54. The bias can be implemented by simply increasing the weight assigned to good past responders and by decreasing the weight assigned to poor past responders. Such a bias can be added to or subtracted from the current weight for a given peer based on a fixed “bias” value or a percentage modification of the current weighting for each peer match. The bias for each peer match can then be presented to the requester using a flag or other indicia when the match is presented to the requester (e.g., via a computer display associated with the user interface) or by re-sorting the list of peer matches to account for the modified weight resulting from the bias. Alternatively, the sorting step 49 can be done subsequent to the bias steps 52 and 54, instead of prior to step 52 as shown in
After the list of peer matches has been sorted, it is presented to the requester 10 using, e.g., a computer display or the like, as indicated at box 56. The requester can also use the user interface to view and/or filter proposed matches based on the tags. Such filtering can be done, for example, with respect to the requester's (and/or the peers') industry, firm size, country, job role, vendor, product service/category, etc. The requester can also filter for peers in his own company if he so chooses.
As indicated in
Upon receipt of the email, the recipient peer 50 reviews the connection request using a provided user interface, as indicated at box 62. If the recipient decides not to accept the request for a connection with the requester (box 63), a connection rejection is sent as indicated at box 67. This rejection can comprise an email sent to the requester that the connection has been refused. The system can keep a record to note that the recipient peer has rejected a communication, which record can be used to provide a corresponding bias with respect to that recipient peer (as described in connection with box 52 of
If the recipient peer 50 accepts the request for a connection, a connection acceptance is sent to the requester 10, as indicated at box 64. The acceptance can comprise an email sent to the requester indicating that the connection has been accepted. A record can be kept by the system regarding the acceptance by the particular recipient peer, for future use in providing a corresponding bias as described in connection with box 54 of
Upon acceptance of the connection request by the recipient, an introductory email is sent by the application on server 12 to both the recipient and requester with the contact information of both parties. Alternatively, the requester can also review the connection status (box 65) and obtain contact information of the recipient peer via the user interface. At this point, the requester can directly contact the recipient peer to commence a business relationship. For example, the requester can ask the recipient peer to provide advice and/or assistance in a particular technology or subject area, or to collaborate on a project that the requester is working on. In one embodiment of the system, the recipient peer 50 will be able to obtain contact information for the requester via his user interface, as indicated at box 68, as soon as the connection has been accepted by the recipient peer.
It should now be appreciated that the present invention provides an interactive peer directory system that enables professionals to find suitable peers for assistance with, advice on, and/or collaboration on a particular project. Although the peers can be employed by the same company as the requester, they will generally be people that work for other companies or are independent consultants, academics, or the like.
A user interface enables user profile information to be entered and stored in a profiles database. A search engine appends tags to the user profile information. A search index associated with the search engine stores tagged user profile information in an indexed form. A peer relevancy algorithm associated with the search engine searches for candidate peers among the indexed user profile information stored in the search index. The peer relevancy algorithm assigns weights to candidate peers based on different categories of the indexed user profile information, and selects peer matches based on the assigned weights.
Once the system provides one or more potential peer matches to the requester, the requester can initiate a connection request to a selected peer. If the selected peer accepts the connection request, the requester can contact the peer directly. In order to provide matches that are most likely to accept a connection request, the system can keep track of which candidate peers have a history of accepting requests to connect and which have a history of refusing to connect. The list of potential matches provided to the requester can be biased to favor those that have a tendency to accept connection requests.
Although the invention has been described in accordance with a preferred embodiment, various other embodiments can be provided and are intended to be included within the scope of the claims.
This application claims the benefit of U.S. Provisional Patent Application no. 61/201,618 filed on Dec. 10, 2008, the entire contents of which is incorporated herein by reference.
Number | Name | Date | Kind |
---|---|---|---|
5983214 | Lang et al. | Nov 1999 | A |
6029161 | Lang et al. | Feb 2000 | A |
6078928 | Schnase et al. | Jun 2000 | A |
6112186 | Bergh et al. | Aug 2000 | A |
6175842 | Kirk et al. | Jan 2001 | B1 |
6236978 | Tuzhilin | May 2001 | B1 |
6236980 | Reese | May 2001 | B1 |
6266649 | Linden et al. | Jul 2001 | B1 |
6308175 | Lang et al. | Oct 2001 | B1 |
6314420 | Lang et al. | Nov 2001 | B1 |
6389372 | Glance et al. | May 2002 | B1 |
7016307 | Vasudev et al. | Mar 2006 | B2 |
7035838 | Nelson et al. | Apr 2006 | B2 |
7043443 | Firestone | May 2006 | B1 |
7047202 | Jaipuria et al. | May 2006 | B2 |
7069308 | Abrams | Jun 2006 | B2 |
7167910 | Farnham et al. | Jan 2007 | B2 |
7177880 | Ruvolo et al. | Feb 2007 | B2 |
7188153 | Lunt et al. | Mar 2007 | B2 |
7249123 | Elder et al. | Jul 2007 | B2 |
7269590 | Hull et al. | Sep 2007 | B2 |
7275102 | Yeager et al. | Sep 2007 | B2 |
7315826 | Guheen et al. | Jan 2008 | B1 |
7359894 | Liebman et al. | Apr 2008 | B1 |
7451161 | Zhu et al. | Nov 2008 | B2 |
7454433 | Ebert | Nov 2008 | B2 |
7499903 | Nevin et al. | Mar 2009 | B2 |
7512628 | Chess et al. | Mar 2009 | B2 |
7657907 | Fennan et al. | Feb 2010 | B2 |
7680820 | Denoue et al. | Mar 2010 | B2 |
7917503 | Mowatt et al. | Mar 2011 | B2 |
20020087632 | Keskar | Jul 2002 | A1 |
20020194018 | Scott | Dec 2002 | A1 |
20030093294 | Passantino | May 2003 | A1 |
20040015329 | Shayegan et al. | Jan 2004 | A1 |
20040073918 | Ferman et al. | Apr 2004 | A1 |
20050050227 | Michelman | Mar 2005 | A1 |
20050240580 | Zamir et al. | Oct 2005 | A1 |
20060085373 | Dhillion et al. | Apr 2006 | A1 |
20060179112 | Weyer et al. | Aug 2006 | A1 |
20060200434 | Flinn et al. | Sep 2006 | A1 |
20070060109 | Ramer et al. | Mar 2007 | A1 |
20080046555 | Datta et al. | Feb 2008 | A1 |
20080104004 | Brave et al. | May 2008 | A1 |
20080104030 | Choi et al. | May 2008 | A1 |
20080215623 | Ramer et al. | Sep 2008 | A1 |
20080288494 | Brogger et al. | Nov 2008 | A1 |
20080294607 | Partovi et al. | Nov 2008 | A1 |
20090018851 | Greenfield | Jan 2009 | A1 |
20090100047 | Jones et al. | Apr 2009 | A1 |
20100105315 | Albrett | Apr 2010 | A1 |
20110113094 | Chunilal | May 2011 | A1 |
Number | Date | Country | |
---|---|---|---|
20100145937 A1 | Jun 2010 | US |
Number | Date | Country | |
---|---|---|---|
61201618 | Dec 2008 | US |