DETAILED ACTION
This communication is a Final Office Action on the merits in response to communications received on 05/28/2026. Claims 25 and 31 have been amended. Therefore, claims 25-36 are pending and have been addressed below. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The amendment filed 05/28/2026 is objected to under 35 U.S.C. 132(a) because it introduces new matter into the disclosure. 35 U.S.C. 132(a) states that no amendment shall introduce new matter into the disclosure of the invention. The added material which is not supported by the original disclosure is as follows:
[¶ 0061] The speech analytics pipeline 510 may include an audio pre- processor 511, a speaker diarization model 512, and a speech to text model 513. Audio recordings 505 are input to the speech analytics pipeline 510, and results of the speech analytics performed using components 511, 512, 513 are output to data collector/shipper 530. In some example embodiments, the output speech analytics results may be stored in a database 515 (e.g., a MONGO DB) and made available to data collector/shipper 530 for retrieval. A MongoDB is a NoSQL database configured to store data in a Binary JSON format that uses collections and documents. The speech analytics pipeline 510 may be implemented using DASK, for example, or other known or future developed equivalents.
Applicant’s filed remarks on 05/28/2026 pg. 1 indicate the paragraph above has been added or amended to the original specification. Applicant is required to cancel all of the new matter in the reply to this Office Action.
Claim Rejections - 35 USC § 112
2. The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
3. Claims 25-36 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
With respect to claims 25 and 31:
The applicant’s disclosure fails to comply with the written description requirement, which demands that an applicant’s specification “describes the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the invention had possession of the claimed invention.” In cases involving computer-implemented functional claims, examiners are instructed to “determine whether the specification discloses the computer and the algorithm (e.g., the necessary steps and/or flowcharts) that perform the claimed functions in sufficient detail….”
The MPEP explains that “the level of detail required to satisfy the written description requirement varies depending on the nature and scope of the claims and on the complexity and predictability of the relevant technology.”
The Specification in [¶ 0027, 0061-0063] recites:
[0027] In one example, a “Lite” edition (partial functionality) may operate to generate interaction insights (110) using, for example, the following information and techniques: a) sentiment analytics, b) generic AI/ML models on agent behaviors, c) contact metadata (e.g., silence time, agent time, customer time), d) transcription, and e) robust search. Sentiment analytics includes analysis of conversation(s) between a customer and an agent using deep learning and machine learning that are built to understand the overall sentiment of the customer at the end of the conversation. Generic AI/ML models on agent behaviors are deep learning algorithms built based on experience over an extended period of time, e.g., months or years, to analyze the conversations and show insights on the behaviors displayed by the agent (e.g., effective probing, actively listening to customer, showing empathy, setting expectations, etc.). The transcriptions can be stored, for example, in database(s) and come from voice recordings, chat conversations, email conversations, social media conversations, etc. For voice recordings, transcriptions may be generated using an infrastructure built on deep learning and Graphics Processing Unit (GPU) technologies versus conventional processors as they are faster at processing, due to the processing need of online games, for example. For the other text-based communication channels, the unstructured data is cleansed and persisted for further processing. Searches may be performed on the conversations transcriptions, and on metadata for the conversations, using natural language processing (NLP) based techniques that help to filter the data quickly and easily. A typical timeline to enable the “Lite” edition deployment (e.g., 4-6 weeks) includes data acquisition and data integration, inference on one month historical data and categories configuration, and onboarding and training before going live.
[0061] The speech analytics pipeline 510 may include an audio pre-processor 511, a speaker diarization model 512, and a speech to text model 513. Audio recordings 505 are input to the speech analytics pipeline 510, and results of the speech analytics performed using components 511, 512, 513 are output to data collector/shipper 530. In some example embodiments, the output speech analytics results may be stored in a database 515 (e.g., a MONGO DB) and made available to data collector/shipper 530 for retrieval. The speech analytics pipeline 510 may be implemented using DASK, for example, or other known or future developed equivalents.
[0062] The email/chat conversation platform 520 may include various components including but not limited to Sales Force 521, Azure 522, Secure File Transfer Protocol (SFTP) 523, and Chat Dump 524. The email/chat conversation platform 520 can also provide various interaction data to the data collector/shipper 530 from one or more of these components 521, 522, 523, 524.
[0063] The data collector/shipper 530 may include various components associated with the processed audio recordings from the speech analytics pipeline 510 and the email/chat conversations from email/chat conversation platform 520, including but not limited to a sales data shipper 531, a database (e.g., Mongo DB) data shipper 532, an SFTP data shipper 533, a database management system (DBMS) data shipper 534, and a data shipper 535 (e.g., a cloud computing service such as AZURE). The data collector/shipper facilitates the transfer of interaction data from the client to the system (e.g., data pipeline 550 and analytics and scoring engine 560) at regular intervals.
The claims now recite: “storing, by the computer, the interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents” The original specification filed 11/28/2022 does not disclose a NoSQL database or a Binary JSON format. In the instant case, the specification fails to describe the database and format being claimed in sufficient detail. The written description requirement mandates the specification adequately describes the features of the claimed invention and applicant’s approach to how the claimed steps are performed. Since the original specification fails to clearly outline the features or steps, the support for the amendments to the claim encompasses new matter and is being rejected as failing to comply with the written description requirement.
Claim Rejections - 35 USC § 101
4. 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.
5. Claims 25-36 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more.
Under Step 1 of the two-part analysis from Alice Corp, claim 25 recites a process (i.e., an act or step, or a series of acts or steps) and claim 31 recites a machine (i.e., a concrete thing, consisting of parts, or of certain devices and combination of devices). Thus, each of the claims fall within one of the four statutory categories.
6. Under Step 2A – Prong One of the two-part analysis from Alice Corp, the claimed invention recites an abstract idea.
Claim 25 which is representative of claim 31 recites:
“collecting…interaction data and metadata data from one or more of voice data, chat data, email data, and mobile data;”, “storing…the interaction data and metadata”, “generating…a transcript of the collected interaction data and metadata;”, “determining…a KPI of the transcript, wherein the KPI is associated with a customer experience outcome.”, and “wherein the metadata is collected from voice data, the metadata comprises one or more of silence time, customer time, and agent time.”
Under the broadest reasonable interpretation, the limitations recite a series a steps for determining key performance indicator(s) from a conversation between an agent and a customer which encompasses concepts that fall within the mental processes (i.e., observations, evaluations, judgements, and opinions) and certain methods of organizing human activities (i.e., marketing or sales activities/business relations) groupings of abstract ideas. See MPEP 2106.04
The Applicant’s Specification in at [0002]Customer support systems can drive differentiated consumer experience and growth in a variety of ways. As consumers make their experience a top reason to choose brands, a consumer-focused, digitally connected and brand consistent consumer care program elevates a given brand’s reputation in the eyes of the consumer, while managing operation efficiency and increasing relevance. By listening intently and learning from each consumer interaction, and delivering delightful experiences and effectively addressing issues, consumer care programs can drive brand loyalty, create vocal champions that can be digitally activated, and drive revenue growth.[0003] Currently, customer support systems rely on operations driven decision making using key performance indicators (KPIs) like average handling time (AHT), provide only market research and consumer feedback survey-based consumer insights, and require human based quality monitoring. One challenge in a customer support program is to proactively identify the resolution rates, customer sentiment, and customer satisfaction (CSAT) scores and/or net promoter scores (NPS) scores.
Consistent with the specification, the limitations recite mental processes for collecting and evaluating known information from interactions between an agent and a customer to derive key performance metric(s). The acts for evaluating the known information involve generating a transcript of the interactions and determining a key performance indicator(s) of the transcript which are limitations can be practically performed in the human mind, with or without the use of a physical aid such as pen and paper. Additionally, the limitations cover commercial interactions, i.e. marketing/sales activities or business relations because they generate and organize key performance indicator(s) of a transcript for agent or manager to track customer satisfaction and/or agent performance metrics. As such, the claim recites an abstract idea.
7. Under Step 2A – Prong Two of the two-part analysis from Alice Corp, this judicial exception is not integrated into a practical application because the additional elements of: “using a machine learning model (MLM)” “by a computer”, “training…the MLM”, “one or more of a data processing technique”, “a classification model”, “a trained MLM”, “by the computer”, “a NoSQL database configured to store data in a Binary JSON format that uses collections and documents”, “using the trained MLM”, “a system, “one or more computer processors”, “one or more computer-readable storage media, program instructions stored on the computer-readable storage media for execution by at least one of the one or more processors, the program instructions comprising:” – see claims 25 and 31 are all recited at a high-level of generality in light of the specification. In [Figs 1A-1B, ¶ 0025 - the invention is not limited to any specific hardware or software configuration, but may rather be implemented as computer executable instructions in any computing or processing environment, including, for example, in digital electronic circuitry or in computer hardware, firmware, device driver, or software. The various computing devices involved may include clients, servers, storage devices and databases, personal computers, mobile devices such as smartphones and tablets, or other similar electronic and/or computing devices.] Thus, because the specification describes the additional elements in general terms without describing the particulars, the additional elements may be broadly but reasonably construed as reciting generic computer components performing the judicial exception in light of the applicant’s specification. Therefore, the additional elements merely add the words “apply it” with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely use a computer processor as a tool to perform the abstract idea as discussed in MPEP 2106.05 (f).
The other additional elements of “a method…to determine key performance indicators (KPI) of an interaction between computing devices, comprising” is merely an attempt to limit the claimed invention to a particular field of use or technological environment, as discussed in MPEP 2106.05(h).
Thus, the additional claim elements are not indicative of integration into a practical application, because the claims do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea and the claims are directed to an abstract idea.
8. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above with respect to integration of the abstract idea into a practical application, the additional element(s) of: “using a machine learning model (MLM)” “by a computer”, “training…the MLM”, “one or more of a data processing technique”, “a classification model”, “a trained MLM”, “by the computer”, “a NoSQL database configured to store data in a Binary JSON format that uses collections and documents”, “using the trained MLM”, “a system, “one or more computer processors”, “one or more computer-readable storage media, program instructions stored on the computer-readable storage media for execution by at least one of the one or more processors, the program instructions comprising:” amounts to no more than mere instructions in which to apply the judicial exception which cannot provide an inventive concept at Step 2B.
9. Claims 26-30 and 32-36 are dependent of claims 25 and 31.
Claims 26 and 32 recite “generating the interaction training data using the data processing technique; wherein the data processing technique comprises one or more of: Term Frequency Inverse Document Frequency (TF-IDF); Word2Vec; Latent Dirichlet Allocation; and Nonnegative Matrix Factorization.” is/are data processing techniques recited at a high-level of generality and amount to nothing more than mere instructions to apply the judicial exception using a computer – see MPEP 2106.05(f), Claims 27 and 33 recite “further comprising: generating the interaction training data using the classification model; wherein the classification model comprises one or more of: Random Forest; Logistic Regression; Support Vector Machines (SVM);Extreme Gradient Boosting (XGBoost); and Neural Networks (NN).” is/are types of classification models recited at a high-level of generality and amount to nothing more than mere instructions to apply the judicial exception using a computer – see MPEP 2106.05(f), Claims 28 and 34 recite “wherein the KPI comprises one or more of: a Customer Dissatisfaction (DSAT) score; a Net Promoter Score (NPS); and a Customer Satisfaction (CSAT) score”, further describes the data or information recited in the abstract idea, but does not make the claim any less abstract. Claims 29 recite “wherein the steps of collecting the interaction data and metadata; storing the interaction data and metadata; generating the transcript; and determining the KPI; are conducted in real-time.” further narrow how the abstract idea may be performed, but does not make the claim any less abstract. The recitation of “real-time” is merely an attempt to limit the claim to a particular technological environment or field of use – see MPEP 2106.05(h) Claims 30 and 35 recite “the step of generating the transcript comprises generating the transcript using a deep learning model and a graphical processor unit.” further narrows how the abstract idea may be performed, but do not make the claim any less abstract. Here, the “deep learning model” and “graphical processor unit” are recited at a high-level of generality and merely being used in their ordinary capacity to organize/arrange information or data recited from the abstract idea – see MPEP 2106.05(f). Claim 36 recites “wherein the program instructions further comprise: program instructions to display the KPI on a graphical user interface (GUI).” which merely adds insignificant extra-solution activity, i.e., data transmission/output, to the judicial exception, but does not add any meaningful limitations to the claim – see MPEP 2106.05(g). Here, the “graphical user interface” is recited at a high-level of generality and merely being used in its ordinary capacity to present information or data from the abstract idea. Thus, the dependent claims when viewed individually and as an ordered combination do not integrate the judicial exception into a practical application or provide an inventive concept.
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
12. Claim(s) 25, 27-31, 33-36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zarecki in further view of KulKarni (US 2023/0252496 A1).
With respect to claims 25 and 31, Zarecki discloses
a method (Fig. 1: discloses contact center 102) of using a machine learning model (MLM) to determine key performance indicators (KPI) of an interaction between computing devices (col. 15:26-45), comprising:
training, by a computer, the MLM based on interaction training data and one or more of a data processing technique and a classification model to generate a trained MLM (col. 15:26-45: discloses the contact center system 102 can use supervised machine learning to train a machine learning model to predict customer effort metrics.);
collecting, by the computer, interaction data and metadata data from one or more of voice data, chat data, email data, and mobile data (col. 6:39-62: discloses the contact center system can generate and/or store dialogue data 118, telephony data 120, and/or application usage data associated with communication sessions.);
generating, by the computer, a transcript of the collected interaction data and metadata (col. 6:39-62, col. 19:1-12: discloses the contact center system 102 may use speech recognition systems to generate a text transcript.); and
determining, by the computer, a KPI of the transcript using the trained MLM, wherein the KPI is associated with a customer experience outcome (cols. 9-10:59-62, col. 12:45-61, col. 19:12-15: discloses the contact center system 102 can generate and store key performance indicators (KPIs). The contact center system 102 can be configured to derive one or more KPI’s based on one or more or the dialogue data 118, the telephony data 120, and other data available to the contact center system 102); and
The Zarecki reference does not explicitly disclose the following limitations.
In the same field of endeavor, the Kulkarni reference is related to the field of contact center operations (¶ 0002) and teaches:
storing, by the computer, the interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents (¶ 0030, 0032, 0063: discloses the event database may store event data. For example, in various embodiments one or more databases may comprise a relational database system using a structured query language (SQL), while others may comprise an alternative data storage technology 38 such as those referred to in the art as “NoSQL”. Call events may include, but are not limited to: call dropped (by enterprise), poor voice quality (observed live voice quality, real-time mean object score and audio generation device mean object score), no issues (e.g., successful calls), missed dual-tone multi-frequency signaling or first attempt at recognition (e.g., no match), failed transfer (e.g., interactive voice response [IVR] to agent, agent to agent, etc.), ring-out (e.g., call not answered), afterhours notice (e.g., calling after office hours, needs special way using choice tags), out of date or incorrect prompts (e.g., incorrect IVR prompt), long delay in getting responses (e.g., major timeout failure), incorrect data being readout (e.g., variable data tag, CURRENCY, NUMBER, ALPHANUM, special type of no match), failed authentication, technical difficulties message (e.g., IVR technical difficulty messaging), long wait time, not understanding customer (e.g., no match, three times failure in understanding), and dead air (e.g., silence, could happen during route to the agents as well [no audio heard])), wherein when the metadata is collected from voice data, the metadata comprises one or more of silence time, customer time, and agent time.(¶ 0032)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system and methods of Zarecki, to include storing, by the computer, the interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents, wherein when the metadata is collected from voice data, the metadata comprises one or more of silence time, customer time, and agent time, as disclosed by Kulkarni in order to achieve the claimed invention. As disclosed by Kulkarni, the motivation for the combination would have been to provide advantages for logging and storing event metadata from contact center operations. (¶ 0002, 0005, 0030)
With respect to claims 27 and 33, the combination of Zarecki and Kulkarni discloses the method and system, further comprising:
generating the interaction training data using the classification model (col. 15:26-45 - Zarecki); wherein the classification model comprises one or more of: Random Forest; Logistic Regression; Support Vector Machines (SVM) ;Extreme Gradient Boosting (XGBoost); and Neural Networks (NN). (col. 15:26-45: Zarecki discloses supervised machine learning can train the machine learning model. The supervised machine learning can be based on support vector networks, linear regression, logistic regression, neural networks, and/or other machine learning.)
With respect to claims 28 and 34, the combination of Zarecki and Kulkarni discloses the method and system,
wherein the KPI comprises one or more of: a Customer Satisfaction (CSAT) score (col.10:5-17: Zarecki discloses the KPIs 126 can be customer effort metrics that measure or estimate customer’s perceptions of customer effort associated with communication sessions with the contact center.):
With respect to claims 29, the combination of Zarecki and Kulkarni discloses the method of claim 25,
wherein the steps of collecting the interaction data and metadata (col. 6:45-62, Fig. 8);
storing the interaction data and metadata (col. 6:45-62, Fig. 8: discloses the contact center system 102 can store data about communication sessions that occur between customers and representatives.);
generating the transcript (col. 6:45-62, Fig. 8: discloses the contact center system 102 uses speech recognition systems to generate a text transcript substantially in real-time as a call is occurring between a customer and representative.); and
determining the KPI (cols. 9-10:59-62: discloses the contact center system 102 can automatically generate and store key performance indicators about communication sessions between customers and representatives.); are conducted in real-time (col. abstract, col. 6:45-62, Fig. 8).
With respect to claims 30 and 35, the combination of Zarecki and Kulkarni discloses the method of claim 25,
wherein the step of generating the transcript comprises generating the transcript using a model (col. 6:54-56: Zarecki discloses using speech recognition systems to generate text transcript from the audio recording) and a graphical processor unit. (col. 19:51-63: Zarecki discloses a graphics processor unit.)
However, the Examiner asserts that the data identifying the model as including deep learning is simply a label for the model and adds little, if anything, to the claimed acts or steps and thus does not serve to distinguish over the prior art. Any differences related merely to the meaning and information conveyed through labels (i.e., the specific type of information) which does not explicitly alter or impact the steps of the method does not patentably distinguish the claimed invention from the prior art in terms of patentability.
Therefore, it would have been obvious to a person of ordinary skill before the effective filing date of the claimed invention, to have the deep learning be included in the system of Zarecki because the name of the model does not functionally alter or relate to the steps of the method and merely labeling the information differently from that in the prior art does not patentably distinguish the claimed invention.
With respect to claim 36, the combination of Zarecki and KulKarni discloses he system of claim 31,
wherein the program instructions further comprise:
program instructions to display the KPI on a graphical user interface (GUI). (Fig. 8, col. 10:38-62: Zarecki discloses the contact center system 102 can also have a dashboard 128. The dashboard 128 can include a user interface that can display scorecards, trends, statistics, records, and/or other information about or derived from communication sessions. For example, the dashboard 128 can display data associated with KPIs 126.)
13. Claim(s) 26 and 32 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zarecki in view of KulKarni in further view of Currier (US 2021/0319457 A1).
With respect to claims 26 and 32, the combination of Zarecki and Kulkarni discloses the method and system, further comprising:
generating the interaction training data using the data processing technique (col. 15:26-45);
The Zarecki reference does not explicitly disclose the following limitations. In the same field of endeavor, the Currier reference is related to a data aggregation platform the utilizes models to aggregate data and to identify insights from the aggregated data (¶ 0011) and teaches:
wherein the data processing technique comprises one or more of:
Latent Dirichlet Allocation (¶ 0029, 0104: discloses the data aggregation platform may train a first model with the first structured historical customer data and the structured second historical customer data to generate a trained first model. The first model may include a machine learning model, such as a latent Dirichlet allocation (LDA) model. An LDA model is a type of topic model, such as a model that can be used to identify abstract topics that occur in a collection of documents, a generative statistical model that allows sets of observations to be explained by unobserved groups that explain why some parts of the data are similar, and/or the like. For example, if observations are words provided in documents, the LDA model may determine that each document is associated with a mixture of a quantity of topics and that the presence of each word is attributable to one topic, of the quantity of topics.)
Therefore, 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 combination of Zarecki and Kulkarni, to include wherein the data processing technique comprises Latent Dirichlet Allocation, as disclosed by Currier to achieve the claimed invention. As disclosed by Currier, the motivation for the combination would have been to provide benefits ranging from topic discovery to improved text analysis and information retrieval. (¶ 0029, 0104)
Response to Arguments
Applicant's arguments filed 05/28/2026 have been fully considered but they are not persuasive.
With Respect to Rejections Under 35 USC 112
Applicant argues “The Examiner has the initial burden of presenting, by a preponderance of evidence, why a person skilled in the art would not recognize in the Applicant's disclosure being sufficient to describe the invention defined by the claims. See Manual of Patent Examining Procedure (MPEP) § 2163. Rather than establish a prima facie case of unpatentability under Section 112(a), the Examiner merely states in a conclusory fashion that "the specification fails to describe the database and format being claimed in sufficient detail [t]he written description requirement mandates the specification adequately describes the features of the claimed invention and applicant's approach to how the claimed steps are performed [s]ince the original specification fails to clearly outline the features or steps, the support for the amendments to the claim encompasses new matter and is being rejected as failing to comply with the written description requirement." Office Action, pg. 4. The Examiner has not provided any evidence to support this conclusion, let alone a preponderance of evidence, purportedly demonstrating that a person of ordinary skill in the art would recognize that the inventor did not possess the claimed invention. Since the Examiner has not set out a prima facie case, Applicant respectfully requests withdrawal of the rejections of claims 25-36 under Section 112(a).” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The Examiner finds the response unpersuasive and maintains the independent claims of 25 and 31 fail to satisfy the written description requirement because the invention is claimed and described in functional language but the specification does not sufficiently identify how the invention achieves the claimed invention. The original specification only mentions a database, published [¶ 0061, 0063], and refers to “MONGO DB". In the instant case, the generic claim language from the original disclosure does not satisfy the written description requirement. Functional claim language that is not limited to a specific structure covers all devices that are capable of performing the recited function. Left unanswered, for example, is the type of database required and how the database would operate to store the information in a Binary JSON format that uses collections and document. As previously explained the courts have held the description of a single embodiment(s) may not satisfy the written description for broad or generic claims. For these reasons, the rejections under 112a - written description are being maintained.
Applicant further argues “The Examiner's general allegations that claims 25-36 fail to meet the written description requirement are clearly erroneous. Applicant therefore respectfully submits that there is no reasonable question that Applicant possessed the claimed invention as of the November 28, 2022, filing date of this application because a person of ordinary skill in the art would understand, at the time the patent application was filed, that the description requires that element. The element is inherently described in the Specification at least at paragraphs [0061] and [0063], which expressly describe "a database 515 (e.g., MONGO DB)" and "data (e.g., Mongo DB) data shipper 532," respectively. Specification, [0061] and [0063]. Here, a person skilled in the art would understand the following: (i) MongoDB is a document database designed to store data in flexible, JSON-like documents. Its flexible schema allows developers to evolve the data model without downtime, iterate quickly, and readily accommodate non-uniform data. MongoDB further provides a powerful query engine, horizontal scaling, and built-in high availability. In addition, it is a fully transactional operational database that supports a wide range of workload types, including data aggregation, vector search, geospatial search, and time series workloads. See What is MongoDB. www.mongodb.com/docs/manual/. Accessed May 27, 2026. (ii) A MongoDB stores data/documents in a serialized format referred to as BSON or binary JSON, which is a binary representation of JSON (JavaScript Object Notation) formatted data. See "BSON." MongoDB Glossary. www.mongodb.com/docs/manual/reference/glossary/. Accessed April 23, 2026. (iii) A collection is a grouping of MongoDB documents. See
"Collection." Id. Based on the foregoing, a person skilled in the art would recognize that a MongoDB is inherently a NoSQL database that stores data in a Binary JSON format that uses collections and documents. This disclosure demonstrates that a person of ordinary skill in the art would reasonably conclude that Applicant had possession of the claimed invention as of the November 28, 2022, filing date of this application. Accordingly, Applicant respectfully requests that the this rejection under section
112(a) be withdrawn.” The Examiner respectfully disagrees.
The Applicant’s arguments in regards to inherency are not persuasive. MPEP 2163.02 – states standard for determining compliance with the written Description requirement the subject matter of the claim need not be described literally (i.e., using the same terms or in haec verba) in order for the disclosure to satisfy the description requirement. If a claim is amended to include subject matter, limitations, or terminology not present in the application as filed, involving a departure from, addition to, or deletion from the disclosure of the application as filed, the examiner should conclude that the claimed subject matter is not described in that application. The Examiner finds the response unpersuasive and maintains the independent claims of 25 and 31 fail to satisfy the written description requirement because functional limitations that are not recited in the original Specification cannot be imported into the claim. For these reasons, the rejections under 112 are being maintained.
With Respect to Rejections Under 35 USC 101
Applicant argues “Contrary to the Examiner's rejection, claim 25, which is representative of claim 30, is patent eligible because the claim includes an element that cannot practically be performed in the human mind. As disclosed in MPEP § 2106.04(a)(2), subsection III(A), "[c]laims do not recite a mental process when they do not contain limitations that can practically be performed in the human mind, for instance when the human mind is not equipped to perform the claim limitations." MPEP § 2106.04(a)(2).”
“Claim 25 recites in part the limitation of storing, by the computer, the interaction
data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents. Under its broadest reasonable interpretation in light of the Specification, this element does not recite mental processes because it cannot be practically performed in the human mind. For example, a human cannot mentally generate JSON-formatted data and a binary representation thereof or manually create such using pen and paper. That is, the human mind is not equipped to store interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents (i.e., a MongoDB) with the inherent features discussed in Section I. Even more, the step cannot be performed by a human using pen and paper. See MPEP 2106.04(a)(2).” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The remarks do not make claim 25 any less abstract. Here, the remarks attempt to distinguish claim 25 from reciting an abstract idea by stating “human minds are unable to store interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents” It is important for Applicant to note the claims in Alice also required a computer that processed streams of bits, but nonetheless were found to be abstract. In the instant case, the “storing” step represents 1) collecting data, 2) recognizing certain data within the collected data set, and 3) storing that recognized data in a memory which is abstract. See Content Extraction, 776 F.3d at 1347. Also, the inability for the human mind to perform each claim step does not alone confer patentability. See Fairwarning For these reasons, the rejections under 101 are being maintained.
Applicant further argues “However, the Examiner posits that "merely adding features describing where the data is being stored and/or describing the type of formatting that may be used at best simply narrows how the abstract idea may be performed but does not make the claimed invention any less abstract [t]he additional elements of 'a NoSQL database' and 'a Binary JSON format' may add some specificity to the claim if supported by the disclosure, however, these limitations are recited in a conclusory manner in the original Specification, and therefore do not alter the previous analysis." Office Action, pg. 20. Applicant respectfully disagrees.”
“Here, the Specification has been amended to explicitly state that a "MongoDB is a NoSQL database configured to store data in a Binary JSON format that uses collections and documents," which, as discussed in Section II of this Response, are inherent features of a MongoDB that a person skilled in the art would recognize.” “Additional inherent features include, but are not limited to, horizontal scaling and data aggregation, vector searching, geospatial searching, and the ability to run multiple read and write operations as a single all-or-nothing event.”
“As such, a person of ordinary skill in the art would conclude that the use of a NoSQL database configured to store data in a Binary JSON format that uses collections and documents (i.e., a MongoDB) is not an attempt to merely describe where data is stored or the type of formatting that may be used, but rather represents specific technical choices that address particular technological challenges such as scalability, data structure flexibility, and processing efficiency. Such inherent features of a MongoDB represent concrete technological improvements rather than abstract narrowing. Based on the foregoing, Applicant respectfully submits that claim 25 does not recite an abstract idea.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The remarks are insufficient as they do not address any of the previous rejections under Step 2A-Prong One. In the instant case, the Applicant relies upon inherent features of a Mongo Database which are not described in the Specification. Thus, Applicant cannot rely on these inherent features to support eligibility. The courts have consistently held, however, that claims are not saved from abstraction merely because they recite components more specific than a generic computer. BSG Tech LLC v. BuySeasons, Inc., 899 F.3d 1281, 1286 (Fed. Cir. 2018) Thus the recited database in claim 25 merely provides a generic environment in which the claimed method is performed. As for the remarks regarding particular technological challenges and concrete technological improvements, these are benefits that flow from performing an abstract idea in conjunction. with a well-known database. The Specification does not provide any findings and the claims do not recite any improvement to the way in which the database stores or organizes information. For these reasons, the rejections under 101 are being maintained.
Applicant further argues “Given that claim 25 does not recite an abstract idea, additional analysis is not required. However, the Examiner further asserts that the judicial exception is not integrated into a practical application. See Office Action, pg. 6. Specifically, the Examiner asserts that the additional elements of "using a machine learning model (MLM)" "by a computer," "training the MLM," "one or more of a data processing technique," "a classification model," "a trained MLM," "by the computer," "a NoSQL database configured to store data in a Binary JSON format that uses collections and documents," and "using the trained MLM" are all recited at a high level of generality in light of the specification, which fail to integrate the judicial exception into a practical application. See Office Action, pgs. 6-7. Applicant respectfully disagrees. The Examiner further posits that in "Figs 1A-1B, " 0025 - the invention is not limited to any specific hardware or software configuration, but may rather be implemented as computer executable instructions in any computing or processing environment, including, for example, in digital electronic circuitry or in computer hardware, firmware, device driver, or software." Office Action, pg. 7. Applicant respectfully disagrees. First, this limited view of the invention is improper and does not provide the claims the broadest reasonable construction in light of the specification as it would be interpreted by one of ordinary skill in the art as required under MPEP § 2111.” The Examiner respectfully disagrees.
The Applicant arguments are not persuasive. The remarks reproduce statements in the previous rejection and allege the rejections under Step 2A- Prong Two of the were improper. In the instant case, the response does not comply with 37 CFR 1.111(b) because Applicant did not specifically point out any supposed errors from the previous rejection. The Examiner asserts the previous Non-Final OA rejection, pgs. 6-7 under Step 2A – Prong Two identified the limitations that are considered additional elements and explained why the additional elements do not integrate the judicial exception into a practical application. The Applicant’s Specification in [Figs 1A-1B, ¶ 0025, 0061, 0063] describes the Mongo database at a high-level of generality and does not provide any technological improvements with respect to the database’s functionality. The specification makes clear that off-the-shelf computer database technology is being used to aid in performing the abstract idea. Applicant does not purport to have invented the Mongo database or the database’s functionality. As discussed in MPEP 2106.05(b) - merely adding a generic computer, generic computer components, or a programmed computer to perform generic computer functions does not automatically overcome an eligibility rejection. Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 224, 110 USPQ2d 1976, 1984 (2014) For these reasons, the rejections under 101 are being maintained.
Applicant further argues “To be sure, a person of ordinary skill in the art would recognize that a NoSQL database configured to store data in a Binary JSON format that uses collections and documents (i.e., a MongoDB) is a specific software configuration that has specific technological advantages and features (see Section II) compared to those of a generic database configuration, which are not considered conventional computer functions. As such, the element of "storing the interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format" does more than merely: "[A]dd the words 'apply it' with the judicial exception." Office Action at pg. 7. Include "instructions to implement an abstract idea on a computer." Id. "[U]se a computer processor as a tool to perform the abstract idea." Id. Instead, the additional elements implement the purported abstract idea with a computer having a NoSQL database configured to store data in a Binary JSON format (i.e., a MongoDB) that is integral to claim 25.” The Examiner respectfully disagrees.
The Applicant arguments are not persuasive. The response alleges that the claim recites a specific software configuration without any description from the Specification of specific technological advantages and features. Although the Applicant has narrowed the remarks to focus upon the use of the database structure, the structure as evidenced from Applicant’s Spec.[ ¶ 0061,0063 – MongoDB] is well understood and conventional. As best understood in light of the specification, nothing the claim requires anything other than off-the-shelf, conventional computer database technology for storing and/or organizing the necessary information. This conventional database structure merely serves as a generic environment in which an abstract idea is carried out. As for the remarks with respect to storing the information in a binary format, these features describe the type of information or data recited in the abstract idea and do not lead towards eligibility. For these reasons, the rejections under 101 are being maintained.
Applicant further argues “A person of ordinary skill in the art would understand that the element goes beyond the routine and conventional functionalities of a generic computer having a generic database because compared to a generic database a NoSQL database configured to store data in a binary JSON format using collections and documents (i.e., a MongoDB) is a specialized database allowing for faster reads and writes for unstructured or changing data, and storage of nested data without needing multiple tables. As such, inclusion of the element results in an improvement of computer capabilities and is not directed to an abstract idea under MPEP § 2106.04(d)(1). In other words, assuming, arguendo, that claim 25 includes a judicial exception, which Applicant does not agree with, such judicial exception is integrated with storing interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format (i.e., a MongoDB) and therefore integrates the judicial exception into a practical application.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The response alleges the features of the recited database in claim 25 are unconventional and purports the claimed database provides speed and storage benefits. The Examiner maintains merely adding the recited database to claim which recites an abstract idea for determining key performance indicators from a conversation between an agent and a customer does not constitute an improvement in database functionality. Use of a computer or other machinery such as a database in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) Also, "claiming the improved speed or efficiency inherent with applying the abstract idea using a database" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1367, 115 USPQ2d 1636, 1639 (Fed. Cir. 2015). For these reasons, the rejections under 101 are being maintained.
Applicant further argues “On pages 8-9 of the Office Action, the Examiner argues that the claims "do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above with respect to integration of the abstract idea into a practical application [and] amount[] to no more than mere instructions in which to apply the judicial exception which cannot provide an inventive concept at Step 2B." Office Action, pgs. 8-9. Applicant respectfully disagrees and submits that claims 25 and 31 recite an inventive concept. Even if the Examiner concludes that claims 25 and 31 recite concepts that fall within the mental processes (i.e., observations, evaluations, judgments, and opinions) and certain methods of organizing activities (i.e., marketing or sales activities/business relations) that are not integrated into a practical application, the Examiner must still determine if the claims provide an inventive concept so they amount to significantly more than the purported abstract idea itself. This occurs, for example, where the claims include a specific claim element or combination of claim elements that are not well-understood, routine, or conventional (MPEP § 2106.05(d)).” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The response alleges the claims recite an inventive concept because the claims include a specific claim element or combination of claim elements that are not well-understood, routine, or conventional. These conclusory allegations that the prior art lacks the claim elements are insufficient. The previous Non-Final Office Action, pgs. 8-9, provided findings that of the generic computer components recited in the claims and how they are being used in their expected manner to implement the abstract idea and explained why adding the generic components to the clams fails to provide an inventive concept. For these reasons, the rejections under 101 are being maintained.
Applicant further argues “When considered both individually and as an ordered combination, the recited element of storing interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents demonstrates that claims 25 and 31 recite an inventive concept that amounts to significantly more than the purported abstract idea itself of mental processes (i.e., observations, evaluations, judgments, and opinions) and certain methods of organizing activities (i.e., marketing or sales activities/business relations).”
“Specifically, this element is not merely a generic data storage limitation, but rather reflects a particularized technical implementation that improves the way computers store, retrieve, and manage complex data. By leveraging a NoSQL architecture that supports BSON-formatted documents organized into collections, the claimed invention enables efficient handling of unstructured and dynamically evolving datasets. This configuration allows for faster read and write operations, reduces the need for costly schema migrations, and permits storage of hierarchically nested data structures without reliance on multiple relational tables or resource-intensive join operations.”
“These technical capabilities represent a concrete improvement to computer
functionality itself, as opposed to merely using a computer as a tool to perform an abstract idea. Notably, the claimed use of document-based storage and binary encoding departs from the routine and conventional operation of generic relational databases, which typically require predefined schemas and normalized table structures. The claimed approach therefore provides a specific technological solution tailored to the challenges of managing large-scale, heterogeneous interaction data, and cannot be fairly characterized as well-understood, routine, or conventional activity.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The Applicant’s remarks towards inventiveness rely upon speed and storage benefits inherent with applying the abstract idea using a computer database. See Customedia Techs., LLC v. Dish Network Corp., 951 F.3d 1359, 1364 (Fed. Cir. 2020) (Claiming the improved speed or efficiency inherent with applying the abstract idea on a computer is insufficient to render the claims patent eligible as an improvement to computer functionality." see also OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015) ("Relying on a computer to perform routine tasks more quickly or more accurately is insufficient to render a claim patent eligible."). Nor does Applicant provide anything inventive with respect to the ordered combination of elements recited in the claim. Thus, this concludes there is nothing inventive in the manner the claimed database stores or organizes information. The response attempts to propose an inventive concept by discussing technical capabilities, departing from the routine and conventional operation, and a specific technological solution which are all described at a high-level of generality. The Examiner maintains after consideration of the support from the Specification and limitations reflected in the claim whether viewing the claims individually or as an ordered combination the alleged claims do not add provide inventive concept.
Applicant further argues “In addition, the Examiner has offered no evidence that storing interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents, or any other element, is well-understood, routine, or conventional because the Examiner did not support the rejection with a citation to any of the following: An express statement in the specification or a statement Applicant made during prosecution demonstrating the well-understood, routine, and conventional nature of the additional elements. A court decision discussed in MPEP § 2106.05(d)(II) noting the well- understood, routine, or conventional nature of the additional elements. A publication demonstrating the well-understood, routine, or conventional nature of the additional elements. (MPEP § 2106.07(a)(III).)” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The response alleges that the previous rejection did not offer evidence that the “storing interaction data and metadata in a NoSQL database” is well-understood, routine, or conventional. The MPEP 2106.07(a)(III) states “at Step 2A Prong Two or Step 2B, there is no requirement for evidence to support a finding that the exception is not integrated into a practical application or that the additional elements do not amount to significantly more than the exception unless the examiner asserts that additional limitations are well-understood, routine, conventional activities in Step 2B.”
This section of the MPEP 2106.07(a)(III) also states “a specification demonstrates the well-understood, routine, conventional nature of additional elements when it describes the additional elements as well-understood or routine or conventional (or an equivalent term), as a commercially available product, or in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. 112(a). In Applicant’s Specification [¶ 0061, 0063] provides an example of the claimed database, i.e., MongoDB, which is described in the disclosure as an example of a commercially available product. In light of the disclosure, these citation(s) from [¶ 0061, 0063] represent an express statement from the Specification that demonstrate the well-understood, routine, conventional nature of the additional element(s). Thus, Applicant cannot rely upon lack of evidence or these features recited in the claims in this case to provide their inventive concept. For these reasons, the rejections under 101 are being maintained.
With Respect to Rejections Under 35 USC 103
Applicant argues “Specifically, the Kulkarni reference does not teach or suggest the element of "storing, by the computer, the interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents" as recited in claim 1 On the contrary, the Kulkarni reference explicitly discloses "HADOOP CASSANDRA TM, GOOGLE BIGTABLE TM" as examples of NoSQL databases. Kulkarni, [0063]. Although the Kulkarni reference describes the use of certain NoSQL databases, a person of ordinary skill in the art would understand that Cassandra and Bigtable are distributed wide-column databases and are not functionally similar to a MongoDB or capable of functioning as a document-oriented NoSQL database configured to store data in a binary JSON format using collections and documents. Moreover, a person of ordinary skill in the art would recognize that MongoDB employs a different data model, provides different query capabilities, and offers different scalability mechanisms as compared to the cited NoSQL databases of the Kulkarni reference.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The response alleges the databases described in the Kulkarni reference are not functionally similar to the database of the claimed invention. Turning to Applicant’s Specification [¶ 0061, 0063] have been reproduced below for context:
[0061] The speech analytics pipeline 510 may include an audio pre-processor 511, a speaker diarization model 512, and a speech to text model 513. Audio recordings 505 are input to the speech analytics pipeline 510, and results of the speech analytics performed using components 511, 512, 513 are output to data collector/shipper 530. In some example embodiments, the output speech analytics results may be stored in a database 515 (e.g., a MONGO DB) and made available to data collector/shipper 530 for retrieval. The speech analytics pipeline 510 may be implemented using DASK, for example, or other known or future developed equivalents.
[0063] The data collector/shipper 530 may include various components associated with the processed audio recordings from the speech analytics pipeline 510 and the email/chat conversations from email/chat conversation platform 520, including but not limited to a sales data shipper 531, a database (e.g., Mongo DB) data shipper 532, an SFTP data shipper 533, a database management system (DBMS) data shipper 534, and a data shipper 535 (e.g., a cloud computing service such as AZURE). The data collector/shipper facilitates the transfer of interaction data from the client to the system (e.g., data pipeline 550 and analytics and scoring engine 560) at regular intervals.
As can be seen under the broadest reasonable interpretation from the Specification, the response is relying upon database naming and functionalities that may be inherent but they are not fully supported in the disclosure to distinguish over the prior art. The Examiner asserts no where does the original Specification expressly describe a binary JSON format using collections and documents. Thus, Applicant cannot rely upon these features or functionalities to distinguish over the Kulkarni reference or overcome an obviousness rejection.. The Examiner contends the prior art reference in [¶ 0063] expressly states one or more different types of database structures such as “NoSQL” may be used. Thus, the database’s from the prior art meets the claim limitations because the use of these database structures and their storing functionalities were well-known in the state of the art and had been previously used in the industry. For these reasons, the rejections under 103 are being maintained.
Applicant further argues “As such, a person of ordinary skill would conclude that the Kulkarni reference does not teach or suggest the claimed element. On page 13 of the Office Action, the Examiner posits that Kulkarni's disclosure of "customer journey synthetic call events may include . . . dead air (e.g., silence, could happen during route to the agents as well [no audio heard])" teaches "wherein when the
metadata is collected from voice data, the metadata comprises one or more of silence time, customer time, and agent time." Office Action, pg. 13. Applicant respectfully disagrees.”
“The Specification discloses that metadata may relate to silence time, customer time, as well as agent time. See Specification, [0056]. Here, a person skilled in the art would conclude that silence time, customer time, and agent time relate to timing data captured during the actual interaction of the customer and the agent as opposed to events external to that interaction. On the contrary, the Kulkarni reference specifically discloses that the silence or dead air happens when the call is routed to the agent. Even more, the synthetic call events are derived from synthetic calls that are "conducted between a scripted 'customer bot' and a virtual assistant 111 a bot." Kulkarni,[0037]. In other words, a person of ordinary skill in the art would determine that the "dead air" or "silence" customer journey synthetic call events are scripted and therefore are predetermined as opposed to organic metadata collected from organic voice data as claimed.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The response points to Applicant’s Specification and alleges the KulKarni reference does teach the metadata as claimed. In the instant case, the limitation of “the metadata comprises one or more of silence time, customer time, and agent time.” is recited broadly in the claim and it may encompass any of these different data types. The Examiner contends the prior art teaches (¶ 0032: discloses event data may comprise a list of pre-determined events which may cause a voice system failure, and for each listed event an associated synthetic operational score. According to an embodiment, customer journey synthetic call events may include, but are not limited to: call dropped (by enterprise), poor voice quality (observed live voice quality, real-time mean object score and audio generation device mean object score), no issues (e.g., successful calls), missed dual-tone multi-frequency signaling or first attempt at recognition (e.g., no match), failed transfer (e.g., interactive voice response [IVR] to agent, agent to agent, etc.), ring-out (e.g., call not answered), afterhours notice (e.g., calling after office hours, needs special way using choice tags), out of date or incorrect prompts (e.g., incorrect IVR prompt), long delay in getting responses (e.g., major timeout failure), incorrect data being readout (e.g., variable data tag, CURRENCY, NUMBER, ALPHANUM, special type of no match), failed authentication, technical difficulties message (e.g., IVR technical difficulty messaging), long wait time, not understanding customer (e.g., no match, three times failure in understanding), and dead air (e.g., silence, could happen during route to the agents as well [no audio heard]).
As best understood from the prior art, the passage from the Kulkarni reference teaches or suggests event data which represents the metadata as claimed. The reference expressly states the event data may include long delay in getting response, long wait time which corresponds to one or more silence time, customer time, and/or agent time. Thus, the teachings from the Kulkarni reference meet the limitations as claimed. For these reasons, the rejections under 103 are being maintained.
Applicant further argues “Therefore, even assuming a person of ordinary skill in the art would have been motivated to combine the Zarecki reference and Kulkarni reference, as the Examiner suggests, which Applicant asserts is improper, the resulting combination would not include (i) storing, by the computer, the interaction data and metadata in a NoSQL database configured to store data in a Binary JSON format that uses collections and documents, or (ii) wherein when the metadata is collected from voice data, the metadata comprises one or more of silence time, customer time, and agent time as required under claim 25. Given that the Zarecki reference, taken alone or in combination with the Kulkarni reference, fails to teach or suggest every element as set forth in claim 25, Applicant submits that claim 25 is allowable and respectfully requests that the rejection be withdrawn.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. The MPEP 2144(IV) section indicates rational different from Applicant’s is permissible and states “The reason or motivation to modify the reference may often suggest what the inventor has done, but for a different purpose or to solve a different problem. It is not necessary that the prior art suggest the combination to achieve the same advantage or result discovered by applicant. See, e.g., In re Kahn, 441 F.3d 977, 987, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006) Thus, the guidance provides support for the motivation to combine the Zarecki and Kulkarni prior art references which was indeed proper. For these reasons, the rejections under 103 are being maintained.
Applicant further argues “As claims 27-30 depend from claim 25, claims 27-30 are also allowable for at least the reasons set forth with respect to claim 25. “Claim 25 is representative of claim 31. As such, claim 31 is allowable for at least the reasons set forth with respect to claim 25. As claims 33-36 depend from claim 31, claims 33-36 are also allowable for at least the reasons set forth with respect to claim 31.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. Claim 31 recites subject matter substantially similar to claim 25 and therefore, are being held rejected under the same grounds. Applicant's arguments with respect to dependent claims 26-30 and 32-36 fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. For these reasons, the rejections under 103 are being maintained.
Applicant further argues “Claims 26 and 32 stand rejected under 35 U.S.C. § 103 as being unpatentable over the Zarecki reference in view of the Kulkarni reference, and in further view of U.S. Patent Publication No. 2021/0319457 to Currier (the "Currier reference"). See Office Action, pg. 16. Applicant respectfully traverses the rejections for at least the reasons set forth below. The discussion of the Zarecki reference and the Kulkarni reference further applies here. However, the Currier reference does not address the above-referenced deficiencies of the Zarecki reference and the Kulkarni reference set forth above. As such, the Zarecki reference, taken alone or in combination with the Kulkarni reference and the Currier reference, fails to teach or suggest every element as set forth in claims 26 and 32. Accordingly, Applicant respectfully submits that claims 26 and 32 are allowable and requests withdrawal of the rejections.” The Examiner respectfully disagrees.
The Applicant’s arguments are not persuasive. Applicant's arguments with respect to the combination of Zarecki, Kulkarni, and Currier references fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. For these reasons, the rejections under 103 are being maintained.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to EHRIN PRATT whose telephone number is (571)270-3184. The examiner can normally be reached 8-5 EST Monday-Friday.
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, Lynda Jasmin can be reached at 571-272-6782. 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.
/EHRIN L PRATT/Examiner, Art Unit 3629
/LYNDA JASMIN/Supervisory Patent Examiner, Art Unit 3629
Prosecution Insights