|Publication number||US20020007356 A1|
|Application number||US 09/054,233|
|Publication date||Jan 17, 2002|
|Filing date||Apr 2, 1998|
|Priority date||Apr 3, 1997|
|Also published as||US6182059, US6411947|
|Publication number||054233, 09054233, US 2002/0007356 A1, US 2002/007356 A1, US 20020007356 A1, US 20020007356A1, US 2002007356 A1, US 2002007356A1, US-A1-20020007356, US-A1-2002007356, US2002/0007356A1, US2002/007356A1, US20020007356 A1, US20020007356A1, US2002007356 A1, US2002007356A1|
|Inventors||Amy Rice, Julie Hsu|
|Original Assignee||Amy Rice, Julie Hsu|
|Export Citation||BiBTeX, EndNote, RefMan|
|Referenced by (27), Classifications (7), Legal Events (19)|
|External Links: USPTO, USPTO Assignment, Espacenet|
 This application is based on and claims priority from U.S. patent application Ser. No. 08/______. filed May 8, 1997 entitled “AUTOMATIC MESSAGE INTERPRETATION AND ROUTING SYSTEM, United States Provisional Patent Application No. 60/042,494, filed Apr. 3, 1997, entitled ELECTRONIC ROUTER FOR E-MAIL, and United States Provisional Patent Application No. 60/042,656, filed Apr. 4, 1997, entitled ELECTRONIC ROUTER FOR E-MAIL, each of which are incorporated herein by reference for all purposes.
 1. Field of the Invention
 The present invention relates to a system for automatically interpreting an incoming data message and, more particularly, the invention relates to a system using combined rule based and case based reasoning in interpreting, classifying, categorizing, prioritizing and responding to electronic messages.
 2. Related Art
 Many businesses have recently sought to expand access to their products and services by using the Internet and other on-line information channels to reach current and potential customers. Indeed, marketing campaigns which solicit customers over on-line information channels using electronic messages are becoming increasingly popular. These marketing campaigns have become very successful and often customers also contact a business concern using electronic messages (for example, E-mail) to request, among other things, product information, account status, and access to products and services.
 Businesses have experienced problems in adapting their business practices to respond to large volumes of incoming electronic messages transmitted over a variety of communications channels (e.g., the Internet, telecommunications channels, and the like). These businesses have had to develop methods for quickly, accurately and efficiently responding to the increased volume of incoming electronic messages in order to meet the demands of their customers. In the case of the banking industry, electronic commerce laws may require a bank to respond to certain types of electronic correspondence within a specified period.
 The problems imposed on businesses in formulating methods to quickly respond to electronic messages will only be exacerbated as the use of on-line information channels and electronic messaging increases in the future.
 Some businesses have responded to increases in incoming electronic messages by having employees work longer hours or employing more people to review and respond to the messages. These methods have the drawbacks of significantly increasing the business costs associated with hiring, training and/or compensating personnel as well as requiring an increase in capital equipment and office space.
 An event driven rule based messaging system, see U.S. Pat. No. 5,555,346 to Gross et al., has been described which employs user specified “when-if-then” rules to manage incoming E-mail messages. The system provides a user with such features as a tickler (permitting the user to put off dealing with the E-mail for a specified period), an automatic forwarding feature, and an automatic replying feature. The forwarding and replying features are triggered by one or more of the form of the message, the source of the message and key words used in the body of the message. For example, when a recipient of E-mail will be out of the office, he or she may specify that any E-mail received from T. Jones should be automatically responded to with the message “I'm out of the office until June 1, see L. White if you need something immediately.”
 Unfortunately, the rule based messaging system described in U.S. Pat. No. 5,555,346 has several drawbacks. For example, that system requires that the recipient of the E-mail know the identity of the sender (i.e., the sender is pre-determined by the user) and, therefore, would be non-responsive to E-mail coming from new customers. Further, because the so-called automatic response is not capable of being altered in accordance with the message content of each incoming E-mail, the response must be overly simple, overly broad or require that a further response be formulated by another individual.
 Software coded systems for executing procedural rules using well known computer languages, for example, COBOL are not well suited for implementing a knowledge-based system for interpreting incoming electronic messages. Indeed, such procedural rules would require impractically large and complicated branched coding structures to respond to the unpredictable and intricate content of the incoming electronic messages.
 Natural language processing products such as SRA or Logicon or augmented transition network in custom developed applications such as the Intelligent Banking System (see Sahin, K. and Sawyer, K. THE INTELLIGENT BANKING SYSTEM: NATURAL LANGUAGE PROCESSING FOR FINANCIAL COMMUNICATIONS. Innovative Applications of Artificial Intelligence, AAAI Press. 1989) are unsuited for producing a response to an incoming electronic message. Indeed, such systems have relatively limited sets of key linguistic clues which are expressible in rule form. Consequently such systems might only provide a pre-processor function to a classification or reasoning task at great expense and complexity.
 A help desk application utilizing a case based reasoning system, see U.S. Pat. No. 5,581,664 to Allen et al., has been described which compares an incoming set of facts (a “Problem”) with a stored set of exemplar cases (a case base). The system then performs the same action for the problem as was performed in connection with the stored case. The case base is stored in the form of case attributes representing past “problems.” The case attributes are compared to the facts of the incoming problem using trigram character matching to obtain a set of prior cases which may be useful in formulating an appropriate action.
 Unfortunately, the help desk application described in U.S. Pat. No. 5,581,664 has several drawbacks. For example, a user must interact with the system to narrow down the results of the case base search to obtain the “best” case match. Consequently, the system would not provide satisfactory results if the input to the system was an electronic message and no user interaction was provided. Further, the system is not capable of automatically responding to the sender of an electronic message. Indeed, a representative or the user must interactively interpret the set of cases retrieved from the case base to obtain a response to the “problem.”
 Accordingly, there is a need in the art for a system which overcomes the shortcomings of the prior art by receiving electronic messages, classifying and categorizing the messages, and automatically responding to the messages without the intervention of a human operator.
 The process of reviewing electronic messages involves complex reasoning which is distinctly knowledge specific. The present invention was developed in a banking industry context and was based on domain specific knowledge of banking products and services. It is understood that the present invention is not limited to the banking industry context and that one skilled in the art could readily adapt the teachings herein to other industries.
 It is understood that a manual process for classifying and formulating responses to ambiguous and/or new electronic messages requires experience and often the collective experience of several members of a business team. Human electronic message reviewers read each message from beginning to end while continuously evolving a final interpretation by recursively applying business knowledge to the content of the message.
 Therefore, the method and system of the present invention emulates the recursive nature of evolving interpretation by utilizing a knowledge base to execute reasoning tasks which automatically classify incoming electronic messages and automatically obtain responses to the messages.
 In order to overcome the disadvantages of the prior art, the method of the present invention includes a method for automatically interpreting an electronic message including the steps of (a) receiving the electronic message from a source; (b) interpreting the electronic message using a rule base and case base knowledge engine; and (c) classifying the electronic message as at least one of (i) being able to be responded to automatically; and (ii) requiring assistance from a human operator.
 According to another aspect, the present invention includes a method for automatically interpreting an electronic message including the steps of (a) receiving the electronic message from a source; (b) interpreting the electronic message using a rule base and case base knowledge engine; and (c) retrieving one or more predetermined responses corresponding to the interpretation of the electronic message from a repository for automatic delivery to the source.
 Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings.
 For the purpose of illustrating the invention, there is shown in the drawing a form which is presently preferred, it being understood, however, that the invention is not limited to the precise arrangement and instrumentality shown.
FIG. 1 is a block diagram showing the automatic message interpreting and routing system of the preferred embodiment of the present invention; and
FIGS. 2A and 2B are flow diagrams showing the high level process flow of the automatic message interpreting and routing system of FIG. 1.
 Referring now to the drawings wherein like numerals indicate like elements, there is shown in FIG. 1 a block diagram of the automatic message interpreting and routing system 1 of the preferred embodiment of the present invention. The system includes a domain server 10, a local server 20, and an automatic message reader 30.
 The automatic message interpreting and routing system 1 also includes a manual reviewer (or human operator) 40 having access to a manual review data base 42. A plurality of customers 50 transmit electronic messages 11 to the automatic message interpreting and routing system 1 via source computers 52 coupled to the domain server 10. The domain server 10 preferably communicates with the local server 20 which communicates with an inbox storage device 22 for receiving the electronic messages 11 and an outbox 26. It is preferred that the electronic messages 11 are E-mail messages and are so referred to herein, it being understood, however, that other types of electronic messages 11 are contemplated as being within the scope of the invention.
 The automatic message reader 30 includes a an archive 32, an action base 33, a case base 34, and a rule base 35. The action base 33, case base 34 and rule base 35 communicate via an appropriate software control program (described below) which executes the steps necessary to achieve the routing and interpretation of incoming E-mail messages 11.
 The automatic message reader 30 preferably includes an embedded artificial intelligence (AI) application operating between an E-mail system and a customer service department. The customer service department, for example, provides new products and services to current and potential customers and maintains existing products and services by interacting with current customers. The automatic message reader 30 is a tool to more efficiently process incoming E-mail messages 11 in the customer service department.
 The AI reasoning component (or knowledge engine) of the automatic message reader 30 uses a hybrid approach, i.e., a data-driven forward chaining rule parser operating in conjunction with a case based reasoner. This hybrid reasoning approach reflects the actual interpretation process used by human message reviewers in a customer service department.
 The AI application emulates the recursive nature of human interpretation by first detecting combinations of prominent words (or text) and patterns of text within an electronic message 1 1 using a character matcher (preferably including a trigram character matching algorithm). As discussed in more detail below, predetermined attributes (or features) may be detected in the electronic message 11 during the character matching process. When certain attributes are detected, corresponding flags are set which (i) may directly lead to the classification of the electronic message 11; and/or (ii) may be subsequently used in a case base search.
 The high level process flow for the system of FIG. 1 for automatically interpreting and routing an electronic message 11 is now described with further reference to FIGS. 2A and 2B. At step 100, the customer so drafts an E-mail message 1 1 on the source computer 52 for transmission to a business concern employing the automatic message interpreting and routing system 1 of the present invention. The E-mail message 11 may include an inquiry and/or a statement for which the customer desires a response.
 Unlike the help desk application of U.S. Pat. No. 5,581,664 described above, in the instant invention the data of the electronic message 11 is delivered to the automatic message interpreting and routing system 1 in a non-interactive manner. Specifically, the customer 50 transmits a non-interactive electronic message 11 to the system 1. This non-interactive transmission of electronic messages 11 prescribes that the customer 50 need not later provide additional input to assist the system 1.
 It is noted that defining an electronic message 11 as being non-interactive prescribes only that the message content need not be supplemented. Thus, as described in more detail below, the form of the non-interactive electronic message 11 may be altered by the system 1 after the customer 50 sends it; however, the customer 50 is not required to provide supplemental information to assist the system 1.
 At step 102 the customer transmits the E-mail message 11 from the source 52 to the domain server 10 over a communications channel 12. The domain server 10 communicates with the local server 20 (step 104) for routing the E-mail message 11 to the inbox storage device 22. A local server 20 suitable for use in the present invention is the Lotus Notes™ mail database system.
 At step 106, the automatic message reader 30 periodically checks the inbox 22 for new E-mail messages 11. The automatic message reader 30 preferably includes an application programming interface (API) which is a rule based program (employing phase rules). The API facilitates data communications between the automatic message reader 30 (which, for example, runs with a Windows™ operating system) and the local server 20 (which, for example, runs with an OS2 operating system). Specifically, the API provides the following functions:
 1. transferring data between the local server 20 and the automatic message interpreting and routing system 1;
 2. retrieving E-mail messages 11 from the inbox 22 and delivering same to the automatic message reader 30;
 3. delivering the E-mail messages 11 and any attachments (predetermined response and/or remarks) to the manual review inbox 24 and/or the outbox 26; and
 4. marking a processed E-mail message 11 as having been processed by the automatic message reader 30.
 The above processing steps and others will now be discussed in more detail. At step 106 the API of the automatic message reader 30 continuously monitors the inbox 22 for received E-mail messages 11 using a program loop. When a new E-mail message 11 has arrived, the automatic message reader 30 retrieves the E-mail message 11 and interprets it using a knowledge base capable of performing rule based parsing and case based retrieval (described in more detail below).
 The interpretation of the E-mail message 11 by the automatic message reader 30 includes classifying the E-mail message 11 into (i) E-mail which is capable of being automatically responded to, called an “automatic” type E-mail message 11; and/or (ii) E-mail which is not capable of being automatically responded to and requires the assistance of the human operator 40, called a “referral” type E-mail message 11. Referral type E-mail messages 11 may also be of the “detected” type, which type of messages imply a particular manual handling procedure or require an interpretive aid for delivery to the human operator 40.
 At step 108, a new E-mail message 11 is passed to the pre-processing block containing the rule base 35 of the knowledge engine. Preferably, the rule base 35 (and case base 34) are realized using the ART*EnterpriseŽ tool, a knowledge-based application development tool, available from Brightware, Inc. of Stamford, Conn. The ART*EnterpriseŽ tool employs a text pattern matcher having a Rete algorithm which provides the interpretation power necessary to process the highly complex message content of the E-mail message 11.
 The rule base 35 of the automatic message reader 30 contains “question” rules which take the form of IF-THEN statements with a left hand side of the statement containing a condition (or set of conditions) and a right hand side of the statement containing conclusion(s) (or actions). For example, a typical rule will take the following form:
 condition1?, condition2? . . . =>action1, action2 . . .
 When the condition(s) on the left hand side of the rule are satisfied (or true) then the rule “fires” and the action(s) are executed. It is noted that the condition(s) will be deemed satisfied regardless of the order in which they are found true (i.e., the sequencing of conditions is irrelevant). This more closely parallels the recursive nature of the message review process of a human and, therefore, it is preferred that the automatic message reader 30 employs this technique.
 The left hand side conditions of the IF-THEN question rules contain the key linguistic clues that directly imply interpretive conclusions. These linguistic clues include literals, wild card patterns (e.g. text patterns), variables and segments, or choices of pattern sets. For example, if the business concern, ABC, Corp., employing the automatic message interpreting and routing system 1 of the present invention, were going to merge with XYZ Corp., any text reciting a “merger,” and/or the “XYZ Corp” in a received E-mail message 11 is a linguistic clue as to the subject matter content of the E-mail message 11.
 Question rules in the preferred embodiment of the present invention take on at least one of three forms, namely, (i) action setting rules, (ii) attribute setting rules, and (iii) action/attribute setting rules. Action rules are preferably received from the action base 33.
 An action setting rule will cause a specific action to occur when the rule condition(s) are met. Depending on the detected conditions, the resulting action may include the final classification of the E-mail message 11 as “automatic” “referral” and/or “detected” (step 114, discussed in detail below). For example, when the condition that the body of the E-mail message 1 1 is blank is satisfied, then the action is preferably that the E-mail message 11 be classified as “automatic.” Such an action rule would have the following form:
 BLANK RULE:
 body contains no text?
 =>classify E-mail as “automatic.”
 An attribute setting rule is used when a satisfied condition is useful in subsequently matching the E-mail message 11 to stored case models of the case base 34 (step 112, described in more detail below). From the example above, one attribute of the E-mail message 11 could be assigned as any reference to the merger between ABC Corp. and XYZ Corp. Thus, an attribute setting question rule in the rule base 35 might be represented as follows:
 MERGER RULE:
 text include “merger,” or “XYZ Corp.”?
 =>flag (set) merger attribute.
 The application of the attribute setting rules produces a case model of the E-mail message 11 (i.e., an index of features useful in comparing the E-mail message 11 to the stored case models of the case base 34). Specifically, when attribute setting rules fire, specific attributes of the case model of the E-mail message 1 1 are flagged (i.e., set true). Thus, when a search of the case base 34 is required, the flagged attributes of the case model are used to search the stored case models of the case base 34.
 An action/attribute setting rule is used when a satisfied condition indicates that the E-mail message 11 may be directly classified into one of the “automatic,” “referred” and/or “detected” classifications and that one or more attributes should be set to aid in subsequently matching the E-mail message 11 to the stored case models of the case base. For example, if the customer sending the E-mail message 11 does not wish to be called on the telephone, then the classifying step should result in a “detected” type classification of the E-mail message 11 and that attribute should be set for aiding in searching the case base 34 (step 112, discussed below).
 The following table lists a set of preferred question rules and the form (action, attribute or action/attribute) of each.
TABLE 1 (Question Rules) Question Rule Detects Action Type: Classification customer's address attribute/action: detected blank body action: automatic service cancellation action: referral change address action: referral no call back attribute/action: detected facsimile number action: detected phone number action: detected request for service attribute reference to error attribute investments attribute foreign country attribute/action: detected lengthy message attribute specific product attribute multiple questions attribute specific employee attribute/action: detected lost product action: referral sensitive info action: refer, auto, detected
 At step 110, if the pre-processing interpretation using only the rule base 35 results in a classification of the E-mail message 11, then the process flow proceeds to step 114.
 When the subject matter of the E-mail message 11 is substantially ambiguous and the pre-processing step using the rule base 35 alone does not result in a classification of the E-mail message 11, then at step 110 the automatic message reader 30 accesses the case base 34 (step 112).
 Recall that the rule base (step 108) produces a case model of the E-mail message 11. The case model of the E-mail message 11 is called a “presented” case model and is compared with a set of stored case models in the case base 34. These stored case models are created from previously received E-mail messages 11 and associated responses. The case base 34 preferably contains over 300 stored case models.
 Referring to TABLE 2 below, each stored case model of the case base 34 preferably includes a title section, a subject section, a description section, an action section, and an attribute section.
TABLE 2 Example: Stored Case Model TITLE: Lengthy Inquiry From lmnop.com SUBJECT: New Account DESCRIPTION: Dear Sirs, I recently saw your advertisement in the newspaper. I am interested in learning whether or not your system would work for me. Please E-mail me back and let me know the details of your system. Thanks, ACTIONS: 1. type: referral 2. sub-class: sales 3. priority: 3 ATTRIBUTES: 1. address: yes 2. lengthy: yes
 The title and subject sections generally identify the stored case model. The description section of the stored case model contains the body of the previously sent E-mail messages 11 for comparison to the body of the presented case model.
 It is noted that certain superfluous literals such as the author's address are removed from the description section of the stored case model. Instead, the attribute “address” is set to “yes” which indicates that an address was received. The proper removal of certain literals and the setting of attributes is very important in automatically interpreting the E-mail messages 11. Indeed, properly formed stored case models obviate the need to exactly match the presented case model and the stored case model.
 The set of attributes (or slots) of the stored case model contain some important features of the prior received E-mail messages 11. For example, the attributes of the stored case model may include (1) a source's address; (2) a do not call request; (3) a request for service; (4) a reference to a foreign country; (5) a lengthy message; (6) a reference to a specific product and/or service; (7) a reference to multiple questions; and/or (8) a reference to a specific employee.
 The attributes and description of the stored case model are searched vis-a- vis the attributes and description of a presented case model with the goal of finding a stored case model which has attributes and a description substantially matching the attributes and description of the presented case model. The automatic message reader 30 of the preferred embodiment of the present invention uses a trigram character matching algorithm which is available using the ART*EnterpriseŽ tool.
 In selecting the best stored case model vis-a--vis the presented-case model, the automatic message reader 30 searches each stored case model of the case base 34 and assigns a raw score to each stored case model. Each instance in which a piece of text, a combination of text, and/or a pattern of text of the presented case model matches the stored case model, the raw score of the stored case model is increased. When a piece of text, a combination of text, and/or a pattern of text of the presented case model does not match the stored case model, the raw score of the stored case model is not increased, and may be decreased.
 The raw score of a stored case model may increase or decrease in differing amounts depending on the particular feature (i.e., attribute) being searched. Thus, if feature1 matches, the raw score may increase by match-weight, while if feature2 matches, the raw score may increase by match-weight2. Similarly, if feature1 does not match, the raw score may decreased by mismatch-weight1, while if feature2 does not match, the raw score may decrease by mismatch-weight2. It is preferred that the match-weight of each feature is a positive number and that the mismatch-weight is zero.
 The weight that any matched feature contributes to the raw score is most meaningful when the maximum possible match score between a particular presented case model and the stored case model is considered. This is so because different stored case models may contain different numbers of features. Accordingly, it is preferred that the automatic message reader 30 of the preferred embodiment of the present invention normalize the raw score by dividing the raw score by the maximum possible match score. Thus, the normalized scores of each stored case model vis-a-vis the presented case model are compared to select the “best” stored case model.
 Preferably, a global absence weight (for example, −1) is also assigned to the stored case models of the case base 34. The contribution of the absence weight to the raw score of a stored case model is determined by multiplying the global absence weight by the number of features (or attributes) which are present in the presented case model but are absent from the stored case model. The raw score is then normalized as described above.
 Once a best stored case model has been identified, the automatic message reader 30 infers that the same or similar action that was taken on the E-mail of the stored case model should be taken on the E-mail message 11 which produced the presented case model. For example, the classification of the stored case model may be assigned to the E-mail message 11 of the present case model.
 At step 114, the E-mail message 11 is classified into at least one of an “automatic” (step 114a), a “referral” (step 114b), and/or a “detected” (step 114c) classification. As discussed above, the classification is achieved either through accessing only the rule base 35, or accessing both the rule base 35 and the case base 34.
 When the automatic message reader 30 has classified the E-mail message 11 as being of the “automatic” type (step 114a), one or more predetermined responses (or prepared responses) are retrieved from a repository (or database), preferably the archive 32 (step 116a), of the automatic message reader 30 for automatic delivery to the source 52. As is evident from the discussion herein, the predetermined response is an appropriate response to the inquiry of the customer 50. It is understood that the predetermined response may be modified and/or altered in accordance with the interpretation of the E-mail message 11 if required to properly respond to a customer 50.
 At step 122, the original E-mail message 11 and the predetermined response are routed from the automatic message reader 30 to the outbox 26 which communicates with the local server 20. The local server 20 then transfers the predetermined response to the domain server 10 for transmission to the source 52 over the communications channel 12 (step 124).
 When the automatic message reader 30 is not capable of automatically responding to the E-mail message 11, the E-mail message 11 must be transferred to the human operator 40 for review. Thus, when the automatic message reader 30 classifies the E-mail message 11 as being of the “referral” type (step 114b), the automatic message reader 30 sub-categorizes the E-mail message 11 according to its subject matter content (step 116b) prior to transferring the E-mail message 11 to the human operator 40. The sub-categories are preferably related to specific business categories, such as (i) sales; and/or (ii) service.
 At step 116b, the automatic message reader also assigns a priority (preferably including a priority number) to the sub-categorized E-mail message 11 where a higher priority indicates that the human operator 40 should process the associated E-mail message 11 before processing lower prioritized E-mail messages 11.
 For example, through the rule based and case based reasoning discussed above, the automatic message reader 30 may interpret the subject matter content of an E-mail message 11 as being related to the product service sub-category. Within the product service sub-category, inquiries may be made relating to: (1) fraud and lost sensitive equipment (i.e., lost/stolen bank cards); (2) sensitive information (i.e., bank account information); (3) general information; and/or (4) user comments. It is preferred that a human operator 40 (dealing with the product service business sub-category) process a customer's inquiry into a fraud before other types of inquiries and, therefore, the fraud inquiry is assigned a highest level of priority. Conversely, a user comment is preferably given a lowest level of priority and may be processed last.
 Alternatively, the automatic message reader 30 may interpret the subject matter content of an E-mail message 11 as being related to the product sales sub-category.
 Within the product sales sub-category, inquiries may be made relating to: (1) promotional content; (2) requests for services; and (3) general questions and/or lengthy messages. It is preferred that a human operator 40 (dealing with the product sales business sub-category) process a customer's inquiry into a promotional effort before other types of inquiries and, therefore, the promotional inquiry is assigned a highest level of priority. Conversely, a general question is preferably given a lowest level of priority and may be processed last.
 It is noted that when the automatic message reader 30 has invoked a case base 34 search in classifying the E-mail message 11, and the best stored case model indicates that the E-mail message 11 is of the referral type, then the sub-categorization and priority of the stored case model will also be assigned to the E--mail message 11 of the presented case model. Further, if the best case model identifies a particular predetermined response, such response (or a modification thereof) may be utilized in responding to the E-mail message 11 of the presented case model.
 After the referral type E-mail message 11 has been sub-categorized and prioritized, the automatic message reader 30 routs the E-mail message 11 to the manual review inbox 24 (step 118) for subsequent retrieval by the human operator 40. If possible, one or more predetermined responses for proposed release and delivery to the source 52 are retrieved from the repository of the automatic message reader 30 and routed to the manual review inbox 24 along with the E-mail message 11.
 At step 120, the human operator 40 (preferably assigned to a specific business sub-category) first reviews and processes the highest priority E-mail messages 11 followed by the lower prioritized E-mail messages 11. When the human operator 40 deems that a predetermined response is appropriate and may be released to the customer 50, the response is routed to the outbox 26 (step 122) for delivery to the domain server 10. The response is then transmitted over the data communications channel 12 to the source 52 (step 124).
 Preferably, all outgoing responses are archived in an archive database 32 for subsequent review and use if desired.
 When the automatic message reader 30 interprets that the referral type E-mail message 11 is also of the “detected” type (step 114c), a particular manual handling procedure for a referred E-mail message 11 has been interpreted from the subject matter of the E-mail. In such a case, one or more remarks (i.e., an explicative aid or advice) for presentation to the human operator 40 may be extracted from the repository of the automatic message reader 30 (step 116c) and routed to the manual review inbox 24 along with the E-mail message 11 (step 118) to assist the human operator 40 in processing the E-mail message 11 in a more efficient manner.
 For example, when the automatic message reader 30 interprets a do not call request, a phone number, a facsimile-number or a foreign address, in the E-mail message 11, it is preferred that a remark indicating a specific manual procedure (e.g., not calling the customer) be forwarded with the E-mail message 11 to the human operator 40. Other types of “detected” features of E-mail messages 11 include, specific employee requests, inclusion of sensitive information, and/or inclusion of other information which dictates a specific manual procedure.
 Such “detected” E-mail messages 11 often contain information which is useful in customizing and improving customer service vis-a-vis the responses to the E-mail messages 11.
 In some instances the response to the customer's 50 E-mail message 11 may not be affected by such “detected” information. However, a human operator 40 might otherwise miss the “detected” information in a strictly manual review process. Thus, a business concern benefits from the classification of “detected” type E-mail messages 11 in that valuable business tools for servicing customers 50 may be developed using the detected information.
 Advantageously, the automatic message interpreting and routing system 1 of the preferred embodiment of the present invention can properly process electronic messages 11 from any number of unknown sources (i.e., the sources need not be predetermined). Indeed, since the automatic message reader 30 employs a knowledge engine to automatically interpret the subject matter content of the electronic message 11, the specific source of the electronic message 11 does not limit the set of electronic messages 11 which may be automatically responded to provided only that they arrive in a recognized format, like ASCII, etc.
 The electronic message 11 is preferably an E--mail message in ASCII text data format, it being understood that the invention is not so limited. Indeed, the electronic message 11 may take on a variety of data formats including digital formats, voice data, dual tone multi-frequency (DTMF) tones, or the like. When the electronic message 11 is in the voice data format or DTMF data format, a receiving device (not shown) suitable for receiving the voice data and/or DTMF tones is included in the automatic message interpreting and routing system 1.
 Further, the message data of the electronic message 11 may be converted from one data format to another prior to transferring the electronic message 11 to the inbox 22. For example, a customer 50 may transmit a printed document (message data) to the automatic message interpreting and routing system 1 by way of a facsimile machine. In that case, the facsimile format file would be converted using, for example, a character recognition process (not shown) which converts the facsimile formatted text into an ASCII data format electronic message 11 prior to transferring the electronic message 11 to the inbox 22.
 The customer SO may also transmit an electronic message 11 in a voice data format to the automatic message interpreting and routing system 1 by way of known methods (e.g., dictation software such as is currently offered commercially from IBM). In such a case, the voice data is preferably converted into a digital text format electronic message 11, for example ASCII, prior to transferring the electronic message 11 to the inbox 22.
 The system for automatically interpreting an incoming electronic message 1 is capable of interpreting electronic messages 11 which contain data in a predetermined arrangement, so-called fixed data electronic messages. An electronic message having fixed data may have the message content (i.e., the customer name, address, message content, etc.) in predetermined positions in the message.
 The system for automatically interpreting an incoming electronic message 1 is also capable of interpreting electronic messages 11 which contain data in variable arrangements, so-called variable data. Such electronic messages having variable data may have the message content in any arrangement.
 It is noted that a business concern may not wish to automatically send a predetermined response to a source 52 without first manually reviewing the response. In such a case, the system for automatically interpreting an incoming electronic message 1 of FIG. I would be modified such that all predetermined responses and/or remarks from the automatic message reader 30 are transferred to the manual review inbox 24. Thus, the process flow of FIG. 2B would be likewise modified such that the output from step 116a (retrieving a predetermined response) is directed to step 118 (transferring to the manual review inbox).
 A working model of the system for automatically interpreting an incoming electronic message of the present invention has been developed which has significantly reduced costs of processing such messages. Specifically, about 5 to 80 percent (depending on the size and structure of the case base) of all incoming electronic messages were automatically processed while the processing time of those messages requiring manual intervention was reduced by about 50 percent.
 The working system utilized the ART*EnterpriseŽ version 2.0b, the Microsoft Win32s library, Visual C/C++1.5, and Lotus NoteS™ version 3.OC running on a Windows 3.1 platform. The system employed an Intel-based 486/66 Mhz, 500 MB hard disk and 32 MB RAM computer.
 Although the present invention has been described in relation to particular embodiments thereof, many other variations and modifications and other uses will become apparent to those skilled in the art. It is preferred, therefore, that the present invention be limited not by the specific disclosure herein, but only by the appended claims.
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7233954 *||Mar 8, 2004||Jun 19, 2007||Microsoft Corporation||Methods for routing items for communications based on a measure of criticality|
|US7337181||Jul 15, 2003||Feb 26, 2008||Microsoft Corporation||Methods for routing items for communications based on a measure of criticality|
|US7577634 *||Aug 5, 2004||Aug 18, 2009||First Look Networks Llc||Method and apparatus for automatically providing expert analysis-based advice|
|US7684068 *||Jan 14, 2004||Mar 23, 2010||Ricoh Company, Ltd.||Method and system for automatically and transparently archiving documents and document meta data|
|US7809663||May 22, 2007||Oct 5, 2010||Convergys Cmg Utah, Inc.||System and method for supporting the utilization of machine language|
|US7840639 *||Sep 21, 1999||Nov 23, 2010||G&H Nevada-Tek||Method and article of manufacture for an automatically executed application program associated with an electronic message|
|US7895611 *||May 31, 2007||Feb 22, 2011||International Business Machines Corporation||Methods and apparatus for creation of parsing rules|
|US7925608 *||Mar 3, 2006||Apr 12, 2011||British Telecommunications Public Limited Company||Fault diagnostics|
|US8166392||May 21, 2003||Apr 24, 2012||Microsoft Corporation||Method for automatically assigning priorities to documents and messages|
|US8296371 *||May 12, 2006||Oct 23, 2012||West Corporation||Individual XML message processing platform|
|US8443378 *||May 31, 2007||May 14, 2013||Red Hat, Inc.||Method and apparatus for associating rules with messages and using the rules for message processing|
|US8892674||Oct 27, 2008||Nov 18, 2014||Microsoft Corporation||Integration of a computer-based message priority system with mobile electronic devices|
|US9092535||Sep 21, 1999||Jul 28, 2015||Google Inc.||E-mail embedded textual hyperlink object|
|US20040160629 *||Jan 14, 2004||Aug 19, 2004||Ricoh Company, Ltd||Method and system for automatically and transparently archiving documents and document meta data|
|US20040172483 *||Mar 8, 2004||Sep 2, 2004||Eric Horvitz||Methods for routing items for communications based on a measure of criticality|
|US20060031182 *||Aug 5, 2004||Feb 9, 2006||First Look Networks Llc||Method and apparatus for automatically providing expert analysis-based advice|
|US20060041583 *||Oct 27, 2005||Feb 23, 2006||Microsoft Corporation||Methods for routing items for communications based on a measure of criticality|
|US20060095473 *||Oct 22, 2005||May 4, 2006||Data Management Associates, Inc.||System and method of orchestrating electronic workflow automation processes|
|US20060195564 *||May 3, 2006||Aug 31, 2006||Accardi Kenneth L||Medical diagnostic system service method and apparatus|
|US20060265462 *||May 12, 2006||Nov 23, 2006||Centerpost Communications, Inc.||Individual XML message processing platform|
|EP1536382A2 *||Nov 26, 2004||Jun 1, 2005||Nec Corporation||Mobile terminal and security remote-control system and method using the mobile terminal|
|EP1703449A1 *||Mar 18, 2005||Sep 20, 2006||BRITISH TELECOMMUNICATIONS public limited company||Fault diagnostics|
|WO2002079936A2 *||Mar 29, 2002||Oct 10, 2002||Capital One Financial Corp||System and method for prioritizing customer inquiries|
|WO2006097675A1 *||Mar 3, 2006||Sep 21, 2006||British Telecomm||Fault diagnostics|
|WO2007094821A1 *||Sep 21, 2006||Aug 23, 2007||Siemens Comm Inc||Method and system for restricting automatic out-of-office email response to configured zone|
|WO2014004810A2 *||Jun 27, 2013||Jan 3, 2014||Groupon, Inc.||Inbox management|
|WO2014004810A3 *||Jun 27, 2013||Feb 12, 2015||Groupon, Inc.||Inbox management|
|International Classification||G06Q10/10, G06N5/04|
|Cooperative Classification||G06Q10/107, G06N5/04|
|European Classification||G06Q10/107, G06N5/04|
|Jul 6, 1998||AS||Assignment|
Owner name: BRIGHTWARE, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RICE, AMY;HSU, JULIE;REEL/FRAME:009517/0914;SIGNING DATES FROM 19980609 TO 19980619
|Oct 13, 1998||AS||Assignment|
Owner name: SILICON VALLEY BANK, CALIFORNIA
Free format text: SECURITY AGREEMENT;ASSIGNOR:BRIGHTWARE, INC.;REEL/FRAME:009522/0583
Effective date: 19980714
|Dec 2, 2002||AS||Assignment|
|Feb 25, 2003||AS||Assignment|
|Mar 8, 2004||AS||Assignment|
|Aug 27, 2004||AS||Assignment|
|Aug 31, 2004||AS||Assignment|
|Nov 8, 2004||AS||Assignment|
|Nov 8, 2005||CC||Certificate of correction|
|Nov 29, 2005||FPAY||Fee payment|
Year of fee payment: 4
|Feb 14, 2006||AS||Assignment|
Owner name: POLARIS IP, LLC, CALIFORNIA
Free format text: MERGER;ASSIGNOR:CIRCINUS IP, LLC;REEL/FRAME:017164/0343
Effective date: 20060206
|Apr 28, 2008||AS||Assignment|
Owner name: BRIGHT RESPONSE, LLC, CALIFORNIA
Free format text: CHANGE OF NAME;ASSIGNOR:POLARIS IP, LLC;REEL/FRAME:020866/0128
Effective date: 20080417
|Jul 22, 2008||RR||Request for reexamination filed|
Effective date: 20080521
|Jul 2, 2009||FPAY||Fee payment|
Year of fee payment: 8
|Jul 27, 2010||RR||Request for reexamination filed|
Effective date: 20100429
|Mar 22, 2011||B1||Reexamination certificate first reexamination|
Free format text: THE PATENTABILITY OF CLAIMS 9, 10, 14, 30-37, 50-51, 57-61, 63-65 AND 66 IS CONFIRMED. CLAIMS 1-8, 11-13, 15-29, 38-49, 52-56 AND 62 ARE CANCELLED. NEW CLAIMS 67-92 ARE ADDED AND DETERMINED TO BE PATENTABLE.
|Jul 2, 2012||AS||Assignment|
Owner name: BRIGHT RESPONSE, LLC, TEXAS
Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ADDRESS OF THE RECEIVING PARTY PREVIOUSLY RECORDED ON REEL 020866 FRAME 0128. ASSIGNOR(S) HEREBY CONFIRMS THE CHANGE OF NAME ASSIGNMENT;ASSIGNOR:POLARIS IP, LLC;REEL/FRAME:028488/0848
Effective date: 20080417
|Jul 6, 2012||AS||Assignment|
Owner name: BRIGHT RESPONSE, LLC, TEXAS
Free format text: CHANGE OF ADDRESS;ASSIGNOR:BRIGHT RESPONSE, LLC;REEL/FRAME:028509/0536
Effective date: 20120701
|Dec 17, 2013||FPAY||Fee payment|
Year of fee payment: 12