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 .
Status of the Claims
Claims 1-3, 5-7, 11-13, 15-17 have been amended. Claims 4, 8-10, 14, 18-19 have been canceled. Claims 1-3, 5-7, 11-13, 15-17 are pending.
Claim Rejections - 35 USC § 112
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.
Claims 1-3, 5-7, 11-13, 15-17 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 1 and 11 – the specification failed to provide a support for the following limitations –
▪ “chatbot infrastructure”.
Although the term infostructure can be interpreted as - support, foundation, basis, in a computing environment - an infrastructure often refers to physical hardware, software, networking components or physical facilities. Thus, it is not clear to what specifically the chatbot infrastructure is intended to be.
▪ “service providers of instant messaging systems”.
The specification teaches “channel provider” (see [0028] “user may enter any statement into the chat window (described as a channel provider)”), “chat provider” [0037], “agent application of any other third-party element” [0031]. However, there is no disclosure of the claimed “service providers.”
▪ “data parsing mechanism arranged on a server.”
There is no server disclosed in the specification. It is not clear of where the parsing is performed.
▪ “API fallbacks.”
Although, the specification discloses “fallback interaction”, “fallback action” and “call back their API” [0028]. There is no disclosure of the “API fallbacks.” In computing API fallbacks are a resilience design pattern where a system provides a backup or alternative solution when a primary API or service fails or becomes unavailable. Calling back an API is not analogous to the claimed “API fallbacks.”
Further - In view of the specification “a second user” is the end user and the first user is a developer. Thus, it is not clear whether there is a support for the limitation “communication between at least a first user and a second user” (i.e. end user and the developer). Although the specification discloses communication between the end user and an agent (human), there is no support for an end user communicating the first user, who is configuring a scenario sequence.
However, the independent claims require – “send messages by the first user”(1), “messages from the second user”(2) and “all messages sent to and by the chatbot”(3) – such embodiment where there are message exchange between three parties is not disclosed by the specification. The specification only show message exchange between a user and a chatbot.
No details explaining how one of ordinary skill in the art would implement such a limitations were provided in the specification and would not enable such that one of ordinary skill in the art to make/use the alleged inventive subject matter. It seems the applicant is making assumptions in view of the specification. However, such assumptions is not an original disclosure.
The dependent claims further carry the same deficiency and likewise rejected.
◊ With respect to claims 2 and 12 – the specification failed to provide a support for the following limitations –
▪ “removing elements, upon selection by the first user”. Although the specification discloses “if then logic”, there is no disclosure to removing any elements based on some unspecified selection.
▪ “enable a plurality of alternative paths within a scenario based on conditional triggers”
▪ “wherein the scenario builder comprises a user interface and a processing system connected to a networked database”.
◊ With respect to claims 5, 15 – no support for “images, voice messages”.
Once again, the applicant is interpreting the specification, which is not a proper disclosure. No details explaining how one of ordinary skill in the art would implement such a limitations were provided in the specification and would not enable such that one of ordinary skill in the art to make/use the alleged inventive subject matter. It is noted, that making assumptions in view of the specification does not provide a proper disclose.
Thus, the claims 1-3, 5-7, 11-13, 15-17 are rejected for failing to comply with the written description requirement.
Claim Construction
The independent claims recite “API fallbacks.” The specification failed to provide a support for such limitation as indicated in the 112 rejection to the claims above.
The API fallbacks – are mechanisms used to maintain application continuity when a primary service or endpoint fails. Depending on the architectural context, they go by several other names –
(1) Failover: The process of automatically routing requests to a backup API or server when the primary target goes down or times out. (2) Fallback Pattern: The architectural design pattern used to provide an alternative solution (such as cached data or a default value) when an external service fails. (3) Contingency Route / Backup Endpoint: The literal alternative API URL or service used to fulfill the request. (4) Model Fallback: Specifically common in modern AI integrations, where an API automatically tries a backup language model if the primary one fails to respond. (5) Graceful Degradation: A broader design philosophy where the system drops to a reduced state of functionality rather than failing entirely.
However, none of the (1)-(5) such API fallbacks are supported by the specification, which instead teaches – [0024] “a fallback interaction, such as when a conversation scenario falls outside of a user's expected action, as may be with respect to speaking with an agent and providing certain information”; [0025] “a fallback or a routing to another scenario may be provided”; [0026] “a fallback interaction 305 essentially explaining that the response is inconsistent (303) and questioning the user's input and logically resetting the flow of the conversation” etc..
Thus, the “API fallbacks” are examined in view of the support of the specification, to be “a fallback interaction, which takes place when a bot is unable to classify a particular response or request” [0034]. However, the applicant is advised to clarify the claimed limitation in order to avoid undue arguments and interpretations.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 11-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazza et al. (US 20200059558) in view of Jonnalagadda et al. (US 20200143265) and in further view of Blandin et al (US 2017/0293681).
Regarding claim 1, Mazza teaches a communication system for real-time communication between at least a first user and a second user, the system including a chatbot operating in connection with an Internet browser (F1), the system comprising:
scenario builder arranged on a processor of a first user (F2) and configured to facilitate the building of the scenario ([0051] “automatically generate customized suggestions and templates for use by human systems administrators ( or chatbot designers) to use when configuring the chatbot”, [0073], [0079], [0120]);
a chatbot configured to send messages within an instant communication channel ([0003], [0056], [0065]) according to a scenario defined by the first user ([0129]), and to respond to messages received from the second user based on the scenario sequence ([0146]-[0147]);
storage configured to save scenarios, messages, and archived chat content associated with prior communications ([0143]-[0144], [0156], [0158]);
application programming interface ([0066]) configured to facilitate communication between the scenario builder, the chatbot, and at least one instant messaging communication channel ([0157]);
application programming interface configured to facilitate communication between chatbot infrastructure and communication channels ([0066]-[0065], [0075]);
a data parsing mechanism arranged on a server ([0073]-[0074]) and configured to:
parse a selected portion of the archived chat content stored in the data storage ([0090]-[0091]);
split the archived chat content into subcategories of questions and answers ([0088], [0128], [0156]);
extract words and tokens from the archived chat content and attach tags to the extracted words and tokens ([0082], [0084], [0091]);
generate sentence embeddings for the archived chat content using a sentence encoder ([0093], [0098] “similarity between word pairs measured using, for example, word2vec”, [0094])(see NOTE);
cluster the archived chat content into groups based on similarity ([0085]-[0086], [0099], [0101], [0105], [0109]-[0111]); and
provide, to the first user during building of the scenario, a suggestion for a chatbot response based on the clustered archived chat content ([0138], [0142], [0153]);
wherein, the scenario comprises a sequence of messages based upon conditions predefined by the first user ([0129]-[0131], [0142], [0150], [0152]);
wherein, the application programming interface further includes fallback interaction ([0067], [0142] “a fallback interaction, which takes place when a bot is unable to classify a particular response or request”), JavaScript Object Notation structure ([0164])
Mazza does not explicitly teach, however Jonnalagadda discloses webhooks discloses ([0087]).
NOTE With respect to the limitation “sentence embeddings,” Mazza teaches generating n-grams from sentences and generating “graph-based ranking algorithms represent sets of documents as a weighted undirected graph whose nodes correspond to words and whose edges represent co-occurrence relations within some distance. According to one embodiment of the present invention, the edges are weighted by the strength of the co-occurrence, measured using a dice coefficient formula (see, e.g., R. Wang, W. Liu and C. McDonald. Corpus-independent generic keyphrase extraction using word embedding vectors.” The incorporated reference of R. Wang, W. Liu and C. McDonald. Corpus-independent generic keyphrase extraction using word embedding vectors” fully teach “sentence embeddings.” Thus, it is reasonable to conclude that Mazza in view of the incorporated reference fully disclose the sentence embeddings as required.
However, to further obviate such reasoning, Jonnalagadda discloses – sentence embeddings ([0081], [0084], [0149]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Mazza to include webhooks and sentence embeddings as disclosed by Jonnalagadda. Doing so would provide a more organic sounding messages in order to reduce this natural frustration on behalf of the user (Jonnalagadda [0007]).
Further, if Mazza does not explicitly teach, however Jonnalagadda discloses scenario builder arranged on a processor of a first user ([0030], [0059]-[0060], F3A-C) and a data parsing mechanism ([0083], [0177]) arranged on a server ([0130], [0131], [0134], F7:720, 550) and send messages within an instant communication channel ([0064]-[0067]; [0086]-[0088]. [0096]; [0101]-[0102], [0105], [0108], [0112]; Figures 1, 3A-C).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Mazza to include scenario builder arranged on a processor of a first user, data parsing mechanism arranged on a server and instant messaging as disclosed by Blandin. Doing so would enable developers to efficiently develop bots that can be improved over time and therefore the providing of services to consumers of the bot platform (Blandin [0028]).
Claim 11 recites substantially the same limitations as claim 1, and is rejected for substantially the same reasons.
Regarding claims 2 and 12, Mazza as modified teaches the system and the method, wherein a scenario builder is configured to:
receive content entered by the first user in the scenario builder (Mazza [0137]-[0138], Blandin F2A-B, 3A-C);
enable conditional communication upon triggers selected by the first user (Mazza [0142], Blandin F2A-B, 3A-C, Jonnalagadda [0087]);
enable a plurality of alternative paths within a scenario based on conditional triggers (Mazza [0079], [0120]-[0122], [0147], [0153], Blandin [0031], F2A-B, 3A-C);
modify elements of the scenario, including removing elements, upon selection by the first user (Mazza [0105]-[0107], [0146], [0149]-[0150], Blandin [0102], F3C:357);
include messages to be sent by the chatbot based on the scenario defined by the first user (Mazza [0121], [0152], Blandin F2A-B, 3A-C);
configure the chatbot to respond to messages received from the second user within the instant communication channel (Mazza [0146], [0150], Blandin F2A-B, 3A-C);
wherein the scenario builder comprises a user interface and a processing system connected to a networked database (Mazza [0148], [0150], Blandin F2A-B, 3A-C, F5); and
wherein the chatbot scenario further comprises content elements comprising audio visual content, triggers, and programmed reactions (Mazza [0003], [0174], Blandin F2A-B, 3A-C, [0143]).
Regarding claims 3 and 13, Mazza as modified teaches the system and the method, wherein the chatbot infrastructure data storage is configured to:
save scenarios created by the first user in the scenario builder in the data storage (Mazza [0143]-[0144], [0156], [0158], Blandin [0098]; [0109], [0113]-[0118]; [0124]-[0127]; Figures 5-6, Jonnalagadda [0086]);
adjust scenarios created by the first user in the scenario builder based upon changes implemented by the first user (Mazza [0105]-[0107], [0146], [0149]-[0150], Blandin F2A-B, 3A-C);
operate in a networked environment (Mazza [0164], Blandin [0152]).
Claims 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazza as modified and in further view of SASTRE MARTINEZ et a. (US 20230274092).
Regarding claims 5 and 15, Mazza as modified teaches, the system and the method, wherein the data parsing mechanism is further configured to:
processing chat content comprising textual and non-textual data (Mazza [0003], [0044], [0058], [0061], Jonnalagadda [0054]);
cluster similar sentences into groups based on the similarity between chat contents; extract words and other tokens from chat content strings (Mazza [0085]-[0086], [0099], [0101], [0105], [0109]-[0111]); process a sequence of words and attach a tag to each element of the chat content (Mazza [0082], [0084], [0091]); classify the chat content into subcategories of questions and answers (Mazza [0089]-[0091]); and other tokens include links, images, voice messages or other unqualified chat content (Mazza [0003], [0044], [0058], [0061]).
Mazza as modified does not explicitly teach, however SASTRE MARTINEZ discloses embed sentences from the chat content to use the Sentence-Bidirectional Encoder Representations from Transformers ([0051]). SASTRE MARTINEZ further discloses cluster similar sentences into groups based on the similarity between chat contents ([0064]-[0065], [0086]); extract words and other tokens from chat content strings ([0076], [0082]); process a sequence of words and attach a tag to each element of the chat content ([0050], [0085]); classify the chat content into subcategories of questions and answers ([0077]); and wherein other tokens include links, images, voice messages or other unqualified chat content ([0077]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Mazza as modified to include SBERT Sentence transformer as disclosed by SASTRE MARTINEZ. Doing so would improve resource efficiency (SASTRE MARTINEZ [0003]).
Note in alternative art CHI et al. (US 20220400159) discloses the same [0022]-[0024], [0039], [0048] and [0082] and further obviates the teachings of Mazza as modified.
Claims 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazza as modified and in further view of Tapuhi et a. (US 20170118336) and BACHRACH et al. (US 20190155905).
Regarding claims 6 and 16, Mazza as modified teaches the system and the method, wherein the application programming interface is configured to scenario is configured to:
assign a sequence of the scenario based on a condition configured by the first user (Mazza [0146], Blandin [0097]-[0098], [0100], [0106]);
control execution of the scenario based on predefined conditions (Mazza [0146], Blandin [0111], [0119], [0122]);
cease the scenario sending upon direct request from the first user sent by the user interface (Blandin [0109]); and
wherein the user interface comprises frontend infrastructure configured to further process information to cease sending through the backend infrastructure (Blandin F2A-B, 3A-C).
However, if Mazza as modified does not explicitly teach, however Tapuhi discloses control execution of the scenario based on predefined conditions and cease the scenario sending upon direct request from the first user sent by the user interface ([0079]-[0080], [0085], [0089], [0096]). BACHRACH discloses the same in ([0048]-[0050], [0053]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Mazza as modified to control execution of the scenario based on predefined conditions as disclosed by Tapuhi and BACHRACH. Doing so would provide a rich dialogue tree that covers the different routes that a customer may potentially choose during the interaction (Tapuhi [0123]) and efficiently provide responses to a large number of user queries (BACHRACH [0005]).
Claims 7 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mazza as modified and in further view of Tapuhi et a. (US 20170118336), Lee et al. (US 20190102801), BACHRACH et al. (US 20190251165).
Regarding claims 7 and 17, Mazza as modified teaches the system and the method, wherein the conditions in the scenario builder are configured to:
trigger a scenario based on human language analysis (Mazza [0158], Blandin [0109], Jonnalagadda [0087]);
introduce multiple alternative paths in the scenario created in the scenario builder by the first user that is based upon the condition (Mazza [0136], [0146]);
Blandin as modified does not explicitly teach, however Tapuhi discloses introduce multiple alternative paths in the scenario created in the scenario builder by the first user that is based upon the condition ([0120]-[0121], [0130]) to accept values exact, similarly, or interpreted as a value in the scenario ([0152]).
Blandin as modified does not explicitly teach, however Lee discloses a Sorensen-dice coefficient ([0022]) and perform A/B testing on the content defined by the first user ([0073]).
Blandin as modified does not explicitly teach, however BACHRACH discloses trigger a scenario based on a Levenshtein distance ([0062]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Mazza as modified to include various conditions as disclosed by Tapuhi, BACHRACH and Lee. Doing so would provide a rich dialogue tree that covers the different routes that a customer may potentially choose during the interaction (Tapuhi [0123]) and improve accuracy and effectiveness (BACHRACH [0073]).
Response to Arguments
Applicant's arguments filed 05/25/2026 have been fully considered but they are not persuasive.
With respect to the rejection under 35 USC 112 1st paragraph, the applicant provides various paragraphs to support the disputed limitations. However, as noted in the updated 112 rejection above, the applicant interprets the specification, which does not constitutes a proper disclosure. The applicant is advised to more carefully align the claim language with the embodiments disclosed by the specification, without making undue assumptions in order to overcome the rejection.
As stated above - “chatbot infrastructure” can be interpreted as - support, foundation, basis, in a computing environment - an infrastructure often refers to physical hardware, software, networking components or physical facilities. Thus, it is not clear to what specifically the chatbot infrastructure is required and intended to be.
For the limitation - “data parsing mechanism arranged on a server.” There is no server disclosed in the specification. It is not clear of where the parsing is performed. The parsing can reasonably be performed by the processor of the first user. The applicant is referring to “server-based resources” in [0038]-[0039] without any factual evidences. Once again the applicant makes undue assumptions based on the specification, which is not an original disclosure.
For the limitation - “API fallbacks.” In computing API fallbacks are a resilience design pattern where a system provides a backup or alternative solution when a primary API or service fails or becomes unavailable. Calling back an API is not analogous to the claimed “API fallbacks.” Once again the applicant makes undue assumptions and arguments, instead of properly amending the claims to be in alignment with the specification.
Therefore, the rejection is maintained.
Applicant's remaining arguments, in regard to the presently amended claims, are addressed in the updated rejections to the claims above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 POLINA G PEACH whose telephone number is (571)270-7646. The examiner can normally be reached Monday-Friday, 9:30 - 5:30.
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, Aleksandr Kerzhner can be reached at 571-270-1760. 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.
/POLINA G PEACH/Primary Examiner, Art Unit 2165 June 22, 2026
Prosecution Insights