METHOD AND SYSTEM FOR UTILIZING INTERNET EMAIL COMMUNICATIONS FOR GROUP COLLABORATION
CROSS-REFERENCE TO RELATED APPLICATIONS
This application claims priority from Fisher, et al . , "Method and System for Utilizing Internet Email Communications for Group Collaboration", U.S. Provisional Application No. 60/185719, filed February 29, 2000, incorporated herein by reference.
TECHNICAL FIELD
This invention relates to group collaboration, and in particular to the use of Internet email for effecting such collaboration in fields such as scheduling, document management, and email content management.
BACKGROUND ART
Email has become a pervasive mechanism for individuals to communicate in real time, whether within an organization or across the Internet. Email can be advantageous because it is generally persistent and memorializes the communication, can provide a vehicle for sending other documents such as attachments, can be viewed and responded to immediately or whenever the user desires, can be obtained and replied to instantaneously via wireless email systems such as BLACKBERRY™ by Research In Motion, Ltd, etc. Anyone with access to the Internet and an email account can utilize email to communicate with anyone else who has an email account.
Although certain enterprise-based email systems have attempted to utilize the email paradigm to effect group collaboration such as group scheduling for meetings, no solution to the problem of collaborating disparate email users over the Internet has been implemented. Thus, the inventors of the present invention have recognized the need
for the use of Internet-based email as a tool for group collaboration regardless of the location and corporate affiliation of the collaborators; as long as he or she has an Internet email account they can use email to collaborate.
Specifically, the inventors have recognized that the volume of email communications, which can be up to hundreds per day, results in a chaotic and haphazard collection of messages, both sent and received. Although prior art systems such as Microsoft Outlook allow for the user to manage the emails by manually "dropping and dragging" them into folders (or by a rules-based algorithm such as "all emails from J. Smith go into the projects folder") , such systems do not provide for intelligent email management in a group collaborative paradigm as set forth herein.
In addition, the inventors have observed that collaboration via email often results in many documents being sent as attachments, with revisions being made in a non-controlled manner, re-sent to recipients, revised again, etc. This process often results in a total lack of document control, in particular when the documents are shared over the Internet amongst multiple users. Thus, the present invention also addresses this problem of Internet document attachment version control by providing a unique way to manage email attachments as independent documents linked to messages or other documents.
The inventors have experienced and observed that there are many other activities associated with collaboration that are currently managed manually. Activities like scheduling' meetings or reminding colleagues about events are tedious and take a significant part of managers' days. This invention addresses this problem by automating the process of coordinating, scheduling, and reminding users of events such as meetings, tasks, or milestones.
Finally, the inventors have observed a trend towards workers trying to accomplish more of their daily personal and professional tasks through their email. The proliferation of services like email news and stock reports and the growth in the use of direct marketing through email have increased people's reliance on email as a way of interacting with the web. This invention enables users to conduct more of their business through email by allowing them to submit information to and access information from the system through structured and unstructured emails.
DISCLOSURE OF THE INVENTION
The system of the present invention is an Internet- based expert messaging service that interprets messages, takes certain actions for the user, and interacts with proprietary and third-party applications to support realtime and cross-company collaboration. Users will be able to interact with the system using their current messaging environment without changing their email application or email address.
The system of the invention is accessible to individual users via a website and email. The invention is intended for use by groups of users. A group is a collection of users, known as group members. Each group has an email address with the system. Group membership enables users to share resources associated with the group. These resources include files, messages, calendar events, and address book contacts . Resources are stored and organized by and on the system. Group members can interact with the system to retrieve, add, edit, organize, delete, and search group resources. All resources for a group are accessible to all members by one of two methods. The first method is via hypertext transfer protocol ("HTTP") compliant web pages viewable on any web enabled device, such as a personal
computer ("PC") or a Wireless Application Protocol ("WAP") compliant device. The second method is through a novel use of email using the simple mail transfer protocol ("SMTP") . Email can be accessed on a device such as a PC, or via a Short Messaging Service ("SMS") device. The fact that a group is addressable by email distinguishes the present invention from prior art systems such as listserv. Existing prior art provides the means for users to interact with resources via the web, but the prior art does not provided the richness of interaction through email found in the present invention.
The present invention provides the means for email to automate group tasks related to group resources. These tasks include message filing, attachment extraction, file version control, file retrieval, events scheduling, contact management, and resource searching.
BRIEF DESCRIPTION OF THE DRAWING
FIG. 1 depicts a user registration form. FIG. 2 depicts a group creation form.
FIG. 3 depicts an exemplary group page.
FIG. 4 depicts an email message for initiating a search of a group's resources.
FIG. 5 depicts an exemplary HTML form returned to a member in response to a file request.
FIG. 6 depicts an exemplary form for creating a folder.
FIG. 7 depicts an exemplary form for creating filing rules.
FIG. 8 depicts a group's Messages page.
FIG. 9 depicts an HTML form displaying the content of an email message.
FIG. 10 depicts an email message for requesting a document from the system.
FIG. 11 depicts an exemplary form used for creating an event . FIG. 12 depicts an exemplary events page.
FIG. 13 depicts an exemplary form used for adding a contact. FIG. 14 depicts an exemplary contacts page. FIG. 15 depicts an HTML form displaying a detailed contact listing.
FIG. 16 depicts an HTML form displaying a detailed event listing. FIG. 17 depicts an exemplary HTML form used for searching a group's resources from the web. FIG. 18 depicts a web page displaying information about a file. FIG. 19 depicts a web page displaying information about a group. FIG 20(a) depicts the use of the "Cc" line to send a message to a group.
FIG 20(b) depicts the use of the "Cc" line to send an attachment to a group. FIG. 21 depicts a web page used to schedule a meeting vis email . FIG. 22 depicts a web page returned to a user in response to a search command.
FIG. 23 depicts the contents of a group's Documents folder. FIG. 24 depicts a flowchart of the steps involved in processing an incoming message
BEST MODE FOR CARRYING OUT THE INVENTION
Users become part of the system by registering with the system. A registration form presented to the user at the system's website is depicted in FIG. 1. A user must provide a valid existing email address in field 103 and choose a user ID and password, entered in the user name field 101 and password field 102. The preferred embodiment of the system also asks the user to enter a first and last name in fields 104 and 105, respectively, and to enter a security question and answer in fields 106 and 107, respectively, to aid the user in remembering the password. The user completes the
registration process by clicking the "Register" button 108. The user' s existing email address verifies their identity and account when accessing the system via email. The user ID and password verifies the user's identity and account when accessing the system via the web.
Each time a user accesses the system via the web, he is presented with his Groups Page, an example of which is depicted in FIG. 3. This page provides links to all groups to which the user is a member. The page provides summaries of how many resources are available to each group. In the example page depicted, the user is a member of the "Advertising" 301, "Maintenance" 302, and "New Product" 303 groups. The "Administrator" labels 304, 305, and 306 below the group name labels 301, 302, and 303 indicate that this group member is an administrator for each group shown. The "New" columns 310 alerts the user to any new group resources. For example, the "Advertising" group has one new contact. Contacts are explained below in this disclosure. By clicking the "Edit Personal Info" button 311 at the bottom of the Groups page, a user can specify any additional email address from which he wishes to access the system.
Groups
Groups become part of the system when they are created. A group is created by a user referred to as the group initiator or group manager. The group initiator creates the group from the website by clicking on the "New Group" button 312 on the Groups page, depicted in FIG. 3, and filling out the HTML form that subsequently appears, referred to as the New Group page, depicted in FIG. 2. This form asks for the following information.
1. A name for the group, entered in the "Group Name" field 201.
2. An email address for the group, entered in the
Group E-mail" field 202 .
3. The names and email addresses for all the group's members, entered under the "Invite Members" heading 203.
4. The level of access each member should have, entered in the "Access" field 204.
The group' s name is a simple text string that can be changed at a later time. The group's email address is the address members will use to access the group's resources via email. This is discussed in detail below. The group initiator chooses the portion of the address that appears before the "@" sign. The domain portion of the address is the location of the email server being used by the system.
The email addresses of members are required in order to verify who can access the group's resources. When a member is added to the group, the system checks to see if the member is a registered user. If the member is a registered user of the system, he is automatically added to the group. If the member is not a registered user, the system emails the new user an invitation to the group and the system. To use the system, the new user is required to register on the website. At registration, the user chooses his user ID and password.
The access levels determine how much access to group resources each member should have. The current embodiment of the invention supports three access levels, although more or fewer access levels can be supported.
The highest access level is referred to as the administrator level. An administrator has total control over the group, and can add, edit, or delete any of the group's resources and settings. Settings include membership information, folders, and filing rules. Membership information includes who is a member and what access level each member has. The administrator can also control access to specific resources. For example, the administrator could
prevent a specific group member from viewing a specific resource, such as one specific file. The group initiator automatically has administrator access.
The next level of access is referred to as the contributor level . A contributor can add and retrieve group resources, but cannot change group settings.
The lowest access level is referred to as the reader level. Reader members can only retrieve group resources.
Once a group is created, members can access it via the web or email. Space is created in the system to hold resources . Group members can log in to the system from the web, after which they can access pages for the group's resources from the Groups page. Group setting information is available by clicking the group's name. An HTML form, an example of which is depicted in FIG. 19, appears displaying the group's settings. A member with administrator access level can edit this information by clicking the "Edit Group" button 1901.
It is the group' s email address that provides the system's greatest novelty. There are prior art systems that allow a user to access similar resources via the web. However, these systems make only a limited use of email, if any. There are other prior art email systems, such as, for example, listserv, but these systems function primarily to forward email to those addresses on a subscription list, and cannot perform other actions based on email commands. Through the group's email address members can access and add resources to the group. The system will automate certain tasks in the process of resource addition and retrieval. The functionality needed to process email requests is described in "METHOD AND SYSTEM FOR PROCESSING REQUESTS USING DYNAMICALLY LOADABLE RULES DETERMINED BY CLASS AND CONTEXT", U.S. Patent Application No. 09/715,470, filed November 17, 2000, by Mellin, et al . , incorporated herein by
reference. The system of this related invention uses the group's email address to determine the context for processing. Incoming email is evaluated by the group's filing rules, which in turn perform actions based on the content of the message's To, Cc, From, and Subject fields, the message's body, and any attachments in the body.
Members send messages sent to the group' s email address and these messages can trigger a variety of actions related to the group's resources. These actions involve simple filing actions as well as tasks triggered by Natural Language Processing ("NLP") , and are described in the following sections. Note, however, that messages sent to the group' s email address are not automatically forwarded to other group members. In addition, as previously mentioned, the system is accessible via the web. An important aspect of the invention is that the system can be accessible via multiple interfaces, for example, a web browser or an email client, as well as multiple communication channels, such as HTTP, WAP, SMTP, and SMS compliant devices. The most novel aspects of this invention comes out of its use of email.
Messages, Folders and Filing Rules
In a preferred embodiment, each group is provided with a Messages page, depicted in FIG. 8, which provides group members with web access to messages, files, folders, and filing rules. The Message page can be accessible from other pages by clicking on an appropriate link, such as one of the "Messages" links 321, 322, 323, on the Groups page, shown in FIG. 3, or the "Messages" tab 324 on the Groups page or on any other page. A key advantage of the invention is its storage and automatic organization of messages and files. Members add, organize, search, and retrieve messages and files in the common group storage space. This is done via web pages or email.
Files and messages are added to the group when members send them to the group's email address. Once added, files and messages are stored in folders. In a preferred embodiment, each group has system default folders, and user- defined folders. In a most preferred embodiment, each group has two default folders, referred to, respectively, as "Unfiled" and "Documents." The "Unfiled" folder contains all messages that are not in a user-defined folder. The "Documents" folder contains all files that were sent in as file attachments or that were uploaded through the website. In an alternative embodiment, files can also be filed in user-defined folders, and the "Documents" folder only contains files not in a user-defined folder.
The user-defined folders are created by the group initiator or any other member with administrator access level by clicking on an appropriate button. In one preferred embodiment, this can be the "Edit Folders" button 801 on the Messages page, depicted in FIG. 8, although other implementations are within the scope of the invention. A web page for creating a folder, referred to as the Message
Folders page, depicted in FIG. 6, will appear. User-defined folders are used to organize messages. For example, in a group developing a new product, the following folders could be set up, as shown in FIG. 6: "Design", "Marketing", and "Testing", as depicted in fields 601, 602, and 603, respectively. Each folder contains appropriate messages. From the web, a member with administrator access can move a message to a user-defined folder. Through email, messages are added to folders by members based on message content, NLP, and filing rules as described below. Once created, a folder's name is displayed on the Messages page FIG. 8. A particular folder can be selected by clicking on the folder's name, at which time a list of the folder's messages is displayed on the Messages page. For example, in the Messages page shown, the name of the "Marketing" folder 802 has been selected, and a list of the messages in that folder
appears in listbox 803. In the embodiment shown, the listbox displays the subject, sender and sent date of each message .
Each folder can be associated with filing rules. Filing rules help automatically place incoming messages into a user-defined folder. A filing rule specifies that if a message contains certain keywords or concepts, then the message belongs in a specific user-defined folder.
Filing rules are defined by a group administrator. In one preferred embodiment, the group administrator can create a filing rule by first clicking on the "Edit Rules" button 604 on the Message Folders page, depicted in FIG. 6, or the corresponding button 804 on the Messages page, depicted in FIG. 8. An HTML form, referred to as the Auto-Filing Rules page, shown in FIG. 7, appears. The administrator can enter keywords in the "keywords" fields 701 opposite each folder name 702 on the form, and when finished, click on the "Save" button 703. Other configurations for defining filing rules are possible, and the invention is not limited to the embodiment described herein.
When messages are received by the system, the headers are processed as described below in this disclosure. The majority of messages received by the system are messages or documents that users wish the system to automatically file into user-defined folders. However, some messages do not require filing, such as commands instructing the system to do something, as explained below, and so the system must first determine if a message requires filing. Once the system decides to file a message, the filing rules are applied and NLP is performed, as described under the next sub-heading. A flowchart depicting the steps involved in processing an incoming message is shown in FIG. 24.
Natural Language Processing The user-defined filing rules give the system an idea of the messages that belong in each folder. These rules
help the system evaluate the subject line and body of an incoming message. In addition to filing rules, NLP is used to improve upon the keyword filing. NLP solves the problem of the user who creates the filing rules not being able to anticipate all the keywords that would cover the topic of a given folder. NLP creates a text profile of an incoming message that improves the keyword list (the original text profile of the fiolder) by adding to the keyword list words that have been shown to relevant in the context of the other messages in the folder.
A text profile is an analysis of a message's content for use by the system. It is a statistical summary of important words, synonyms, and concepts contained in a message, which make it useful for organizing and searching. A search engine indexer is used to extract content from a message and the resulting text profile is stored in a text profile database that is part of a group's resources and is used by the search engine.
The text profile of a message is created through an analysis that selects the most relevant words, synonyms of these words, as well as the most relevant concepts expressed by those words . This is done by looking at the frequency of words/concepts both within a message, referred to as the term frequency ("TF") , and across all messages within a folder, referred to as the inverse document frequency
("IDF") . The weight of a word or concept within a message is then calculated from these frequencies by means of the similarity formula TF*IDF, and the words of the message are then sorted by weight. The sorted words/concepts are then compared against the keywords for the folder and the weight of the word or concept in the text profiles for messages contained in each folder. The similarity formula is described in Salton, Gerard and McGill, Michael J., "Introduction to Modern Information Retrieval", McGraw-Hill Book Company, 1983, the contents of which are incorporated herein by reference.
Text profile creation also considers the position of words in regard to other selected words, information for identifying multiple words that really express one idea, the total number of words, the clustering and dispersion of words, and synonym look ups . Once selected, words are stemmed down to their root forms, as opposed to their infection forms . One stemming algorithm well known in the art is the Porter stemmer algorithm, described in Porter, M. F., "An Algorithm for Suffix Stripping", Program, Vol. 14, No. 3, July 1980, pp. 130-137, the contents of which are incorporated herein by reference. In addition, spell checking can correct frequently misspelled words when there is an obvious correction.
Another aspect of creating a text profile involves organinzing words in a message into hierarchies of concepts. For example, a "puppy" is a type of "dog" and a "dog" is a type of "canine." Through this embedded hierarchy of knowledge, known in linguistics as an ontology, the system can match the most relevant words to the keywords or concepts specified in filing rules created by a group administrator. The ontology expands the keyword list (i.e. the text profile) by going up and/or down the hierarchy. This can be performed interactively by the group administrator during a web session or via email. In a preferred embodiment, the system automatically reminds the group administrator via email that the text profile of a folder can be improved. The use of ontologies is described in McGiunness, Deborah L., "Conceptual Modeling for Distributed Ontology Environments", http: //www. ontology.org/main/papers/iccs-dlm. html .
Message filing is done by comparing words in a new message's subject line against the various user-defined rules, and by comparing the message's text profile with the text profile database of existing group messages on a folder by folder basis. The message is then filed in that folder whose filing rules and text profile most closely match those
of the new message.
For example, consider a group with a user-defined folder called "Canines". A group administrator creates a rule to file all canine related messages into this folder. A message comes to the group with a subject of "Reasons to Love Your Golden Retriever." The text profile of the message body extracts words such as the following as the statistically most relevant through number occurrences and other criteria: loyal, love, friendly, hungry, drools, golden, retriever, golden retriever, puppy, pet, dog, children, and feed. The procedures that created the profile have the intelligence to know that when used together, the words "Golden" and "Retriever" can constitute one semantic element, namely a breed of dog. Based on a statistical analysis of how many times each word appears in the text profile and whether the words match the message subject, the invention can determine that the most relevant words are probably "Golden Retriever". The use of an ontology would find a match with "Canine" since a "Golden Retriever" is a "Dog" and a "Dog" is a "Canine". The presence of other related words such as "puppy" lend support for the system' s conclusion.
Thus, the correct folder for a new message is determined by matching concept and word frequency in the new message against both filing rules and the text profiles of messages currently contained in user-defined folders. Text profiles of other messages contained in the "Canine" folder would likely contain a high frequency of terms such as "puppy" and "dog". Therefore, similar messages are grouped together based on the frequency of concepts in the text profile database created from past text profiles.
There are obviously cases where the system cannot draw a clear conclusion. In addition, subjects and text profiles do not always contain matches to keywords. The system relies heavily on the subject lines as containing the most relevant information. If the system cannot determine a
correct folder, the message is placed in the default "Unfiled" folder. An administrator can later move the message to a correct user-defined folder. In an alternate embodiment, a message with subject keywords or message content that match more than one foldering scheme could be linked to more than one folder.
Although the system is not always correct in it's filing choices, it makes highly educated guesses based on statistical analysis and linguistic processing. This automatic filing has a clear benefit to users. It spares the user from the tedious exercise of manually organizing email .
Thus, the original filing rule for a folder serves as the seed for the folder's text profile. As the folder becomes populated with messages or files, NLP helps update the folder's text profile. Over time, automatic filing of a group's messages becomes smarter, because the more messages in a folder, the more comparisons can be made. When an administrator manually moves a message to a new folder, the text profile of the moved messages becomes associated with the new folder. Thus, any new messages similar to the moved message would then be filed in the same folder as the moved message. In fact, if enough messages are distributed into appropriate folders, filing rules would not be needed. The text profile database could be used to file messages entirely based on existing message organization.
In the previously mentioned alternative embodiment where attached files are also filed into user-defined folders, filing rules and NLP can act on certain files. The text portion of file types such as MS Word, PDF,
WordPerfect, HTML, or Rich Text is temporarily converted to a pure ASCII text file. The filing rules and NLP process this temporary text file in the same manner as a message body. Once acted upon, the original, non-ASCII file is placed in an appropriate folder. In a further alternative embodiment, non-text or binary file attachments, such as
video, image, or sound files, can be placed in an appropriate user-defined folder based on the file type of the attachment.
Sending and Retrieving Messages
Members add a message or file to the group by sending it to the group's email address, as depicted in FIG. 20(a). When the email is received by the system, the headers are processed first. The "To" or "Cc" line determines which group a message belongs to. The message depicted in FIG. 20(a) shows the group address in the "Cc" line 201. The "From" line determines if the sender' s email address is valid for the group. Only those group members with administrator or contributor access levels can add messages or files to the group. If the "From" line does not contain the email address of a member with the appropriate access level, the message is rejected.
The "Subject" line is examined for email commands, discussed below, and is analyzed as part of the automatic filing process. In addition, the first few lines of the message body are searched for email commands as discussed below and any file attachments are extracted and filed in the default Documents folder. Once file attachments are extracted, the body is analyzed for automatic filing. In an alternative embodiment where attachments are filed based on content and type, the attachments are analyzed and filed as well .
The majority of email sent to a group is meant to be filed and stored. The message management functionality of the invention is used to build a common repository of email information. Group members sending messages between each other can send copies of their messages to the system by placing the group's address in the "Cc" line, as shown in FIG. 20(a). Thus, messages normally accessible only to their specific recipients are placed in the common group
repository. Information previously lost is collected in one place . Group members can read and search email in the repository to find answers to group related questions .
This use of cc'ing a message to the group address is a key component of the invention. It allows group members to more effectively maintain information without changing the way they currently work. By simply cc'ing the group address during normal correspondence, group members can maintain their existing email addresses. Group members can also send files to each other as email attachments, as depicted in FIG. 20(b). By cc'ing a copy of the email containing the attachment to the group address, as shown in the "Cc" line 202, these files are added to the group. This provides similar benefits as sending email to the group, as previously described.
An additional benefit is received through automatic file and message separation. A novel aspect of the invention is its separation of email attachments from originating messages. When a file is sent via email, the file becomes a part of the email message. Although users tend to perceive files as attached to messages, and the term attachment is widely used, a more accurate term would be embedded. This invention automatically extracts the embedded files from messages. It then treats each extracted file as a separate entity from its originating message. In addition, the system displays links allowing users to easily link from messages and files that originated together. Current prior art email management systems require users to manually extract and save file attachments . Once manually extracted, these systems do not provide a tracking mechanism such as links between originating files and messages.
In addition, the system provides file versioning to maintain the various versions for each file. Every file with the same name is grouped together and classified based on the date it was sent to the system. Thus, members can
track file changes and retrieve versions that are often lost.
In addition to email, files can be added to a group through the systems' website. In one preferred embodiment, this can be done by clicking on the "Upload Document" button 805 on the group's Messages page, shown in FIG. 8. The user will then be prompted to enter a document name.
Once a message or file is in a group's folder, it can be retrieved via email or the web. In a preferred embodiment, a member can log in and view a message list on the group's Messages page, FIG. 8. In this embodiment, the subject line, sender, and arrival date for each message in the selected folder are displayed in, respectively, the "Subject", "From", and "Sent" columns 803, 806, 807, on the Messages page. A member can sort the message list by clicking on the various column headings. A member can view a message by clicking on its listing on the page, after which a page appears displaying the message's content, header information, and any file attachment links. An example of such a page is shown in FIG. 9.
Members with administrator access can move a message into a different folder by clicking the "Move" button 901 and selecting a folder in the box 902, or delete a message entirely by clicking the "Delete" button 903. They can also add, edit, or delete user-defined folders and keywords.
From the web, documents are accessible in several ways. Selecting the Documents folder 808 on the Messages page displays a list of all files in the group, as shown in FIG. 23. To download or view additional information about a file, a user clicks it's listing. A page appears, depicted in FIG. 18, which links to the originating message, displayed next to the "Attached to:" label 1801, links to the sender of the file, displayed next to the "From" label 1802, and allows a user to download or forward the file. To download a file, members click the file's name 1803 and the
file is transported to the user via the web. To forward a file via email, members specify the recipient's email address in the "to Email Address" text box 1804 and click "Forward Attachment" button 1805. In addition, each file's page lists any other versions of the file 1806. These file versions are accessible from any other version. In addition, files sent in as attachments are accessible from links on their originating message, as shown in the attached field 904 in FIG. 9. Use of email to retrieve files and information is a novel aspect of the invention. This is accomplished by sending an email command to the system. Email commands are a flexible set of commands that can be initiated by a user through email. They are short predefined text messages that cause the system to take an action, other than filing the incoming message. These text commands must appear in either the message subject field, or the beginning of a message body.
For example, in one preferred embodiment, to retrieve a file from a group via email, a member sends an email to the group with the following email command text in the subject line: "Request Document". An example of this email request is illustrated in FIG. 10. In this embodiment, the system creates an HTML page containing a list of all the group' s files with a check box next to the name of each file and a submit button at the end of the page. The HTML list is emailed by the system to the member's email address. An example of the HTML list is illustrated in FIG. 5. The member receives the emailed HTML list and checks the boxes 501 for the files he wishes to receive. He can also enter an email address in text box 502 to which to forward the file. The member than clicks the "Submit" button 503 within the HTML email. This returns his response to the system. The system receives the response and sends the requested files to the member by email.
This entire email interaction is accomplished using SMTP and not HTTP. The HTML form sent from the system to the member's email client is a static file. The submit button uses the "mailto:" method to return the message to the group's address. This means that no connection to a web server is required.
The "Request Document" command just described is but one possible method for a user to request files from the system and other variations are, of course, within the scope of the invention. In addition, the preferred embodiment of the invention currently supports other more complex variations of the above command. For example, the system allows a member to request a specific document through the following command: "Request Document: [document_name] " . Thus, if a group member sends "Request Document: New
Features.doc" to the system, the system will return to the member an HTML form listing the names of all matching versions of the document.
In addition, the system makes educated guesses as to other possible files by performing Natural Language
Processing on the requested file name. Referring to the previous example, if the file "New Features.doc" is not found, the list of files will contain files with similar names and similar spellings. For example, if the group contained the following files, their names would appear in the list: "Newest Features.doc", "New_Features.doc", "New Fetures.doc", etc.
The system also allows members to request the system to forward files to another email address. This can be accomplished through the following command: "Request
Document: [document_name] : [to recipient ' s_email_Address] " . Once again, other variations on the syntax of this command are possible, and the invention is not limited to the syntax illustrated herein. All of these "Request Document" command variations
require a member to have an HTML compatible email client.
From a text based email client, such as a cellular telephone, a member can obtain information regarding received email by sending the following command: "Any mail". The system returns a brief text message to the user's email client stating how many files and messages have arrived to the group's email address. An example of this message is the following: "New: 12 messages, 2 documents." By default, it says how many have arrived in the past 24 hours. A variant of this command allows a member to ask how many new messages have been added since a certain day of the week. For example "Any mail since Fri" returns the number of new messages and files since the last Friday. These simple text based answers are ideal for SMS devices such as cellular telephones.
A more advanced command allows users to view summaries of recent messages. For example, sending an email message to the group with the command "request summary" returns to the sender the most important information about recent messages sent to the group address. Upon receiving the
"request summary" command, the system uses the text profile information and weights extracted from the similarity formula to extract the most important sentences from messages sent to the group. Methods for summarizing text content are well known in the art. One such summarizing product is Summarizer SDK, a product of Inxight Software, Inc, http : //www . inxight . com/products_sp/summarizer_sdk/index . html
Once the summaries are built, they are returned to the requesting user as a single email text message. Each summary contains the "From" line, "Subject" line, any attachment names, and the summary. An example of a returned summary is "From: user@companyname . com -Subject: Reasons to Love Your Golden Retriever. -Attached: Golden. jpg -
Summary : Golden retrievers are a highly affectionate breed,
ideal for a family with small children."
One embodiment of the invention returns summaries for all messages sent in the past 24 hours, up to a maximum of 50 messages. This invention is not, however, limited to this number, and more or fewer messages can be returned. Since SMS devices, such as cell phones, display only a limited number of characters in a message, only one or two summaries will be displayed on these devices
Other variations on the summary command syntax are possible. For example, a user can request messages from a particular folder via a command such as "request summary in <folder-name>", or the user can request messages sent to the group on a particular day using "request summary on <Day-of- week>". For example, the command "request summary on fri" returns summaries of email sent to the group on the most recent Friday. The invention can support combinations, such as the command "request summary on fri in <folder-name>" to return summaries of all messages sent to the named folder on the most recent Friday. Date ranges can also be specified via a command such as "request summary on mon to fri" or "request summary on 1/1/01 to 1/7/01". Other possible variations on date ranges include "request summary for today", "request summary for yesterday", "request summary for 3days", etc. In another variation of the command syntax, day names can be replaced with the first two letters or full spelling of each day name . Other commands can filter summarized messages based on the "From" or "Cc" lines of messages. One example of such a command is "request summary from <email-address>" . This command summarizes the last 50 messages sent to th e group from the specified email address. An alternative form of this command could be "request summary from <user-name>". The invention is not limited in scope to the command syntax presented herein, and other variations of the command syntax are possible.
Scheduling
The system provides a means for members to manage shared calendar events. Events include meetings, milestones, and tasks. In addition, each message or file sent to the group is considered an event. Events take place on a certain date and involve other members . The system can send out reminder emails to members as an event date approaches .
Events can be created via either the web or email, by a member with either administrator or contributor access.
To schedule via the web, a member clicks on a link such as the "Events" tab 809 on the Messages page, FIG. 8, and enters information into an HTML form that subsequently appears . In one preferred embodiment of the invention, a • member can click on an "Events" link on the Groups page, or on an "Events" tab on any other page. An example of the HTML form presented, referred to as a New Event form, is illustrated in FIG. 11. The information entered includes the event type, a name for the event in "Title" field 1101, the start time or due date for the event in the "Starts" field 1102, the end time for the event in the "Ends" field 1103, and the participants in text box 1104. Optionally, the member can associate files with the event in the "Related Files" text box 1105, choose when the event re- occurs by checking button 1107 or set up a reminder by checking button 1106.
To schedule via email, the member emails the group's address with an email command in the subject line or beginning of message body. In one preferred embodiment, the possible commands include, respectively, "Request Meeting", "Request Milestone", or "Request Task". When the command is received by the system, the member is emailed an HTML form to fill out. This form, depicted in FIG. 21, is similar to the HTML form available on the website, with an additional button referred to as a submit button 2101. Once the form is filled out, the member clicks the "Submit" button 2101 on
the form to return the form to the system. The event is then scheduled.
Events can also be scheduled via email, using vCalendars®. A vCalendar® is an electronic format for exchanging calendar and scheduling information between independent applications. More information on vCalendars® is available at www.imc.org/pdi, the contents of which are incorporated herein by reference. To use vCalendars®, a member creates an event in an application that supports vCalendars®, such as Microsoft® Outlook®. The member. can then export the event by saving the event as a vCalendar®. Once exported, the vCalendar® is a file that can be sent to a group's address as a file attachment. When the file is received, the event is automatically added to the group' s calendar of events .
Once scheduled, members become aware of the event through an email notification. The system sends all participants an email with an attached vCalendar® for the event. This vCalendar® can then be imported into an application such as Outlook®. In addition, as the event date approaches, the system can send reminders to participants .
In addition, event information can be viewed on the web through the group's Events page, depicted in FIG. 12, which is accessible from either the Groups page or other pages associated with the group. A detailed description of the event, as shown in FIG. 16, can be viewed by clicking on the event's listing 1201 on the Events page shown in FIG. 12. From this page a member can download a vCalendar® for the event .
To delete, reschedule, or edit an event, an administrator or the member who created the event can click the "Edit" button 1601 shown in FIG. 16.
A user can also discover if there are any new events through email commands. The preferred embodiment of the invention currently supports several email commands that can
be used to discover event information. For example, the command "Any event?" causes the system to return a text message to the requesting member listing any events scheduled for the current day. This returned message includes information about the events, such as the start time and location, for example, "Meeting - Title: Budget Plan - Location: Conference Room A - Starts: 2:00 PM - Ends: 3:00 PM." As another example, the command "Any events Fri" returns a listing of any events scheduled for the next Friday. Many other variations of these commands are possible, and the invention is not limited to the commands illustrated herein.
Contacts The system provides a means for members to share lists of contacts . A contact is a person' s name and email address, not necessarily that of a group member. Members establish contacts to share with the group from either the web or email . Each group member is automatically a contact. In addition, contacts can be manually added on the web or automatically added by email.
To add a contact via the web, a member clicks on links and fills out information in an HTML form, referred to as the New Contact page, depicted in FIG. 13. In one preferred embodiment of the invention, a member can click on a "Contacts" link 325 on the Groups page, shown in FIG. 3, or on the "Contacts" tab on any other page. The information entered into the HTML form shown in FIG. 13 includes the person's first and last name in text fields 1301 and 1302, respectively, and email address in text field 1303.
To add a contact via email, a member simply emails the group address a vCard® as a file attachment. A vCard® is an electronic format for exchanging address book information
between independent applications. More information is available at www.imc.org/pdi, previously incorporated herein by reference. This vCard® can be exported from applications such as Outlook®. A vCard® sent as an attachment is extracted from the message and turned into a contact. This automated creation of a contact list by extracting attachments from email is a novel aspect of the invention.
In addition, contacts are automatically created from message headers. Each time a message comes to the group's email address, the system scans the headers (To:, From:,
Cc:) . If a message sent from a member to the group contains email addresses of non-contacts in the headers, new contacts are automatically created. For example, a message From a valid member address is sent To: Joe Smith (jsmith@companyname.com) , and cc'ed to the group. The group does not have a contact for Joe Smith ( smith@companyname. com) , so a new contact is automatically created.
Once created, a list of contacts can be viewed on the web from a Contacts page, illustrated on FIG. 14. This page is accessible from various other pages associated with the group. A detailed contact listing, illustrated in FIG. 15, can be viewed by clicking on the contact's entry on the Contacts page. From the detailed listing, members can download a vCard for the contact.
Searching
The system of the invention also provides search capabilities for all group resources. Group members can search for messages, files, events, or contacts from either the web or email.
Searches can be initiated from the web by clicking on the appropriate links. A user can perform a search of any group of which that user is a member. In a preferred embodiment, a member can click on a "Search" tab 326 on a
group page such as that shown in FIG. 3 to invoke a Search page, depicted in FIG. 17. On the Search page, the member specifies which groups to search in the "Search" field 1701, checks the boxes 1702 for which resources to search, and enters the search text in the "For" field 1703.
The system searches file names, message subjects, text portions of message bodies, contact names, contact email addresses, and event titles. In addition, the system searches the content of certain files types such as MS Word, PDF, HTML, and Rich Text Format. Once the system has searched the selected group's resources, an HTML page appears, depicted in FIG. 22, that displays links to items found by the search. Members can click on the links to access the found resources. The use of email to search group resources is another novel aspect of the invention. A member can initiate an email search by sending an email command to the system in the messages' subject line or the beginning of the message body. In one preferred embodiment, this command can take the from "Request Search search_text" . An example of such an email message is depicted in FIG. 4, in which the search_text is the word "Error" in the subject line 401. This will cause the system to search all resources for the word "Error". The system generates an HTML list of the search results. This HTML list is returned to the requesting member via email. The member can retrieve an item by checking its box on the list and clicking on the "Submit" button.
In one preferred embodiment, the system of the invention is implemented in an object orientated language, such as Java or C++, although non-object languages, such as C, can also be used. The invention executes on a server running the Sun Solaris operating system. In this preferred embodiment, a relational database such as the Oracle
database management system is used to store user registration information, group information, and links to messages and files stored in the groups file folders. The invention is not limited to this embodiment, however, and can be implemented in any appropriate language on any TCP/IP enabled computer, including Windows, Apple's Macintosh, and machines executing the Unix or Linux operating systems. In addition, any relational database management program can be used. The system of the invention is not limited to the embodiment disclosed herein. It will be immediately apparent to those skilled in the art that variations and modifications to the disclosed embodiment are possible without departing from the spirit and scope of the present invention. The invention is defined by the appended claims.