|Publication number||US20060155750 A1|
|Application number||US 11/203,049|
|Publication date||Jul 13, 2006|
|Filing date||Aug 12, 2005|
|Priority date||Aug 12, 2004|
|Also published as||CA2575176A1, CN101268486A, EP1776668A2, EP1776668A4, US8015058, US20060064436, US20060111975, US20060116896, WO2006020893A2, WO2006020893A3|
|Publication number||11203049, 203049, US 2006/0155750 A1, US 2006/155750 A1, US 20060155750 A1, US 20060155750A1, US 2006155750 A1, US 2006155750A1, US-A1-20060155750, US-A1-2006155750, US2006/0155750A1, US2006/155750A1, US20060155750 A1, US20060155750A1, US2006155750 A1, US2006155750A1|
|Inventors||James Fowler, Garth Moulton, Peng Sien, Saaed Fattahi, Rajan Madhavan, Kenneth Lenga|
|Original Assignee||Fowler James F, Moulton Garth B, Sien Peng C, Saaed Fattahi, Rajan Madhavan, Lenga Kenneth R|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (5), Referenced by (15), Classifications (15), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application claims the priority benefit of U.S. Provisional Application Ser. No. 60/601,343, filed Aug. 12, 2004, and entitled “METHOD AND SYSTEM TO PROCESS BUSINESS CONTACT INFORMATION”, the contents of which is incorporated in its entirety herein.
This application relates to a method and system to maintain a data management and publication system and, in one example embodiment, a system to collect and maintain information regarding an entity (e.g., contact information regarding a corporate entity).
Information regarding corporate entities, and individuals employed by those corporate entities, is highly valuable information for potential and actual suppliers, customers and competitors of a corporate entity. Specifically, the sales department of a seller corporation is usually interested in locating individuals at a potential customer corporation who can be contacted to discuss a possible relationship between the seller corporation and the customer corporation. Further, information regarding individuals within a particular corporate entity may be very useful to corporate recruiters.
To meet the demand for business information (e.g., individual and corporate contact information), a number of companies offer such information services.
For example, the Hoover's Inc, a Dun and Bradstreet Company, has provided information on U.S. companies and industries since 1990, originally only in print form, but since '93 via its website, Hoover's Online. The Dun and Bradstreet Corporation is a leading provider of business information, and its major divisions are Risk Management Solutions, Sales and Marketing Solutions, Supply Management Solutions, and e-Business Solutions. In order to gather and keep current a collection of business information that rapidly changes, business information companies are required to employ a large number of researchers and analysts, and also to employ sophisticated data gathering technologies.
Social networking services have also emerged as a valuable avenue for users to locate jobs, people and business opportunities. Such social network services typically deploy specialized software to focus on building and verifying social networks for a number of purposes, including business purposes. Linkedln.com is an example of such an Internet-based social network service, and enables users to locate other users who may be useful to them for business purposes, and that may be connected (by varying degrees) to the seeking users' social network. Such social network services may encourage a user to upload their address book to the social network service. Software deployed by the social network service then matches the entries within the uploaded address book to entries within its database in order to establish connections.
In addition to contact information relating to corporate entities, other business and corporate information may be extremely valuable to external entities. Examples of such information include head count, revenue and organizational structure information. Such information may or may not be published by a particular corporate entity. For example, where the corporate entity is a private entity, such information may be hard to obtain. Accordingly, it is a challenge to the business information companies to gather and publish such information to their customers.
It will also be appreciated that there are a number of technical challenges and difficulties in maintaining a large body of business information. This information, as noted above, is continually evolving. Accordingly, the information gathering systems employed by business information companies typically are required to provide researchers and analysts with access to a large number of sources from which current business information can be a gleaned. The provision of such access, and the management of the resulting data traffic and storage requirements, presents a number of technical challenges.
According to an example aspect of the invention, there is provided a system to generate corporate data pertaining to a corporate entity. The system includes an interface to communicate, to each of a plurality of users of a data system, a corporate data attribute relating to a corporate entity, and a plurality of candidate data attribute values for the corporate data attribute. The interface further receives, at the data system and from the plurality of users, votes for at least one candidate data attribute value of the plurality of candidate data attribute values. The system further includes a vote module to automatically tally the received votes, and to publish vote information based on the votes received from the plurality of users in connection with the plurality of candidate data attribute values for the corporate data attribute.
Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of an embodiment of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.
An exemplary embodiment provides a business contact platform that includes a network of users, client terminals, network apparatus, host servers, middleware, applications, database objects, data, administration interfaces and user interfaces. The business contact platform may operate to provide a value (e.g., a reward in the form of award points) to a user that provides business contact information (e.g., corporate information, contact information etc.) to the platform and/or that maintains (e.g., updates, challenges confirms etc.) business contact information accessible via the business contact platform. The business contact platform may furthermore allow a user to exchange the awarded value (e.g., to redeem the award points) for access to business contact information that had been added and/or maintained by other users. Accordingly, in one embodiment, the business contact platform may be viewed as an open, collaborative and self-correcting information exchange system.
Specifically, the business contact platform may maintain a database of contact information that is considered “open” because users may enter, confirm, update and/or challenge information stored in this database. This database may furthermore be made accessible (e.g., displayed) in real time by the business contact platform.
The business contact platform may also be considered collaborative, as users vote, maintain and sustain the database through collective action on the data. Further, the business contact platform may be considered “self-correcting”, because users may validate, update, correct and/or delete information through collective action on the data. In one embodiment, the business contact platform may also be considered an exchange, because users exchange information they have for information that they need, either directly or through a stored value (e.g., points) system.
Turning now specifically to the contact information system 12, web servers 24 and Application Program Interface (API) servers 26 are coupled to, and provide web and programmatic interfaces to, application servers 28 (and other servers such as messaging servers 30). The application servers 28 host both service applications 32 and domain application 34. The service applications 32, in one embodiment, provide web and database services to the domain applications 34, which in turn provide higher-level services, processes and functionalities to users of the contact information system 12. While the platform 10 shown in
The contact information system 12 also includes one or more database servers 36 that facilitate access to databases 38. The databases 38 may be implemented as relational databases, and include tables having entries (or records) that are linked by indices and keys. In a further embodiment, the databases 38 may be implemented as collections of objects in an object-oriented database. The databases 38, as will be described more fully below, are populated with tables that store corporate data, including contact information for corporate entities and individuals employed by those corporate entities. This corporate information is received, processed, stored, retrieved, modified and maintained by the service and domain applications 32 and 34.
The contact information system 12 also includes a financial system interface 40 which allows the service and domain applications 32 and 34 to interface with an external financial system 42 (e.g., a bank or a stored value system, such as the PayPal service) via the network 14. In one embodiment, the financial system interface 40 may allow the contact information system 12 to debit and credit, with appropriate authorization, accounts managed by an operator of the contact information system 12 and accounts of users. The transfer of value between accounts held on behalf of the contact information system 12 and users as one or more financial systems 42 may, in one embodiment, be performed by a domain application 34 responsive to the purchase or sale of stored value (e.g., reward points) maintained by the contact information system 12 within the databases 38.
The web server modules 50 provide a single point of access to other service applications 32 and domain applications 34 for web clients 20 executing on client machines 16. The web server modules 50 are utilized to process web pages that present content (e.g., user interface elements, navigational controls, forms etc.) to a user of a client machine 16. In addition, the web server modules 50 may utilize a variety of web server technologies (e.g., the Apache Web Server etc.), Internet technologies (e.g., Java, J2EE, JSP, Dynamic HTML, Struts Forms and Actions etc.), and comply with web services standards (e.g., XML, HTML, SOAP, etc.).
The API modules 52 provide programmatic access to the service applications 32 and the domain applications 34 for a programmatic client 22 executing on a client machine 18. In one embodiment, the API modules 52 may support a set of functions provided by the service and domain applications 32 and 34, and may support communication between the contact information system 12 and the programmatic client 22 utilizing XML. The API modules 52 enable the development, by external services, of service-based applications by exposing interfaces to the service and domain applications 32 and 34.
The form processing modules 54 provide support services for processing web pages that accept user input from web forms. For example, the forms processing modules 54 provide support to utilize Strut forms and actions, in conjunction with JSP pages and XML technology.
The relational database modules 56 support services for access to the database 38. In various embodiments, the relational database modules 56 may provide support for object relationship mapping, database independence and distributed computing. The relational database modules 56 are utilized to add, delete, update and manage database elements maintained within the databases 38.
Messaging modules 58 are utilized to process incoming and outgoing messages (e.g., email messages) for the contact information system 12. In one embodiment, the messaging modules 58 may utilize the Simple Mail Transport Protocol (SMTP). The contact information system 12 may generate emails, which are stored within the database 38, and that are also communicated to users via the network 14. For example, to process stored emails, the messaging modules 58 may include an email transmitter that asynchronously checks the databases 38, and periodically sends messages (e.g. notifications) as appropriate.
The structured formatted text modules 60 are utilized to provide support for the processing of comma separated value data, for example.
Turning to the domain applications 34, a registration and login module 62 enables registration, login, lost password management, account management, subscription, credit card and referral processing. A status module 64 enables a user to view a chronological listing of transactions (e.g., point transactions) handled by the contact information system 12. For example, various details regarding points that have been earned by a user may be displayed by the status module 64.
A stored value module 66 is responsible for the allocation of awards (or rewards), in the exemplary form of stored value in the form of points, to users of the contact information system 12. The stored value module 66 may allocate rewards to users for any one of a number of actions performed with respect to the contact information system 12. For example, the stored value module 66 may allocate points to a user for registering with the system 12, for referring a further user to the system 12, for adding corporate data (e.g., individual or corporate contact information) to the body of corporate information stored by the system 12, and for performing an action to maintain the validity and currency of the body of corporate information (e.g., for updating, challenging or confirming instances of corporate data).
The search module 68 facilitates user navigation of a body of corporate data, either for example through the performance of keyword searching, attribute searching, or category-based browsing. Further details regarding the search functionality provided by the contact information system 12 are provided below.
An add module 70 enables users of the system 12 to add corporate data (e.g., contact data) to the body of corporate data maintained by the system 12, while an update module 72 enables users to update such information. A validation module 74, as will be described in further detail below, enables users to perform various actions to contribute towards the maintenance, validity and currency of corporate information stored by the system 12.
A voting module 76 operates to enable users to vote for one or more values for a corporate data attribute, the relevant value being otherwise generally unavailable. As will be described in further detail below, the voting module 76 then operates to process such votes, and publish the vote information to users of the contact information system 12. The voting module 76 may also associate one or more values with a particular corporate attribute, based on voting information received from users. A rating module 78 maintains reputation information for users of the contact information system 12 by providing a rating to each user, based on their interactions with, and contributions to, the body of corporate data maintained by the system 12. For example, a user 18 may be enhanced by the provision of corporate data that is later validated, or stands the test of time. On the other hand, the rating of a user may be negatively influenced by the provision of corporate data that is subsequently found to be inaccurate or false.
It will also be noted that the module 62, 70, 72, 74 and 76 are each linked to the stored value module 66, so as to enable, in one embodiment, the stored value module 66 to allocate rewards to users for the performance of functions facilitated by these modules. Further details regarding certain functions performed by the domain applications 34, in conjunction with the service applications 32 will be described in further detail with reference to the figures that follow.
As mentioned, a user may also have purchased corporate data, in the form of contact information, from the system 12. The purchase contact information for each user is recorded in an owned contact table 98, which links a record in the user table 91, to one or more records in a contact table 100. A unique record exists within the contact table 100 for each instance of contact information. As noted, the contact table 100 maintains for each contact, a record of whether the relevant contact information has been challenged by a user, a count of challenges received, whether the relevant contact information has been withdrawn from publication (e.g., hidden), with an identifier for the originator of the contact information, as well as details of awards that may have been allocated to the originator of the contact.
Of course, different versions of contact information, for a single contact, may be received at the system 12 from different users. For this reason, the tables 90 include a contact version table 102, which may contain multiple records associated with each record within the contact table 100. For example, two different users may have different contact details for a single person. Each of these “versions” of the contact information for the single contact may be stored within the version table 102. The version table 102 is shown to store various information including a hide field indicating whether the relevant version is hidden or exposed by the system 12, a confirmation count field indicating the number of confirmations received from users of the system 12 for the relevant version, as well as other fields of contact information.
Each field within the user contact table 92 and the contact table 100 may furthermore be associated with a record within a company table 104 in which are maintained records for companies, or other corporate entities. One or more domains for each company may also be stored in a domains table 106 that is associated with the company table 104.
Referring to the user table 91, a referral history table 108 maintains a referral history for each user. A user information table 109 maintains information utilized by the rating module 78 to generate a rating for a user (e.g., by examination of positive-neutral actions), and that is utilized by the stored value module 66 to store an allocation (or a deduction) of a stored value (e.g., award points) to the user for various actions performed in connection with the system 12. For example, the various domain applications 34 discussed above may write records to the point transaction table 112 and/or user action table 110 for each stored value allocation, or deduction, operation attributable to the user. The information within the point transaction and user action tables 110 and 112 may be utilized by the status module 64, for example, to calculate a total stored value (e.g. a points balance) for each user. A points field in the user information table 109 may indicate a type of action that led to the allocation, or deduction, of points. For example a points field may identify an event as being a referral event, cash event, a purchase event, a challenge event, an update event, a confirmation event, an origination event, a bonus event etc.
The tables 90 also include a user action table 110 which is populated with records for each user action in connection with the system 12 which results in allocation, or deduction of stored value (e.g. points). The user action table 110 includes a type field that indicates whether the action is an origination, confirmation, challenge or update action, examples of which are discussed in further detail below. The user action table 110 is linked to a point transaction table 112, which includes a type field, indicating whether the relevant user action was a referral, cash, purchase, challenge, update, confirmation, origination or a bonus type action. Further, the points transaction table 112 includes a points field, indicating the number of points earned, or lost, as a result of the user action.
A user vote table 114 is populated with records for each vote cast by a user in connection with a value for one or more corporate data attributes (e.g., revenue, employees and classification). Records within the user vote table 114 are utilized by the voting module 76 to tally and published vote information based on votes received from a number of users. The information contained in the vote table 114 is also used by the voting module 76 to attribute a “top voted” value to a specific attribute. For example, the voting module 76 may identify a certain range of employees (e.g. 100-200) as being the most voted for range, and then identify this range as a “top voted” range for the relevant corporate data attribute.
In one embodiment, each user of the business contact system 12 has a personal address book or contact list. The contact list is made up of user contacts 22 and owned contacts 98. In one embodiment, the contacts in the user's personal contact list may either be made accessible by the user, or kept private or hidden. To this end, contacts which the user wishes to keep private may be flagged as “hidden”.
Each contact in the user's personal contact list may further reside in one of a number of states, these states including, for example:
For originated, purchased or owned records, the system may further indicate if there are any updates the user has not yet viewed.
Having now described the architecture of, and data structures supporting, the contact information system 12, a description of the various functions performed by the contact information system 12 will be described with reference to a number of user interfaces, in the example form of web pages, generated by the system 12, and flow charts will be provided below.
As alluded to above, in one example embodiment, the contact information system 12 supports a marketplace for corporate information (e.g., contact information) wherein users can accumulate stored value (e.g. a proprietary currency, such as points) with the contact information system 12 through any one of a number of avenues, and then exchange (e.g., redeem) such stored value for corporate information stored by the contact information system 12, such corporate information having been contributed by other users. In the example embodiment, points may be accumulated through user registration with the system 12, referral of another user to the system 12, the supply of corporate information (e.g., individual or contact information), and contributing to the maintenance on the corporate data (e.g. challenging, updating, and/or confirming such data). Having accumulated points, the user may then exchange points for corporate information pertaining to individuals or corporate entities. Accordingly, the marketplace is supported by the provision of stored value to a user in exchange for the receipt of corporate information, and via the exchange of such stored value for corporate information that may have been contributed by other users.
By way of introduction to the contact information system 12,
The address book interface 120 provides a total 122 of instances of corporate data, in the example form of individual contact data, which is maintained in an address book for the user at the system 12. The interface 120 further includes a search window 124, into which a user may input data to search contact information stored in his or her address book.
A listing window 126 provides a listing of contact information within the user's address book, this listing being sorted in accordance with criteria inputted into the search window 124. Specifically, within the listing window 126 each record is shown as a respective line item populated with a number of fields. In addition to the name, title, company, phone, email and date acquired fields, a line item also includes a “recently updated” field 128 which may include a visual indication flagging this particular instance of contact information as having been recently updated. An “originated/acquired” field 130 provides indications, for each contact within the address book of whether the contact was acquired (e.g., by the display of a dollar symbol), or originated by the relevant user (e.g., by the display of a star). A “challenged” field 132 further indicates, for each address in the address book, whether this address has been challenged by the display of an appropriate visual indicator (e.g., a red exclamation mark). In the example address book displayed in the listing window 126, it will be noted that the top address is flagged in the “challenge” column as having been challenged by a user of the contact information system 12.
Each line item in the listing window 126 is furthermore hypertext linked to invoke a user entry displaying full contact details (in conjunction with appropriate corporate data and optionally bibliographic data) for the selected contact.
The information panel 142 includes a scorecard window 152, which provides an indication of a total stored value, in the example form of an available points balance 154, a total number of contacts stored in an address book maintained by the system 12 for the user, a referrals indication indicating the number of referrals to the system 12 that have been originated by the user, and a rating indication indicating a rating for the user as determined by the rating module 78.
The information panel 142 also includes a “saved searches” window 158 that provides a drop down menu (not shown) of a search queries authored by the user and stored at the system 12.
A details window 176 provides a line item representation of activities that have occurred within the selected month, and that contributed to the activity totals displayed in the window 172.
Returning now to the buy points interface 180, the interface 180 is the first in a flow of interfaces (not shown), and pricing information for various purchase levels. A purchasing-user may enter the number of points he or she wishes to acquire into the purchase total field 182, and then select a next button 184 to advance the interface flow to the next user interface, which prompts the user for payment instrument details (e.g., a credit card number or a details of PayPal account). At the end of the purchase flow, the number of points inputted to the scorecard window 52 would then be credited to the available points balance of the purchasing user.
The sell points interface 190 includes an information section 192 providing information regarding the point selling process, a selling points section 194 into which the seller can input a number of points to be added to, or subtracted from, a sell order that contributes towards the pool of points that are available for sale via the contact information system 12. The interface 190 also includes a payment section 196 to receive details of an account, maintained by an external financial system 42, into which the selling user is to receive monetary payment in exchange for transfer of points under one or more sell orders.
Having above provided some context regarding functioning of the contact information system 12, various operations supported by the system 12 will now be described in further detail. These operations include the adding of corporate information (e.g., company and individual business contact details) to a body of corporate information maintained by the system 12, the maintenance of a such corporate information (e.g., through the updating, challenging and/or confirming of such information), and also the generation of supplementary corporate information through a voting process and an incentive process will be described.
At block 202, the search module 68 publishes a contact information search interface, which includes both mechanisms for locating a corporate entity, and a mechanism for locating individuals across a number of corporate entities.
At decision block 204, a determination is made by the search module 68 whether corporate search input has been received or whether individual search input has been received. If it is determined that corporate search input has been received, the method 200 progresses to block 206, where the search module 68 proceeds to display results based on the company search input received. It may be that the results of the company search, displayed at block 206, include details for more than one corporate entity. In this case, at block 208, the search module 68 may receive, via a web interface supported by the web server 24, a selection of a particular corporate entity contained in the search results.
Responsive to receiving the company selection input at block 208, at block 210, the search module 68 displays a corporate contact information for the selected corporate entity, in conjunction with a list of individual contact data for individuals that are associated with (e.g., are employees of) the selected corporate entity.
Returning to decision block 204, in the event that corporate search input is not received, a determination is made at decision block 212 whether individual search input has been received. If not, the method 200 enters a waiting loop by continuing to loop through decision blocks 204 and 212 until either corporate or individual search input is received.
On the other hand, should individual search input be determined to have been received at decision block 212, the search module 68, at block 214, displays a list of individual contact data items for individuals across multiple corporate entities that match the individual search input. Examples of various user interfaces that may be generated by the contact information system 12 (e.g., the search module 68, operating in conjunction with the web server modules 50 and the form processing modules 54) are illustrated in
Dealing now specifically with the “find a company” interface shown in
The listing section 244 displays a list of line items, contact details for individuals associated with the relevant corporate entity, as filtered by the criteria inputted into the search section 242. It will be noted that the contact detail line items displayed within the listing section 244 displays the title of the relevant individual within the corporate entity, as well as geographic location data and a date on which the individual's contact data was received by the contact information system 12. However, actual contact details, and the names of the relevant individuals are not displayed in the listing section. Additionally, the listing section provides check boxes 248 for each line item, thereby to enable a user to select a set of contact details from the line items displayed in the listing section 644 for purchase, as will be described in further detail below.
In summary, it will be appreciated that the interfaces discussed above with reference to
Returning to the method 200 shown in
At block 218, the search module 68 presents purchase confirmation information to the user, indicating the number of points required to purchase the selected contact data (purchase points), and an available points balance of the user.
Responsive to receiving confirmation of the purchase from the user, at block 220, the relational database modules 56 update the tables 90 to effectively store the purchased contact data in an “address book” of the user maintained by the contact information system 12. Further, the stored value module 66, at block 220, deducts the purchase points from the available points balance of the user thereby directing a predetermined value from a stored value from the user responsive to the communication of the selection of contact data to the contact information system 12. Having purchased business contact data for one or more individuals, at block 222, the contact information system 12 may display contact data usage preferences, associated with the purchased contact details, to the purchasing user. Specifically, in one embodiment, a user whose contact information is stored and owned by the contact information system 12 may specify preferences relating to the usage of his or her business contact information. For example, the preferences may indicate that the relevant individual willing to receive requests of a certain type, but that requests of a different type should be directed to someone else in his or her organization. The method 200 then ends at termination block 224.
The contact business card interface 290 includes a business card portion 292 that displays business contact details for an individual that would typically be included on a business card that the user would freely hand out to potential business acquaintances. It will be noted that version tabs 294 are provided in conjunction with the displayed contact data, where more than one version of contact data is stored for the relevant individual. Utilizing the version tabs 294, a user can select between different versions of the individual's contact information. The business card portion 292 also includes an update button 296, which is user selectable to invoke an update process whereby the user may update the information of the individual, this update process being described in further detail below. The business card section 292 also includes a challenge button 298, which is user selectable to challenge the data of the individual as displayed.
The contact business card interface 290 also includes an actions section 300, including a preferences link 302, which is user selectable to display preferences regarding usage of the displayed business contact information, a download link 304 to download the business contact information as a V-card, a report problem link 306 that is user selectable to invoke a problem reporting interface (e.g., see
FIGS. 19 and
Having parsed the email address at block 332, at decision block 334, the corporate data (e.g., the domain name of the email address) is utilized to identify a corporate entity, and a determination is made as to whether business data for the relevant corporate entity is stored at the contact information system 12.
User of selection of the “add contacts” tab 146 invokes a drop down menu 374, which provides the options of invoking a number of process flows, namely an “add single contact” process flow, a “staging area” process flow and an “upload to staging area” process flow. To this end, the contact information system 12 provides two ways for the provision of contact information to the system 12, namely a single entry via a web form, and a file upload of multiple entries. Turning first to the single entry by a web form, the exemplary interfaces shown in
Turning to the file upload methodology, as an alternative to adding contacts one at a time to their personal contact lists, users may utilize an upload wizard to communicate a list of contacts to the system 12. Such a list may be exported from several leading contact management applications, examples of such contact management applications are provided in the export help block 376 of the interface 370. In one embodiment, structured formatted text exports from Microsoft Outlook, Palm Pilot, ACT!, Salesforce.com, and excel spreadsheets may be accepted.
The upload wizard operates to detect when a contact being uploaded is a duplicated one that is already in the personal contact list of the user, and may in the situation ask the user if the wizard should prompt the user for each duplicate individually, ignore all duplicates, or add all duplicates to the personal contact list. If prompted individually for each record, the user may be able to decide whether to ignore each duplicate, or add it to their personal contact list.
The add contact interface 372 is invoked responsive to user selection of the “add single contact” item from the drop down menu 374, and provides an email field 380. A user can provide contact information in the form of an email address of the individual whose contact information is to be provided to the contact information system 12. This email address is then parsed, at block 332 of the method 330, to extract the individual information (e.g., “vhasen”) and to extract the corporate domain (e.g., “imagingos.com”).
Returning to the method 330 shown in
In the event that data for the corporate entity is not already stored at the system 12, the method 330 progresses to block 336, where the user is prompted, via appropriate interfaces for data regarding the relevant corporate entry. Such corporate information, having been provided into relevant forms generated by the forms processing modules 54, is then received at the system 12 via an appropriate interface (e.g., the web interface), and then subject to a normalization process and a validation process, prior to storage in the databases 38, and specifically within the company table 104. The data normalization may include, for example, the normalization of various acronyms such as “Blvd” to “Boulevard” and “Ste.” to “Suite”.
Regarding of the validation process, the add module 70 may operate to apply criteria to the corporate information received at block 336. For example, the corporate information provided may be required to include a minimum set of information, including the URL for a website with its primary domain, and the name of at least one employee.
At block 338, the corporate information having been stored in the databases 38, the stored value module 66 proceeds to award a first portion of a corporate points award (e.g., 10 points) to the user, thereby effectively adding the awarded points to the user's balance of available points. Following a positive determination at decision block 334, or following completion of the award operation at block 338, the method 330 progresses to decision block 340, where a determination is made as to whether contact information for the relevant individual is stored at the contact information system 12. Again, this determination may be made by the add module 70, utilizing the user name as parsed out of the email address received at block 332. If a record for the individual already exists within the system 12, the user seeking to add the contact is advised of the potential duplicate at block 342, and the method may then terminate at block 344.
In other embodiments, on detection of a potential duplicate, as opposed to terminating the receipt of contact information, the system 12 may nonetheless allow the user to submit the new contact information and determine whether it exactly matches the already stored contact information, or exhibits some variations. In the event that the exhibits variations, the newly added contact information (for an already known individual) may be stored as a different version of the contact information within a new record in the contact version table 102.
Returning to decision block 340, if contact information for the individual is not stored at the system 12, the user is prompted for a full set of contact information for the individual at block 346. Further, at block 346, this full set of contact information is received, and again subject to a normalization and validation process, prior to being stored in the contact version table 102.
The normalization process may again normalize certain information items received as part of the full set of contact information. For example, the title field may be automatically normalized from “Dir” or “Eng” to the words “Director” and “Engineering”. To this end, subsequent to receiving the contact information, the system 12 may prompt the user to accept the normalized alternatives. As part of the validation process, the system 12 may also utilize USPS or other services to standardize and check postal addresses.
During receipt of the contact information, the address and phone number for the individual may default to that of the corporate entity identified at decision block 334. Further, the system, in the validation process, may reject certain email addresses that have high a likelihood of being personal email addresses (e.g., email addresses from a number of popular web-based email services, such MSN Hotmail, Yahoo! and Google). The validation process may also apply various filters to detect generic emails (e.g., email@example.com).
In a further embodiment, the validation process may also prohibit certain phone numbers from being included in the contact information received at block 346. For example, in certain jurisdictions, the prefix for a phone number (or the area code) may identify the phone number as being a mobile number. The validation process may employ one or more filters to detect the attempted provision of mobile telephone numbers, and disallow or block receipt thereof Finally, the validation process also checks that a complete record of contact information has been submitted, and that no required fields within an input form have been omitted.
Having received the contact information inputted into the add contact interface 390, the system 12 may display the add contact interface 400, shown in
Any one of a number of notifications, which result from the normalization and validation process as described above, may be included within the interface 400 and presented to the user for review, editing and/or acceptance.
In connection with the company sections 392 of the interfaces 390 and 400, each of these company sections 392 includes a “report problem” link 406 that is user selectable to invoke a problem reporting process, whereby a user can report any one of a number of problems pertaining to the corporate information displayed in a company section 392 of an interface.
Returning again to
At block 350, a determination is made as to whether a verification time period in connection with the received corporate and/or individual information has expired. For example, the system 12 may publish the corporate and/or individual information received at blocks 336 and/or at block 346 subject to verification for a period of 30 days. In the event that the verification time period has not expired, a determination is made at decision block 354 whether a challenge or an update to the contact information has been received from other users of the system 12. If not, the method loops back to decision block 350. On the other hand, should a challenge or update to the contact information have been received, at block 356 an available points balance for the submitting user may be adjusted in accordance with the outcome of an update, challenge, appeal or arbitration process, examples of such processes being discussed in further detail below.
Returning to decision block 350, should the verification time period be determined to have expired, the method progresses to block 352, where the stored value module 66 then proceeds to award a second portion (e.g., bonus points) of the individual and/or corporate points awards to the user, and adds the awarded points to an available points balance for the user. For example, upon expiration of the verification time period, the add module 70 may provide the submitting user with five bonus points for individual contact information.
The method 330 then ends at block 344. In one embodiment, the corporate and individual points awards are different, with a higher number of points being allocated for the receipt of information regarding a previously unknown corporate entity than is awarded for the receipt of previously unknown individual contact data.
Further, the points awarded to a submitting user within the context of the method 330 may be redeemable for contact information, pertaining to another entity, and potentially submitted by another user. In this manner, the system 12 supports marketplace functionality.
At block 432, the contact information system 12 publishes contact information of a first entity (e.g., an individual or a corporation) to a number of users of the contact information system 12. This publication of the contact information may, for example, be the display of contact details for an individual maintained within the personal contact list (or address book) of a user, subsequent to a purchase of the contact information in the manner described above.
At block 434, the contact information system 12 receives information relating to the validity of the published contact information of the first entity. For example, considering the contact business card interface 290 as shown in
In one embodiment, a user is encouraged by the contact information system 12 to challenge a contact if a contact is known to have left, or become disassociated with, a corporate entity, or if an email to a reflected email address bounces and a phone number for the entity does not work. Users are discouraged from challenging the validity of the contact information merely on the basis of a bounced email. Further, users are encouraged to update contact information for an entity if the contact is known still to be associated with a respective company, and the updating user has access to correct contact information. For example, the address of a particular corporation may have changed, in which case an updating user, utilizing the update button 296 may invoke a process whereby the contact information for the corporate entity may be updated. Responsive to the updating of the contact information, a new virtual “business card” may be created for the contact. Further, if more than one version of business contact information exists for an individual, the update is made to the most recent version.
Returning to the method 430, at block 436, the validation module 74 of the contact information system 12 automatically determines the information type (e.g., challenge or update) received at block 434, and determines the value of a reward based on the information type. For example, in one embodiment, a higher value reward may be provided for a challenge than for an update, or vice versa.
The validation module 74 then, at block 438, communicates with the stored value module 66 to automatically award a first portion (e.g., five initial points) to the user, and may add this first portion of the reward to an available points balance maintained by the system 12 for the user.
The method 430 then progresses to decision block 440, where it is determined whether a verification period for the published contact information has expired. Specifically, the contact information system 12 may institute a verification period (e.g., 30 days) following the submission of contact information to the system 12 wherein the originator of the contact information is notified of any validity or correctness issues pertaining to a submission that they have made.
If the verification period is deemed to have expired, the originator is not included in the process and the method progresses directly to block 458, where the update published contact information is validated (in the case of an update), or the contact information is withdrawn from publication (after a predetermined expiration period (e.g., again 30 days)).
On the other hand, should the verification period for the published contact information not have expired, at block 442, the validation module 74 initiates transmission of a notification of receipt of the information regarding the validity (e.g., the challenge or update) to the published content information.
At decision block 444, if a response is not received from the originator, it is determined whether a challenge time period in connection with the challenge or update has expired. For example, upon receipt of an update or a challenge to published content information, a 30-day period may be provided for the originator to respond to notification of the update or challenge. If the challenge period has not expired, the method then loops back to decision block 444.
On the other hand, should a response from the originator have been received, at block 448 the validation module 74 determines whether the originator has conceded to the challenge or update. If so, the method again jumps to block 441, where the stored value module 66 awards a second portion of the reward, for receipt of the information regarding validity, to the challenging user, and updates an award balance (e.g., available points balance) for that user. The stored value module 66 may also penalize the originator of the contact information (e.g., by ten points, or applying a ten point penalty), and then reducing an award balance total for the originator by the appropriate number of points.
On the other hand, should the originator not concede the challenge, the method 430 progresses to decision block 450, where a determination is made as to whether the challenger concedes the challenge, in light of the response received from the originator. If the challenger does in fact concede, the method progresses to block 456, where the challenging user is penalized (e.g., by reducing the challenging user's available points balance by a predetermined points penalty (e.g., ten points)). On the other hand, should the challenger not concede the challenge, a genuine dispute is then recognized to have risen between the originator and the challenger, and the contact information system 12 may then institute an appeal or an arbitration process at block 452 between the challenger and the originator.
Should the originator of the contact information then be unsuccessful, as determined at decision block 454, the method then again proceeds to perform the operations discussed above with reference to block 441. On the other hand, if the originator is successful in overcoming the challenge, the method again progresses to block 456, where the challenging user is penalized.
It should also be noted that following a successful challenge or update at block 441, the method progresses to block 458, where the update of the published contact information is validated, in the case of an update, or the contact information is withdrawn from publication (e.g., relegated to being a “graveyard” contact).
On the other hand, should the challenge or update be defeated, following the penalizing of the challenging user, at block 460, the update or the challenge to the published contact data is invalidated. From each of blocks 458 and 460, the method 430 then progresses to block 462, where ratings for both the originating user and the challenging user are updated. For example, if the originating user was successful in defending the originally published contact information, a rating for the originating user may be increased, or at least maintained. While the rating for the challenging user may be reduced. On the other hand, should the originating user be defeated, the rating for the originating user would be decreased, and that for the challenging user increased or at least maintained. Accordingly, a rating may be regarded as the aggregate of ratings for all actions (e.g., add, update and challenge actions) that a user performs with respect to the contact information system 12. The rating may, in one embodiment, be calculated as a percentage of actions that are either positive or neutral. For example, a rating of 95% means that the relevant user received a negative rating 5% of the time.
While the method 430 is described above as being applicable to published contact information, it will be appreciated that, once an update to published contact information is validated at block 458, the update would then in fact be regarded as published content information, and the challenger would then migrate into the role as an “originator” of the updated information. Accordingly, once an update has been validated, a challenger may challenge that updated information.
Further, originators are encouraged to appeal updates that are considered to be trivial. Examples of trivial updates may include correcting punctuation, fixing minor spelling errors, rearranging word order (e.g., “Director of Marketing” to “Marketing Director”), changing a first name to a nickname (e.g., “Mike” to “Michael”), completing partial but mostly correct first name (e.g., “Rob” to “Robert”), completing first names that are initials (e.g., “J.R. Smith” to “John Robert Smith”), completing partial words that are clear in meaning (e.g., “network admin” to “network administrator”), adding a suffix or professional designation, and spelling of acronyms that have four letters or more. Examples of non-trivial updates may include updating a phone number or address from a corporate phone number or address to a direct phone number or address, spelling or acronyms that are three letters or less, and completing names with only one letter (e.g., “J. Smith” to “John Smith”).
In one embodiment, when a user challenges contact information, the record may be “locked” for a predetermined period (e.g., 90 days). During this period, the contact information system 12 may refuse to allow users to add a contact that matches in a version of the locked contact period. During this period, the contact information may continue to be displayed to users when they view their personal contact lists. However, at the end of the 90-day period, the lock record may no longer be displayed (e.g., withdrawn from publication) when a user views their personal contact list. After the 90-day period, the contact may then again be entered into the contact information system 12 as a new contact.
In a further embodiment, the information relating to the validity of the contact information may be a confirmation indication received from a user, confirming the validity of the contact information published by the originating user.
The method 470 commences at block 472 with the communication of at least one corporate data attribute, and a set of candidate values for the corporate data attribute, to a number of users of the contact information system 12. The candidate values may be communicated as a set of ranges, or as fixed values. The corporate data attribute, and candidate values, may be communicated by the web server modules 50, based on messaging received from the voting module 76.
The industry classification section 496 provides a collection of drop down menus 502, using which a user can vote for a particular industry and sub-industry, according to which the user believes the relevant corporate entity should be classified. Having provided votes for various candidate values for one or more corporate data attributes utilizing the interface 490, the user may select a “submit vote” button 504 to communicate his or her votes back to the contact information system 12.
Returning to the method 470 depicted in
At block 476, the voting module 76 automatically tallies votes received from users of the contact information system 12 in a predetermined time period. For example, at any time, the tallied votes may constitute votes received within the past 90 days. By limiting votes that are tallied at block 476 to votes received in the predetermined time period, the currency of the vote tallies can be optimized.
Further, at block 476, the voting module 76 proceeds to publish vote totals for each set of candidate values, in conjunction with the corporate data attributes. Referring again to the vote interface 490 shown in
At block 478, the voting module 76 may then also operate to allocate a selected value of the candidate values to the corporate data attribute, based on the votes received. For example, with respect to the employee count corporate data attribute shown in
At block 480, the voting module 76 may then expose the candidate value, selected at block 478, as searchable data in connection with the corporate attribute, for use in the location of corporate data by users of the contact information system 12. Again, for example considering the employees attribute, a search query to locate corporate entities with employees in the 0-25 range would locate the corporate entity represented in interface 490, on a count of the 0-25 range having been allocated as a selected candidate value to the employee data attribute for the relevant corporate entity.
The method 470 then ends at block 482. The above described method 470 advantageous in that it allows users of the contact information system 12, who may have some knowledge regarding a particular corporate entity, to vote with respect to values that should be assigned to corporate data attributes, thus enhancing the ability of all users of the contact information system 12 to either positively locate or filter out corporate entities based on corporate data attributes that, except for the voting of users, would have unknown values. Thus, the voting methodology described above with reference to method 470 may be viewed as a method of capturing data pertaining to a corporate entity the data capture being performed in a democratic manner based on votes received from users who may have some knowledge regarding the relevant corporate entity.
One example of such a request may be for information regarding a member of a corporate entity that is most responsive to sales requests of a particular type, or a request for information regarding the reporting hierarchy within the corporate entity. Further, where the relevant corporate entity is a private company, the communicated request may be for any information that may not be publicly available pertaining to the private corporation. Other examples of unavailable corporate information may include financial information pertaining to the corporate entity, a number of corporate employees of the corporate entity, employee organizational information for the corporate entity, and recommended contact information for the corporate entity. The recommended contact information for the corporate entity may be in connection with the provision of goods or services to the entity.
At block 514, the contact information system 12 receives corporate information, relating to a corporate entity for one or more users. Again, the communication of the request, and the receipt of the corporate information at blocks 512 and 514 may be performed via an appropriate interface (e.g., a web interface) of the contact information system 12.
At block 516, the stored value module 66 operates to automatically provide a reward to the user, responsive to receipt of the corporate information at block 514. In one embodiment, the provided reward may constitute points that are, as described above, exchangeable within the contact information system 12 for other contact information, or that may be sold via the system 12 for monetary value.
In one embodiment, the reward provided at block 516 may constitute a two-part reward, namely an initial reward and a bonus reward that is provided if the corporate information received at block 514 is validated in some way. For example, the stored value module 66 may operate to immediately award an initial number of points (e.g., five) responsive to receipt of the value, and award a second portion (e.g., a further five points) subsequent to a verification event with respect to the received corporate information. The verification event may, for example, be the absence of a challenge or update to the corporate information within a predetermined time period, or the confirmation of the received corporate information by one or more further users of the system 12.
In yet a further embodiment, the stored value module 66 may also operate to determine the type of corporate information received at block 514, and automatically determine the value of a reward based on the determined information type. Certain types of information may be regarded by users of the contact information system 12 as being more valuable. For example, 10 points may be awarded for the provision of corporate information pertaining to the revenue of a corporate entity, whereas only 5 points may be awarded by the stored value module 66 for information indicating a number of employees of the same corporate entity.
The example computer system 600 includes a processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory 604 and a static memory 606, which communicate with each other via a bus 608. The computer system 600 may further include a video display unit 610 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 600 also includes an alphanumeric input device 612 (e.g., a keyboard), a user interface (UI) navigation device 614 (e.g., a mouse), a disk drive unit 616, a signal generation device 618 (e.g., a speaker) and a network interface device 620.
The disk drive unit 616 includes a machine-readable medium 622 on which is stored one or more sets of instructions and data structures (e.g., software 624) embodying or utilized by any one or more of the methodologies or functions described herein. The software 624 may also reside, completely or at least partially, within the main memory 604 and/or within the processor 602 during execution thereof by the computer system 600, the main memory 604 and the processor 602 also constituting machine-readable media.
The software 624 may further be transmitted or received over a network 626 via the network interface device 620 utilizing any one of a number of well-known transfer protocols (e.g., HTTP).
While the machine-readable medium 622 is shown in an example embodiment to be a single medium, the term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-readable medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such a set of instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, optical and magnetic media, and carrier wave signals.
Although an embodiment of the present invention has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US2151733||May 4, 1936||Mar 28, 1939||American Box Board Co||Container|
|CH283612A *||Title not available|
|FR1392029A *||Title not available|
|FR2166276A1 *||Title not available|
|GB533718A||Title not available|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7788296 *||Dec 29, 2005||Aug 31, 2010||Guidewire Software, Inc.||Method and apparatus for managing a computer-based address book for incident-related work|
|US8015058||Aug 12, 2005||Sep 6, 2011||Salesforce.Com, Inc.||User-maintained contact information data system|
|US8150422||Jan 19, 2007||Apr 3, 2012||Tepa Datasolutions Co., Llc||Method of displaying contact information|
|US8346307||Jan 19, 2007||Jan 1, 2013||Tepa Datasolutions Co., Llc||Method of displaying contact information|
|US8504559||Jul 11, 2005||Aug 6, 2013||Linkedin Corporation||Method and system for leveraging the power of one's social-network in an online marketplace|
|US8631021 *||Mar 26, 2010||Jan 14, 2014||Jostle Corporation||Systems and methods for managing organizational information|
|US8713000 *||Jun 6, 2005||Apr 29, 2014||Linkedin Corporation||Method and system for leveraging the power of one's social-network in an online marketplace|
|US9043405||Feb 26, 2007||May 26, 2015||Linkedin Corporation||Method of leveraging social networking with a messaging client|
|US9064339 *||Apr 12, 2012||Jun 23, 2015||Salesforce.Com, Inc.||Computer implemented systems and methods for providing a mobile social enterprise interface|
|US9104846 *||Feb 5, 2008||Aug 11, 2015||Microsoft Technology Licensing, Llc||Access provisioning via communication applications|
|US20080177796 *||Jan 19, 2007||Jul 24, 2008||Eldering Charles A||Method of Distributing Contact Information to Merchant Websites|
|US20090034696 *||Aug 1, 2007||Feb 5, 2009||Microsoft Corporation||Mechanism of distributing voice call using email distribution groups|
|US20110184962 *||Mar 26, 2010||Jul 28, 2011||Jostle Corporation||Systems and Methods for Managing Organizational Information|
|US20130007049 *||Apr 12, 2012||Jan 3, 2013||Salesforce.Com, Inc.||Computer implemented systems and methods for providing a mobile social enterprise interface|
|US20140136436 *||Nov 26, 2013||May 15, 2014||Jostle Corporation||Systems and Methods for Managing Organizational Information|
|U.S. Classification||1/1, 707/999.102|
|International Classification||G06Q30/00, G06Q10/00, G06F17/30|
|Cooperative Classification||G06Q30/0208, G06Q10/00, G06Q30/02, G06Q10/10, G06Q30/0231|
|European Classification||G06Q30/02, G06Q10/10, G06Q30/0208, G06Q10/00, G06Q30/0231|
|Feb 28, 2006||AS||Assignment|
Owner name: JIGSAW DATA CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FOWLER, JAMES F.;MOULTON, GARTH B.;SIEN, PENG CHONG;AND OTHERS;REEL/FRAME:017296/0694;SIGNING DATES FROM 20051011 TO 20051013
|Sep 29, 2010||AS||Assignment|
Owner name: SALESFORCE.COM, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:JIGSAW DATA CORPORATION;REEL/FRAME:025063/0379
Effective date: 20100920