DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3, 4, 10, 12 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dhoolia U.S. PAP 2020/0219494 A1.
Regarding claim 1 Dhoolia teaches a computer-implemented method for discovering system actions from historical conversation logs (), the method comprising:
receiving historical conversation logs comprising conversations between users and human agents (obtaining a plurality of conversational logs, each of the conversational logs representing interactions between at least one user and at least one human agent, see par. [0002]);
analyzing user messages and human agent responses within the historical conversation logs using a generative language model to identify opportunities for system actions (From the set of data, the deep learning model learns an algorithm that can be used to respond to inputs that have not been previously seen by the deep learning model, see par. [0025]);
converting identified user messages and human agent responses into system actions using a generative language model (GLM) to perform natural language processing (NLP) (the system then provides the conversational agent workspace that allows the agent designer to generate a conversational specification for the conversational agent. The conversational specification identifies intents for the conversational agent and a dialog flow for the conversational agent. The described system automatically builds the specification of the conversational agent from the plurality of conversational logs, see par. [0027]);
generating an action configuration comprising the identified system actions and required parameters (The system mines these conversational logs to provide suggestions for intents that may be useful for generation of a conversational agent. For example, the system may cluster utterances provided by users within the conversational logs into intent clusters. In other words, when a user first accesses a dialog application to request assistance from a human agent, the user provides a reason or request for assistance, see par. [0028]);
and storing the action configuration for use in training an autonomous conversational AI system (From the selection of intents and dialog nodes, the system can generate a dialog flow at 103C. To create a dialog flow that includes more than just a single intent node and a single response or dialog node, the system may iteratively provide suggestions and receive selections for additional intents, referred to as aspects or sub-intents, and dialog response nodes, see par. [0033]).
Regarding claim 3 Dhoolia teaches the method of claim 1, wherein converting identified user messages and human agent responses into system actions comprises:
analyzing agent responses to identify application programming interface (API) call patterns (The bootstrapping service is then configured. Within the bootstrapping service, the system learns an application program interface (API) in the form of a human agent emulator and a user emulator, see par. [0023]);
converting the identified agent responses into API calls using the GLM performing NLP, wherein
i) the GLM performing NLP translates agent response phrases indicating external service requests into corresponding API call structures (The conversational specifications specify an intent and a dialog or conversational flow. An intent is what the user says or what the user intends to say. In other words, an intent can be identified as an utterance or conversational turn that could be provided by a user of the conversational agent, see par. [0016]; to identify possible utterances the system may generate a deep learning model and/or index structure from the conversational logs, see par. [0025]),
ii) the agent response phrases comprise statements about retrieving third-party system information, and the API call structures define operations for accessing and retrieving information from external services ( he conversational or dialog flow identifies how the conversational agent will respond when provided with a particular input from a user. For example, if the user provides input X, then the dialog flow would indicate how the conversational agent should respond to that input X. The dialog flow can have different dialog nodes that allow the conversational agent to respond to different inputs that can be provided by the user, see par. [0016]);
executing the API calls on connected third-party systems to obtain response data (As the conversation progresses, the conversational agent processes input received from a user and accesses a node within the dialog flow that is responsive to the received input, see par. [0016]);
and storing the response data in conversation context variables for use in generating agent responses ( within the conversational specification the agent developer creates the nodes and provides an algorithm to the conversational agent so that the conversational agent can select and traverse nodes of the dialog flow in response to intents provided by the user. Once both the intent and the dialog flow are identified the conversational agent can be created from the conversational specification, see par. [0016]).
Regarding claim 4 Dhoolia teaches the method of claim 1, wherein the GLM is fine-tuned on domain-specific conversation data from a similar business domain (These suggested intents are generated by mining the plurality of conversational logs to identify things that a user has said to a human agent within a particular domain, see par. [0019]), enabling the model to:
identify domain-specific intents without requiring explicit programming (After the designer selects an intent, the system can provide a suggestion for a dialog node that corresponds to the selected intent, see par. [0019]);
recognize linguistic variations of the same intent across different phrasings (The intent clusters then contain utterances which have a similarity to other utterances within the cluster. For example, an utterance of “Application X password reset” and an utterance of “I need help resetting my password for Application X” may be identified as having a similar purpose and may, therefore, be clustered within the same intent group, see par. [0029];
and discover new intents that were not explicitly defined in training data ( To generate the suggestion(s), the system provides the intent to the agent emulator and the agent emulator provides possible responses that may have been provided by a human agent. The dialog flow for the conversational agent can then be generated by iteratively providing dialog nodes to a user emulator to receive suggestions for intents and aspects (also referred to as sub-intents) providing a selection of the suggestion for an intent or aspect from a developer, see par. [0019]).
Regarding claim 10 Dhoolia teaches a system for discovering system actions from historical conversation logs (apparatus, see par. [0003]), the system comprising:
one or more processors (processor, see par. [0003]);
one or more memory storage devices storing instructions thereon, which, when executed by the one or more processors (a computer readable storage medium having computer readable program code embodied therewith and executable by the at least one processor, see par. [0003]), cause the system to perform operations comprising:
receiving historical conversation logs comprising conversations between users and human agents; analyzing user messages and human agent responses within the historical conversation logs using a generative language model to identify opportunities for system actions; converting identified user messages and human agent responses into system actions using a generative language model (GLM) to perform natural language processing (NLP); generating an action configuration comprising the identified system actions and required parameters; and storing the action configuration for use in training an autonomous conversational AI system.
receiving historical conversation logs comprising conversations between users and human agents (obtaining a plurality of conversational logs, each of the conversational logs representing interactions between at least one user and at least one human agent, see par. [0002]);
analyzing user messages and human agent responses within the historical conversation logs using a generative language model to identify opportunities for system actions (From the set of data, the deep learning model learns an algorithm that can be used to respond to inputs that have not been previously seen by the deep learning model, see par. [0025]);
converting identified user messages and human agent responses into system actions using a generative language model (GLM) to perform natural language processing (NLP) (the system then provides the conversational agent workspace that allows the agent designer to generate a conversational specification for the conversational agent. The conversational specification identifies intents for the conversational agent and a dialog flow for the conversational agent. The described system automatically builds the specification of the conversational agent from the plurality of conversational logs, see par. [0027]);
generating an action configuration comprising the identified system actions and required parameters (The system mines these conversational logs to provide suggestions for intents that may be useful for generation of a conversational agent. For example, the system may cluster utterances provided by users within the conversational logs into intent clusters. In other words, when a user first accesses a dialog application to request assistance from a human agent, the user provides a reason or request for assistance, see par. [0028]);
and storing the action configuration for use in training an autonomous conversational AI system (From the selection of intents and dialog nodes, the system can generate a dialog flow at 103C. To create a dialog flow that includes more than just a single intent node and a single response or dialog node, the system may iteratively provide suggestions and receive selections for additional intents, referred to as aspects or sub-intents, and dialog response nodes, see par. [0033]).
Regarding claim 12 Dhoolia teaches the system of claim 10, wherein converting identified user messages and human agent responses into system actions comprises:
analyzing agent responses to identify application programming interface (API) call patterns (The bootstrapping service is then configured. Within the bootstrapping service, the system learns an application program interface (API) in the form of a human agent emulator and a user emulator, see par. [0023]);
converting the identified agent responses into API calls using the GLM performing NLP, wherein
i) the GLM performing NLP translates agent response phrases indicating external service requests into corresponding API call structures (The conversational specifications specify an intent and a dialog or conversational flow. An intent is what the user says or what the user intends to say. In other words, an intent can be identified as an utterance or conversational turn that could be provided by a user of the conversational agent, see par. [0016]; to identify possible utterances the system may generate a deep learning model and/or index structure from the conversational logs, see par. [0025]),
ii) the agent response phrases comprise statements about retrieving third-party system information, and the API call structures define operations for accessing and retrieving information from external services ( he conversational or dialog flow identifies how the conversational agent will respond when provided with a particular input from a user. For example, if the user provides input X, then the dialog flow would indicate how the conversational agent should respond to that input X. The dialog flow can have different dialog nodes that allow the conversational agent to respond to different inputs that can be provided by the user, see par. [0016]);
executing the API calls on connected third-party systems to obtain response data (As the conversation progresses, the conversational agent processes input received from a user and accesses a node within the dialog flow that is responsive to the received input, see par. [0016]);
and storing the response data in conversation context variables for use in generating agent responses ( within the conversational specification the agent developer creates the nodes and provides an algorithm to the conversational agent so that the conversational agent can select and traverse nodes of the dialog flow in response to intents provided by the user. Once both the intent and the dialog flow are identified the conversational agent can be created from the conversational specification, see par. [0016]).
Regarding claim 13 Dhoolia teaches the system of claim 10, wherein the GLM is fine-tuned on domain-specific conversation data from a similar business domain (These suggested intents are generated by mining the plurality of conversational logs to identify things that a user has said to a human agent within a particular domain, see par. [0019]), enabling the model to:
identify domain-specific intents without requiring explicit programming (After the designer selects an intent, the system can provide a suggestion for a dialog node that corresponds to the selected intent, see par. [0019]);
recognize linguistic variations of the same intent across different phrasings (The intent clusters then contain utterances which have a similarity to other utterances within the cluster. For example, an utterance of “Application X password reset” and an utterance of “I need help resetting my password for Application X” may be identified as having a similar purpose and may, therefore, be clustered within the same intent group, see par. [0029];
and discover new intents that were not explicitly defined in training data ( To generate the suggestion(s), the system provides the intent to the agent emulator and the agent emulator provides possible responses that may have been provided by a human agent. The dialog flow for the conversational agent can then be generated by iteratively providing dialog nodes to a user emulator to receive suggestions for intents and aspects (also referred to as sub-intents) providing a selection of the suggestion for an intent or aspect from a developer, see par. [0019]).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 2, 5-8, 11, 14-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dhoolia U.S. PAP 2020/0219494 A1 in view of Mazza U.S. PAP 2019/0182382 A1.
Regarding claim 2 Dhoolia does not teach the method of claim 1, wherein converting identified user messages and human agent responses into system actions using the GLM performing NLP comprises: analyzing agent responses to identify database retrieval patterns; converting the identified agent responses into database queries using the GLM, wherein i) the GLM translates agent response phrases indicating database access into corresponding SQL query structures, ii) the agent response phrases comprise statements about loading or retrieving user account information, and iii) the SQL query structures define database operations for accessing and retrieving the user account information; executing the database queries on connected database systems to obtain response data; and storing the response data in conversation context variables for use in generating agent responses.
In the same field of endeavor Mazza teaches interactive chatbots and systems and methods for training and operating chatbots, see par. [0001].
analyzing agent responses to identify database retrieval patterns ( If the communication is to be routed to an agent, the call controller 118 interacts with the routing server (also referred to as an orchestration server) 124 to find an appropriate agent for processing the interaction. The selection of an appropriate agent for routing an inbound interaction may be based, for example, on a routing strategy employed by the routing server 124, and further based on information about agent availability, skills, and other routing parameters provided, for example, by a statistics server 132, see par. [0063]);
converting the identified agent responses into database queries using the GLM, wherein
i) the GLM translates agent response phrases indicating database access into corresponding SQL query structures (The database may also be a SQL database and may be managed by any database management system, see par. [0064]),
ii) the agent response phrases comprise statements about loading or retrieving user account information (once an appropriate agent is identified as being available to handle a communication, a connection may be made between the customer and an agent device 130a-130c (collectively referenced as 130) of the identified agent. Collected information about the customer and/or the customer's historical information may also be provided to the agent device for aiding the agent in better servicing the communication, see par. [0065]), and
iii) the SQL query structures define database operations for accessing and retrieving the user account information (performing data processing associated with contact center operations, and for interfacing with customers via voice and other multimedia communication mechanisms, see par. [0065]);
executing the database queries on connected database systems to obtain response data (the module 750 may take in a customerId parameter in 752. In node 754, the chatbot sends, to the customer, the message “may I please get the last 4 numbers on the payment method you have on file with us?, see par. [0154]);
and storing the response data in conversation context variables for use in generating agent responses (the chatbot receives a response from the customer (756 may, formally, correspond to an edge of the dialogue graph). The received input is stored in the variable “cc” and the “Type” is specified to be four digits (denoted in FIG. 7B as “\d{4}” where “\d” indicates a digit and “{4}” indicates that the previous character class is repeated four times). In 758, the chatbot determines whether the given cc is valid, see par. [0154]).
It would have been obvious to one of ordinary skill in the art to combine the Dhoolia invention with the teachings of Mazza for the benefit of improving the topical coverage of a resulting configured chatbot compared to manually configured chatbots. This is because embodiments of the present invention can include larger amounts of sample dialogue data (e.g., thousands to tens of thousands of sample dialogue data or more) whereas a human chatbot designer would only be able to consider a comparatively smaller sampling of a few of chat transcripts, see par. [0051].
Regarding claim 5 Mazza teaches the method of claim 1, further comprising: extracting parameters required for executing the system actions using a slot-extractor model (conversations are treated as ordered sequences where each slot in the sequence may contain one of the anchors found in operation 354 or a gap, see par. [0133]), wherein the slot-extractor model i) identifies requestable slots representing outputs of the system actions (nodes correspond to the agent side of the interaction and edges correspond to the customer side, see par. [0137]), and ii) identifies placeholder parameters required for grammar purposes (The keyphrases serve as a way to communicate, to the designer, the semantics of the transition between the agent states. In particular, for each edge (u, v) in the dialog graph, the data extraction module 172 collects all customers sentences that were in direct response to u and that were followed by v with no other anchors between them, see par. [0138]).
Regarding claim 6 Mazza teaches the method of claim 5, wherein extracting parameters required for executing the system actions using a slot-extractor model further comprises:
identifying entity types within user messages and human agent responses ( finding the main input and output entities in each dialogue topic, see par. [0048]);
mapping the identified entity types to database fields and/or API parameters (.g., receiving as “input” from the customer: account numbers, payment information, mailing address, and the like, and sending as “output” from the agent of the contact center: dates, prices, ticket numbers, tracking numbers, and the like, see par. [0048]);
determining which parameters are required versus optional for each system action ( the chatbot generation module 174 prunes (e.g., removes) or modifies the edges at each node of the dialogue graph in order to define deterministic paths for the chatbot to follow through the dialogue graph in order to conduct an interaction with a customer. The modifications may include, for example, modifying the collection of keyphrases characterizing a transition (e.g., to remove keyphrases or insert keyphrases), completely removing the edge, or adding a new edge between two nodes, see par. [0147]);
and validating extracted parameter values against expected formats and constraints (In 704, the pruned dialogue tree may execute a verification “module” or subtree for providing verification of a customer, see par. [0149]).
Regarding claim 7 Mazza teaches the method of claim 1, wherein analyzing user messages and human agent responses comprises one or more of: preprocessing the historical conversation logs to remove filler words and repetitions from voice recordings; preprocessing the historical conversation logs to extract relevant content from email bodies; and preprocessing the historical conversation logs to segment user utterances into individual sentences. (the data extraction module 172 cleans and normalizes the sample dialogue data. According to one embodiment, as part of the cleaning and normalizing of the transcripts, the data extraction module 172 extracts a “description” and a “body” from each interaction in the sample dialogue data, see par. [0082-0083]; some embodiments, where such transcripts may not be available, generic training data collected from other enterprises and redacted (e.g., to remove enterprise-specific information) may be used as the sample dialogue data, see par. [0079]).
Regarding claim 8 Mazza teaches the method of claim 1, wherein analyzing user messages and human agent responses comprises: preprocessing the historical conversation logs, wherein the preprocessing normalizes conversation logs from multiple communication channels including chat, email and voice recordings into a canonical representation for analysis (The media interactions may be related, for example, to email, vmail (voice mail through email), chat, video, text-messaging, web, social media, co-browsing, and the like, see par. [0066]).
Regarding claim 11 Dhoolia does not teach the system of claim 10, wherein converting identified user messages and human agent responses into system actions using the GLM performing NLP comprises: analyzing agent responses to identify database retrieval patterns; converting the identified agent responses into database queries using the GLM, wherein i) the GLM translates agent response phrases indicating database access into corresponding SQL query structures, ii) the agent response phrases comprise statements about loading or retrieving user account information, and iii) the SQL query structures define database operations for accessing and retrieving the user account information; executing the database queries on connected database systems to obtain response data; and storing the response data in conversation context variables for use in generating agent responses.
In the same field of endeavor Mazza teaches interactive chatbots and systems and methods for training and operating chatbots, see par. [0001].
analyzing agent responses to identify database retrieval patterns ( If the communication is to be routed to an agent, the call controller 118 interacts with the routing server (also referred to as an orchestration server) 124 to find an appropriate agent for processing the interaction. The selection of an appropriate agent for routing an inbound interaction may be based, for example, on a routing strategy employed by the routing server 124, and further based on information about agent availability, skills, and other routing parameters provided, for example, by a statistics server 132, see par. [0063]);
converting the identified agent responses into database queries using the GLM, wherein
i) the GLM translates agent response phrases indicating database access into corresponding SQL query structures (The database may also be a SQL database and may be managed by any database management system, see par. [0064]),
ii) the agent response phrases comprise statements about loading or retrieving user account information (once an appropriate agent is identified as being available to handle a communication, a connection may be made between the customer and an agent device 130a-130c (collectively referenced as 130) of the identified agent. Collected information about the customer and/or the customer's historical information may also be provided to the agent device for aiding the agent in better servicing the communication, see par. [0065]), and
iii) the SQL query structures define database operations for accessing and retrieving the user account information (performing data processing associated with contact center operations, and for interfacing with customers via voice and other multimedia communication mechanisms, see par. [0065]);
executing the database queries on connected database systems to obtain response data (the module 750 may take in a customerId parameter in 752. In node 754, the chatbot sends, to the customer, the message “may I please get the last 4 numbers on the payment method you have on file with us?, see par. [0154]);
and storing the response data in conversation context variables for use in generating agent responses (the chatbot receives a response from the customer (756 may, formally, correspond to an edge of the dialogue graph). The received input is stored in the variable “cc” and the “Type” is specified to be four digits (denoted in FIG. 7B as “\d{4}” where “\d” indicates a digit and “{4}” indicates that the previous character class is repeated four times). In 758, the chatbot determines whether the given cc is valid, see par. [0154]).
It would have been obvious to one of ordinary skill in the art to combine the Dhoolia invention with the teachings of Mazza for the benefit of improving the topical coverage of a resulting configured chatbot compared to manually configured chatbots. This is because embodiments of the present invention can include larger amounts of sample dialogue data (e.g., thousands to tens of thousands of sample dialogue data or more) whereas a human chatbot designer would only be able to consider a comparatively smaller sampling of a few of chat transcripts, see par. [0051].
Regarding claim 14 Mazza teaches the system of claim 10, wherein the operations further comprise: extracting parameters required for executing the system actions using a slot-extractor model (conversations are treated as ordered sequences where each slot in the sequence may contain one of the anchors found in operation 354 or a gap, see par. [0133]), wherein the slot-extractor model i) identifies requestable slots representing outputs of the system actions (nodes correspond to the agent side of the interaction and edges correspond to the customer side, see par. [0137]), and ii) identifies placeholder parameters required for grammar purposes (The keyphrases serve as a way to communicate, to the designer, the semantics of the transition between the agent states. In particular, for each edge (u, v) in the dialog graph, the data extraction module 172 collects all customers sentences that were in direct response to u and that were followed by v with no other anchors between them, see par. [0138]).
Regarding claim 15 Mazza teaches the system of claim 14, wherein extracting parameters required for executing the system actions using a slot-extractor model further comprises: identifying entity types within user messages and human agent responses ( finding the main input and output entities in each dialogue topic, see par. [0048]);
mapping the identified entity types to database fields and/or API parameters (.g., receiving as “input” from the customer: account numbers, payment information, mailing address, and the like, and sending as “output” from the agent of the contact center: dates, prices, ticket numbers, tracking numbers, and the like, see par. [0048]);
determining which parameters are required versus optional for each system action ( the chatbot generation module 174 prunes (e.g., removes) or modifies the edges at each node of the dialogue graph in order to define deterministic paths for the chatbot to follow through the dialogue graph in order to conduct an interaction with a customer. The modifications may include, for example, modifying the collection of keyphrases characterizing a transition (e.g., to remove keyphrases or insert keyphrases), completely removing the edge, or adding a new edge between two nodes, see par. [0147]);
and validating extracted parameter values against expected formats and constraints (In 704, the pruned dialogue tree may execute a verification “module” or subtree for providing verification of a customer, see par. [0149]).
Regarding claim 16 Mazza teaches the system of claim 10, wherein analyzing user messages and human agent responses comprises one or more of: preprocessing the historical conversation logs to remove filler words and repetitions from voice recordings; preprocessing the historical conversation logs to extract relevant content from email bodies; and preprocessing the historical conversation logs to segment user utterances into individual sentences. (the data extraction module 172 cleans and normalizes the sample dialogue data. According to one embodiment, as part of the cleaning and normalizing of the transcripts, the data extraction module 172 extracts a “description” and a “body” from each interaction in the sample dialogue data, see par. [0082-0083]; some embodiments, where such transcripts may not be available, generic training data collected from other enterprises and redacted (e.g., to remove enterprise-specific information) may be used as the sample dialogue data, see par. [0079]).
Regarding claim 17 Mazza teaches the system of claim 10, wherein analyzing user messages and human agent responses comprises: preprocessing the historical conversation logs, wherein the preprocessing normalizes conversation logs from multiple communication channels including chat, email and voice recordings into a canonical representation for analysis (The media interactions may be related, for example, to email, vmail (voice mail through email), chat, video, text-messaging, web, social media, co-browsing, and the like, see par. [0066]).
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Dhoolia U.S. PAP 2020/0219494 A1 in view of Ciano U.S. PAP 2019/0238487 A1.
Regarding claim 9 Dhoolia does not teach method of claim 1, wherein the method further comprises: detecting poor performance of the autonomous conversational AI system; gathering conversations where poor performance was observed; generating an updated action configuration using the gathered conversations; and retraining the autonomous conversational AI system using the updated action configuration to improve performance over time.
In the same field of endeavor Ciano teaches techniques of constructing and configuring a conversational agent learning model dynamically, see par. [0003].3
Increased automation and increased ability to customize aspects of the conversational agent learning model in accordance with the various embodiments may result in increased client satisfaction and an improved customer relationship management process relative to conventional cognitive models, see par. [0022].
detecting poor performance of the autonomous conversational AI system (at step 225 the model advisor, based upon information received consequent to the interaction between the conversational agent learning model and the plurality of clients, may identify at least one deficiency in the conversational agent learning model, see par. [0051]);
gathering conversations where poor performance was observed (such information received consequent to the interaction may include conversation content and/or general information associated with one or more of the plurality of clients, see par. [0051]);
generating an updated action configuration using the gathered conversations (at step 230 the model advisor may update the conversational agent learning model to address the at least one deficiency, see par. [0051]);
and retraining the autonomous conversational AI system using the updated action configuration to improve performance over time (The model advisor may add new information to existing categories within the model structure. Additionally or alternatively, the model advisor may determine one or more new categories and may embed such new categories into the model structure. The model advisor may embed such new categories autonomously, i.e., without intervention from a domain administrator, see par. [0051]).
It would have been obvious to one of ordinary skill in the art to combine the Dhoolia invention with the teachings of Ciano for the benefit of increased automation and increased ability to customize aspects of the conversational agent learning model in accordance with the various embodiments may result in increased client satisfaction and an improved customer relationship management process relative to conventional cognitive models, see par. [0022].
Regarding claim 18 Dholia does not teach the system of claim 10, wherein the operations further comprise: detecting poor performance of the autonomous conversational AI system; gathering conversations where poor performance was observed; generating an updated action configuration using the gathered conversations; and retraining the autonomous conversational AI system using the updated action configuration to improve performance over time.
In the same field of endeavor Ciano teaches techniques of constructing and configuring a conversational agent learning model dynamically, see par. [0003].3
Increased automation and increased ability to customize aspects of the conversational agent learning model in accordance with the various embodiments may result in increased client satisfaction and an improved customer relationship management process relative to conventional cognitive models, see par. [0022].
detecting poor performance of the autonomous conversational AI system (at step 225 the model advisor, based upon information received consequent to the interaction between the conversational agent learning model and the plurality of clients, may identify at least one deficiency in the conversational agent learning model, see par. [0051]);
gathering conversations where poor performance was observed (such information received consequent to the interaction may include conversation content and/or general information associated with one or more of the plurality of clients, see par. [0051]);
generating an updated action configuration using the gathered conversations (at step 230 the model advisor may update the conversational agent learning model to address the at least one deficiency, see par. [0051]);
and retraining the autonomous conversational AI system using the updated action configuration to improve performance over time (The model advisor may add new information to existing categories within the model structure. Additionally or alternatively, the model advisor may determine one or more new categories and may embed such new categories into the model structure. The model advisor may embed such new categories autonomously, i.e., without intervention from a domain administrator, see par. [0051]).
It would have been obvious to one of ordinary skill in the art to combine the Dhoolia invention with the teachings of Ciano for the benefit of increased automation and increased ability to customize aspects of the conversational agent learning model in accordance with the various embodiments may result in increased client satisfaction and an improved customer relationship management process relative to conventional cognitive models, see par. [0022].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Pertinent prior art available on form 892.
Kneller ‘417 teaches training data creation processes that may use NLU technology, deep learning and language modeling to automatically generate or create bot training data or automatically create automatic bots, see par. [0005].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michael Ortiz-Sanchez whose telephone number is (571)270-3711. The examiner can normally be reached Monday- Friday 9AM-6PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bhavesh Mehta can be reached at 571-272-7453. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MICHAEL ORTIZ-SANCHEZ/Primary Examiner, Art Unit 2656
