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 .
Notice to Applicant
The following is a Non-Final, first Office Action responsive to Applicant’s communication of 5/10/24, in which applicant filed the application. Claims 1-18 are pending in the instant application and have been rejected below.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 386(c) as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed applications, Application No. 63/155,449; 17/682,537, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. “Summarizer” found in claims 1-9 is not disclosed in these earlier applications.
The priority date is believed to be 9/1/22, based on provisional 63/403,054 disclosing the “Summarizer.”
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 8/12/24, 9/13/24, 12/9/24, 2/12/25, and 6/12/25 are being considered by the examiner.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: engine in claim 14.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 9 and 14-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 14 limitation “solve engine” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Examiner suggests reciting something like : “computer-readable medium storing code executed by a processor” then comprising the different engines, as supported in [0270-0271] as published. Applicant can also consider other amendments, to avoid the 112b indefinite issue in light of 112f interpretation.
Claim 14 is also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential structural cooperative relationships of elements, such omission amounting to a gap between the necessary structural connections. See MPEP § 2172.01. The omitted structural cooperative relationships are: The preamble recites a “system”, but the system appears devoid of any structure as the “system” comprises a “database, a machine learning model, and a solve engine”. Based on FIG. 1-2B, [270-271] as published and other portions of the specification, Examiner suggests amending the claim to recite:
A customer support system, comprising:
at least one processor;
a database…
a topic discovery machine learning model, executed by at least one of the processors,…
a solve engine, stored in a computer readable medium that is executed by at least one of the processors,…
Other amendments may also resolve the issues.
Claims 15-18 depend from claim 14 and are rejected for the same reasons.
Claim 9 recites “the context of the email.” There is insufficient antecedent basis for this limitation in the claim. Examiner suggests introducing “a context” in either claim 1 or claim 9.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 12 is rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 12 recites the same limitations as the last step of claim 10, from which it depends from. Applicant may cancel the claim 12, amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without reciting significantly more.
Step One - First, pursuant to step 1 in MPEP 2106.03, the claim 1 is directed to a method which is a statutory category.
Step 2A, Prong One - MPEP 2106.04 - The claim 1 recites–
“A computer-implemented method of augmenting customer support, comprising:
generating a granular taxonomy of topics indicative of different intents of customers, including:
ingesting customer support tickets associated with a helpdesk;
filtering the customer support tickets to filter at least one of noisy and irrelevant tickets (Applicant’s [0163] as published gives examples for filtering as using heuristics, “other heuristic rules”, thresholds, percentages - accordingly, this is directed to a “mathematical relationship”);
for the filtered customer support tickets, converting unstructured ticket data to structured data to form tickets with structured data ([0161] as published states “conversion of the unstructured text data into structured text may use any known algorithm, model, or machine learning technique to convert unstructured text into structured (or semi-structured) text that can be clustered in the later clustering step of the process.” - accordingly, this is directed to a “mathematical relationship);
clustering the customer support tickets with structured data;
utilizing the clusters to label the customer support tickets to form a weakly supervised training data ([0162] as published states “The clustering algorithm may include a rule or an algorithm to assign a text description to the cluster”; The may include a variety of different clustering algorithms, such as k-means clustering. Another option is agglomerative clustering to create a hierarchy of clusters); and
training a classifier on the weakly supervised training data, to classify customer support tickets into topics of a granular taxonomy;
for an incoming longform email of a customer, utilizing an abstractive summarizer (Examiner notes at this time the support in [0206] as published for “abstractive summarizer” states “a long rambling unstructured email rant by a customer may be converted into structured data identifying the most likely real problem the customer had.” It says an alternative is it “may use machine learning techniques”) to generate a summary of the email;
determining an intent of the email using the classifier to determine a topic from the summary of the email;
selecting a workflow for the email based on the topic;
handing off the workflow … to interact with the customer to complete the workflow.
As drafted, this is, under its broadest reasonable interpretation, directed to the Abstract idea groupings of “certain methods of organizing human activity” (“managing personal behavior (including social activities, teaching, and following rules or instructions)) and “mathematical relationships” and “mental processes”- as here we have removing tickets that are noisy/irrelevant, mathematically converting unstructured (e.g. text) to structured data to represent the tickets in a standard way, clustering the tickets (i.e. requests for help), using the clusters to then label the tickets, which is then used to classify the tickets into a taxonomy of topics, summarizing email messages from customers, determining intent (i.e. question) topic, selecting a workflow (Applicant’s [0138] as published gives examples of “issuing a customer survey”, scheduling a refund, follow-up call), handing off workflow to interact with the customer to complete the workflow). Accordingly, claim 1 is directed to an abstract idea because it is for helping a person (e.g. employee) group the tickets into an organized taxonomy of topics to provide customer support; where math relationships are used at multiple steps – a) filtering tickets deemed noisy/irrelevant (Applicant’s [0163] as published gives examples for filtering as using heuristics, “other heuristic rules”, thresholds, percentages”); b) converting unstructured data (Applicant’s [0161] as published - conversion of the unstructured text data into structured text may use any known algorithm); c) clustering the tickets; and use of “training a classifier” based on the labels (0162] as published states “The clustering algorithm may include a rule or an algorithm to assign a text description to the cluster”; The may include a variety of different clustering algorithms, such as k-means clustering); see also July 2024 Subject Matter Eligibility Update, Example 47, claim 2 – series of mathematical calculations, includes the “training”; Example 48, claim 1 – series of mathematical relationships in mixed speech signal. At this time, the claim is also directed to Mental Processes – as a person performs the same process of placing customer email questions into 3 topics in a taxonomy, removing noisy/irrelevant tickets, putting “structured data” of a label representing the topic, then grouping at least 2 tickets together, then “summarizing” the email, determining its intent and which topic cluster to put it in, and selecting a relevant workflow (to resolve the question/email/ticket).
Step 2A, Prong Two - MPEP 2106.04 - This judicial exception is not integrated into a practical application. In particular, the claim 1 recites additional elements that are:
A computer-implemented method of augmenting customer support, comprising:
generating a granular taxonomy of topics indicative of different intents of customers, including:
ingesting customer support tickets associated with a helpdesk;
filtering the customer support tickets to filter at least one of noisy and irrelevant tickets;
for the filtered customer support tickets, converting unstructured ticket data to structured data to form tickets with structured data;
clustering the customer support tickets with structured data;
utilizing the clusters to label the customer support tickets to form a weakly supervised training data; and
training a classifier on the weakly supervised training data, to classify customer support tickets into topics of a granular taxonomy;
for an incoming longform email of a customer, utilizing an abstractive summarizer to generate a summary of the email;
determining an intent of the email using the classifier to determine a topic from the summary of the email;
selecting a workflow for the email based on the topic;
handing off the workflow to an interactive chat widget to interact with the customer to complete the workflow
(Additional element involve computer performing a number of operations, and computer is construed as sending messages in chat for the “interactive chat widget”; MPEP 2106.05f applied – each limitation in claim involves a computer and is considered “apply it” – applying the abstract idea on a computer – merely uses a computer as a tool to perform an abstract idea; see also MPEP 2106.05h field of use that the machine learning model is training using a computer and the combination of computer, learning, classifier, chat widget; See also July 2024 Subject Matter Eligibility Update, Example 47, claim 2; Example 48, claim 1; the “machine learning model” and training are “mere instructions to implement abstract idea on a computer at MPEP 2106.05f and “field of use” (MPEP 2106.05h)).
These elements of computer in the preamble and “trained machine learning model”, amounts to no more than mere instructions to apply the exception using a generic computer component (See MPEP 2106.05(f)) and individually or in combination is consideration “field of use” (MPEP 2106.05h). Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim also fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, and/or an additional element applies or uses the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. See 84 Fed. Reg. 55. The claim is directed to an abstract idea.
Step 2B in MPEP 2106.05 - The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a computer system are MPEP 2106.05(f) (Mere Instructions to Apply an Exception – “Thus, for example, claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible.” Alice Corp., 134 S. Ct. at 235) and MPEP 2106.05h (field of use). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
The claim fails to recite any improvements to another technology or technical field, improvements to the functioning of the computer itself, use of a particular machine, effecting a transformation or reduction of a particular article to a different state or thing, adding unconventional steps that confine the claim to a particular useful application, and/or meaningful limitations beyond generally linking the use of an abstract idea to a particular environment. See 84 Fed. Reg. 55. The claim is not patent eligible. Viewed individually or as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
Independent claim 10 is directed to a method at step 1, which is a statutory category. Claim 10 recites similar limitations as claim 1 and is rejected for the same reasons at step 2a, prong one; step 2a, prong 2 and step 2b. In addition, claim 10 recites: “generative large language model”- this is considered to be executed by a computer and in combination/individually at step 2a, prong two and step 2b - is considered MPEP 2106.05f – apply it [abstract idea] on a computer and field of use (MPEP 2106.05h). See also Updated July 2024 Subject Matter Eligibility Update, Example 47, claim 2 and Example 48, claim 1; that is “mere instructions to implement abstract idea on a computer at MPEP 2106.05f” and field of use (MPEP 2106.05h) for having “deep neural network, learning” for determining vectors of a speech signal, which is part of the abstract idea as in claim 1 of Example 48.
Independent claim 14 is directed to a system at step 1, which is a statutory category. Claim 14 recites similar limitations as claim 1 and claim 10 and is rejected for the same reasons at step 2a, prong one, 2a, prong 2, and step 2b.
Claims 2, 15 narrow the abstract idea by requesting a user to fill out any necessary information for the workflow to presumably resolve the question from the customer; To extent the question is posed by “interactive chat widget” this is “mere instructions to implement abstract idea on a computer at MPEP 2106.05f” and field of use (MPEP 2106.05h), as the chat computer could ask user(s) for any missing information.
Claims 3, 13, 17 have an additional element of using API to access a service/resource to complete the workflow ; the example is the API call for a service could just “requesting a refund” [0220] as published. At this time, this is considered “mere instructions to implement abstract idea on a computer at MPEP 2106.05f” and field of use (MPEP 2106.05h). At step 2B, the API to access a service (e.g. for information), is considered a conventional computer function – See MPEP 2106.05d - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321.
Claims 4, 16 have a “generative large language model,” which is mere instructions to implement abstract idea on a computer at MPEP 2106.05f” and field of use (MPEP 2106.05h) for same reasons as claim 10 above. The specific information being email, email address, or customer information is considered part of the abstract idea and at this time is not functionally involved, as it only has meaning to a human.
Claim 5 narrows the abstract idea by having different workflows (i.e. actions to resolve issues such as billing) for different topic.
Claim 6 narrows the abstract idea as it gives a recommendation to a user to automate a workflow. To extent computer would perform workflow/steps, it is an additional element treated under step 2a, prong two and step 2B. It is viewed as just “apply it [abstract idea] on a computer” for just using computer to give the response.
Claim 7 narrows the abstract idea by further “optimizing” the classifier; specification [0164] states any optimization can be performed; [0122] as published states optimizing algorithms are based on positive/negative feedback from customers; [0207] as published just states “optimized” for determining topics.
Claim 8 narrows the abstract idea by having a “mapping” to a topic, such as “payroll problem” being closest topic [0221 as published].
Claim 9 narrows the abstract by also having a “context” of the email, which is how a person can understand a question/email. To extent the context is saved/stored/”maintained” by the computer, this is considered “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong two and step 2B.
Claim 11, 12 narrows the abstract idea by having “slot filling” for a topic, similar to claim 2; claim 11 and claim 12 recite “generative language model” which is an additional element addressed in claims 10 and 4 above.
Claim 18 has summarizer which is addressed in claim 1 above as “apply it [abstract idea] on a computer” (MPEP 2106.05f) at step 2a, prong two and step 2B.
Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information on 101 rejections, see MPEP 2106.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1 and 7-18 are rejected under 35 U.S.C. 103 as being unpatentable over Nefedov (US 2019/0220695) and Attwater (US 2023/0244855).
Concerning claim 1, Nefedov discloses:
A computer-implemented method of augmenting customer support (Nefedov – see par 57 - The present invention provides a system for discovering new trends and clustering cases in Customer Support Systems, PCSS 3, and includes automatic tagging for clusters and a Recommendation Engine to find relevant resolutions. In this example the CTE 7 is configured to use features engineering and unsupervised clustering; automatic topic tagging for a set of documents/cases; and creation of new tags for topics documents if the reported problems are not in the knowledge database; see par 44 - The PCSS includes a central server and is computer-based and includes processors, memory components that store executable code sets for processing by the processors, and a database or mechanisms to access one or more databases, including the PKD. See par 55 – processors/computers), comprising:
generating a granular taxonomy of topics indicative of different intents of customers (Nefedov – see par 57 - The present invention provides a system for discovering new trends and clustering cases in Customer Support Systems, PCSS 3, and includes automatic tagging for clusters and a Recommendation Engine to find relevant resolutions. In this example the CTE 7 is configured to use features engineering and unsupervised clustering; automatic topic tagging for a set of documents/cases; and creation of new tags for topics documents if the reported problems are not in the knowledge database), including:
ingesting customer support tickets associated with a helpdesk (Nefedov – see par 19 - For example, sets of known solutions (Known Solution Records—KSR) and sets of historical data records (Historical Data Records—HDR) combined provide a Product Knowledge Database collection of records. Customer complaints may result in service tickets and are referred to herein as “cases” and include, for example, a description of a problem, …product information, and resolution or suggested or recommended solutions to the reported problem. Each case may result in a record and ultimately an HDR. See par 66 - For instance, when users 12 call or chat or otherwise access PCSS 3 for interaction with an agent 32, the agent receives information, formulates questions to ask users 12 to gain more information and initiate a service ticket or case number which ultimately becomes a record stored in the PKD 2, e.g., becomes an Historical Data Record);
filtering the customer support tickets to filter at least one of noisy and irrelevant tickets (Nefedov – See par 64 - the Discovery Engine 6 uses text analytics methods (text cleaning, stemming, feature extraction, features cleaning, TF-IDF, and/or others) to build Feature Matrix T with dimensions Case_Id x Feature_Vector. In addition, a Clean Feature Matrix using standard methods such as SVD, or heuristic methods on dimensionality reduction for a large corpus of documents. The discovery engine 6 may be used to build a sparse similarity matrix M between cases, e.g., based on cosine similarity, M=T*T′. Also, the Discovery Engine 106 may apply dimensionality reduction to similarity matrix M to clean cases with low similarity; See par 77 - Process 402 may be used to generate a list of keyword IDs (identifiers) with email, TF (Term Frequency) stemming, cleaning noisy features and clean/remove low-weight features. Next, a similarity normalization and similarity threshold process 404 may be used to remove low-weight similarity links, thus avoiding less relevant objects/keywords in the cluster);
for the filtered customer support tickets, converting unstructured ticket data to structured data to form tickets with structured data (Nefedov – see par 11 - often documents and files are generated in simple form as unstructured documents. Tagging of data (disclosing “structured data”) is used to enhance files (unstructured files or to further enhance structured files) and data structures may be created to link data and documents containing data with resources to provide enhanced services. See par 48 - The PCSS may use natural language processing techniques, for example term frequency (tf), inverse term frequency (idf), tf-idf, part-of-speech tagging and others to identify, extract and/or tag data received via user input or by other content delivery functions. See par 71, 73 - In the case of a customer support system to support a manufacturer's products sold to consumers, the article 104 may be related to a product 110, for example a refrigerator product, and may have a title including tagged or structured information classified based on the product or nature of the article. Summary 108 provides information about the product 110 and may include tagged or structured data. Answer 112 is related to product 110 and may also include tagged or structured data.);
clustering the customer support tickets with structured data (Nefedov – see par 48 - The PCSS may also use its processes on a large corpus of documents to build a taxonomy and/or classification. In addition, the PCSS may employ matrixes or tables or other structures in identifying and scoring similarities and in clustering data and documents in the cluster engine. Ultimately the PCSS may arrive at a set of clusters as a master customer service system to use in processing user inputs and generating sets of recommendations);
utilizing the clusters to label the customer support tickets to form a weakly supervised training data (Nefedov See par 52 - in the event there is an existing knowledge database having data related to a set of products, the present invention may use features and similarities based on tagged information or semi-supervised processes to generate a set of documents for use in a customer support for a new product. The PCSS/PKD can then automatically update the clustered problems/solution/feature with information related to service/support inquiries and resolutions related to the new product thereby enriching the set of problems and recommendations for use with all products associated with the clustered problems/solution set. In addition, over time as problems/solutions become less relevant to the cluster the PCSS/PKD may automatically disassociate documents to refine and update the cluster and improve the efficiency of the customer support resource (last 2 sentences here disclose “training” data). See par 57 - The CTE 7 may also be configured to provide cross-content learning and soft clustering as well as semi-supervised learning to use already classified cases from an existing product knowledge database. See par 108, FIG. 1 - In the context of Training, PKD 2/PCSS 3 are configured to make features (keywords) mapping between cases Description and its Diagnosis, make mapping between Description clusters and Diagnosis clusters, and build relevant transition matrices between Description and Diagnosis features); and
training a …, on the weakly supervised training data, to classify customer support tickets into topics of a granular taxonomy (Nefedov - See par 58 - Algorithm-based processes are used in the PCSS 3/PKD 2. Using a customization block 15, the PCSS 3/PKD 2 is configured by database and configuration settings, semi-supervised learning, and auxiliary data, which includes knowledge base, specific customer/product requirements, customer/product taxonomy/ontology/rules. See par 60 - the system may be configured to combine clustering/taxonomy extraction results with: knowledge database; specific customer/product requirements; and customer/product taxonomy/ontology/rules, including by using semi-supervised learning (e.g., a modified LDAt); see FIGS. 14-17, par 98 - FIG. 17 illustrates use of the PCSS 3 in a second stage to generate Automatically Built Taxonomy: Stage 2 (cf. sub-clustering 602) representing three clusters: Diagnosis Cluster_ID=2 1701, Cluster_ID=1 1702, and Cluster_ID=4 1703. In this example we focus on Cluster_ID=1 1602 derived at the Stage 1 shown at FIG. 16. At this stage the sub-clustering for 1602 split the lower level features 1602 (1616, 1618, 1620, 1622) and resulted in three sub-clusters Cluster_ID=1:0 1712, Cluster_ID=1:1 1714 and Cluster_ID=1:2 1719. In particular, Cluster_ID=1:0 1712 comprises a taxonomy branch DIAGNOSIS 1704/Connectivity 1708/Networking 1710/Platform 1722).
Nefedov discloses using tagging for refining and updating clustering (See par 52) and then using clusters to build taxonomies (See FIGS. 14-17) and that inventive concepts may be implemented semi-automatically. Nefedov also discloses using “Training” to make mappings between description clusters (See par 108).
Attwater discloses explicitly “training a classifier” (Attwater – See par 59 - The conversation classifier server 101B is connected to a network 103 and configured such that is it capable of storing and running one or more of the following: a conversation processor 104, a conversation classifier 105, a topic classifier 106).
Nefedov discloses:
for an incoming longform email of a customer (Nefedov – see par 66 - customer support system receiving communications from customers, such as by chat; see par 69 – customer 12 imitates an email communicating a problem or request for assistance)
Nefedov discloses extracting features from content or documents using “content feature extraction module 4” (See par 70, FIG. 1, fig. 3) where cases may have description, question, product, diagnosis (See par 73), and having questions relate to inputs received from customers having purchased the associated products (See par 73). Nefedov does not explicitly disclose generating a “summary”
Attwater discloses the entire limitation:
for an incoming longform email of a customer “utilizing an abstractive summarizer to generate a summary of the email” (Attwater –see par 152- conversational data into AI-based Conversation Analysis from email conversations; see par 154 - The present invention discloses a system that creates a conversation summary automatically using components of Artificial Intelligence and machine learning. These conversation summaries are produced in human readable form or in an encoded digital form; see par 156, FIG. 27-28 - Summary Features 2802 may comprise fragments of sentences or whole sentences, in natural language text, which may include additional structured data such as named entity markup or semantic markup such as Abstract Meaning Representation (“AMR”)).
Nefedov and Attwater disclose:
determining an intent of the email using the classifier to determine a topic from the summary of the email (Nefedov – see par 77, 82 - FIG. 4 is a schematic diagram illustrating an exemplary data processing flow or sequence of operation associated with one or more of the Discovery Engine 6, the Cluster Tagging Engine 7 and the Search Navigation Engine 8 associated with the PCSS 3 and PKD 2. In one embodiment and manner of operation, the Discovery Engine 6 includes a discovery mode for exploration of topics in a set of documents
Attwater – discloses entire limitation including classifier – See par 149 - These intent models are statistical classifiers trained with the identified set of goals/intents and that can be applied to full datasets (including future data from the same type of conversation corpus) and automatically identify the best labels for the conversations. see par 159 – Conversation features include… Topics; see par 160 - One or more representative sentences that are closest to the centroid of the relevant cluster(s) can then be automatically summarized using one of the known techniques for summarizing text in a manner similar to the generation of the short labels for each cluster, for example using models such as the example process 2900 shown in FIG. 29);
selecting a workflow for the email based on the topic (Nefedov – see par 57-58 - The PCSS 3/PKD 2 may also be configured to recommend a possible solution based on cases resolved before Recommendation Engine 9 soft-clustering; Using a customization block 15, the PCSS 3/PKD 2 is configured by database and configuration settings, semi-supervised learning, and auxiliary data, which includes knowledge base, specific customer/product requirements, customer/product taxonomy/ontology/rules. Cross-content analysis may be used including multiple network layers (e.g., Description, Symptoms, Diagnosis), auxiliary content (e.g., customer specific data, requirements), and cross-layer learning (e.g., based on multiple layers and aux content above). see par 67 - FIG. 2 shows a typical PCSS agent workflow; and 3) User/customer in both an agent-assisted manner and in an automated self-service manner with a limited query to the PCSS 3/PKD 2 to find a solution to a problem encountered with a product or service.
See also Attwater – see par 97 - Referring now to FIG. 16A, at least one possible arrangement 1600 of systems and components… in which a cognition engine 1602 utilizes one or more computer-performed processes … to one or more virtual assistant frameworks and agent desktop providers 1601, such as, but not limited to, Salesforce Einstein™, IBM Watson™, Google Dialog Flow™, Kore.ai, Salesforce Service Cloud™, Amazon Connect™ and Genesys™, via RESTful API calls and responses including a projected next-best intent and one or more entities. The training pattern for output to an AI-based automated conversation agent may include, but are not limited to, some or all of sample prompts, entities, flows, intents, … topics, phases, sentiment, clarifying questions or statements, conversation summaries, … next best action, agent activities, business processes, and events);
handing off the workflow to an interactive chat widget to interact with the customer to complete the workflow (Nefedov - see par 70 - The set of results may include a set of Known Solution Records and/or a set of Historical Data Records. Similarity scoring and other threshold parameters may result in a reduced set of records to present to the agent (or to the user in the case of an automated system or an AI (Artificial Intelligence) agent for use in resolving the problem. In this example, a responsive cluster formed comprising KSR #1 (article 104), HDR #1 (case number 114) and HDR #2 (case number 124); see par 71 – Answer 112 is related to product 110 and may also include tagged or structured data. In this manner the article 104 may be used in a knowledge database to efficiently connect other data records or inputs, for example a request from a product manager or a customer. The answer 112 may include a response or recommendation associated with product 110. For example, a part to be replaced or technical information related to repair or to address faulty operation of the associated product 110.
Attwater – see par 61 - the improved data processing system creates 205 a weighted conversation model 600 as further illustrated by FIG. 6 which can be used by a plurality of computer interlocutor systems to improve input and output performance in a number of ways, including but not limited to: [0062] a. allowing for predictive responses by automated systems in order to handle transactions faster, … and allowing more transactions to by handled by the same amount of hardware; [0063] b. supporting optimized product design and upgrades by identifying and automating the most likely conversation behaviors to target in resource reduction; see par 98 – AI-based chatbot… uses dominant path modeler of FIG. 4, 6; Specific available chatbot platforms each require particular machine-learning seed value input data structures, which can be readily generated by a chatbot exporter as shown in FIG. 15; see par 99 - text-based conversation records accumulated during subsequent user interactions with the chatbot, such as changes in dominant paths among previously-known intents, topics and outcomes, as well as additions of new intents, topics and outcomes, the machine-learning models and their operating coefficients may be periodically or continuously updated into the production pipeline 1500, performing the forgoing processes on the augmented or supplemented corpus of conversation data, and exporting new (or revised) machine-learning coefficients to one or more AI-based chatbot platforms 1503.).
Both Nefedov and Attwater are analogous art as they are directed to handling customer problems (see Nefedov Abstract, par 19; Attwater Abstract). Nefedov discloses using tagging for refining and updating clustering (See par 52) and then using clusters to build taxonomies (See FIGS. 14-17) and that inventive concepts may be implemented semi-automatically. Nefedov also discloses using “Training” to make mappings between description clusters (See par 108). Nefedov discloses extracting features from content or documents using “content feature extraction module 4” from email (See par 69-70, FIG. 1, fig. 3) where cases may have description, question, product, diagnosis (See par 73), and having questions relate to inputs received from customers having purchased the associated products (See par 73). Attwater improves upon Nefedov by explicitly disclosing a) having a “classifier” that is trained, b) using “text summarization” by an automated agent. One of ordinary skill in the art would be motivated to further include explicitly having training classifiers on frequently asked question topics and summarizing questions from customer emails to efficiently improve upon the clustering, taxonomy, and “training” disclosures in Nefedov.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the clustering of documents for customer support using semi-supervised processes (par 18) in Nefedov to further train classifiers on topics in conversations and summarize question content from customer as disclosed in Attwater, since the claimed invention is merely a combination of old elements, and in combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable and there is a reasonable expectation of success.
Concerning independent claim 10, Nefedov and Attwater disclose:
A computer-implemented method of augmenting customer support (Nefedov – see par 57 - The present invention provides a system for discovering new trends and clustering cases in Customer Support Systems, PCSS 3, and includes automatic tagging for clusters and a Recommendation Engine to find relevant resolutions. In this example the CTE 7 is configured to use features engineering and unsupervised clustering; automatic topic tagging for a set of documents/cases; and creation of new tags for topics documents if the reported problems are not in the knowledge database; see par 44 - The PCSS includes a central server and is computer-based and includes processors, memory components that store executable code sets for processing by the processors, and a database or mechanisms to access one or more databases, including the PKD. See par 55 – processors/computers), comprising:
discovering a granular taxonomy of the customer support ticket, wherein the granular taxonomy is generated from a set of previous customer support tickets (Nefedov – see par 57 - The present invention provides a system for discovering new trends and clustering cases in Customer Support Systems, PCSS 3, and includes automatic tagging for clusters and a Recommendation Engine to find relevant resolutions. In this example the CTE 7 is configured to use features engineering and unsupervised clustering; automatic topic tagging for a set of documents/cases; and creation of new tags for topics documents if the reported problems are not in the knowledge database;
See also Attwater – See par 85 - create a digital representation or model of customer behavior paths over time; see par 147 - label discovering process can be performed on multi-party conversations as well as agent-client interactions and conversations. ) including:
1) ingesting customer support tickets associated with a helpdesk (Nefedov – see par 19 - For example, sets of known solutions (Known Solution Records—KSR) and sets of historical data records (Historical Data Records—HDR) combined provide a Product Knowledge Database collection of records. Customer complaints may result in service tickets and are referred to herein as “cases” and include, for example, a description of a problem, …product information, and resolution or suggested or recommended solutions to the reported problem. Each case may result in a record and ultimately an HDR. See par 66 - For instance, when users 12 call or chat or otherwise access PCSS 3 for interaction with an agent 32, the agent receives information, formulates questions to ask users 12 to gain more information and initiate a service ticket or case number which ultimately