Information organization and collaboration tool for processing notes and action requests in computer systems6026410Abstract A natural language-based information organization and collaboration tool for a computer system is disclosed. The present invention includes an apparatus and method for processing text expressions in a computer system, the apparatus including: 1) an object database defining an information object with an associated keyword; 2) a user input device for receiving an input text expression; 3) a parsing device for identifying the keyword in the input text expression, the parsing device including functions for linking the input text expression to the information object based on the keyword identified in the input text expression; and 4) a user output device for displaying to the user the identity of the information object to which the input text expression was linked. The apparatus of the present invention further includes supplemental information in the object database which is related to the information object, the user output device further including functions for displaying the supplemental information when a corresponding keyword is identified in the input text expression. The apparatus of the present invention further includes a method and apparatus for collaboration between users of a time and project management system. Claims We claim: Description FIELD OF THE INVENTION
______________________________________
Date Description Parses to This Date
______________________________________
today Mon., 6/10/96
this morning/afternoon/evening
Rule: Parse to current
date
tonight
tonite
tomorrow Tues., 6/11/96
tomorrow morning/afternoon/
Rule:Parse to the current
evening/night date + 1 day
[0]6/10 Mon., 6/10/96
[0]6-10 Rule: Parse to the current date
or the nearest future
occurrence of the specified date.
[0]6.10
June 10
June 10th
June ten[th]
ten[th] of June
[0]6/10/98 Wed., 6/10/98
[0]6-10-98 Rule: Parse to the specified
date.
[0]6.10.98 Note: The parser must be
configured for European
locations to enable handling of
the DD/MM/YY date format.
June 10, 1998
10 June 1998
two days* from today**
Wed., 6/12/96
Rule: Parse to the
Specified starting
date ("today," etc.) +
specified increment
("two days," etc.).
in/within fourteen days*
Mon., 6/24/96
Rule: Parse to the
current date + specified
number of days or
weeks. Adding
months will yield the
same day of the month
(if possible), x months
later. In other words, "2
months from "june 4.sup.th,
96" will yield "August
4th, 96". "one month
from May 31.sup.st 38 , will
yield "June 30.sup.th " (the
last day of the month,
since June 31.sup.st does not
exist). Similarly, "five
years from 5/5/94" will
yield "5/5/99".
Monday Mon., 6/17/96
this Monday Rule: Parse to the next
occurrence of the
specified day; never the
current date. For
example, Tuesday" is
Tue, 6/11/96.
this coming Monday
next Monday Mon, 6/17/96
Rule: Parse to:
1. "next <day>" is
specified during the next
week, using Monday as
the first day of the week.
2. "On a Sunday, "next
<day>" parses to the
specified day during the
2.sup.nd week following the
Sunday (i.e., the week
beginning eight days
from the Sunday) -
except for Sunday, which
parses to the Sunday that
is one week away.
first*** Monday of next month
Mon., 7/3/96
first*** Monday of/in July
Rule: Parse to the first
occurrence of
the specified day during
the next month on the
calendar.
first*** Monday of June, 1995
first*** Monday of June, 95
first*** Monday of 6/95
______________________________________
*Could specify "weeks," "months," "years," "Mondays," "Tuesdays," etc.
instead of "days
**Could specify "tomorrow," "next Thursday," etc. instead of "today
***Could specify "second", "third", "fourth", "fifth", and "last".
Recurring events can occur on a daily, weekly, monthly, annual basis. The keyword and date/time parser 810 also handles the entry of recurring events. The keyword and date/time parser 810 recognizes the following types of recurring event specifications and associated date-related keywords or key expressions. Note that other forms may similarly be handled. every day* every other day* every three days* every Thursday every weekday (every Monday, Tuesday, Wednesday, Thursday, and Friday) every weekend (every Saturday & Sunday) every other weekend every other Thursday Tuesdays (every Tuesday) weekdays (every weekday) first Thursday of every [other] month first Thursday of every three months fifteenth of every month *"day(s)" can be replaced by "week(s)", "month(s)", and "year(s)". Note that recurring dates are assumed to occur forever in the preferred embodiment. The keyword and date/time parser 810 always picks an intelligent starting date, but does not report an ending (late. For example, assuming that today is Monday, 6/11/96, "every Tuesday" will be interpreted by the parser 810 as "every Tuesday" starting Tuesday, 6/12/96 (the nearest weekday starting from today). As with dates, abbreviations and numerical/ordinal substitutions are correctly interpreted. DLL Interface of the Preferred Embodiment of the Present Invention The following section describes the interface to the parser 300 dynamic link library (DLL) component of the preferred embodiment of the present invention. The generic use of DLL's is well known to those of ordinary skill in the art. The parser 300 of the preferred embodiment is composed of a single DLL. In this embodiment, the DLL is written in the C++ programming language. It will be apparent to those of ordinary skill in the art that other programming languages, such as C, Basic, etc., may alternatively be used. The parser 300 capabilities of the preferred embodiment include the following: Date and time parsing. Recurring event parsing. List, project, and contact parsing via keywords. Suggestions of list, project, and contact keywords. Automatic Completion (auto-complete or auto-fill) of list, project, and contact names. This process is similar to a conventional "quick fill" technique designed to assist the user by completing the partial entry of data based on previously entered data. Collaboration parsing. From the point of view of parser 300, date and time parsing requires no special knowledge of data. On the other hand, parsing, completing, and suggesting keywords, lists, projects, and contacts requires explicit knowledge of the existing or predefined lists, projects, contacts, and keywords. The parser 300 of the preferred embodiment is data-independent. In other words, it is not aware of any files or databases. Therefore, the parser 300 must be initialized with lists, projects, contacts, and keywords. The initialization process usually occurs during the boot time of the application that uses the parser 300, or when the application switches to another set of data. The following pseudo code illustrates a typical initialization of the parser 300 of the preferred embodiment:
______________________________________
declare list, project, contact, keyword as strings
for every list in database
AddList(list)
for every project in object database
AddProj ect(project)
for every contact in object database
AddContact(contact)
for every keyword in object database
AddKeyword(keyword, list, project, contact)
______________________________________
After this initialization, the parser 300 knows about all the lists, projects, contacts, and keywords. It is now able to correctly auto-fill, parse, and suggest keywords upon request from the client. Of course, the parser 300 must be kept in synchronization with the data in the object database 850; changes in the object database 850 should be reflected in the parser 300. Updates are accomplished using Add, Delete, and Rename function calls. As an example, consider the following situation: a user deletes an existing project named "Paint Fence". The application removes the project from the object database 850 and removes (or updates) its associated keywords. This change must be reflected in the parser 300 and can be done with a single function call as follows: DeleteProject("Paint Fence"); This single function call will remove the project and any references to it from the parser 300. The project name will no longer auto-complete and all of the keywords that are associated with the "Paint Fence" project will be automatically removed or updated. Note that DeleteProject(), AddProject(), and RenameProject() return values indicating success or failure of the function. For the sake of simplicity, the previous examples ignore the return values. The Rename functions support renaming of lists, projects, contacts, and keywords. Renaming a list ("list" is used as an example--it can be replaced by "project" or "contact") is easily done in the object database 850. It is effectively a simple database update operation. Because the list has a primary key in the object database 850, and the keywords that are associated with the list are related to the list via this key (rather than the list's name), modifying the name of the list will not affect its associated keywords. In other words, the keywords will remain linked to the list after the name change. The Rename functions of the preferred embodiment are as follows:
______________________________________
BOOL WINAPI EXPORT RenameList(const char FAR* sOldList,
const char FAR* sNewList);
BOOL WINAPI EXPORT RenameProject(const char FAR* sOldProject,
const char FAR* sNewProject);
BOOL WINAPI EXPORT RenameContact(const char FAR* sOldContact,
const char FAR* sNewContact);
BOOL WINAPI EXPORT RenameKeyword(const char FAR*
sOldKeyword, const char FAR* sNewKeyword);
______________________________________
A single function call to any of the above functions will handle the entire renaming process, and will simplify the client's task. Retrieving Results From The Parser In order to retrieve information from the parser 300, a client must allocate buffers and pass them into the parser 300 DLL via function calls. Parsing information is retrieved using the ParseOutput Data Structure 830, which is defined as follows:
______________________________________
typedef struct.sub.-- ParseOutput{
char sList[BUFFER.sub.-- SIZE];
char sProject[BUFFER.sub.-- SIZE];
char sContact[BUFFER.sub.-- SIZE];
char sDelegate[BUFFER.sub.-- SIZE];
char sDate[BUFFER.sub.-- SIZE];
char sTimeBegin[BUFFER.sub.-- SIZE];
char sTimeEnd[BUFFER.sub.-- SIZE];
char sDateEnd[BUFFER.sub.-- SIZE];
long nFrequency;
BYTE bRecurring;
BYTE nUnits;
BYTE nWeekdays;
BYTE nWeekdayPos;
}ParseOutput, *ParseOutputptr;
______________________________________
The client of the parser 300 DLL allocates a ParseOutput data structure ("struct" or "type" in Visual Basic), and passes it along with the input expression to be parsed using any of the following function calls: Parse() DateParse() Keyword suggestions are retrieved from the parser 300 using the KeywordSuggestion structure, defined as follows:
______________________________________
typedef struct.sub.-- KeywordSuggestion{
char sKeyword1[BUFFER.sub.-- SIZE];
char sKeyword2[BUFFER.sub.-- SIZE];
char sKeyword3[BUFFER.sub.-- SIZE];
}Keyword Suggestion, *KeywordSuggestionPtr;
______________________________________
The client of the parse DLL allocates a KeywordSuggestion data structure, and passes it along with an input expression using any of the following function calls: SuggestListKeywords() SuggestProj ectKeywords() SuggestContactKeywords() Auto-completion (auto-fill) requires only a character buffer which can be declared by the client as: char sBuffer[BUFFER.sub.-- SIZE]; in C or C++, or Dim sBuffer As string * BUFFER.sub.-- SIZE in Visual Basic. The buffer, along with the expression to be completed, is then passed into any of the following function calls: AutoFilIList() AutoFillProject() AutoFillContact() Handling Recurring Dates The present invention supports recurring date parsing by use of the following fields of the Parse Output Data Structure. These fields are:
______________________________________
nFrequency
Long. Null value = 0. "five days" -> nFrequency = 5.
nUnits BYTE. Null value = 0. DAYS = 1, WEEKS = 2,
MONTHS = 3, YEARS = 4.
nWeekdays
BYTE. Null value = 0. SUN = 1, MON = 2,
TUE = 4, WED = 8, THU = 16, FRI = 32, SAT = 64.
All possible combinations of weekdays can be stored. For
example, Sat and Sun = 64 + 1 = 65. Mon, Tues, and
Wed = 14. To find out if nWeekdays includes a specific
weekday, simply "bitwise and" that weekday with
nWeekdays (& operator in C/C++, "and" operator in
Visual Basic). If the result of the bitwise operation is
zero, then the weekday is not included in n Weekdays;
otherwise, it is.
nWeekdayPos
BYTE. Null Value = 0. 1.sup.st, 2.sup.nd, 3.sup.rd, 4.sup.th, or
5.sup.th weekday
of a given month. Thus, "the second Monday of July"
would imply that nWeekdayPos = 2.
______________________________________
Finally, a boolean value is provided to signal whether we are dealing with a simple date or a recurring date: bRecurring: BYTE. False=0. True=anything else. If bRecurring=True, sDate serves as the starting date of the recurring event. The parser 300 doesn't require end dates. That is, recurring events are assumed to go on "forever" (the user must use the user interface 200 to specify a full range). The "sEndDate" field in the ParseOutput data structure, is nonetheless provided to support specified end dates. A starting date, however, is always provided when a recurring date is parsed. Although the parser 300 doesn't require starting dates (i.e., every Friday starting on 8/8/97), it always tries to guess (intelligently) a starting date for the recurring event. This starting date will be passed via the ParseOutput struct in the sDate field. Collaboration Collaboration support is provided in the preferred embodiment of the present invention. The parser 300 looks for two possibilities at the beginning of each keynote. Note that other similar keywords triggering collaboration could also be provided. The word "please" (or "pls") immediately followed by a contact keyword. A contact keyword immediately followed by the word "please" (or "pls"). The parser 300 also accepts a single or multiple punctuation (comma, period, colon, and semicolon) between the contact keyword and the word "please" (e.g., "Brian. Please . . . " or "Please, Brian . . . "). When the parser 300 recognizes this keynote sequence, parser 300 fills the sDelegate field of the ParseOutput data structure with the contact name (pointed to by the contact keyword). The next contact keyword (if any) will appear in the sContact field. For example, consider the two contacts, "Brian Smith" (keyword="brian") and "Danny Jones" (keyword="danny"). The input expression: "Brian, please call Danny and arrange for all of us to go to lunch tomorrow at 2 pm" will result in the following ParseOutput data structure fields: sDate=<tomorrow's date> sTimeBegin=14:0 sDelegate="Brian Smiga" sContact="Danny Rabbani" Further details on collaboration support of the present invention are provided in a subsequent section this document. Object Database The object database 850 of the present invention supports arbitrary association of one type of object in the database with one or more other objects of any type. The object database 850 also supports collaboration (including negotiation and tracking action requests to completion) between two users of the present invention who may or may not share a common server. Referring now to FIGS. 15-18, various tables maintained within object database 850 are shown. Note that the table keys are shown only for illustrative purposes. Types of Objects FIG. 15 shows the object type table of the preferred embodiment. There are several types of objects currently supported in the database of the present invention. A representative portion of these types of objects are shown in FIG. 15 along with a description of the type of the particular object in the preferred embodiment. Because the object types are stored in a table in the object database 850, an object type can be added, deleted, or modified at run time. This is useful for supporting user-defined types of information or objects (e.g., a "GPS Location"). Association of Object Types to Tables Where They Reside Every type of object listed in FIG. 15 is stored in the object database 850 in one of several tables. The association between the object type the table in which it resides is retained in the object association table shown in FIG. 16. As the object association table shown in FIG. 16 illustrates, multiple types of objects may be associated with--and thus actually stored in--the same table. For example, the object types of: Person, Delegate, FYI, and Attached Person are all associated with the "People" table. Object Links Table The links table of the preferred embodiment is a special table in the database of the present invention that allows free association of one object of any type to another object of any type. For example, the links table allows the present invention to associate a Person object type to an Email Address object type. Note that the same Person could also be associated with additional email addresses, each represented in the Links table as separate entries. Referring to FIG. 18, a sample link table is illustrated. As shown, the columns (structure) of the link table includes the specification of a two keys and two object types: key 1, type 1, key 2, and type 2. Every object in the object database 850 of the present invention has a unique identifier, or key, associated with the object. These keys are stored as part of the record, or entry, describing an object in a particular table. For example, Brian Smiga is an instance of a Person object type with a key of 101; Brian's first name and last name, as well as his object instance key, will be stored directly in the People table as part of a single record. As indicated previously, every object in the database of the present invention also has a type associated with it. Given the object key and object type of one object and the key and type of another object, the two objects may be "linked" via a single entry (record) in the links table, a sample of which is shown in FIG. 18. For example, if "Brian Smiga" represents an instance of a Person object type with a key 101 and "smiga@actioneer.com" represents an instance of a corresponding Email Address with a key 102, the "Brian Smiga" object instance may be linked to his corresponding "smiga@actioneer.com" email address instance in the link table as follows:
______________________________________
Key 1 Type 1 Key 2 Type 2
______________________________________
110 5 102 13
______________________________________
where a Person object type has a key 5 and an Email object type has a key 13. The above example of a links table entry indicates that Brian Smiga (key=101) of type Person (5) is associated to (i.e. linked to) smiga@actioneer.com (102) of type Email Address (13). In the preferred embodiment, entries are always stored in the links table such that the value of Type 1 is less than or equal to the value of Type 2. This table organization aids in searching. Sample Database Representation Referring now to FIG. 17, an example illustrates the organization and use of the various tables in the object database 850 of the present invention. The columns shown for each table are only a subset of the columns actually in the database of the present invention. For example, Projects also have an associated Outcome (goal), which would be saved in a separate column in the Projects table. Additional information about a project might be entered in another table, such as Simple Date (which would include the start, due, and completion dates for the project), and linked to the associated Project via the links table as described above. Additional information about any of the contacts in the Contacts table might be entered in a Physical Address table, the Email Address table, etc. and linked to the associated Person via the links table as described above. Note that in the table representations illustrated in FIG. 17 and 18, the italicized columns showing descriptions of the linked items do not actually appear in the database of the preferred embodiment. Rather, they are shown here for purposes of clarification in this patent application. Given the initial database table content shown in FIG. 17, suppose a user named "Dennis Buchheim", creates a keynote by entering a text expression into a keynote region 220, the sample keynote reading as follows: "Brian, please call Jim tomorrow re patent status" Further suppose the user attaches the Person "Jim Salter" and the Project "Patents", also sending an FYI keynote to Tom Hagan as described in detail above. In this example, the parser 300 of the present invention will automatically determine many of the links that need to be established in the tables shown in FIG. 17: keyword "Brian" will be recognized as a keyword linked to "Brian Smiga," who is a Delegate of the keynote; keyword "call" will be recognized as a keyword linked to the "Calls" list, keyword "Jim" will be recognized as a keyword linked to the contact person "Jim Salter"; "tomorrow" will be recognized as meaning 2/8/97 (or whatever the current date is plus one day); and "patent" will be recognized as a keyword linked to the "Patents" Project. The remaining links will be determined by the user interface 200, in which the new keynote was created. Once the new keynote is filed by user Dennis, the following significant data will be recorded in the object database 850 by the present invention: An envelope (Type=0) will be added as a container for the keynote being sent to a delegate person. The Envelope includes such data as a subject for the note, when the note was used, or when it is received in a standard email client. Assume that this Envelope was assigned a database key of 212 by the object database 850. A List Item (Type=1) will be added for the note and would read "Brian, please call Jim tomorrow re patent status". Assume that this List Item was assigned a key of 213 by the object database 850. Several link table entries would be created for the new keynote in this example. The sample link table resulting from this sample input keynote is shown in FIG. 18. These entries in the links table (and one or two less significant additional entries) as shown are sufficient to describe the note that was entered as an example. It will be apparent to those of ordinary skill in the art that the object database 850 implementation of the present invention as described herein is of broader applicability than strictly for use with the natural language parser 300 as described herein. In an alternative embodiment, the input text data may be provided as a structured record or buffer from which the object database 850 extracts the information necessary to create the link table shown by example in FIG. 18. Collaboration Between Two Or More Users Of The Present System The present system allows a user to manage his or her own actions/projects and time more effectively. In many cases actions/projects have to be handled by more than one person. The collaboration cycle described below allows interaction between users to further completion of actions/projects and to allow information to be efficiently exchanged between users of the present system. FIG. 1, described above, illustrates a typical data processing system upon which one embodiment of the present invention is implemented. It is understood that the present invention utilizes at least one instance of the system, for the originator of the action request. In one embodiment, the communication device 125, described above, allows the users to collaborate as will be described below. Alternatively, the computer systems of users may be directly coupled. Alternatively, multiple users may be using the same computer system. In addition to parsing input text, the parser 300, described above, further utilizes the keywords to "classify" the text entered. In one embodiment, the message types are shared and personal. Shared messages include: FYI and action requests. Personal messages include personal action and personal memo. Of course, other message types may be utilized. An action request is input text which is sent out to at least one other person, and requires a response. It generally asks another user to do something. In one embodiment, the keyword "please" may initiate an action request. As discussed above, other keywords may be added to the list, at the user's discretion. For example, a user may add the keywords "I need you to", "pls", or similar words to indicate that the text entered is an action request. Thus, the sentence "Joe, I need you to call Bill about the Project X deadline" is classified as an action request, targeted at Joe. The contact is Bill, and the project is Project X. There is no date, since the requester did not include a date. Such analysis may be done using the parsing methods described above. However, the present system is not limited to the parsing method described above. Other methods of identifying the target, contact, project and date may be utilized. An FYI, or "for your information," is input text that is sent out to at least one other person, and requires no response. It is used to inform others about facts. For example, and FYI might be used to inform others that a new manager has been brought in. Keywords for an FYI type may be "FYI", "For your information", "Please note", and any other keywords which the user included in the keyword list. Generally, the targets of the FYI are deduced from the proximity to the keyword. For example, an FYI which read "John, FYI, Tom is in charge of Project X now." would send a copy of this FYI to John. A personal action/memo is text that is not sent to anyone. The absence of the other keywords would indicate that an entry is classified as a personal action/memo. For example, the input text "Call Jim about Project X" is a personal action. It is filed in the user's own system, as described above, but is not forwarded to anyone else. Framework For Collaboration The present system may be implemented on a number of different frameworks. FIG. 19 is a diagram of a client-server system. The client server system consists of a server 1910, and a plurality of clients 1920 connected to the server 1910. The server 1910 stores the information regarding the action requests sent between users and the database(s) to support the interaction. This assumes, and necessitates, the existence of a server in a client-server system. In addition to being expensive and complex, this limits collaboration to members of the limited group sharing access to the server 2010. In other words, it is limited to a closed loop of clients C1 . . . Cn 2020 who have access to the server 1910. This means that the collaboration system can not be used for interacting with individuals outside of the client-server framework. FIG. 20 is a diagram of a peer-to-peer distributed system. A number of peers P1 . . . Pn 2030 are interconnected. The peer-to-peer system allows any two peers to communicate over the system, even if not directly linked. This distributed system model parallels the Internet. Thus, any two individuals can communicate using the peer-to-peer distributed system, as long as both individuals have access to an e-mail address. In one embodiment, the peer-to-peer distributed system can be expanded to include such mechanisms as voice mail, personal digital assistants, and any other mechanisms capable of receiving and/or sending messages. The distributed peer-to-peer system enables communication with users who do not utilize the present system. Thus, the present system allows seamless integration of all action requests, and to-do-lists, regardless of whether the recipient is a subscriber to the present system or not. In one embodiment, the peer-to-peer distributed system model is used for the present invention. Keeping Track of Action Requests Utilizing a distributed system necessitates an alternative means of keeping track of action requests. Because there is no server which tracks each action request, a method of identifying each action request and its associated objects, such as project, sender, etc., is needed. This method enables the system to match replies to the proper action request. In one embodiment, a foreign key table is utilized to keep track of action requests. To clarify, the example described above with respect to FIGS. 15-18, is continued. The action request in question was:
______________________________________
Delegate Brian
From Dennis
FYI Tom
Subj. Action Request: Please Brian, call Jim. . .
Encl. Project Information, Contact Information
Text Please Brian, call Jim re: patent project.
______________________________________
The format of the action request does not reflect the actual format of the action request displayed on the present system. The appearance of such an action request is described below. This action request was entered by Dennis, and sent to Brian. In addition, an FYI copy of the action request was sent to Tom. This is to alert Tom to the action request. When the action request is generated, an envelope is generated, to contain the action request. The envelope includes a subject, and links to the list item, as well as the e-mail addresses of recipients. Below, only the actions occurring in Brian's system are described. However, similar activity occurs in. Tom's system. When Brian receives the action request, several Link table entries are created for the new action request. These Link table entries parallel the entries in Dennis' table, described above. Since the local key numbers are unique to the database of the individual, these key numbers may be different. In addition, Brian's system generates a number of entries into a Foreign Key table. The Foreign Key table is utilized in mapping a collaborative action request in one database, part of the sender's system, to the same action request in another database, part of the recipient's system. This link is represented by associating the Envelopes containing the corresponding List Items.
TABLE 1
______________________________________
Local Foreign
Creator
Database Local Key Database
Foreign Key
______________________________________
SMTP Brian's Brian's Received
Dennis' Dennis' Sent
Database ID
envelope key Database ID
envelope key
(212)
SMTP Brian's Brian's key for note
Dennis' "me" key for
Database ID
creator (Dennis)
Database ID
Dennis
SMTP Brian's Brian's key for
Dennis' "my e-mail"
Database ID
creator's e-mail
Database ID
key for
address (Dennis) Dennis
SMTP Brian's "me" key for Brian
Dennis' Dennis' key
Database ID Database ID
for delegate
(Brian)
SMTP Brian's "my e-mail" key for
Dennis' Dennis' key
Database ID
Brian Database ID
for dele-
gate's e-mail
address
(Brian)
SMTP Brian's Brian's key for
Dennis' Dennis' key
Database ID
linked person (Jim)
Database ID
for linked
person (Jim)
SMTP Brian's Brian's key for FYI
Dennis' Dennis ' key
Database ID
recipient's e-mail
Database ID
for FYI
address (Tom) recipient's
e-mail
address
(Tom)
SMTP Brian's Brian's key for
Dennis' Dennis' key
Database ID
linked project
Database ID
for linked
(Patents) project
(Patents)
SMTP Brian's Brian's key for
Dennis' Dennis' key
Database ID
sender Database ID
for sender
SMTP Brian's Brian's key for
Dennis' Dennis' key
Database ID
sender e-mail
Database ID
for sender
e-mail
______________________________________
The creator column is the creator of the entries in the Foreign Key table. The creator column displays the device which received the action request. In this example, it was the simple mail transfer protocol (SMTP) plug-in which received the action request from Dennis. The Local Database column contains a unique identifier identifying the delegate's (Brian's) database. The Foreign Database column contains a unique identifier identifying the requester's (Dennis')database. In one embodiment, the identifier is a Globally Unique Identifier (GUID), which is a 128-bit value based on the Ethernet address of the machine on which the GUID is generated, as well as the time at which the GUID was created. Alternatively, other unique identifiers may be utilized. The Local Key and Foreign Key are the key numbers from the Database tables of the individuals. The example keys described above with respect to Figure X are included in the Foreign Key table, i.e. Dennis' database entries. For example, the local key for note creator (Dennis) is the key number associated with Dennis in Brian's database. The "me" key is a special purpose value utilized because the user's database may or may not contain information identifying the user himself or herself, and it is unreliable to match user names via text comparison. This method allows for a match to be indicated. The "my e-mail" key is a similar key for the e-mail address of the database owner. Additionally, a parallel table is generated in Dennis' system when Dennis receives a reply from Brian. Of course, in Dennis' system, Dennis' database ID is the Local Database, while Brian's is the Foreign Database. Foreign Key entries are also created on both sides (requester and delegate) for the Person and Project linked to the action request, as well as the Creator (another Person) of the action request, the Sender (another Person) of the action request, the Delegate, and any Email Address associated with the action request. The Person, Project, etc. entries are created to ensure that the correct links are created/maintained on reply and that duplicate entries are not created in any user's database. In an alternative embodiment, the e-mail addresses of the sender and the recipient, coupled with a unique identification attached to the action request itself identifies the action request. In another alternative embodiment, a unique local identification coupled with a public key/private key identification of the sender/recipient is utilized to identify each action request. Collaboration Cycle FIG. 21 is a flowchart illustrating an overview of the present invention. At block 2100, the present collaboration cycle starts. It is initiated by a requester sending a message to a delegate or delegates. At block 2110, there is collaboration between the systems of the requester and delegate or delegates. This collaboration involves a complex series of negotiation steps that are designed to arrive at a final answer. This is described in more detail below. At block 2120, the process queries whether the final answer is affirmative or negative, or done. An affirmative answer occurs when the parties agree to perform the task. A negative answer occurs when the parties decide to not perform the task. If the final answer is affirmative, the process continues to block 2130. At block 2130, the final answer is filed in the appropriate calendars and lists, including lists associated with contact, project, if appropriate. These lists will be referred to hereinafter as project/contact list. Where it is filed depends on the interpretation of the original action request, and the collaboration process, as described below. If the final answer is negative, the process continues to block 2140. At block 2140, the action request, and collaborative updates of the original action request are deleted from the calendar and lists. This process is further described below. At one point, unless a negative reply was received, the delegate sends a Done reply to the requester. A Done reply may be sent by the delegate using the process described below. Alternatively, when the delegate checks the action/project off his or her calendar and/or project/contact lists, an automatic Done reply may be generated and sent to the requester. When the requester receives the Done reply, the original action request is marked done in the requester's system. Additionally, in one embodiment, an automatic acknowledgment form is generated. In one embodiment, an acknowledgment form consists of a generic text, such as "Thank you for completing my action request regarding the `Project name` project." In one embodiment, different types of acknowledgments may be associated with different delegates. For example, the requester may identify certain delegates that should receive a thank you voice mail, or document. In those instances, such an acknowledgment may be automatically generated by the system. In one embodiment, the user may select the type of acknowledgment. In one embodiment, the requester only receives a notification that an acknowledgment should be sent. FIG. 22A is a flowchart illustrating the collaboration cycle as viewed by the originator, or requester. The process starts at block 2200, when an input text has been parsed, and classified as an action request. In one embodiment, this occurs when the parser detects the keyword such as "please". At block 2205, the process identifies the delegate. An action request can be addressed to one or more parties. These parties are the delegate. As described above, in one embodiment, the names prior to, or following, the keyword "please" are generally considered the delegate. As described above, the user may have added additional keywords which indicate that the present entry is an action request. The delegate may be an individual or a group. For example, an action request could be addressed to "managers". In that instance, the keyword "manager" could include a plurality of managers. In one embodiment, for multiple delegates, separate action requests are spawned for each delegate, and each delegate is dealt with individually. For simplicity's sake, the remainder of this flowchart will assume that there is only a single delegate. In one embodiment, a header is generated when the delegate is identified. In one embodiment, the header includes a number of fields. In one embodiment, these fields include: Delegate, FYI, and Enclosures. The Delegate field includes the delegates, which are determined as described above. The FYI field is determined in a similar way. In one embodiment, the Delegate field maps to the To field, the FYI maps to the CC field in other messaging applications. The Enclosures field enables the requester to attach a variety of items to the action request. In one embodiment, the enclosures may include arbitrary files or information about the projects and the contacts related to the action request. This is especially useful when an action request is sent to a delegate who is not using the present system. In that instance, the message received by the delegate may not be linked to databases) with information about contacts or projects. Thus, by attaching those items, the requester can simplify the recipients' work. The requester's name is placed in the From: field. The header may also include a subject. The subject may be the first few words of the action request, the project to which the entry was parsed, or may be entered by the author of the action request. In one embodiment, the subject appears as "Action Request: <first few words of request>," or "FYI: <first few words of FYI>." This makes apparent to the recipient the type of message received, in addition to giving some information about the subject matter of the message. At block 2210, the action request is sent to the delegate. The action request may be sent via electronic mail or any other means. In one embodiment, the action request is sent directly to the delegate's in-box in the system of the present invention. In one embodiment, if the delegate is not utilizing the present system, the action request is sent to the delegate's address. In one embodiment, this may include the delegate's e-mail address, fax number, voice email number, or pager. Much of the filing and similar actions described in the present application require the use of the system of the present invention. However, action requests may be sent to any individual who has a receiver object, which can receive text or voice in some format. In one embodiment, if the delegate does not have an e-mail connection, the action request can be faxed to the delegate. In one embodiment, the present system may format the action request in a rich text format (RTF) and fax it to the delegate. In one embodiment, the action request may be turned into a voice mail message and sent by the present system. In another embodiment, the action request may be sent as a pager message to a pager. In one embodiment, the action request is formatted into an ASCII format, which is readable by a user. In one embodiment, the action request is reformatted to read as follows: "Text of the original action request." This is an Action Request for "Delegate" from "Requester". It relates to: Project: "Project" Contact: "Contact" Due Date: "Due Date" Attachments: "Enclosures" The text in quotation marks is inserted based on the information from the action request. This text format is sent, and is readable by delegates who are not subscribers to the present system. At block 2215, the action request is filed, and penciled into the appropriate calendars and/or project/contact lists. In one embodiment, the action request is filed in the "Waiting For" list. This is a list which contains action requests which have not been resolved. In one embodiment, a copy of the action request is also filed in the project/contact list to which it was parsed. Additionally, if appropriate, the action request is penciled into any lists, projects, contacts, and calendars that it was parsed to. "Penciling" indicates entry into a calendar or project/contact list in a different color. This allows the user to easily identify items which are not yet agreed upon. In one embodiment, penciled items appear in gray, compared to normal entries in black or blue. At block 2220, the process waits for a reply from the delegate. The process does not remain in a wait state, but rather continues to execute other processes. However, this action request cycle waits for completion. When the reply from the delegate is received, the process continues to block 2225. The reply from the delegate appears in the in-box of the requester. In one embodiment, if there is no reply a reminder is sent before the due date. At block 2225, the process queries whether the reply is affirmative, negative, or an other category. These categorizations are described below with respect to FIG. 22B. In one embodiment, the reply list is selected by the delegate by selecting from a preset selection or replies. In an alternate embodiment, the reply is reparsed to determine the appropriate reply list. In one embodiment, the date is reparsed. In an alternate embodiment, all of the reply is reparsed and reclassified. If the reply is affirmative, the process continues to block 2230. At block 2230, the original action request is updated and refiled. As described above, the action request is originally in the Waiting For list. Now, the action request is recategorized to the appropriate list, as determined from the parsing. The action request is also placed into the calendars and project/contact lists in ink. In one embodiment, writing in ink comprises entering the request in a different color from penciling. In one embodiment, ink is a black or blue color. If the reply is negative, the process continues to block 2235. At block 2235, the action request is deleted from the calendar and from the Waiting For category. At this point, the process is closed, since the delegate has refused to complete the request. However, the negative reply remains in the in-box of the delegate. Thus, if the requester wishes to reassign the project, he or she can do so using the copy in the in-box. If the reply is other, the process continues to block 2240. At block 2240, the requester and delegate negotiate. The negotiation process is described in more detail with respect to FIG. 23. When the negotiation is completed, the process continues to block 2245. At block 2245, the process once again queries whether the final answer is an affirmative or negative. If the final answer is affirmative, the process returns to block 2230. If the final answer is negative, the process returns to block 2235. FIG. 22B is a flowchart illustrating the collaboration cycle as viewed by the recipient, or delegate. At block 2250, a copy of the received action request is placed in the delegate's in-box. In one embodiment, the in-box is a part of the present system. In an alternative embodiment, the in-box may be the e-mail box of the delegate. In one embodiment, if the delegate is not a user of the present system, the in-box is the delegate's e-mail address box. In one embodiment, the in-box is also a list in the present system, into which received action requests are placed. At block 2250, the opened action request is displayed to the delegate. In one embodiment, if the delegate is using the present system, the action request is displayed in the format described above, with respect to FIG. 4. If the delegate is not using the present system, in one embodiment the delegate can open the action request as an e-mail message. If the delegate opens the present invention as an e-mail, it appears as plain or formatted text, which is human readable. The format of the text is as it appears above. In an alternative embodiment, if the delegate opens the information in any format that permits linking, enclosures are linked to the text. In one embodiment, if the delegate opens the action request in a Web browser, it appears in hypertext markup language (HTML) format. In one embodiment, enclosures appear at the bottom of the document. In one embodiment, in HTML, enclosures may be linked to the appropriate information in the text. For example, if the requester enclosed the contact information, the contact name is linked to that enclosure. Thus, when the delegate selects the contact name, the enclosed contact information is displayed. Other means of displaying text are well known in the art. Once the action request has been opened, the delegate may further delegate the action request. Of course, if the delegate is riot using the present system, he or she can not do this, except through standard e-mail communication. At this point, in one embodiment, the user can further delegate the action request by adding a "Please `new delegate`" to the action request. This, in reparsing, directs the action request to the new delegate. In an alternative embodiment, the user can manually select a new delegate in the header, and thereby forward the action request. The action request is readdressed to the new delegate, and sent on. The original delegate becomes a requester at this point. However, the original delegate is still has to respond to the original requester. At block 2260, the user is prompted to enter a reply. In one embodiment, when the user opens the action request in the in-box, it appears with reply classification choices in a reply box on the displayed action request. In one embodiment, the reply box is a pull-down menu. In an alternate embodiment, the reply box includes radio buttons, or other means of indicating one choice from a number of listed items. One of these choices can be selected by the user, as the reply to the action request. In one embodiment these choices include: Yes, Yes if, No, Comment, and Done. The Yes reply indicates that the delegate accepts the delegation, and will perform the action requested. A Yes if reply indicates that the delegate is willing to perform the action requested, but is making a counter-suggestion. For example, the counter suggestion may be to change the meeting date. A No reply indicates that the delegate is refusing the delegation. The Done reply indicates that the delegate accepts the delegation, and has completed the project assigned. And finally, the Comment reply indicates something outside of these categories. For example, if the delegate feels that the requester misunderstands the project, this reply may be utilized. Other reply choices may be incorporated without changing the fundamental purpose of the present invention. In one embodiment, these choices appear when the delegate opens the action request in his or her in-box. In one embodiment, the user must select one of these choices. In an alternative embodiment, no such reply options appear. In that embodiment, the user replies in a free-form text. In that embodiment, a parser is used to parse the user's reply, and fit it into one of the above categories. When the user selects one of these choices, a reply form is created. If the reply was either a Yes, No, or Done, the reply form is complete. The user need not enter any further information. However, the user may enter further information. In one embodiment, if the reply is Yes, No or Done, a header is automatically added to the reply, and it is automatically sent. The user is not prompted for entry. If, on the other hand, the choice selected is a Yes If or a Comment, a reply form is automatically generated, with the appropriate header information. In one embodiment, if the reply was Yes if, a phrase such as "Yes, I will do it, if" appears, followed by the cursor. The user can then complete this phrase. In an alternative embodiment, the user can delete the phrase and enter his or her own words. In one embodiment, if the Comment button is selected, the phrase such as "I have a comment," followed by the cursor is displayed. Again, the user can either finish the phrase, or erase it and write it differently. In this way, the reply format is automatically filled in based on the reply choice selected. At block 2265, the action request and reply are placed on the appropriate project/contact lists and calendars of the delegate. The information placed on the lists and calendars is based on the parsed action request and parsed reply. In one embodiment, only the date information is reparsed, and all other information remains. When the delegate opens the action request, preliminary project/contact list, contact, and other information is indicated in the shadow of the action request, in parentheses. However, the delegate can change this information, either directly in the shadow, or by changing the information in the reply. At block 2270, the reply is sent to the requester. In one embodiment, this occurs when the user presses a button. In one embodiment, there is a send button. At block 2275, the process queries whether the just sent reply was affirmative, a negative, or other. The affirmative reply includes Yes and Done. The negative reply includes No. The Yes if and Comment replies are classified as other. Similarly, if different categories are utilized, any category which refuses the delegation is negative. Any category which accepts the delegation, without attempting to change it in any way is affirmative. Any other categories are Other. If the reply is affirmative, the process continues to block 2280. At block 2280, the original action request is updated and filed. As described above, the original action request is on the Out-box list of the delegate. At this point, the action request is refiled based on the results of the parsing. The action request is also placed into the appropriate calendars and lists in ink. In one embodiment, placing the request in the calendar in ink comprises entering the request in a different color from penciling. In one embodiment, ink is a black or blue color. In one embodiment, a notification of the reply remains in the requester's in-box. In another embodiment, the user may select whether or not to receive notification. If the reply is a negative, the process continues to block 2285. At block 2285, the action request is deleted from the calendar and from the Waiting For category. At this point, the request is closed, since the delegate has refused to complete the request. In one embodiment, a notification of the reply remains in the requester's in-box. In another embodiment, the user may select whether or not to receive notification. If the reply is Other, the process continues to block 2290. At block 2290, the requester and delegate negotiate. The negotiation process is described in more detail with respect to FIG. 23. When the negotiation is completed, the process continues to block 2295. At block 2295, the process once again queries whether the final answer is affirmative or negative. If the final answer is affirmative, the process returns to block 2280. If the final answer is negative, the process returns to block 2285. FIG. 23 is an illustration of the negotiation process. The negotiation is initiated at block 2240 and 2290, as described above. If the requester and delegate do not come to an agreement during the initial exchange of messages, they segue into the negotiation process. At block 2310, the negotiation process starts. At block 2320, the recipient of the last message is prompted for a reply. The negotiation process is entered when the delegate returns a reply which is either a "Yes, if" or a "Comment," or any other reply which is not affirmative or negative. Thus, in the first iteration, at block 2320, the requester is prompted for a reply, in response to the delegate's initial reply. The reply form that appears before the requester is very similar to the reply form for the delegate. In one embodiment, the categories that may be selected are: OK, OK If, No, Withdraw/Done, and Comment. These categories parallel the categories of Yes, Yes If, No, Done and Comment. The category names may be changed without affecting the present process. The OK reply means that the requester accepts the change or comment proposed by the delegate. An OK If reply is a counterproposal by the requester. A No is a rejection of the delegate's proposal. A Withdraw is notification of the delegate that the original action request is being canceled, and the delegate no longer has to do anything in connection with the action request. An OK is classified as affirmative. A No or Withdraw is classified as a negative. And OK If and Comment are classified as Other. In an alternative embodiment, the reply form does not contain any categories. In that embodiment, the user enters a free-form reply. A parser is used to parse the reply, and determine the reply choice into which it belongs. As described above, with respect to blocks 2270 and 2320, based on the reply choice selected, a preformatted reply appears, along with the appropriate header information. This simplifies the negotiation process. At block 2330, the reply is sent and a copy of the reply is placed in the appropriate calendars and project/contact lists. The message is also appropriately updated in light of the reply just sent. At block 2340, the process tests whether the reply just sent was an affirmative, negative or other. As described in the above classification, a delegate's Yes, Done, and a requester's OK are classified as an affirmative. The delegate's No, and the requester's No or Withdraw is classified as a negative. All other answers, i.e. Yes If, OK If, and Comment, are classified as other. Either an affirmative or a negative answer is a final answer. That is, it is a conclusion to the negotiation. If the answer was either affirmative or negative, the process continues to block 2350. At block 2350, the negotiation process terminates. If, at block 2340, the answer was found to be Other, the process continues to block 2360 At block 2360, the process tests whether there is an auto-terminate that is activated. In one embodiment, the auto-terminate is an option which a requester can select. The auto-terminate automatically ends the negotiation process after a preset number of exchanges. In one embodiment, the user enters the number of exchanges after which the negotiation ends. For example, if the parties can not agree after five e-mail exchanges, the process automatically terminates. This is a method to avoid endless cycles of negotiation when it is apparent that the parties can not agree. If the auto-termination process is not activated, the process returns to block 2320, and prompts the recipient of the last message for a reply. For example, if the last message was written by the requester to the delegate, the process prompts the delegate to respond to the message. If, on the other hand, the auto-termination process is activated, at block 2360, the process continues to block 2370. At block 2370, the final answer is set to a No. This indicates that no agreement was reached between the requester and the delegate. The process then continues to block 2350, where the negotiation process terminates. FIG. 24 is a flowchart illustrating the distribution of an FYI. As discussed above, an FYI is sent out by an originator to at least one recipient. In one embodiment, an action request may be also sent as an FYI to other users. The FYI does not require a reply. In one embodi | ||||||