The use of electronic mail, or email, has become an integral, if not necessary, part of nearly every individual's life. Indeed, especially in the business context, individuals use email at least several times a day. In addition to using email as a part of their business activities, individuals also often need to interact with a computer system or business process application to accomplish a certain task or make necessary requests. For example, a business process application may be set up to complete a certain business practice, such as enrolling individuals for health benefits, updating human resource information, adding users to, or removing members from, an email distribution list, etc. A user may desire to join or leave a group or change one's address or telephone information. Further, a user may wish to determine the status of his/her request, such as finding out whether the request was approved or rejected. To take such actions, individuals have been required to work within the business process application in and of itself to interact with the application for purposes of accomplishing the desired, or required, tasks or status checks.
Requiring the user to access the business process application to complete a certain task often leads to a host of problems and inefficiencies. For example, where users are required to work within the business application context, they are required to be connected to the application and then, once connected, to navigate through the application's user interface (“UI”) to formulate the request. Where an individual desires to perform a follow-up regarding the status of the request, the user may be required to repeatedly navigate to the business application, requiring the user to either switch the context within which he/she is working or fail to obtain such information altogether where the user is unable to connect to the application. Thus, requiring the user to access the business process application to complete the desired action may cause delays, confusion, and errors where, for example: (1) at the time of desiring to make a request to the business application, the individual is working from a site with limited or no connectivity, or access, to the corporate business network and resulting business application, in which a mobile user, for example, may have greater connectivity to his/her email server than to corporate business applications; (2) the individual postpones switching contexts from the email or message interface to the business process application, i.e., navigating to a given website to complete the desired action; (3) the user does not know which business process application to contact to formulate the desired request or perform a status check; and (4) the individual is unable to accomplish the desired task in a timely manner as a result of unfamiliarity with the business process application user interface and functionality from which the appropriate task is requested. Further, delays and inefficiencies in checking on the status of a request are also present where the user is required to navigate to the business application, if such location is even known to the user, to check on the status of a particular request.
Requiring a user to navigate away from the email interface to access a business application not only consumes time but also requires the user to give up functionality inherent to email and not provided by most business applications. Such functionality consists of, by way of example only, the ability of an email user to save a partially-completed message and finish such message at a later time or the ability to “carbon copy” other users when sending the message. Such functionality is typically not available in most business application contexts.
Although specific problems have been addressed in this Background, this disclosure is not intended in any way to be limited to solving those specific problems.
Embodiments of the present invention generally relate to enabling a user to initiate a request to a business process application from within the context of the user's email client and to thus model the user's request to the business process application as an email form. More specifically, a method is provided for initiating a request to a business process application by a user as an email form. Further embodiments of the present invention relate to providing status updates regarding the processing of a request through utilization of the email client UI of the original request.
In accordance with embodiments of the present invention, a method is provided for allowing a user to select the action of making a certain request, e.g., a request to join a certain group, from within the UI of a general-purpose email client in which the user is working. An interactive UI window, or form, appears which represents the mail message and whose body contains fields that the user can complete, or fill-in, to indicate the specifics of the request he/she wants to make, e.g., to join a specific group. The form which appears to the user is a UI representation of the mail message data that guides the user as to what information he/she needs to provide, or, in other words, guides the user to enter the information needed to process the request. Thus, the user does not simply send a text request. Rather, the user completes both required, and optional, information in the form provided to the user upon the user's indication to make a request. After completing the form for the requested action, the user selects the necessary control, button or other indicator to send the request. The message is then sent to the email server that manages the user's email box. The receiving email server then sends the message to the email server that manages the mailbox that is monitored by the relevant business application. In addition to human-readable text that summarizes the request, the message that is sent contains data in a specific format, or data structure, embodying the request. The data structure is received by the business process application which decodes the message, extracts the data, and performs the requested action. Without such data structure, the business process application could not understand the request by the user.
Further embodiments relate to the provision of updates regarding the status of a requested action and of the resulting business process application from within the UI of the original email message. In an embodiment, after sending a request, a user may open the request from the user's “Sent Items” folder in the user's email client to see the status of that request in the UI of the originally sent email message. In such embodiments, the email client has information to be able to update the original email item to reflect the status of the request. In another embodiment, a human-readable status update message is sent to the user from the business application. The update message is correlated to the previous request and the original request is then updated so that it reflects the new information contained in the status update, e.g., “Request was approved,” “Request was rejected,” “Request is pending approval,” etc. The business application or the user may initiate the sending of such a status update in accordance with embodiments of the invention. Where a status update is sent, the UI of that status update can be modified, or refreshed, to reflect the most recent knowledge of the process. The status updates can thus be sent via email and/or may be in the UI of the original request in accordance with embodiments of the present invention.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter. Nor is this Summary intended to be used to limit the claimed subject matter's scope. The foregoing general description and the following Detailed Description should not be considered to be restrictive. Features or variations may be provided in addition to those set forth herein. For example, embodiments may be directed to various feature combinations and sub-combinations described in the Detailed Description.
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate various embodiments of the present invention. In the drawings:
The following Detailed Description refers to the accompanying drawings. Wherever possible, like structures and elements shown throughout are indicated with like reference numerals. Dashed lines may be used to show optional components or operations.
According to embodiments of the present invention, a method and system for enabling a user of an email client to initiate a request of an action by a business process application from within the familiarity and convenience of the UI of the user's email client is disclosed. A method and system is also disclosed for allowing the user to check on the status of a request to a business process application from within the familiar UI of the user's email client. Individuals often require action from a business process application. There are numerous types of actions which may be requested. For example, a user may request to change human resources information, to join a distribution list, to remove one's membership in a group, etc.
A network environment 100 for modeling a request initiated by a user to a business process application as an email form and for providing a status update to a user in the UI of the original email is shown in
In an embodiment, the sending and receiving process for the request works as follows: the user formulates a request for a particular business process application 108 using client computer 112 and the familiar UI of the email client depicted in user interface screen 114. The email client then sends the formulated request to the email server 116 managing the user's email mailbox. Using the network 110 for transmitting the requests and status updates, the email server 116 then sends the message to the email server 118 managing the mailbox monitored by the business application 108. In an embodiment, the network 110 may include multiple companies, e.g., the user using client computer 112 for sending a request may be at a different company, such as a partner company, than the business application 108. Examples of business process application 108 include, although are not limited to, applications used by companies to manage email distribution lists, accounting data, human resources information, expense reporting, etc. As shown in the embodiment depicted in
In embodiments, business process application 108 executing on the server 102 has most, or all (according to some embodiments), of the business logic. Determinations of the necessary tasks for execution, for example, are based on the logic/business rules stored on the server. Two components (not shown) related to the email requests of the present invention may exist on server 102, namely, a mail listener, or monitor, and a mail sender.
Networked system 100 is merely an exemplary embodiment. Other computing devices may also participate in the networked system 100. For example, the computer network 110 may include a secure network such as an enterprise network, or an unsecure network such as a wireless open network. The computer network 110 may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Further, the exemplary environment of networked system 100 may be considered in terms of the specific components mentioned, e.g., server, processor, storage system, etc., or, alternatively, may be considered in terms of the analogous modules corresponding to such units, e.g., executing or processing module, recording or storing module, display module, etc.
In an embodiment, on the computer system 112, there exists a general-purpose email client application, e.g., Microsoft Office Outlook 2007®, and, according to some embodiments of the present invention, an email client add-in, e.g., Outlook add-in. “Outlook” is offered for example purposes only and is in no way intended to limit the scope of this invention. General-purpose email clients include, but are not limited to, email clients executing in a dedicated program on a local computer, i.e., a “rich client,” or email clients whose functionality is realized by code executing on a server. Where the functionality is realized by code executing on a server, the functionality on the email client is limited primarily to rendering the user interface, i.e., a “web client” or “thin client.” Any number of types of general-purpose email clients reasonably known to those of ordinary skill in the art could be used in accordance with embodiments of the present invention.
In accordance with an embodiment of the present invention, the email client add-in, if one is used, provides functionality beyond that provided in the email client application. The add-in integrates with the email client using publicly disclosed APIs and provides the UI that allows the user to enter his/her request and send that request to the server-based business application from the email client. In embodiments, the add-in modifies the email client to provide appropriate UI controls to the user depending on the request desired by the user.
In an embodiment, the email client and/or email client add-in existing on computer system 112 maintains a list of business process application addresses and thus knows where to send a given request based on the type of request made, e.g., a request to join the Sporting Goods group; a request to change Human Resources information, etc. In other words, the email client or email client add-in knows the email address of the destination business application. In an embodiment, the UI to send the mail, and the functionality for sending the mail, are primarily the responsibility of the email client. In another embodiment, the email client add-in is integrated with the email client to provide such functionality. In sending the message request from the user, an embodiment uses a protocol for various elements of the system to negotiate the email address to which to send a specific request. In further embodiments, the user may be required to know, and enter, the email address of the business application that will process the request, i.e., the destination business application. The user may find such addresses in the user's email address book, in which the addresses may be listed in a standard, recognizable form in accordance with embodiments of the present invention. In another embodiment, all user requests are sent to one email address. Specific Inbox rules or policies at the receiving mailbox automate the delivery of the requests to the correct address for the particular request in accordance with an embodiment of the present invention. In another embodiment, a service is used to determine the correct address correlating to a particular request, in which a protocol may be used for enabling communications between the email client or add-in and such service.
Turning to
Process 200 begins with start operation 202 in which the user opens his/her email client, such as, Microsoft Office Outlook 2007®. Next, in enter email request context operation 204, the user, in an embodiment, selects a control, icon, or other indicator from the Inbox view to make a request, e.g., select “Forms” or “Groups,” etc. In an aspect of an embodiment, the user may select to join a group by simply clicking on the “Groups” control, icon or button, or other similar control, icon, button, or UI, in the user's Inbox view. In such an embodiment, the user may select to “Join Group,” “Leave Group,” “Add Members to Group” operation 206, “Remove Members from Group,” etc. In another embodiment, the user can select a control, button, icon, or other indicator to select “Forms . . . ” in general and then receive either a pop-up dialog box of available forms for making requests or a scroll-down menu of available forms, e.g., vacation-time leave form, change of address form, etc. In yet another embodiment, the user can select to create a “New” email message and a message composer view, for example, opens. From within this email message, the user selects a control indicating to add a member to a group in select add member operation 206, in accordance with an embodiment of the present invention. A person of ordinary skill in the art would understand that there could be any number of ways, without departing from the spirit and scope of the present invention, to show a user a choice of forms or to allow the user to obtain the message composer view for a request useful to a particular context. For example, in accordance with embodiments of the present invention, requests could be relevant and accessible via a calendar view, e.g., a request for vacation time for a future date marked as “Out-of-Office;” a contact view, e.g., a request to add a personal contact to the corporate database; and/or a tasks view, e.g., a request to delegate a task that is shown in the email client and tracked in another application, etc. In embodiments, UI controls would be associated with any of these contexts. While the above-described embodiments have related to forms invoked by the UI of the email client, the email client or email add-in can fetch the needed form from the business process application in accordance with another embodiment of the present invention.
Upon indicating the user's request to add a member to a group, a form 208 appears for the user to complete with fill-in information operation 210. In accordance with embodiments of the present invention, the form 208 is the UI representation of mail message data that helps the user complete the form, such as, by way of example only, checkboxes, auto-fills, data validation, etc. In embodiments, options for the user for adding a member to a group are shown, such as a list of names of potential members, a list of possible groups, etc. Where a list(s) is displayed, this list(s) may include entries derived from a variety of sources, as appropriate for a particular context. For example, a list(s) may be displayed showing: (1) the user(s) or group(s) on the email that the user was reading at the time of making the request; (2) the groups that the user is already a member of, etc. In an embodiment, such lists may be automatically displayed to the user, in which the user may mark a given checkbox to select a member for adding and select another checkbox to indicate the group to which the user wants the member assigned. In another embodiment, the user may click separately on the controls, icons or buttons of “Members . . . ” and “Groups . . . ” to open dialog boxes displaying such lists as overlays to the message view screen. Any number of required and optional fields in form 208 reasonably known to those of ordinary skill in the art could be used.
An example of an optional field is a business justification for the request, in which the user may enter text in the text entry field of the message as a part of fill-in operation 210. Information typed in the business justification field cannot be understood by the business application or email client. Rather, such information may only be read and understood by a human receiving the request. The email client and business application may only understand data in a specific format, in which such data is hidden from view of the user in accordance with an embodiment of the present invention but is carried with the message as the necessary data structure for enabling the request by the user. In such an embodiment, the data structure does not have a human-readable UI. The business process application thus works based on the data structure which is not easily visible, and may even be invisible altogether in some embodiments, to the end user. In such an embodiment, the email item in and of itself, e.g., located in “Sent Items,” also has human-readable text that reflects most or all of the data elements in the data structure. This human-readable text enables the user to see what the email item was later on. In other embodiments, the data structure is itself visible to the user. In further embodiments of the present invention, such data structure may be encoded using encryption methods or rights management technology, among other possible methods or technologies reasonably known to those of ordinary skill in the art, to preserve the confidentiality, if necessary, of any requests which may be intercepted after transmittal by the email user or before receipt of a status update by that user. In another embodiment, the request may be processed by the business application based on the raw text in the email message request and takes action to put the information into the right structure. By putting the data of the request into a certain structure, the application can easily parse, validate and use the information to process it.
Upon completing form 208 in fill-in operation 210, the user next selects to send the request to the business application in send operation 212, in which the user clicks on the “Send” control or “Send” icon, or any other type of indicator, in accordance with embodiments of the present invention, to send the email request.
Upon sending the email message, this message is transmitted to the email box on the email server in which the user is working, such as server 116 in
In accordance with embodiments of the present invention, business process applications regularly, periodically, or upon event triggers, monitor, or listen, to the email server's mailbox to which they are configured to listen. As discussed above, the business application mailbox is managed by an email server 118 which is often, if not always in the case of a large corporate network, a different email server from the one that manages the user's email box, such as server 116 shown in
Turning to
In accordance with further embodiments of the present invention, the functionality and interactions of the email client with the business process application also enable the business application 230 to send a status update regarding the user's request to the user in send status update method 232. In such an embodiment, the business process application 230 composes and sends a status update regarding the request to the email server managing its mailbox. In an embodiment, the correlation of the status update with the user request is accomplished in the email system on the email server of the business application. Such correlation may occur through the use of a process identification (“process ID”). However, such correlation may be accomplished in other ways. In another embodiment, the correlation of the status update with the application request occurs on the email client. After sending the status update to the email server managing the business application's mailbox, the status update is then sent to the email server managing the user's mailbox. As noted, for illustrative purposes, only one email server 228 is shown in operation 232 of
Upon receipt of the status update, the email server 228 sends the status update to the email client 226, with the status update 234 shown in the email form and UI of that originally used by the individual in formulating the request from within the context of the user's email client 226 and associated UI. In accordance with an embodiment of the present invention, the status update may contain any type of information, such as, by way of example only, notification that the “Request is in-process,” “Request was approved,” “Request was rejected,” “Request is pending approval,” “Request is suspended or on-hold,” etc. The status update email may thus contain human-readable text that the user is able to read and understand. Whether or not human-readable text is present, the update has machine-readable content to update the UI, in which the machine-readable content may or may not be visible to the user and may or may not be human-readable. The status update may contain any number of notice types and be displayed in a number of ways, as may be reasonably understood by one of ordinary skill in the art.
Operation 232 shows the sending of a status update from the business application 230 to the email client 226. In an embodiment, the status update is sent via email to the email client and to the user's Inbox. In another embodiment, the status update may be displayed to the user when the user re-opens the original request he/she originally sent, in which such request would now be located in the user's “Sent Items.” In such an embodiment, the last-known, or most recent, state of a process would be displayed to the user. The display of a status update, or of multiple status updates, within the original email item thus correlates such status updates regarding a business application with the email request, in which such correlation is able to occur even though the email server has no particular understanding of the business processes relevant to the request. In other embodiments, UI in the email client enables the user to see the status of multiple requests in one user interface.
Further, in accordance with an embodiment of the present invention, the business application determines where to send the status update through identification of the user's email address provided in the original message request. Or, in another embodiment, the message request contains a process ID which can be cross-referenced with other data available to the business application to determine which user(s) need to have updates sent to them. This process ID accompanies the overall data structure sent with the user request. In other embodiments, the email client or email client add-in has knowledge a priori of the address to which the user's request should be sent. In other embodiments, the destination address could be determined through the use of a protocol for various elements of the system to negotiate the email address to send a specific status update.
Process 200 is shown in flow chart 300 in
Upon reviewing the available options to make a request from within the context of the email client, the user 302 selects the appropriate UI control in the email client UI 306 for the desired request (“step 2”), such as to add a member to a group, in operation 316. Next, add-in 304 shows the message composer view of the desired request (“step 3”), such as to add a member to a group by way of example only, in show message operation 318. In another embodiment, the user indicates to the email client 306 UI that he/she desires to send a request and then is prompted to select which form he/she desires. The user may not know, or even care, to which application the form should be sent. Rather, the user might merely choose, by way of example only, the “vacation request form,” and the form or add-in or the email client would know where this form needs to be sent to be processed by the correct or appropriate application. In yet another embodiment, the user indicates to the email client 306 UI that he/she desires to send a request and then is prompted to select which application 312 he/she desires, upon which selection, the applicable form is displayed to the user for completion. The form that appears to the user is the UI representation of the mail message data. In accordance with embodiments of the present invention, numerous ways of initiating such a request and providing such form to the user can reasonably be understood by those of ordinary skill in the art. The user 302 is then able to provide the necessary information, and optionally, a business justification, using the email UI in fill-in operation 320 (“step 4”). Upon completion, the user 302 clicks “Send,” and the email client 306, in accordance with an embodiment of the invention, sends the form, or message request, to the email server 308 managing the mailbox of email client 306 in send operation 322 (“step 5”). In other embodiments, no add-in is used, and the message request is instead sent directly by the email client 306. Next, email server1308 sends the request 324 to the email server2310 managing the mailbox that is monitored by the business application (“step 6”). Finally, the business process application 312 monitors, or listens, to the email box managed by the email server2310 in listen operation 326 to detect if any new messages have been received (“step 7”). Such monitoring occurs through the use of a mail agent (not shown) in accordance with embodiments of the present invention. The application can be configured to know at which mailbox to look. While
Turning now to
As discussed above in accordance with an embodiment of the present invention, upon clicking “Send” 416, the message request is transmitted to the user's Outbox, and, from there, the email client sends the request to the user's email server. If a separate server manages the business process application's mailbox, the user's email server then sends the request to the business application's email server, where the message is detected. The business application detects that a message is present by listening for, or monitoring, the appropriate mailbox on the application's server for new messages.
In accordance with an embodiment of the present invention, when the business application receives a new message, it reads the message and processes the request, as shown generally in process 500 shown in
Upon receiving a response to the approval request in receive operation 512, the business application determines whether the response approves of the request to join the group in query operation 514. If the response denies such request, flow branches NO to reject user request operation 516, in which process 500 is then terminated at end operation 526. In rejecting the request, the business application may optionally send a status update, or notice, to the requester indicating that the request was rejected in optional send status update operation 518. The optional nature of this operation is shown by the dashed-lines format of this operation. On the other hand, if the response approves such request, flow branches YES to add member to group operation 520, in which the request action is taken. Process 500 then proceeds to query operation 522 where the business application determines whether a status update should be sent to the user notifying him/her that the requested action was approved and executed, e.g., that the specified member was added to the specified group. In an embodiment, the business application is pre-configured to specify whether a status update should be sent. In other embodiments, the user specifies in the request form whether a status update is desired, and the data structure accompanying the request is interpreted to notify the business application of such a request for a status update. If no status update is required, process 500 branches NO and terminates at end operation 526 in accordance with an embodiment of the present invention. If a status update is required, process 500 branches YES to compose and send status update operation 524, in which a status update is composed and sent. Upon sending the status update, process 500 terminates at end operation 526. In embodiments, the functionality provided by the email add-in and method allows the user to cancel a pending request to a business application that was previously sent via email. In further embodiments, a user may update a previously-made request by modifying or deleting information provided or requested. While process 500 has been provided for illustrating the steps in the exemplary method of submitting a request to join a group to a business application, these steps can occur in other sequences. For example, the business process application might send a status update immediately upon receiving the message, to let the user know the message was received or, alternatively, that it could not be processed due to some error. Further, steps shown in
Next, turning to
While
In another embodiment, the status update and the original request are correlated so that the current status of the request is displayed to the user if and when the user operates UI (other than the text of the status update message) to view that status. Examples of such UI operations include, for example: The user opens the original message request now located in the user's “Sent Items” box; or the user looks in UI provided by the email client that displays the status of multiple requests in one UI surface, message view, or preview pane. In an embodiment, correlation with message request 628 occurs on the email client. In other embodiments, correlation with the message request 628 occurs on the email server(s) managing the user's mailbox or on the email server managing the mailbox of the business application. In another embodiment, this correlation occurs on servers other than, or in addition to, the server managing the user's email client or the server managing the mailbox of the business application. This correlation occurs in the background and does not require user interaction. Further, such correlation is not evident to the user. In other words, the user is not necessarily aware of the concept of “correlation.” Instead, the user knows that when he/she operates UI that displays the status of a request, the last-known status of that request is provided. This last-known status is provided by correlating the messages that correspond to a specific request and displaying to the user the process state as reported in the last message. As discussed, in an embodiment, such correlation may be made by the use of a process ID shared by the original request and the business application message in accordance with an embodiment of the present invention. Numerous ways of correlating the request to the user and to the business application could reasonably be used by those of ordinary skill in the art in accordance with embodiments of the present invention.
Upon correlating the status update to the correct user, the email client or add-in displays UI 630 to the user to notify the user of the status of the request. As noted above, such display may be accomplished in a number of ways, such as by sending a new email to the user, updating the original request sent by the user now located in the user's “Sent Items” mailbox, etc. After notifying the user of the status update, process 600 then terminates at end operation 632. Again, steps may be combined, steps may be deleted, and/or steps may be added to process 600 without departing from the spirit and scope of the present invention. For example, a status update could be automatically sent following workflow run operation 622.
Turning now to
With reference to
Computing device 700 may have additional features or functionality. For example, computing device 700 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in
Computing device 700 may also contain a communication connection(s) 726 that may allow computing device 700 to communicate with other computing devices, such as over network 110 in
As stated above, a number of program modules and data files may be stored in system memory 706, including operating system 708. While executing on processing unit 704, programming modules 710 may perform processes including, for example, one or more method stages as described above. The aforementioned process is an example, and processing unit 704 may perform other processes. Other programming modules that may be used in accordance with embodiments of the present invention may include electronic mail and contacts applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-aided application programs, etc.
Generally, consistent with embodiments of the invention, program modules may include routines, programs, components, data structures, and other types of structures that may perform particular tasks or implement particular abstract data types. Moreover, embodiments of the invention may be practiced with other computer system configurations, including hand-held devices, e.g., phones, cell phones or other similar mobile devices, personal digital assistants, smartphones, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like, in which the forms, or message requests, of the present invention are submitted via such devices. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
Furthermore, embodiments of the invention may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. Embodiments of the invention may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies. In addition, embodiments of the invention may be practiced within a general-purpose computer or in any other circuits or systems.
Embodiments of the invention, for example, may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer-readable media. The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process. Accordingly, the present invention may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.). In other words, embodiments of the present invention may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. A computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific computer-readable medium examples (a non-exhaustive list) may include the following: an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EEPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CD-ROM). Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
Embodiments of the present invention, for example, are described above with reference to block diagrams and/or operational illustrations of methods, systems, and computer program products according to embodiments of the invention. The functions/acts noted in the blocks may occur out of the order as shown in any flowchart. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Further, certain blocks may not be executed at all.
Although certain embodiments of the invention have been described, other embodiments may exist. Furthermore, although embodiments of the present invention have been described as being associated with data stored in memory and other storage mediums, data can also be stored on or read from other types of computer-readable media, such as secondary storage devices, like hard disks, floppy disks, or a CD-ROM, a carrier wave from the Internet, or other forms of RAM or ROM. Further, as noted, the disclosed methods' stages may be modified in any manner, including by reordering stages and/or inserting or deleting stages, without departing from the spirit or scope of the invention.
While the specification includes examples, the invention's scope is indicated by the following claims. Furthermore, while the specification has been described in language specific to structural features, methodological acts, and/or computer-readable media containing such acts, the claims are not limited to the features or acts described above. One skilled in the art will recognize other embodiments or improvements that are within the scope and spirit of the present invention. Therefore, the specific structures, features, acts, or media are disclosed only as illustrative embodiments. The invention is defined by the appended claims.
This application claims priority to U.S. Provisional Application Ser. No. 60/913,213, filed on Apr. 20, 2007, and entitled, “Modeling User-Initiated Requests And Status Updates Within An Email Message,” which is hereby incorporated in its entirety for all that it teaches.
Number | Date | Country | |
---|---|---|---|
60913213 | Apr 2007 | US |