1. Field of the Invention
The field of the invention is data processing, or, more specifically, methods, apparatus, and products for hint-based email address construction.
2. Description Of Related Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely complicated devices. Today's computers are much more sophisticated than early systems such as the EDVAC. Computer systems typically include a combination of hardware and software components, application programs, operating systems, processors, buses, memory, input/output devices, and so on. As advances in semiconductor processing and computer architecture push the performance of the computer higher and higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems and networks today that are much more powerful than just a few years ago.
One of the more popular ways that people utilize these powerful computer systems and networks is for communications using electronic mail or ‘email.’ Email is an electronic message that is transferred between users in a store and forward manner over data communications systems. An email sender creates the email in an email client, which in turn transfers the email to an email server. The email is forwarded along from one email server to another until the email reaches the email server serving a recipient's email client. The recipient's email client then retrieves the email from the email server for delivery to the recipient. Transferring information in such a manner is typically cheaper and faster than sending a traditional letter, less intrusive than a phone call, and less time consuming than sending a fax. In addition, using email to communicate makes differences in location and time zone less of an obstacle to communication.
A user who exchanges information through the use of email typically has his or her own unique email address. Email addresses are of the form of ‘username@organization.xxx’ where @ is pronounced as ‘at’ and ‘organization.xxx’ refers to the domain to which the recipient's email account belongs. Examples of domains could include ‘ibm.com,’ ‘uspto.gov,’ and so on. The ‘username’ portion of the email address specifies the username within the domain associated with the recipient's email account.
When sending an email, a user typically provides either the recipient's email address or the recipient's name to the email client. When provided with the recipient's email address, the email client has the information needed to instruct the email server to deliver the email to the recipient's email address. When provided with the recipient's name, the email client may look up the recipient's email address in the sender's address book using the recipient's name provided by the sender.
One drawback to the current way of providing the recipient's email address is that often the sender does not know the recipient's email address and does not have the recipient's email address associated with the recipient's name in the sender's address book. Even in situations where the recipient's email address is associated with the recipient's name in the sender's address book, the sender may not be able to remember enough of the recipient's name to locate the entry in the address book. As such, readers will appreciate that room for improvement exists in the area of constructing email addresses for email recipients.
Methods, apparatus, and products are disclosed for hint-based email address construction that include: receiving, in an email address constructor, an email address hint specified by a user, the email address hint representing an email address for an email recipient; parsing, by the email address constructor, the email address hint for a plurality of hint tokens, each of the hint tokens specifying a user attribute for the email recipient, and at least one of the hint tokens specifying an attribute other than the email recipient's name; and determining, by the email address constructor, the email address for the email recipient in dependence upon the plurality of hint tokens.
The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.
Exemplary methods, apparatus, and products for hint-based email address construction in accordance with the present invention are described with reference to the accompanying drawings, beginning with
The exemplary computing device (152) of
An email address hint represents an email address for an email recipient using a plurality of hint tokens. Each hint token specifies a user attribute for the email recipient such as, for example, the recipient's name, location, address, employer, organizational department, friends, family, or any other attributes as will occur to those of skill in the art. In such a manner, the user attribute specifies a characteristic describing the email recipient. At least one of the hint tokens of an email address hint, however, specify an attribute other than the email recipient's name. For example, consider the following exemplary email address hint:
The exemplary email address hint above includes four hint tokens. The first hint token specifies that the recipient's name includes ‘Robert.’ The second hint token specifies that the recipient is located in ‘Austin.’ The third hint token specifies that the recipient belongs to the organizational department identified as ‘Customer Support.’ The fourth hint token specifies that the recipient works for ‘IBM.’ Readers will note that the exemplary email address hint above is for explanation only and not for limitation. Other email address hints having other formats and other structures may also be useful in hint-based email address construction according to embodiments of the present invention.
In the example of
“X.500” is a joint standard of both the International Standards Organization (“ISO”) and the International Telecommunication Union (“ITU”) defining structure for global directories. X.500 directories are hierarchical with different levels for each category of information, such as country, state, and city. Both LDAP and X.500 implement hierarchical directories in which particular sets of attributes of directory entries comprise distinguished names. X.501 is the X.500 specification for directory models as such.
The email address constructor (102) of
In the exemplary LDAP URL format above, the ‘host’ is the DNS or IP address of the LDAP server to search. ‘Port’ refers to the network port of the LDAP server. ‘DN’ refers to the distinguished name to use as the search base. ‘Attributes’ refers to a comma-separated list of attributes to retrieve. ‘Scope’ specifies the search scope and may have values of ‘base,’ ‘one,’ or ‘sub.’ ‘Filter’ refers to a search filter such as, for example, ‘objectClass=*.’ ‘Extensions’ refer to extensions to the LDAP URL format.
When implemented according to LDAP, the directory repository (124) of
The exemplary LDAP entry above is for a single user named ‘Robert Doe’ who works at IBM. The entry is identified by a unique DN, which is the first line of the exemplary entry above. The entry includes various attribute-value pairs, the first of which specifies the entry inherits from the ‘inetOrgPerson’ object class described in RFC 2798. Readers will note that the exemplary LDAP entry above is for explanation only. Other entries in the directory repository having other formats as will occur to those of skill in the art may be useful in hint-based email address construction according to embodiments of the present invention.
Because LDAP entries are arranged in a hierarchical tree, and because each node on the tree can be uniquely identified by a DN, the LDAP model lends itself well to sophisticated queries and powerful search filters. For example, searches may be restricted to a particular subset of the tree simply by specifying a different base for the query to begin from, or querying only against specific attributes in the directory repository.
The email address constructor (102) exposes an application programming interface (‘API’) (104) for use by other software components in order to allow these other software components to provide hint-based email address construction according to embodiments of the present invention. In the example of
The explanation above with reference to
Also stored in RAM (168) is an operating system (154). Operating systems useful for hint-based email address construction according to embodiments of the present invention include UNIX™, Linux™, Microsoft XP™, AIX™, IBM's i5/OS™, and others as will occur to those of skill in the art. The operating system (154), the email address constructor (102), the email client (106), the word processor (108), and the web browser (110) in the example of
The computing device (152) of
The example computing device (152) of
The exemplary computing device (152) of
The arrangement of servers and other devices making up the exemplary system illustrated in
For further explanation,
The email address constructor may receive (200) the email address hint (202) according to the method of
In the example of
The method of
The email address construction may determine the type of attribute specified by each of the hint tokens (204) by looking up each hint token (204) in an attribute type identification table that associates common attribute types with particular words or phrases and selecting, from the attribute type identification table, the attribute type associated with each hint token (204). For example, consider the following exemplary attribute type identification table:
Each entry in the exemplary attribute type identification table, associates a hint token with a primary attribute type and a secondary attribute type. The primary attribute type is the attribute type most likely to provide the semantics to the hint token that the user intended. The second primary attribute type is the attribute type second most likely to provide the semantics to the hint token that the user intended. The primary and secondary attribute type may be assigned to each possible token value based on usage statistics for various words and phrases contained in a particular language.
The exemplary attribute type identification table above illustrates four entries, each of which associates common attribute types with particular words or phrases used by a user as a hint token. The first entry associates the hint token ‘Austin’ with a primary attribute type ‘Location’ and a secondary attribute type ‘Given Name.’ That is, the first entry specifies that when the user typed the word ‘Austin,’ the user most likely intended ‘Austin’ to refer to a location and second most likely intended ‘Austin’ to refer to a person's name. The second entry associates the hint token ‘Customer Support’ with a primary attribute type ‘Organizational Department,’ but not a secondary attribute type. That is, the second entry specifies that when the user typed the phrase ‘Customer Support,’ the user most likely intended ‘Customer Support’ to refer to a department in an organization. The third entry associates the hint token ‘IBM’ with a primary attribute type ‘Company,’ but not a secondary attribute type. That is, the third entry specifies that when the user typed the word ‘IBM,’ the user most likely intended ‘IBM’ to refer to a company. The fourth entry associates the hint token ‘Robert’ with a primary attribute type ‘Given Name’ and a secondary attribute type ‘Surname.’ That is, the fourth entry specifies that when the user typed the word ‘Robert,’ the user most likely intended ‘Robert’ to refer to a recipient's first name and second most likely intended ‘Robert’ to refer to a recipient's last name. Readers will note that the exemplary attribute type identification table and the description for determining the type of attribute specified by each of the hint tokens are for explanation only and not for limitation. In fact, other ways of determining the type of attribute specified by each of the hint tokens as will occur to those of skill in the art may be used in embodiments according to the present invention.
In the method of
The method of
The email address constructor may select (212) a subset of the plurality of hint tokens (204) according to the method of
The email address constructor may query (214) a directory repository for a result using the subset of the plurality of hint tokens (204) according to the method of
The exemplary query above requests the return of the email field in all the entries of the directory repository where the common name field ‘cn’ has a value of ‘Robert.’ The following exemplary list of results may be returned:
The email address constructor may determine (216) whether the email address (224) can be constructed from the query results by identifying the number of results returned from the query. In some embodiments, if the number of results returned from the query is one, then the email address (224) can be constructed from the query results. The email address (224) cannot be constructed from the query results if the number of results returned from the query is more than one. Using the exemplary query results returned above in such an embodiment, the email address constructor determines that email address (224) cannot be constructed from the query results above.
Readers will note that determining that the email address (224) cannot be constructed from the query results if the number of results returned from the query is more than one is for explanation and not for limitation. In other embodiments, the email address constructor may determine (216) whether the email address (224) can be constructed from the query results by identifying whether a single result can be identified from a set of query results based on other hint tokens or other information available to the email address constructor. For example, using the exemplary query results above and the additional hint token ‘IBM,’ the email address constructor may identify a single result ‘robert@us.ibm.com,’ thereby determining that the email address (224) can be constructed from the query results. For still further explanation, consider the following exemplary query:
The exemplary query above requests the return of the email username field and the company field in all the entries of the directory repository where the common name field ‘cn’ has a value of ‘Robert.’ Further consider that the exemplary query above returns the following exemplary query results:
Using the exemplary query results above, the email address constructor may identify a single result ‘robert’ from the exemplary query results above using the additional hint token ‘IBM’ already provided to the email address constructor. In such an embodiment, therefore, the email address constructor may determine that the email address (224) can be constructed from the query results.
The email address constructor may construct (222) the email address (224) from the query results according to the method of
In other embodiments, the email address constructor may construct (222) the email address (224) from the query results according to the method of
When the email address (224) cannot be constructed from the query results, the email address constructor may select (218) a larger subset of the plurality of hint tokens (204) and querying (220) the directory repository for an additional result using the larger subset of the query results. The email address constructor may select (218) a larger subset of the plurality of hint tokens (204) according to the method of
The exemplary query above requests the return of the email field in all the entries of the directory repository where the common name field ‘cn’ has a value of ‘Robert,’ the field ‘location’ has a value of ‘Austin,’ and the field ‘department’ has a value of ‘Customer Support.’ The following exemplary list of results may be returned:
Upon receiving the exemplary query results above, the email address constructor may determine (216) that the email address (224) can be constructed from the query results because only a single result containing an email address is returned. The email address constructor may then construct (222) the email address from the query results by selecting the email address (224) in the single query result. The email address constructor may then return the email address (224) for further processing to the email client as a return parameter for the function invoked by the email client to request the hint-based email address construction according to embodiments of the present invention.
Readers will note that in some embodiments the hint tokens included in the email address hint may each be associated with a hint token weight that is used to indicate the relative significance that a particular hint token relative to the other hint tokens. For example, a user may want to indicate that the user is confident that certain attributes describe a particular email recipient, while indicating that the user is not as confident concerning how well other attributes describe a particular user. For example, a user may be confident that the email recipient is located in Austin and is employed with IBM, but the user is less confident that the email recipient works in the Customer Support department. For further explanation, consider
The method of
As mentioned above, each hint token (204) is associated with a hint token weight (300). Consider the exemplary email address hint illustrated by the text (303) in GUI (201):
The exemplary email address hint above specified by the user through GUI (201) includes four hint tokens—‘Robert,’ ‘Austin,’ ‘Customer Support,’ and ‘IBM.’ Each of the exemplary hint tokens are associated with a hint token weight by the presence or absence of a ‘*’ after each token. A ‘*’ after a hint token in the example of
The method of
The exemplary construction directive above is a cache directive that instructs the email address constructor to bypass any data stored in a local cache when determining (210) email address for the email recipient.
In the method of
In the method of
In some embodiments, the email address constructor may not be able to determine an email address for the email recipient based exclusively on the hint tokens included email address hint because the email address constructor needs additional hint tokens to construct the email recipient's email address. For further explanation, therefore, consider
The method of
The method of
In some embodiments, the email address constructor may determine (400) whether the email address (224) can be constructed from the plurality of hint tokens (204) according to the method of
If the email address (224) cannot be constructed from the plurality of hint tokens (204), the email address constructor may prompt (402) the user for at least one additional hint token according the method of
If the email address (224) cannot be constructed from the hint tokens ‘Robert,’ ‘Austin,’ and ‘IBM,’ then the email address constructor may prompt (402) the user for at least one additional hint token. The user may provide the email address constructor with an additional hint token of ‘Customer Support.’ Using the hint tokens ‘Robert,’ ‘Austin,’ and ‘IBM,’ and the additional hint token of ‘Customer Support,’ the email address constructor may then determine (404) the email address (224) for the email recipient.
In the description above with reference to
The method of
In the example of
In the method of
Exemplary embodiments of the present invention are described largely in the context of a fully functional computer system for hint-based email address construction. Readers of skill in the art will recognize, however, that the present invention also may be embodied in a computer program product disposed on a computer readable media for use with any suitable data processing system. Such computer readable media may be transmission media or recordable media for machine-readable information, including magnetic media, optical media, or other suitable media. Examples of recordable media include magnetic disks in hard drives or diskettes, compact disks for optical drives, magnetic tape, and others as will occur to those of skill in the art. Examples of transmission media include telephone networks for voice communications and digital data communications networks such as, for example, Ethernets™ and networks that communicate with the Internet Protocol and the World Wide Web as well as wireless transmission media such as, for example, networks implemented according to the IEEE 802.11 family of specifications. Persons skilled in the art will immediately recognize that any computer system having suitable programming means will be capable of executing the steps of the method of the invention as embodied in a program product. Persons skilled in the art will recognize immediately that, although some of the exemplary embodiments described in this specification are oriented to software installed and executing on computer hardware, nevertheless, alternative embodiments implemented as firmware or as hardware are well within the scope of the present invention.
It will be understood from the foregoing description that modifications and changes may be made in various embodiments of the present invention without departing from its true spirit. The descriptions in this specification are for purposes of illustration only and are not to be construed in a limiting sense. The scope of the present invention is limited only by the language of the following claims.