JP2003303094 | MULTIPLICATION CIRCUIT |
JPS6116330 | BIT SHIFTING SYSTEM |
PATTERSON JEFFREY (US)
BRYDON ANTONY (US)
PATTERSON JEFFREY (US)
US6697865B1 | 2004-02-24 |
We claim: 1. A method for maintaining ownership rights to relationships in a social network, the method comprising: storing relationship capital data that identifies a plurality of relationships between entities, a given one of the relationships owned by a first entity; preventing access to the given relationship by a second entity; requesting access to the given relationship by the second entity ; responding to the request for access by the first entity; allowing access to the given relationship where the first entity approves the request for access. 2. The method of claim 1 wherein the entity includes an entity selected from the group comprising an individual and an organization. 3. The method of claim 1 wherein responding comprises an approval response, a conditional approval response and a denial response. 4. The method of claim 1 comprising preventing access to the given relationship where the first entity denies the request for access. 5. The method of claim 1 comprising preventing access to the given relationship where the first entity conditional approves the request for access. 6. A method for maintaining ownership rights to relationship capital data in a social network, the method comprising: storing relationship capital data owned by a first entity; preventing access to the relationship capital data by a second entity; requesting access to the relationship data by the second entity; responding to the request for access by the first entity; allowing access to the relationship capital data where the first entity approves the request for access. 7. The method of claim 6 wherein the entity includes an entity selected from the group comprising an individual and an organization. 8. The method of claim 6 wherein responding comprises an approval response, a conditional approval response and a denial response. 9. The method of claim 6 comprising preventing access to the relationship capital data where the first entity denies the request for access. 10. The method of claim 6 comprising preventing access to the relationship capital data where the first entity conditional approves the request for access. 11. A method for maintaining anonymity in a social network, the method comprising: storing relationship capital data that identifies a given entity, the relationship capital data owned by the first entity; preventing access to the relationship capital data by a second entity; requesting access to the relationship data by the second entity; responding to the request for access by the first entity; identifying the first entity where the first entity approves the request for access. 12. The method of claim 11 wherein the entity includes an entity selected from the group comprising an individual and an organization. 13. The method of claim 11 wherein responding comprises an approval response, a conditional approval response and a denial response. 14. The method of claim 11 comprising preventing access to the relationship capital data where the first entity denies the request for access. 15. The method of claim 11 comprising preventing access to the relationship capital data where the first entity conditional approves the request for access. |
(My fl Ej) V (Emij n Mj) = EMijk Therefore, the path is allowed if either of the sets Myk or EMy is not empty. Generally speaking, the workgroup rules may be expressed as: a) the searcher and the intermediaries must all be in the same workgroup, except that at most one of these may be an extranet user of that workgroup, or b) the searcher and the intermediaries must all be non-extranet members of either of two workgroups in an extranet relationship. [0073] Connection rules to determine direct paths according to one embodiment consist of: A. for two users to be linked in a path, either a first user must be directionally connected to a second, or the second be directionally connected to the first; and B. for the last link in a given path, an intermediary must be directionally connected to the search target. The connection engine 116 may additionally infer connections between account holders that are members of the same workgroup. Therefore, the connection engine 116 may find paths from a source to a target, with an intermediary that may be connected to the target and has an inferred connection to the source. Where second order relationships are included within the system, the above-described algorithm may be modified as follows: A'. If the connection to or from is a second order connection, the target of the connection is a leaf node; and A" . If a path can be found without using a second order connection, the path using the second order connection may be ignored. [0074] Figs. 6A and 6B are flow diagrams illustrating a method for determining paths between individuals on the basis of relationship capital according to one embodiment of the present invention. The algorithm illustrated in Figs. 6 A and 6B is also illustrated by the following pseudo code and accompany comments of Table 1: function fmdPaths(userid, targetid) 'get second degree results for user and target userCircle = getSecondDegree(userid) targetCircle = getSecondDegree(targetid) 'check for one degree connection if inFirstCircle(target) addPath(userid|targetid) end if 'check for two degree connections while (pathResult = inSecondCircle(target)) addPath(pathResult) end while 'check for three degree connections thirdCircle = makeThirdCircle(userCircle, targetCircle) while (pathResult = inThirdCircle(target)) addPath(pathResult) end while
'check for four degree connections fourthCircle = makeFourthCircle(userCircle, targetCircle) while (pathResult = inFourthCircle(target)) addPath(pathResult) end while end function
Table 1
[0075] The method begins with step 602 in Fig. 6A, wherein a connection is
opened to the data store, which may comprise a bi-directional read/write connection to
thereby allow user information and connection information to be read and written to and
from the data store. A given user and target are selected from the data store for which
connection information is to be calculated, step 604. A two degree contact table is
constructed for the user, step 606, as well as the target, step 608. An exemplary two
degree table is illustrated in Table 2:
Table 2
According to the exemplary two degree table, the first degree relationships of the user
comprise the set of users {11, 18, 27}, whereas the second degree relationships comprise
the set of users {[11,9], [11, 27], [18,5], [18,12], [18,32], [27,35]}. Based on the two
degree table of the user, a check is performed to determine if the target is within one
degree of the user, step 610. If the target and user comprise a one degree relationship, a path is added between the two and written to the data store for storage and use, step 612, e.g., for weighting operations or searching, and the process ends for the current user/target pair, step 614. [0076] Where the user and target are not related by one degree of separation, step 610, a given first degree contact is selected from the user's two degree contact table, step 616. A check is performed to determine the existence of a connection between the given first degree contact of the user and the target, step 618. Where a connection is present, a path is added between the two and written to the data store, step 620, and a check is performed to determine whether additional first degree contacts are present in the user's two degree contact table, step 622. If the check evaluates to true, processing returns to step 616, and a subsequent contact is selected. [0077] Where there are no additional contacts in the user's two degree contact table, step 622, processing continues with Fig. 6B. A calculation is performed to determine the intersection of the second degree of the user's two degree contact table and first degree of the targets two degree contact table, step 624. The paths with duplicate identifiers may be removed from the intersection of the two tables, step 626. A given contact is selected (by identifier) from the intersection, step 628, and a check is performed to determine whether a connection exists between the contact and the target, step 630. Where a connection exists, a path is added between the two and written to the data store, step 632. A check is performed to determine whether additional contacts are present in the intersection, step 634. If the check evaluates to true, processing returns to step 628, and a subsequent contact is selected. [0078] Where there are no additional contacts in the intersection, step 634, a calculation is performed to determine the intersection of the second degree of the user's two degree contact table and the second degree of the target's two degree contact table, step 636. The paths with duplicate identifiers may be removed from the intersection, step 638. A given contact is selected from the intersection, step 640, and a check is performed to determine whether a connection exists between the contact and the target, step 646. Where a connection exits, a path is added between the two and written to the data store, step 648. A check is performed to determine whether additional contacts are present in the intersection, step 650. Where the check evaluates to true, processing returns to step 640 with the selection of a subsequent contact, otherwise the process terminates, step 652. It should be noted that the method described may be expanded to encompass greater degrees of separation. [0079] In another embodiment, the connection algorithm searches outward from both the user and the target, as follows: 1. Find all users known by user; 2. Find all users known by target; 3. If count from step 1 is lesser than the count from step 2, then explore next user degree, else explore next target degree In this embodiment, the algorithm proceeds to expand outward from the smaller of the user and target contact sets, until the maximum path length has been explored. This technique exploits the limiting effect that the target's own social connections have on finding path solutions, which may reduce the number of computations required to find a path solution. [0080] The scope of a search through a given relationship network may be reduced by pruning paths that would result in a privacy violation, e.g., a path that goes through an intermediary whose inclusion would violate the privacy setting for the workgroups of any of the users preceding a given intermediary in the path. For example, assume that user one is a member of workgroup A, and user two is a member of workgroup B. Assume further that user two is a contact of user one, but workgroup B and workgroup A do not have an extranet connection. The connection engine may prune the remainder of the graph of the network that is rooted at user two. [0081 ] Fig. 7 is a flow diagram illustrating a process of identifying paths within the context collecting relationship capital and processing introduction requests. The process begins with the collection of relationship capital from one or more users using the RCM system, step 702. According to certain embodiments, the collection of relationship capital is conducted manually, with each user supplying their relationship capital to the RCM system. Alternatively, the RCM system may auto-discover the user's relationship capital using techniques described herein and those generally known to those of skill in the art. [0082] The RCM system correlates the relationship capital to eliminate redundancies, step 704. The correlation of relationship capital, both relationship capital that is being collected from a user as well as correlation with relationship capital previously collected by the system, advantageously limits intermediary fatigue by limiting the total amount of relationship capital in the RCM system to that for actual contacts and eliminating duplicate or redundant relationship capital. For example, if a user enters supplies relationship capital such as a name or an email address that is similar to relationship capital already in the RCM system, the system may ask the user to correlate and/or verify the information, or do so automatically. [0083] Relationship capital is collected and correlated, steps 702 and 704, respectively, and made available to user for searching. Relationship capital may be searched according to search criteria that the user supplies, step 706, such as a name, address, title, etc. According to certain embodiments, the user may be presented with an initial result set of the search, which he or she may narrow to a single individual, e.g., the target. Paths are identified that connect the user to the target, which may comprise one or more intermediaries between the two, step 708. The user selects a given path from the one or more paths to the target, step 710, and may initiate the processing of introduction requests and responses between the user and the one or more intermediaries, step 712. The processing of introduction requests ultimately leads to the approval, conditional approval or denial of access to the relationship capital to which the user wishes to obtain access. [0084] Referring to Fig. 8, in further embodiments of a system for relationship capital management, a variety of client devices 1002 may invoke web services over the Internet to access the relationship capital management functions of the analysis system 1022, e.g., searching for the strongest path between two individuals. A client device 1002 may be any type of a computing device that is capable of providing the relevant functionality described herein, such as a personal computer, a workstation, a notebook computer, a tablet PC, a wireless device such as a cell phone, smartphone or personal data assistant ("PDA"), etc. [0085] In one embodiment, a request handler tier 1008 receives web service calls from client devices 1002. The request handler tier 1008 may be a web service wrapper that maps each Web service call to a matching business function or transaction exposed via a business tier 1010. Both the request handler and business tiers, 1008 and 1010, respectively, may be implemented using Java or other programming and scripting languages, e.g., C#, python, PERL, ruby, Visual Basic, etc. The functionality of the analysis system 1022 may be exposed to clients 1002 through a set of Web services. A set of exemplary services that the system may implement is shown in Appendix A. [0086] The program logic in the business tier 1010 may be implemented and exposed using Enterprise JavaBeans ("EJBs") hosted by an application server 1012, such as Tomcat (http://jakarta.apache. org/ tomcat/). Transactions implemented in the Business Tier 1010 are enabled primarily through the use of three back-end data services available from the data and data services tier 1022: the RDMBS 1016, the connection engine 1020 and the weighting engine 1018. EJBs access back-end data services through the use of "connector objects", which expose such services through interfaces that shield any complexity associated with the underlying communication protocols, mechanisms, etc. Although the request handler 1008 is shown as a layer between the application server 1012 and the clients 1002, it should be understood that the application server 1012 may be exposed to the clients 1002 directly. Advantageously, the request handler 1008 may address considerations and implications outlined below in Table 3.
Table 3 [0087] Users may interact with the analysis system 1022 through the use of RCM client applications 1004. An RCM client application 1004 may be a standalone application, or an existing application that utilizes an RCM "plug-in" to provide access to the RCM functionality of the analysis system 1022. Typically, a user has a pre- established relationship capital from an existing relationship capital sources 1000 including, but not limited to, appointments, tasks and any other record involving multiple individuals, as well as collections of outbound and inbound message headers from prior email communications, in addition to other relationship capital. This relationship capital is synchronized with the data store 1016 for analysis by the weighting and connection engines, 1018 and 1020, respectively. For enterprise deployments, such synchronization must occur for as many enterprise users as possible. In addition, the synchronization function must take into account the complex enterprise messaging architectures, contact lists and directories. Techniques for relationship capital auto-discovery and mining are described in greater detail herein. [0088] According to the embodiment of Fig. 8, interaction between clients 1002 and the analysis system 1022 occurs via electronic mail messages. For example, whenever introduction requests are made or responded to, emails may be generated to notify the users that the analysis system 1022 is initiating an action. The analysis system 1022 may also use email 1014 to validate a user's email address upon registration with the analysis system 1022. It should be understood by those of skill in the art that the analysis system 1022 may employ various other methods to notify users in this respect. Emails may be generated upon request and monitored for failed delivery attempts and erroneous responses. The system 1022 also provides processes for monitoring mail spools for "bounce backs," which it may log them accordingly in the data store 1016. [0089] Clients 1002 and other devices within the enterprise may run one or more enterprise applications that integrate with the analysis system 1022. An exemplary integration as discussed herein relates to Microsoft Outlook and Exchange. It should be noted, however, that this discussion should not be construed as limiting. A typical deployment of Outlook/Exchange is shown in Fig. 9, which illustrates multiple Exchange Servers 1106 each provide email throughput to multiple Outlook clients 1102 and being served by a central Active Directory server 1110, which provides directory services for the Exchange servers. A given Outlook client 1102 can operate in one of two modes: Internet or Corporate/Workgroup. In one embodiment suitable for an enterprise deployment, Outlook may be configured for Corporate/Workgroup mode. It is understood that various techniques may be used to integrate the present invention into the relevant enterprise platform. [0090] With respect to Outlook 1102, contact, directory and message data may be stored in various locations. The various Outlook clients 1102 may store both personal contact and message data locally, residing in a local database file named outlook.pst 1104. Outlook 1102 may also store personal contact and message data centrally 1108, on a designated Exchange server 1106, depending on the Exchange deployment configuration. Older versions of Outlook 1102 may store contacts in what is known as PAB' s, or personal address books. The various Exchange servers 1106 may be stored public or private contact folders, message folders and distribution lists. The Active Directory domain server 1110 may store global address lists in a data store 1112, which include listings for all members of an enterprise, as well as certain "off system forwards." [0091] Thus, in the embodiment in Fig. 9, contact, directory, and messaging data exists in three distinct locations: locally on the Outlook client 1102, centrally in an Exchange server 1106, (though potentially distributed in an enterprise amongst numerous servers) and centrally in the Active Directory domain server 1110. For each data store 1104, 1108, 1112, there are number of technologies that can be used to mine the relationship capital contained therein. For example, it is possible to use MAPI on a Microsoft Outlook Client, along with the Outlook object model, to traverse all data within view of a given client, regardless of the client's location. Additionally, it is possible to employ server-side script agents, which read directly from the Exchange server data stores. Finally, APIs exist for communicating with Active Directory. [0092] In some embodiments, there may be two distinct aspects related to synchronization of data between an enterprise installation of Outlook/Exchange and the analysis system: 1) initial upload of all data at "a moment in time," and 2) ongoing updates to keep the relationship capital at the analysis system in synch with the live enterprise data. It should be understood from the prior discussion that synchronization of relationship capital may be accomplished in a variety of ways. For example, upload and synchronization of personal contact and message information being stored locally in Outlook may be accomplished by installing a client-side "MAPI walker" application on client machines, which retrieves message and contact information from Outlook. Since MAPI abstracts the actual data storage areas and provides a common interface to all contact and message folders, whether local or server-based, the MAPI walker is agnostic regarding whether the relationship capital resides on the local client or across a network. [0093] In addition to the foregoing, synchronization may be accomplished with a MAPI interface that allows a user to specify the location of contacts and message data. Another technique employs the installation of a COM Plug-in that is installed on each appropriate application program. The plug-in is operative to trap all events, e.g., where a contact is added or edited, or where a message is sent or received. For each event, the relationship capital may be written to a local database, which is uploaded to the analysis system at pre-configured time intervals. In this way, the analysis system obtains an initial load of relationship capital, in addition to batch updates of all incremental changes. [0094] According to embodiments of the invention, the RCM client application 1004 discussed in Fig. 8 is operative to mine raw relationship capital, which it uploads to an analysis system for storage. The RCM client application 1004 leverages the client's native data repositories and messaging technology interfaces. Such interfaces include Outlook (e.g., MAPI), Lotus Notes, ACT, Goldmine and salesforce.com, etc. [0095] The RCM client application 1004 supports two modes of operation: user initiated and system initiated. User-initiated scanning involves an explicit instruction from the user to scan one or more relationship capital source at a specific moment in time. User-initiated scanning addresses the need to mine pre-existing data. System-initiated scanning, by contrast, occurs in one of two sub-modes: interval-based and event-based. The event-based sub-mode actively monitors the user's relationship capital sources for only new messaging activities that carry social networking implications. Interval-based scanning occurs at set intervals, e.g., daily or weekly. Irrespective of the mode, all scanning is preferably incremental; that is to say, the desktop shall have knowledge (a memory) of what has been scanned to date to minimize CPU utilization. [0096] The RCM client application 1004 provides a number of user controls, including, but not limited to, determining the sources from which relationship capital is retrieved, specific items for scanning, determining the scanning mode (user-initiated versus system initiated), the scanning interval (continuous, daily, weekly, monthly, etc.) and a scanning rate. The RCM client application 1004 also provides for persistent retention of user settings, including, but not limited to scanning mode, interval-based scanning timers, and previously scanned relationship capital sources. The RCM client application 1004 provides the user with controls to disable the application, as well as launch an options menu to control the above-described processes. A description of the interfaces that embodiments of the RCM client application 1004 provide, along with the functionality of the interfaces, is discussed in detail herein. Appendix B further presents a number of exemplary functions for mining sources of relationship capital. [0097] The RCM client application 1004 provides functionality for auto-discovery and collection of relationship capital from a user's relation capital sources, e.g., enterprise applications. Fig. 10 illustrates a flow diagram presenting one embodiment of a method for providing such functionality. The method comprises identifying applications containing relationship capital, step 1202. Identifying application containing relationship capital may comprise specific applications that contain relationship capital, and may also comprise identifying specific types of relationship capital from a specific application. For example, where the user identifies Microsoft Outlook as an application containing relationship capital, the user may further identify only email as the identified relationship capital within the application. The application that the user identifies and, optionally, the specific types of relationship capital, are stored in a configuration file, step 1204. [0098] Relationship capital is auto-discovered according to a number of triggers, step 1206. According to one embodiment, the RCM system uses the information contained within the configuration file to periodically discover and retrieve a user's relationship capital, e.g., according to a frequency, or a schedule. Alternatively, the RCM client application may discover and retrieve a user's relationship capital for transmission to the RCM system. Upon occurrence of the trigger when auto-discovery is set, step 1206, the relationship capital is collected according to the configuration file, step 1208. The user may be provided with an opportunity to approve the discovered relationship capital, allowing the user to select specific pieces of relationship capital for exclusion from collection, step 1210. Alternatively, relationship capital maybe uploaded and subsequently removed by the user. [0099] There are situations where the user decides to refrain from auto-discovery and collection of relationship capital, step 1206. Where the user has not indicated auto- discovery of relationship capital, the user is provided with an opportunity to manually upload relationship capital to the RCM system, step 1212. Relationship capital is collected and approved and uploaded to the RCM system, step 1214. [00100] Returning to Fig. 8, the RCM client application 1004, in conjunction with functionality that the analysis system 1022 provides, allows users to register with the system 1022. Advantageously, the registration employs correlation and currency techniques to reduce the amount of information that a user provides. Thus, various combinations of the RCM client application 1004 and the analysis system 1022 attempt to correlate information presently in the system with information that the user provides. For example, if a user enters a name or an email address during registration that is similar to information already in the data store, the system may display an intermediate screen that asks the user to correlate and/or verify the information. [00101] Alternatively, or in conjunction, the system 1022 may also automatically correlate the existing data. For example, there may be times when multiple instances of the same user exist in the database, e.g., Antony may list John Doe at JD@yahoo.com, while Jeff may list John atjohn.doe@aol.com. Additionally, John may register to use the system as john.doe@yahoo.com. Different instances of the same user should therefore be tied together or correlated, when appropriate. It should be noted by those of skill in the art that correlation and currency are not necessarily tied to the registration process and may be implemented at other times, e.g., when the analysis system 1022 receives new relationship capital from a user for managing. [00102] As noted above, correlation may be performed manually (explicit correlation), automatically (implicit correlation), or according to combinations thereof. The system may correlate instances of the same individual in order to reduce intermediary fatigue. For example, the contact Adam Ross may appear in the data store multiple times due to a particular user having several different "v-cards" for him in his contact manager. If there were no correlation, and a user were to initiate a search for Adam Ross, the system 1022 returns a result set that contains several matches for the same individual. If the user chooses to generate introduction requests (explained in greater detail herein) for each of the "versions" of Adam Ross based on the result set, the intermediaries connecting the user with the target receive multiple introduction requests for the same
connection path to the same target, which is an exemplary cause of intermediary fatigue.
[00103] Multiple references to the same person may be implicitly correlated. For
example, the syst em 1022 may use implicit correlation by treating email addresses as
unique and as belonging to unique individuals. Thus, where multiple contacts in the data
store each contain the same email address, an assumption is made that the email addresses
belong to the same individual and the relationship capital should be correlated. Table 4
illustrates one embodiment of a decision matrix for determining correlation when email
addresses are entered into the system. Table 5, presented subsequent to Table 4,
illustrates one embodiment of a decision matrix for determining how two email addresses
may be merged. The system may further ask users to verify implied correlations to
ensure accuracy.
Table 4
Table 5 [00104] In some embodiments, implicit correlation advantageously limits data entry when registering, as well as intermediary fatigue. Implicit correlation alone, however, may lead to errors. Explicit correlation combined with implicit correlation, where users are asked to approve or reject correlations that the analysis system 1022 intuits as being valid, results in fewer mistakes and adds a level of privacy protection to the system. Correlation according to one embodiment is discussed further in Appendix C. [00105] According to embodiments that support second order relationship mining, correlation of second order relationships may be implemented. For example, assume that A is a user of the system and B, C and D are individuals known to the system whereby a first order connection exists from A to B and a second order connection exists from A to C. Continuing with the example, after additional relationship capital is uploaded into the system, B and D are correlated and all instances of B in the relationship network are replaced with D. Accordingly, A now has a first order connection to D and a second order connection to C, since B and D have been correlated and merged. If instead of the above example, B is correlated with C, the second order connection from A to C can be safely ignored or removed from the system since A already has a first order connection to B. [00106] The RCM client application provides a number of interfaces for allowing a new user to set-up an account with the RCM system of the present invention. As shown in Fig. 11, a registration interface screen 1302 in some embodiments may include form elements 1304 for users to enter account information, such as a username, name, email address, password, etc. When a new user is responding to an invitation to join the RCM system, the new user's email addresses, name, etc., may be pre-populated in the form fields 1304 of the interface 1302 when they register. In this instance, the email address may be pre- validated since the email address is either entered by an administrator and/or is where access to registration originates. [00107] The RCM client application may also use interfaces to obtain extended email information for a user. As shown in the interface of Fig. 12, the interface 1402 allows a user to supplement his or her primary email address 1404 with a number of secondary email addresses 1406 for inclusion in the user's profile that the system maintains. An alternative embodiment of an interface for allowing the user to enter a plurality of email addresses is illustrated in Fig. 13. The interface 1502 provides controls that allow the user to supply email addresses 1506 in addition to the user's primary email address 1504. Advantageously, the interface 1502 also allows the user to indicate old email addresses 1508 that are no longer in use, but were previously associated with the user. In this manner, the user may be properly associated with other users in the system who identify the registering user by an outdated email address, but that nonetheless have a relationship with the registering user. [00108] The interface of the RCM client application may provide controls to a user that allows for review and editing of the user's account and profile information. According to the embodiment illustrated at Fig. 14, the interface 1602 provides a control 1604, the selection of which invokes the display of the user's account information. Using techniques well known to those of skill in the art, the user may edit the text boxes presenting account information 1606 through the interface 1602 to provide updated account information. Similarly, according to Fig. 15, an interface 1702 provides a control 1704, the selection of which invokes the display of the user's profile information. Again, using techniques well known to those of skill in the art, the user may edit the text boxes presenting profile information 1706 through the interface 1702 to provide updated profile information. [00109] Where the system determines that the user's relationship capital, e.g., the name and/or email address of the user, matches that of another user or contact in the system, the system may display a registration screen asking the user to correlate the data with information already resident in the system. According to the embodiment of an interface illustrated at Fig. 16, the interface 1802 provides controls that allow the user to correlate information that exists in the system with his or her profile 1804. Only individuals whose title and company information are available is shown 1806 and 1808; if only the name is shown, there may not be enough information for the user to decide if information is indeed identifying him or her. According to one embodiment, the system makes matches based on a name value where there is other matching relationship capital, such as a phone number. The system may also keep relationship capital that may be used to contact an individual hidden from the user. [00110] The feature exposed by the interface of Fig. 16 increases the likelihood of the system properly correlating multiple instances of the same user. The following rules may be applied with regard to email addresses. If a user enters an email address that's already in system as another user's contact, the system may allow the user to correlate the contact information. If an email address matches that of another user, the user may receive an error with explanation. For each email address that the user adds, a verification email may be sent to that address. For old email addresses, where the email bounces or there is no rejection within a predetermined amount of days, the address may become part of the user's account. If a user lists another user's email address as a primary current address (and can validate the address), the user may claim it from the user that listed the address. [00111] The system also provides a user with the ability to manage all companies to which the user belongs. The graphical interface 1902 illustrated at Fig. 17 presents one or more companies to which the user belongs 1916 and related information regarding each company, 1906, 1908, 1910, 1912 and 1914. Information regarding a company 1916 includes, but is not limited to, the company name 1906, a company administrator 1908, the user's status with regard to the companyl910, and any outgoing or incoming restrictions, 1912 and 1914, respectively. The interface 1902 also provides control for removing a company to which the user belongs 1918. [00112] In addition to account setup and maintenance, embodiments of the relationship capital RCM client application give users control through graphical interfaces over various aspects of the process for gathering relationship capital in order for the user to retain control over their relationship capital. Advantageously, the system provides information through its graphical interfaces sufficient for the user to understand how their relationship capital is being used by the system, thereby allowing the user to make better- informed decisions with regard to that relationship capital uploaded to the system. The user should have control in the following stages: 1. Relationship capital gathering - where the system looks for contact info on the client computer [e.g., what applications and systems]; 2. Relationship capital approval - which data is actually uploaded to the RCM system's data store; and 3. Relationship capital information data usage - how the data is used by other users of the RCM system i. Broadly (e.g. - hide contact information) ii. On a case-by-case basis (e.g. - rejecting or approving particular introduction request with individuals whose relationship capital is owned by the user). [00113] As discussed above, the RCM client application, which may act in concert with the RCM system, collects relationship capital from system users for management. Illustrated at Fig. 18, the system may provide an interface 2002 through which the user may select automatic 2004 or advanced 2006 collection of relationship capital. The interface may also provide a control 2008, the selection of which presents the interface of Fig. 19, which illustrates an interface 2102 providing additional information regarding the automated relationship capital collection process. [00114] Figs. 20 through 2 present embodiments of graphical interfaces that allow a user to identify the sources of relationship capital for management by the present system. According to Fig. 20, the interface 2202 allows the user to identify applications 2204 for retrieval of relationship capital. After the user identifies the source of relationship capital for management, the graphical interface of Fig. 21 allows the user the set the "granularity" of the relationship capital for management by the system. The interface 2302 presents a listing of sources of relationship capital 2304 that the user identifies and allows the selection of only certain types of relationship capital 2306 from those sources for the system to gather. As an alternative, the graphical interface 2302 allows the user to identify 2308 and upload a data file that contains relationship capital for management. The data file may be of any type known to those of skill in the art including, but not limited to, a tab delimited data file, a comma separated value data file, etc. Similarly, Fig. 22 presents another graphical interface 2402 that allows a user to identify a contacts file 2402 that contains relationship capital for management by the system. [00115] The system gathers relationship capital from the sources that the user identifies, a graphical interface may be displayed, such as the embodiment illustrated at Fig. 23, which lists the gathered relationship capital and that allows the user to explicitly approve those contacts that get imported into the system's data store. Alternatively, the user may identify specific relationship capital for importing into the system's data store, which may then collected by the system. According to the embodiment illustrated at Fig. 23, the interface 2502 presents a listing of the user's relationship capital 2504, for example, contacts that the system identifies from the user's relationship capital. In this respect, the user has complete control with regard to the relationship capital that he or she uploads for sharing with other users. The graphical interface 2502 includes elements, such as a slider bar 2506, which allows a user to specify the relative strength of their relationship with a given contact. Alternatively, or in addition, the system may scan the user's relationship capital to calculate an initial strength of the relationship. The system may also rate the strength of the relationships, graphically display the relationship strength rate, and allow the user to edit the rating if they want. In this instance, the elements, such as the slider bar, are pre-populated with the relationship strength rating, which may be modified by the user. [00116] Regardless of the specific technique or techniques that are employed to calculate the weight of the user's relationships with other individuals on the basis of the user's relationship capital, the system provides interfaces for reviewing the weights. Fig. 24 presents one embodiment of an interface 2602 through which the user may view the path strength 2606 of connections with various individuals. Each of the user's contacts is associated with a graphical representation 2608 of the weight of the user's relationship with a given individual, which the RCM client application may display upon selection of a control 2604 that the RCM client application displays within the interface 2602. Selection of the control queries the RCM system to return the relevant information. [00117] Turning to Fig. 25, RCM client application may further display a graphical interface 2702 that allows the user to remove an individual from the list of individuals with which the user has a relationship. The RCM client application presents the graphical interface 2702 upon selection of a control 2704 by the user that the client displays within the graphical interface 2702. The user may select one or more individuals 2706 for removal using control 2708 to add the individual to a deletion list. Upon completion of the changes, the RCM client application transmits the changes in relationship capital to the RCM system managing the user's relationship capital for recordation in the RCM system's data store. [00118] Fig. 26 presents a graphical interface that the RCM client application presents through which the user may define global actions to be taken in response to incoming requests for access to the user's relationship capital. Aspects of the present invention that relate to ownership of and access to relationship capital are described in greater detail herein. The interface 2802, which the RCM client application displays upon selection of a control 2804 by the user that the client displays within the graphical interface 2802, allows the user to set relationship capital to which all other users always have access and relationship capital to which other users never have access. [00119] The graphical interface 2802 displays the users' relationship capital as a list 2806. Selection by the user of a first control 2808 adds a selected piece of relationship capital, e.g., a contact, to an "auto approve" list 2810. Requests for access by other users for relationship capital on the user's auto approve list 2810 are approved by the RCM system in an automated fashion. Selection by the user of a second control 2812 adds a selected piece of relationship capital to an "auto refuse" list 2814. Requests for access by other users for relationship capital on the user's auto refuse list 2814 are refused by the RCM system in an automated fashion. Upon completion of the changes, the RCM client application transmits the changes in relationship capital to the RCM system managing the user's relationship capital for recordation in the RCM system's data store. [00120] One embodiment of a graphical interface that the RCM client application presents to an administrator for adding users of the RCM system to a company is illustrated in Fig. 27. The client displays a text entry box 2904 and a list of relationship capital 2906 along a left side of the interface 2902. Using the text entry box, the administrator may enter email addresses for people the administrator wishes to invite to use the RCM system. Selection of a control 2912 records the addresses in an invitation recipient list 2908. Similarly, the administrator can select one or more contacts that the administrator wishes to invite to use the RCM system. Selection of a control 2914 records the selected contact in the invitation recipient list 2908. The interface 2902 also provides a text entry box to write a personal message 2910. Selection of the submit control 2916 transmits the recipient list to the RCM system, which sends the personal message the individuals on the invitation recipient list, optionally with program code that allows the individual to install and run the RCM client application. [00121 ] Fig. 28 illustrates an embodiment of another administrative graphical interface 3002 that the RCM client application present for detailed management of users within a company. The interface 3002 presents a listing 3004 of all users that are part of a given company, in addition to a control 3004 that allows the addition of new users to the list 3004. The graphical interface 3002 provides information regarding each user including, but not limited to, username 3006, email address 3008, user status 3010, the date of activation for the user 3012, radio controls 3014 to set user type, a control to resend an invite (for pending users who have not yet joined the RCM system) or password (for active users), and a checkbox 3018 to set the removal of a user from the given company. Where the administrator makes changes, e.g., setting the removal status of a user 3018, selection of the apply control 3020 transmits the changes in relationship capital to the RCM system managing the company's relationship capital for recordation in the RCM system's data store. [00122] Fig. 29 illustrates an embodiment of a third administrative graphical interface that the RCM client application presents for configuring groups of companies or extranets. The interface 3102 presents a listing 3104 of companies that the administrator directs. The administrator selects companies for inclusion within the extranet 3108 and effects the selection by use of a control 3106. The interface 3102 also allows the setting of domains for exclusion from serving as intermediaries in incoming and outgoing searches. The administrator provides the domain name in a text entry box 3110 and adds the domain to the exclusion list 3114 through selection of control 3112. Where the administrator makes changes, e.g., adding a domain to the exclusion list 3114, selection of the apply control 3116 transmits the changes to the RCM system managing the company's relationship capital for recordation in the RCM system's data store. [00123] The graphical interfaces for gathering and approval of relationship capital have been heretofore described. The processes and graphical interfaces for exploration of relationship capital managed by an RCM system are described in greater detail herein. [00124] In addition to providing the user with an interface to functions for collecting and categorizing relationship capital, as well as setting options regarding his or her relationship capital, the RCM client application provide interfaces that expose functions of the RCM system, e.g., those provided by the connection engine and weighting engine, for exploration of the user's relationship capital. Fig. 30 illustrates a graphical interface according to one embodiment of the present invention that allows for searching of relationship capital that the RCM system is managing. The graphical interface 3202 is split into three general frames: a search criteria frame 3204, a search results frame 3206 and an item viewer 3208. The search criteria frame 3204 comprises a number of text entry boxes 3210 that allow the user to set criteria for the RCM system to use in searching the relationship capital that it is managing. The item viewer frame 3208 remains empty until the user runs a search and selects an item in the result set, which the search results frame 3206 displays. The interface also includes menus 3224 for accessing other RCM system functions such as those described above. [00125] Prior to running a search, or in response to a user command, the search results frame 3206 may display a graph that analyzes or provides an overview 3212 of the user's relationship capital. According to the embodiment of Fig. 30, the analysis 3212 is a graph of the user's relationship capital wherein a first axis 3222 demarcates numbers of people and a second axis 3220 demarcates date, e.g., months of the year. Within the graph 3212 is an indication of the current date 3226, along which is a further indicator 3218 of the number of individuals who are within three degrees of the user, as is described herein in greater detail; the numeric value 3214 of the number of individuals within three degrees of the user is also indicated. [00126] The graph 3212 also provides the historical 3218 A and anticipated number of individuals 3218B that have been or are anticipated to be within various degrees of the user. Thus, the graph 3212 that the RCM client application display through its graphical interface 3202 provides the user with information regarding the number of individuals within a given degree of the user on past dates 3218 A, as well as predictions regarding the anticipated number of individuals 3218B that are predicted to be within various degrees of the user. For example, using the graph 3212, the user may easily determine that there were one thousand individuals within two degrees on the first of October. [00127] According to another embodiment of the search frame illustrated in Fig. 31, the frame displays numeric information regarding the user's relationship capital. The display includes, but is not limited to, the number of contacts that the RCM system is managing 3302, of those contacts, the number that are also users of the RCM system 3304 and the number of individuals identified by the relationship capital that the system is managing that are within three degrees of the user 3306. The RCM client application receives these data from the RCM system for display to the user. [00128] According to a third embodiment of the search frame illustrated at Fig, 32, the search frame 3402 presents a graphical representation of the relationships exposed by the relationship capital that the RCM system is managing, along with the date and time that the user was last using the RCM system 3404. The graphical representation depicts the user 3406 in conjunction with the number of individuals that are within the first 3408, second 3410 and third 3412 degrees from the user 3406. Below each of the graphical depictions of the individuals within each degree (3408, 3410 and 3412) is the numeric indication 3414 of the number of individuals within each degree. It can be seen that the user is connected directly connected to 213 individuals, connected by one intermediary to 3234 individuals and connected by two intermediaries to 27,945 individuals. Similarly, the frame 3402 displays the numeric indication 3416 of the number of individuals within each degree of the user on the date the user was last using the RCM system. The frame 3402 may display status updates 3418 to the user and provide controls to view past requests 3420. [00129] The RCM client application creates the graphical representation 3402 using values derived by the RCM system on the basis of the relationship capital that it is managing. Alternatively, the graphical representation 3402 may be created remotely from the RCM client application, e.g., at the RCM system, and delivered to the RCM client application for display. [00130] hi some embodiments, the following guidelines may be used in categorizing the relative degrees of contacts: 1. 2nd degree contacts may include all valid contacts that could be considered a 2nd degree contact for a "safe search", e.g., contacts based on relationship capital that the user provides, as opposed to those identified from the relationship capital of other users; 2. 3rd degree contacts include all valid contacts that could be considered a 2nd degree contact for a "safe search"; 3. Responses since last visit should total all requests that have changed in status since date/time of last activity of last logon; and 4. Last activity of last logon session (vs. date time of logon from last session) so it doesn't include response that occurred during that last session, such as auto-responses. [00131] Where the user decides to run a search for other individuals, he or she may use the RCM client application's search frame, an embodiment of which is illustrated at Fig. 33. The user uses the text entry 3504 or other controls to specify search criteria for identifying relationships. Such exemplary criteria may include a target name, title, company, etc. Upon entering the search criteria through the controls 3504 that the interface 3502 provides, the user selects a control 3506 that initiates the search. The RCM client application transmits the search criteria to the RCM system, which uses functionality that the connection engine provides to explore and expose relationships that are contained in the relationship capital that the system is managing. The RCM system may return a result set comprising one or more individuals 3508 that fall within the scope of the search criteria set by the user. The RCM client application may provide a check box 3510 or other similar graphical control that allows the user to narrow the search to one particular individual in the result set upon selection of a control 3512. In some cases, the user may be able to save the search criteria for the system to run periodically and alert the user of new results. [00132] According to one embodiment, the RCM system returns a list of one or more individuals that match the search criteria 3606 that the RCM client application displays in a search results graphical interface 3602, as is illustrated in Fig. 34. The RCM system may also correlate multiple instances of a match when possible (e.g. when the email matches), displaying ancillary information available (title, company) for that match. The user, by setting options at either the RCM system or client application, may limit the list to matching individuals that are within a certain degree of relatedness to the user, such as in the third degree, fourth degree, etc. In this respect the user may not be provided with individuals to whom they are not connected through any intermediaries. Exemplary search methodologies are provided in Appendix D. A user may select one or more individuals from the list of matches to view additional information regarding the target. [00133] Turning to the embodiment of RCM client application interface illustrated at Fig. 35, the graphical interface 3702 comprises the above described search criteria frame 3704, search results frame 3706 and item viewer 3708. According to the illustration, a user has entered several characters of an individual's name as the search criteria 3710. After selection of a search control 3712, the RCM client application transmits the query to the RCM system for generation and return of a result set, which the RCM client application displays in the search results frame 3706. The search results frame 3706 displays information regarding the individuals that fall within the scope of the results set, including, but not limited to, the status 3714 of the individual with respect to the user (as is explained in greater detail herein), the degrees of separation 3716 between the user and the individual (e.g., the number of intermediaries connecting the two) and the strength of the path 3718 connecting the individual to the user. Selection of a given individual 3720 causes the RCM client application to display extended information 3722 in the item viewer 3708 regarding the individual that the RCM system returns in response to the search query. The graphical interface 3702 also provides a control 3724 to enable a "map" view, which is described herein in greater detail. [00134] In response to the selection of a given individual, the RCM client application may show detailed path information regarding the intermediaries between the two. Fig. 36 illustrates one embodiment of such a graphical interface 3802 for the display of detailed path information regarding the intermediaries between the user and a given individual within a result set. The RCM client application receives the path information from the RCM system and presents a listing of the paths between the user and the selected individual, which presents information such as path status 3804, degree of separation 3806 and path strength 3808. In some cases, the user may elect to save the set of paths to this individual so that the system might periodically alert the user of updates to the set, including new paths between the user and the individual, changes in the strength of the paths, or changes in the approval status of the paths. [00135] Advantageously, the graphical interface 3802 may include an introduction status indicator for each path 3810, 3812, 3814, 3816, 3818 that indicates the introduction status of a path as indicated by the RCM system. According to the present embodiment, introduction status indicators 3804 may be a red stoplight 3816 (indicating that an introduction request has been denied by one or more relationship owners in the path), a yellow stoplight 3814 (indicating that an introduction request has been conditionally approved by one or more relationship owners in the path) or a green stoplight 3810 (indicating that an introduction request has been approved by the one or more relationship owners in the path). The introduction status indicator 3804 may also comprise a grey stopwatch 3818 that indicates that an introduction request has been sent to one or more relationship owners in the path, or may comprise no indicator 3812 where an introduction request has not been sent to one or more relationship owners in the path. It should be noted that the current status of a path's introduction status 3810, 3812, 3814, 3816, 3818 may change over time on the basis of introduction status information that the client receives from the RCM system. [00136] The graphical interface 3802 may also provide the strength for the paths 3808 between the user and selected individual. A particular path through one or more particular intermediaries to a particular target individual is typically a persistent entity once the RCM system begins managing relationship capital that identifies the relationships. The strength of the path however, may, change over time, which is reflected in the path strength graphic 3822 on the basis of path strength information that the RCM system returns to the RCM client application. The interface 3802 may initially sort the paths 3808 according to path strength, which the use may override by selection of the column headings 3804, 3806 and 3808. [00137] When the user selects a given path, the RCM client application presents a map graphical interface that depicts a graphical representation of the paths to individuals for which the user is searching. The RCM client application may receive the map from the RCM system, or alternatively, the RCM client application may receive from the RCM system data sufficient to generate and render the map. Figs. 37A through 37F illustrate embodiments of the map graphical interface. [00138] According to Fig. 37 A, the map graphical interface 3902 displays only a limited number of paths between the user 3904 and the individual for whom the user is searching 3906, such as the ten best paths between the two, although the interface 3902 provides controls to toggle between a limited number of paths 3920 and all paths between the two 3922. Advantageously, the paths may be color coded or differentiated (e.g., through the use of lines of varying patters) to indicate the introduction status 3908, 3910, and 3912 of a given path. The intermediaries between the user 3904 and the individual for whom the user is searching 3906 are also plotted on the map graphical interface, e.g., 3916 and 3918. [00139] The map graphical interface is interactive in that the user may select paths that the map displays. Continuing with Fig. 37B, the map graphical interface 3928 displays paths between the user 3930 and the individual for whom the user is searching 3934. Using the map graphical interface, the user selects an intermediary 3932, which causes the map to highlight 3936 or otherwise indicate as selected the path between the user 3930 and the individual for whom the user is searching 3934 through the intermediary 3932. As is explained in greater detail herein, the selected path may be used by the user to solicit approval to introduction requests by selection of an introduction request control 3938. [00140] Turning to Fig. 37C, where the user 3952 selects a path 3950 in which all intermediaries 3954, 3956 approve of an introduction to the individual for whom the user is searching or attempting to contact 3958, e.g., each intermediary approves of the use of his or her relationship capital, the user 3952 may select the path to initiate a communication with the target 3958. Similarly, as shown in Fig. 37D, the user 3960 may select a path 3966 to the individual for whom the user is searching or attempting to contact 3962 that includes intermediaries who have not provided the user with access to their identity 3964. In this case, the identity of the intermediary 3964 is therefore hidden. According to 37E, selection of a "show all" control 3970 causes the display of an unlimited number of intermediaries, such as 3974 and 3976, through which paths pass between the user 3972 and the individual for whom the user is searching 3978. As illustrated at Fig. 37F, selection of an intermediary 3984 highlights the selection of the intermediary and the path 3980 between the user 3982 and target 3986 through the intermediary 3984. [00141] As has been described herein, the systems and methods of the present invention provide privacy for the owner of relationship capital that the RCM system is managing. When a user discovers an individual for whom he or she is searching, e.g., locates a target individual using the functions and interfaces of the RCM system and RCM client application, the user may request access to the target individual's relationship capital. A request may be sent to the one or more intermediaries along the path connecting the user and target individual, each individual approving or denying access to the relationship capital for the next intermediary in the path. Thus, any individual may explicitly allow or deny access to his or her relationship capital that the RCM system is managing. [00142] Fig. 38 presents one embodiment of a graphical interface 4002 illustrating a request for access to relationship capital. The graphical interface 4002 may provide one or more pieces of information, or alerts, 4004 and 4006, regarding the request before transmitting the request through selection of control 4010. Table 7 presents a listing of exemplary alerts: Backwards connection. Already have intro out to one or more intermediaries Already have intro out to these exact intermediaries that is pending Already have intro out to these exact intermediaries that was approved Already have intro out to these exact intermediaries that was conditionally approved. Already have intro out to these exact intermediaries that was rejected Must be a power user Table 7 [00143] When the user chooses to transmit the relationship capital request to the one or more intermediaries by selecting the control 4010, the interface illustrated at Fig. 39 is presented to the user, confirming the transmission of the request. The graphical interface 4102 displays a confirmation, and instructs the user as to the next steps in the process of requesting access to relationship capital owned by others 4104, which is explained herein. The graphical interface may also display a control 4106 that allows the user of view past requests for relationship capital. [00144] The RCM system transmits requests for relationship capital to owners of relationship capital. Figs. 40 through 42 present three exemplary requests for relationship capital that an owner of relationship capital may receive from a user seeking access to the relationship capital. Turning to Fig. 40, the request 4202 indicates that user 4204 who is seeking access to the owner's relationship capital, as well as the specific relationship capital the user is seeking 4206, e.g., an introduction to a contact 4206, who may be the target of a search. The request may also display a graphical representation 4208 that displays the path from the user 4208a to the target 4208c, including any intermediary 4208b. [00145] The request 4202 allows the owner of the relationship capital to allow, conditionally allow or deny access to the requested relationship capital. According to the embodiment of Fig. 40, the request 4202 comprises a three frame interface, each frame providing controls to either allow 4210, conditionally allow 4212 or deny 4214 access to the relationship capital. The allow frame provides a control that allows the owner of the relationship capital to set a flag for auto-approval 4216 of future requests from the user, which the RCM system may store in its data store. Selection of the allow control 4210 causes the RCM system to reveal the owner's identity to the user, if not currently known, as well as send the user select pieces of relationship capital that the user is requesting 4226; the request includes text to this effect or any other effects 4224. [00146] The conditional allow frame provides a control that allows the owner of the relationship capital to set a flag for auto-approval 4218 of future requests from the user, which the RCM system may store in its data store. Selection of the conditional allow control 4212 causes the RCM system to reveal the owner's identity to the user, if not currently known, as well as send the user select pieces of the owner's relationship capital 4230 to further discuss the introduction with the user; the request includes text to this effect or any other effects 4228. The deny frame provides controls that allow the owner of the relationship capital to set flags to auto-deny future requests from the user, as well as auto-deny requests for the relationship capital that for which the user is searching, 4220 and 4222, respectively. Selection of the deny control 4214 causes the RCM system to not reveal the owner's identity to the user; the request includes text to this effect or any other effects 4232. [00147] Fig. 41 illustrates another exemplary request 4302 for relationship capital. A graphical representation 4308 displays the path from the user 4304a to the target 4304d, including two intermediaries 4304b and 4304c. According to the request 4302, which is addressed to intermediary 4304b, the user 4304a is attempting to access the relationship capital of intermediary 4304c. Thus, the user 4304a, must first request that intermediary 4304b share his or her relationship capital for intermediary 4304c, whom the user must then request the relationship capital regarding the target 4304d. As was the case with regard to the embodiment of Fig. 41, the request 4302 comprises a three frame interface, each frame providing controls to either allow 4306, conditionally allow 4308 or deny 4310 access to the relationship capital the user is requesting. [00148] A third exemplary request for relationship capital is illustrated at Fig. 42. A graphical representation 4404 displays the path from the user 4404a to the target 4404d, including two intermediaries 4404b and 4404c. It should be noted that in the exemplary request 4402, the user who is initiating the request for relationship capital 4404a is hidden or otherwise obscured from the recipient of the request, intermediary 4404c. Thus, the user protects his relationship capital related, e.g., his identity, by withholding the relationship capital from those to whom the user has not granted access. As was the case with regard to the embodiment of Figs. 40 and 41, the request 4402 comprises a three frame interface, each frame providing controls to either allow 4406, conditionally allow 4408 or deny 4410 access to the relationship capital the user is requesting. [00149] The RCM system transmits responses from owner's of relationship capital to users who are requesting access to the relationship capital. Figs. 43 through 45 present three exemplary responses to requests for relationship capital that a user may receive from an owner of the relationship capital. Turning to Fig. 43, the response 4502 indicates that the user 4504 is attempting to contact the target 4506. The response may also display a graphical representation 4508 that displays the path from the user 4508a to the target 4508c, including the intermediary 4508c, which is the owner of the relationship capital the user is attempting to access. The response comprises text 4510 that indicates the status of the request, e.g., allowed, conditionally allowed or denied. According to the response, the owner of the relationship capital is allowing access 4510 and the response therefore contains the relationship capital the user was requesting 4512. [00150] Fig. 44 illustrates another exemplary response to a request for relationship capital. According to the graphical portion 4608 of the response 4602, the user 4608a is attempting to access target 4608c through a hidden intermediary 4608b. As discussed above, this represents an intermediary who is not known to the user and who has not provided the user with access to their relationship capital. According to the response 4602, the owner of the relationship capital is denying access 4610 and the response therefore contains no relationship capital. [00151 ] A third exemplary response to a request for relationship capital is illustrated at Fig. 45. According to the graphical portion 4706 of the response 4702, the user 4706a is attempting to access target 4706c through intermediary 4706b. According to the response 4702, the owner of the relationship capital is conditionally allowing access 4708 to the relationship capital the user is requesting; the response contains the relationship capital sufficient to identify the owner of the relationship capital to which the user is requesting access. [00152] Fig. 46 illustrates one embodiment of a method for requesting access to relationship capital and providing responses regarding the same. The user selects a path to a target, step 4802. As described above, the user may select a path through the use of a graphical map interface. Alternatively, the user may select a path to a target using other graphical and command line techniques known to those of skill in the art. The RCM system generates one or more requests for access to the relationship capital of the intermediaries comprising the path from the user to the target, step 4804. As should be apparent to one of skill in the art, the routines for generating the requests and responses as is described herein may also be run at the RCM client application, or combinations thereof. According to some embodiments, the request for relationship capital may present one or more pieces of information, or alerts, regarding the request, which may also include a requirement for user input, step 4806, e.g., requiring that the user supply a reason for requesting the relationship capital. Where user input is required, step 4806, the user supplies the information, step 4808, and the request for access to relationship capital is transmitted to the intermediaries that comprise the path from the user to the target, step 4810. [00153] The intermediaries receive one or more requests for access to relationship capital from the user, step 4810, which may be routed by the RCM system through the use of an email server that transmits the one or more requests. For example, where there are three intermediaries that comprise a path from the user to the target, the second degree intermediary would receive a request for access to the relationship capital of the third degree intermediary. Similarly, where the second intermediary approves the request, the third degree intermediary, which is the last intermediary on the path before the target (fourth degree), would receive a request to access the relationship capital of the target, e.g., the target's name, title and telephone number. The intermediary may approve, conditionally approve or deny the request, step 4812. [00154] According to one embodiment of the present method, the first intermediary comprising the path between the user and target, e.g., the intermediary that is separated from the user by one degree, receives the response. Further according to this embodiment, where there is only one intermediary between the user and the target, the request seeks access to the relationship capital of the target. Similarly, where there is a subsequent intermediary, the request seeks access to the relationship capital of the subsequent intermediary in the path, e.g., the first degree intermediary is being asked by the user to supply the name, title and telephone number of the second degree intermediary. [00155] Where the intermediary approves the request for access to relationship capital, step 4812, the intermediary reveals pieces of their own relationship capital, e.g., name and title. As was described above, the system provides users with the ability to control access to all their relationship capital, including their own identity. Thus, the user might not know the identity of the intermediary, which is revealed, step 4814. The intermediary selects one or more pieces of relationship capital that the user is requesting, step 4816, such as, the identity of the next intermediary in the path or the target. The intermediary transmits an approval, providing the user with access to the relationship capital that the user is requesting of the intermediary, step 4818. [00156] The intermediary may alternatively conditionally allow or deny a user's request for access to relationship capital. Where the intermediary denies a request to access relationship capital, step 4812, the intermediary may instruct the RCM system to set flags in the data store for auto-denial of request for relationship capital, step 4820, e.g., requests from the particular user. The intermediary transmits the denial of the user's request to access a given piece of relationship capital, step 4822, preventing the user from accessing the requested relationship capital. [00157] The intermediary may alternatively conditionally allow the user access to the requested relationship capital, step 4812, such as where the intermediary requires additional information from the user regarding the reason for the request. The intermediary selects pieces of relationship capital to provide to the user, which may be sufficient to allow the user to contact the intermediary, step 4824. The intermediary transmits the conditional allowance of the user's request to access a given piece of relationship capital, step 4826. The user, however, remains prevented from accessing the requested relationship capital, e.g., the identity of the next intermediary in the path. [00158] The intermediary decides to transmit an approval, step 4818, a denial, step 4822, or a conditional allowance, step 4826. Regardless of the response to the request, a check is performed at step 4828 to determine whether additional intermediaries comprise the path between the user and the target, step 4828. Where additional intermediaries exist, processing returns to step 4810 where a request is sent to the next intermediary in the path. Where no additional intermediaries exist, the process terminates, step 4830. [00159] In addition to the relationship capital management functions described herein, the RCM system may also present statistics on usage of the RCM system by users. Fig. 47 illustrates one embodiment of a graphical interface 4902 for presenting statistics regarding access to the RCM system by all users. The interface 4902 provides controls 4910 for providing summary statistics according to users, months or a summary, as well as a control 4904 for switching between chart and graph views. According to the summary, statistics regarding the RCM system are presented 4906 by month 4908. Information that the RCM system may tabulate for presentation include, but are not limited to, logins, searches, requests made, intros received, a success rate, requests received, intros made and a helpfulness rate, which is a function of requests received and intros made. Similarly, statistics by user may be presented as is shown in Fig. 48, in which an interface 5002 displays statistics regarding the RCM system 5010 by month 5012, which can be presented for various users of the RCM system by selection using a drop down menu 5008 or similar selection control. Statistics may also be presented by month as is shown in Fig. 49, in which an interface 5102 displays statistics regarding the RCM system 5108 by user 5110, which can be presented for other months by selection using a drop down menu 5106 or similar selection control. [00160] While the invention has been described and illustrated in connection with preferred embodiments, many variations and modifications as are to be evident to those of skill in the art may be made without departing from the spirit and scope of the invention, and the invention is thus not to be limited to the precise details of methodology or construction set forth above, as such variations and modifications are intended to be included within the scope of the invention. It is to be understood by those of ordinary skill in the art that the various data processing tasks described herein may be implemented in a wide variety of ways, many of which are known and many more of which are doubtless to be hereafter developed. For example, a wide variety of computer programs and languages are now known, and are likely to be developed, which are suitable for storing, accessing, and processing data, as well as for performing, processing, and using forecasts and other analyses are disclosed herein. Except to the extent necessary or inherent in the processes themselves, no particular order to steps or stages of methods or processes described in this disclosure, including the figures, is implied. APPENDIX A
APPENDIX B
The Relationship Capital Source (RCS) API provided by an RCM system
may consist of a collection of interfaces, such as IDispatch / COM interfaces, that
collectively allow any third-party application in conjunction with the RCM system to:
• Discover the hierarchical structure of the underlying data source, and
• Capture data from specified portions of that hierarchy.
According to one embodiment, the RCS API may expose the following
methods within its RCSDataSource Interface:
• Open: Opens the relationship capital source; allows the provider to perform initialization logic. • Name: Returns the displayable name of the relationship capital source. This name pertains to the root node of data source. • Capabilities: Returns an XML string describing the capabilities of the relationship capital source provider. Such capabilities include event monitoring, image lists, and properties. The intent is to provide the client with the means to determine the relationship capital source provider's level of sophistication. • Properties: Clients call this interface to configure the relationship capital source provider, which may or may not be necessary. • EnumerateNodes: Returns a list of folders (nodes) that contain data from the data source (e.g., actual outlook folders). • Capture: Captures all relationship capital items within a specific node. • Close: Closes the relationship capital source; allows the provider to release system resources and to perform termination logic. • IsOpen: Determines if the underlying relationship capital source is currently open. Returns a Boolean value to that effect. APPENDIX C To obtain and display comprehensive and accurate relationship capital regarding individuals in the RCM system, the following steps may be taken: 1. Resolve Email Domains 2. Group companies and resolved domains 3. Correlate users based on multiple attributes 4. Determine first seen, last seen, and still active dates for each email address 5. Display relevant information in a useable format 1. Resolve Email Domains The methods for resolving email domains include automated whois (www.whois.com) queries and acquisition of bulk whois data. Both methods are frowned upon by registrars since this is an activity mostly performed by mass mailing and marketing groups, e.g., purveyors of spam. Each registrar has individual policies automated lookups and ways to access bulk whois data.
The conclusion is that bulk whois data should be acquired where possible, but automated queries may be available for fallback resolution. Known commercial mail hosts may be ignored. A new domainLookup table within the RCM system's data store, an embodiment of which is illustrated below, caches the results of these lookups for future use.
2. Grouping Companies and Resolved Domains Once email addresses are resolved to company names, similar companies may be grouped together where possible to tie email currency to companies and positions, thereby eliminating multiple representations of the same company with slightly different spellings. A new masterCompany table may be created within the RCM system's data store to contain the accepted display name for each company, along with an identifier. In addition, the contactlnfo table may contain a column for the masterCompanylD, thereby correlating each representation of a user to a master company. At any point, company name grouping may be regenerated from original values with no effect on the integrity of the data. Grouping Methodology Company name grouping uses the search engine methodology to determine the likelihood that two company names should be treated as the same. These correlations are more accurate as the search engine is modified to use first term weighting. 3. Correlate Users Based on Multiple Attributes For any contact in a user's relationship capital, the individual may be correlated against: a) the user's other contacts b) all other contacts in the system For each case, different rules apply. For example, within a user's contacts, it might be safe to determine that two contacts with the same first and last names are the same person. This assumption, however, would lead to incorrect correlations when applied to
the entire universe. Exemplary rules are as follows:
Further correlation may take into account the source of the matching relationship capital.
For example, where a similar contact is found in a coworkers relationship capital, it might
be more relevant than one found elsewhere.
4. Determine Email Currency
For each email address, first-seen and last-seen dates will be determined. Before
determining these dates, the email address may be check for validity by:
a) verifying the syntax of the address is valid;
b) checking to see that a mail server exists for the domain; and/or
c) connecting to the mail server to see if the address will be accepted.
Addresses may be checked on a regular basis and the result of each validation stored in a
new email Validation table in the RCM system's data store that contains information such
as the emaillD, the date of the validation check, and the result of that check.
From this, date ranges can now be assigned to each address:
5. Display relevant information in a useable format The relationship capital is collected, companies and email domains are mapped to
master companies, multiple representations of people are correlated, and dates associated
with each email address are recorded. On the basis of this collected and processed
relationship capital, search results information may be determined:
To display detailed information about each search result, code is used, e.g.,
javascript, to pass the user's information into the item viewer panel where may be
formatted and shown. The information in this panel may include:
o Each Master Company the user is associated with
o The most common title they had at each company
o The date ranges gathered from email currency. APPENDIX D
Search Methodology Analysis