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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.
Applicant's submission filed on 01/08/2026 has been entered.
Status of the Claims
Claim 1 have been amended. Claims 1-19 are pending.
Priority
This application is a CIP and claiming the benefit of prior-filed application No. 16/117084 file 08/30/2018 (now abandoned). With respect to claims 5, 10 and 15, the prior-filed application No. 16/117084 failed to provide a proper support. Therefore, the claims 5, 10 and 15 are given the filing date of the present application - 10/02/2022.
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-19 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 –
▪ enable a plurality of paths that constitutes a scenario. Although the specification discloses “proceed along a decision tree” it is not analogous to enabling a plurality of paths.
▪ remove elements of the scenario upon the first user selection. Although the specification discloses “if then logic”, there is no disclosure to removing any elements based on some unspecified selection.
e. adjusting the scenario based on the messages sent by the chatbot infrastructure and responses by the second user;
▪ wherein the scenario builder further comprises a front end and a backend infrastructure connected to a networked database.
Once again, the applicant is interpreting the specification, which is not a proper disclosure.
The rest of the dependent claims are similarly deficient, based on similar limitations and reasonings (For example – claims 3, 13 – no support for “webhooks”, claim 4, 14 – completely no support, claims 5, 15 – no support for “maximum chat content size”, “images, voice messages”, Claim 6 , 16 - no support for “reassign the scenario if” and “cease the scenario sending”, claims 7, 17 – no support for “introduce more than one fork in the scenario”, claims 8, 18 – not support for “support the uploading of audio-visual content; and enable the use of hyperlinks and direct redirects to other websites”, claims 9, 19 – not support for “audio-visual elements, hyperlinks according to the scenario”, Claim 10 – not support for “includes 10 independent communication items” etc.).
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-19 are rejected for failing to comply with the written description requirement.
Claim Objections
Claims 8, 18 are objected to because of the following informalities: Claims recite limitation "the uploading". There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
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-4, 8-9, 11, 13-14, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blandin et al (US 2017/0293681) in view of Shanmugam et al. (US 2019/0311036), and in further view of Smullen et al. (US 2017/0048170).
Regarding claim 1, Blandin teaches a communication system for real-time communication ([0032]-[0033]) between at least a first user and a second user ([0095]), the system including a chatbot operating in connection with an Internet browser ([0023] “messaging bot may be included as a temporary participant in any other thread, whether a one-on-one thread between two users or a group thread between multiple users”), the system comprising:
a scenario builder arranged on a processor of a first user and configured to facilitate the building of the scenario ([0030], [0059]-[0060], F3A-C);
a chatbot infrastructure configured to send messages by the first user as an element of the scenario and to respond to messages from the second user within an instant communication channel based on the scenario sequence configured by the first user ([0064]-[0067], [0086]-[0088], [0096], [0098], [0103], [0109], [0113]);
data storage configured to save scenarios, messages, and responses created by the first user and sent by the chatbot infrastructure ([0032]);
an application programming interface configured to facilitate communication between the scenario builder, chatbot infrastructure, and service providers of instant messaging systems ([0064]-[0067]; [0086]-[0088]. [0096]; [0101]-[0102], [0105], [0108], [0112]; Figures 1, 3A-C);
application programming interface configured to facilitate communication between chatbot infrastructure and communication channels ([0064]-[0067]; [0086]-[0088]. [0096]; [0101]-[0102], [0105], [0108], [0112]; Figures 1, 3A-C);
a data parsing mechanism ([0083], [0177]) arranged on a server ([0130], [0131], [0134], F7:720, 550), the data parsing mechanism configured to cluster data of a chat content ([0050] “message thread may collect together the messages shared between a particular group of users”, “identifier uniquely identifying the group thread”, [0061] “collects the actual conversations”, [0106] “processing the current state of the user-to-bot conversation using a sequence model to generate a collection of possible bot responses”, [0122] “conversations … are joined together”) and provide a suggestion for the chatbot response ([0084], [0107]);
wherein, the scenario comprises a sequence of messages based upon conditions predefined by the first user ([0059]-[0080]);
wherein, the application programming interface further includes application programming interface
wherein, the chat content includes all messages sent to and by the chatbot ([0066] “semantic analysis of a most-recent user message, for all user messages in a conversation”, [0071]).
Blandin does not explicitly teach, however Shanmugam discloses API fallbacks ([0035]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Blandin to include API fallbacks as disclosed by Shanmugam. Doing so would provide efficient allocation and hand-off of tasking between chatbots and live agents (Shanmugam [0006]).
Blandin does not explicitly teach, however Smullen discloses JSON structure, and webhooks discloses ([0150], [0180], [0311]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Blandin to include JSON structure, and webhooks as disclosed by Smullen. Doing so would provide a secure bidirectional communication with data sources to respond directly or broadcast messages to users (Smullen [0003]).
Regarding claim 11, Blandin teaches a method for real-time communication between at least a first user and a second user using a communication system including a chatbot operating in connection with an Internet browser, the method comprising the steps of: configuring the scenario builder on the processor of the first user; sending messages by the first user as an element of the scenario; responding to the second user messages within an instant communication channel based on a scenario sequence configured by the first user; storing data including scenarios, messages, and responses created by the first user and sent by the chatbot infrastructure in the networked database; facilitating communication between the scenario builder, chatbot infrastructure and service providers of instant messaging systems with a networked infrastructure; and parsing data arranged on server configured to cluster the data of a chat content to provide a suggestion for the chatbot response; wherein, the scenario created in the scenario builder by the first user comprises a sequence of messages based upon conditions predefined by the first user; and wherein, the chat content includes all messages sent to and by the chatbot.
Claim 11 recites substantially the same limitations as claim 1, and is rejected for substantially the same reasons.
Regarding claims 2 and 12, Blandin 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 (Blandin F2A-B, 3A-C);
enable conditional communication upon triggers selected by the first user (Blandin F2A-B, 3A-C);
enable a plurality of paths that constitutes a scenario (Blandin [0031], F2A-B, 3A-C);
remove elements of the scenario upon the first user selection (Blandin [0102], F3C:357, Smullen [0154])
adjusting the scenario based on the messages sent by the chatbot infrastructure and responses by the second user (Blandin F2A-B, 3A-C, Smullen [0150], [0156]);
include messages sent by the chatbot infrastructure (Blandin F2A-B, 3A-C);
respond to the messages sent by the second user of the invention (Blandin F2A-B, 3A-C);
wherein the scenario builder further comprises a front end and a backend infrastructure connected to a networked database (Blandin F2A-B, 3A-C, F5); and
wherein the chatbot scenario further comprises content elements comprising audio visual content, triggers, and programmed reactions (Blandin F2A-B, 3A-C, [0143], Smullen [0100]).
Regarding claims 3 and 13, Blandin 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 (Blandin [0098]; [0109], [0113]-[0118]; [0124]-[0127]; Figures 5-6);
adjust scenarios created by the first user in the scenario builder based upon changes implemented by the first user (Blandin F2A-B, 3A-C, Smullen [0150], [0156]);
operate in a networked environment (Blandin [0152]); and
issue and receive application programming interface calls and webhooks (Shanmugam [0035], Smullen [0150], [0180], [0311]).
Regarding claims 4 and 14, Blandin as modified teaches the system and the method, wherein the application programming is configured to:
issue application programming interface calls and webhooks that refer to an action performed by the chatbot while the chatbot proceeds with a chatbot scenario (Blandin F2A-B, 3A-C, Shanmugam [0035]);
receive application programming interface calls from external service providers (Blandin [0064]-[0067]; [0086]-[0088]. [0096]; [0101]-[0102], [0105], [0108], [0112]; Figures 1, 3A-C); and
trigger actions in the scenario built by the first user upon application program interface calls and webhooks sent by external service providers (Shanmugam [0035], Smullen [0150], [0180], [0311]).
Regarding claims 8 and 18, Blandin as modified teaches the system and the method, wherein the scenario builder is configured to:
on the first user processor and within the browser (Blandin [0040]-[0041]);
operate with the user input (Blandin F2A-B, 3A-C);
accept alphanumeric content (Blandin F2A-B, 3A-C);
support the uploading of audio-visual content (Blandin F2A-B, 3A-C, [0143], Smullen [0100]); and enable the use of hyperlinks and direct redirects to other websites (Blandin [0154], Smullen [0168], [0365]).
Regarding claims 9 and 19, Blandin as modified teaches the system and the method, wherein the chatbot infrastructure is configured to:
operate within the instant messaging channel (Blandin F2A-B, 3A-C);
send messages to initiate the communication with the second user (Blandin F2A-B, 3A-C);
respond to the messages sent by the second user (Blandin F2A-B, 3A-C);
send textual content, audio-visual elements, hyperlinks according to the scenario (Blandin F2A-B, 3A-C, [0143], Smullen [0100]); and
send messages and responses according to the scenario (Blandin F2A-B, 3A-C).
Claims 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blandin as modified and in further view of SASTRE MARTINEZ et a. (US 20230274092) and BACHRACH et al. (US 20190155905).
Regarding claims 5 and 15, Blandin as modified does not explicitly teach, however SASTRE MARTINEZ discloses the system and the method, wherein the data parsing mechanism is further configured to:
set up a minimum chat content size and a maximum chat content size ([0050], [0063], [0074]-[0075], [0085]);
embed sentences from the chat content to use the Sentence-Bidirectional Encoder Representations from Transformers ([0051]);
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]).
Further, BACHRACH discloses set up a minimum chat content size and a maximum chat content size ([0041]-[0042], [0046], [0049], [0052], [0070]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Blandin as modified to include SBERT Sentence transformer as disclosed by SASTRE MARTINEZ and BACHRACH. Doing so would improve resource efficiency (SASTRE MARTINEZ [0003]) and efficiently provide responses to a large number of user queries (BACHRACH [0005]).
Note in alternative art CHI et al. (US 20220400159) discloses the same [0022]-[0024], [0039], [0048] and [0082] and further obviates the teachings of Blandin as modified.
Claims 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blandin as modified and in further view of Tapuhi et a. (US 20170118336) and BACHRACH et al. (US 20190155905).
Regarding claims 6 and 16, Blandin 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 (Blandin [0097]-[0098], [0100], [0106]);
reassign the scenario if the response of the second user does not match the scenario configured by the first user (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 Blandin as modified does not explicitly teach, however Tapuhi discloses reassign the scenario if the response of the second user does not match the scenario configured by the first user 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 Blandin as modified to reassign the scenario 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 Blandin 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, Blandin 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 (Blandin [0109]);
to accept values exact, similarly, or interpreted as a value in the scenario; and
Blandin as modified does not explicitly teach, however Tapuhi discloses introduce more than one fork 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 Blandin 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]).
Claims 8-9 and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blandin as modified and in further view of Tapuhi et a. (US 20170118336).
Regarding claims 8 and 18, Blandin as modified teaches the system and the method as disclosed above, Tapuhi further discloses wherein the scenario builder is configured to:
support the uploading of audio-visual content ([0003], [0064], [0068], [0083]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Blandin as modified to include audio-visual content as disclosed by TapuhiDoing so would provide a rich dialogue tree that covers the different routes that a customer may potentially choose during the interaction (Tapuhi [0123]).
Regarding claims 9 and 19, Blandin as modified teaches the system and the method as disclosed above, Tapuhi further discloses, wherein the chatbot infrastructure is configured to:
send textual content, audio-visual elements, hyperlinks according to the scenario (Blandin F2A-B, 3A-C, [0143], Smullen [0100]).
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Blandin as modified to include audio-visual content as disclosed by TapuhiDoing so would provide a rich dialogue tree that covers the different routes that a customer may potentially choose during the interaction (Tapuhi [0123]).
Claims 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Blandin as modified and in further view of SASTRE MARTINEZ et a. (US 20230274092) and BACHRACH et al. (US 20190251165) or alternatively by KIM et al. (20120239650).
Regarding claim 10, Blandin as modified does not explicitly teach, however SASTRE MARTINEZ discloses the system according to claim 1, wherein a minimum chat content size includes 10 independent communication items ([0050], [0063], [0074]-[0075], [0085]) and wherein the system considers sentence pairs with a cosine similarity larger than 0.75 (BACHRACH [0062], [0079]).
Kim alternatively discloses claim 10 in [0039], [0045], [0047]-[0048], [0063].
It would have been obvious to one of ordinary skill in the art at the time of invention to modify the teachings of Blandin as modified various conditions as disclosed by SASTRE MARTINEZ, BACHRACH and KIM. Doing so would improve resource efficiency (SASTRE MARTINEZ [0003]) and efficiently provide responses to a large number of user queries (BACHRACH [0005]).
Response to Arguments
Applicant's arguments filed 01/08/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 - “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,” which often require a subscription or contract to facilitate instant messaging. The applicant is assuming such functionality.
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.
As for claims 2, the limitation “enable a plurality of paths that constitutes a scenario” allows for multiple interpretations. It is not clear of what the enabling actually requires and specifically multiple paths for a single scenario. Although the specification discloses “proceed along a decision tree” it is not analogous to enabling a plurality of multiple paths for a single scenario. Interpreting the specification is not an original disclosure. Analogously, there no removal of nodes disclosed in the spec. Such functionality is only an assumption and is not an original disclosure.
Once again, the applicant is advised to amend the claims based on actual functionality disclosed by the specification, without making undue assumptions and interpretations, in order to overcome the rejection.
◊ With respect to the rejection under 35 USC 103 and the Blandin reference, the arguments have been fully considered, but they are not deemed persuasive. The applicant argues the Blandin in combination does not teach –
“(i) a user-operated scenario builder on the author's processor, (ii) a server-side parsing with clustering mechanism that "provide[s] suggestion for the chatbot response", and (iii) the claimed API architecture between the scenario builder/chatbot infrastructure/service providers and, separately, between the chatbot infrastructure and communication channels.”
The arguments are not persuasive. Blandin clearly teaches prong (i) –“The bot platform may provide a bot engine that empower developers to define the behavior of their bots using stories” [0029]; “The developer may write a plurality of example conversations, where each conversation represents a scenario for the messaging bot” [0030]. Such development is surely implemented by a processor , shown in Figure 9 – “exemplary computing architecture 900 suitable for implementing various embodiments as previously described” [0141]. Thus, Blandin fully discloses prong (i) as required.
Blandin further discloses prong (ii) – “The centralized server device 720 may implement the bot server 525, natural-language machine learning component 550, and bot application 190” [0134]; “NLP system to perform the analysis of messaging conversations” [0025], wherein applying NLP processing to the messages is parsing. Blandin further teaches “message thread may collect together the messages shared between a particular group of users” [0050], “identifier uniquely identifying the group thread”, [0061] “collects the actual conversations”, [0106] “processing the current state of the user-to-bot conversation using a sequence model to generate a collection of possible bot responses”, [0122] “conversations … are joined together” and provide a suggestion for the chatbot response ([0084], [0107]. A collection of possible bot responses is a cluster. There is no additional requirement in the claim with respect to parsing or cluster. Blandin teaches, collecting conversations, joining them together, identifying a group thread all of which are synonymous with the claimed clustering. Thus, Blandin fully discloses prong (ii) as required.
With respect to the prong (iii) above, the claim requires “API application programming interface fallbacks, JavaScript Object Notation structure, and webhooks.” There is no requirements of “API architecture between the scenario builder/chatbot infrastructure/service providers and, separately, between the chatbot infrastructure and communication channels” and as such, such statement is not addressed.
The applicant is reminded that during prosecution before the USPTO, claims are to be given their broadest reasonable interpretation, and the scope of a claim cannot be narrowed by reading limitations appearing in the specification into the claim. See In re Morris, 127 F.3d 1048, 1054 (Fed. Cir. 1997).
Although Blandin explicitly teach “bot API call “ [0066]-[0067], [0086]-[0087] and various API calls between the users and various bots [0112], [0122], Blandin does not explicitly teach, JSON structure, fallbacks and webhooks. However, it is respectfully noted that one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck& Co., 800 F.2d 1091,231 USPQ 375 (Fed. Cir. 1986). Smullen and Shanmugam fully disclose such functionality as required. Other features of Smullen and Shanmugam do not need to be included when these modification takes place.
The applicant further argues –
“Additionally, the cited disclosure lacks the claimed server-side parsing and clustering mechanism that outputs suggestions. The specification explains this component in detail as presented by §[0038] and further Fig. 7”
The arguments are not persuasive. It is noted that there is no server disclosed by the specification. It is not clear of where the parsing and clustering is taking place. The applicant is interpreting the specification. Still, Blandin clearly and explicitly teaching the Bot server 525, in communication with the client device (see Figure 5 and 7). See further Figure 8 which discloses a plurality if Bot Servers. Blandin also teaches “natural-language machine learning (NLML) component to generate a sequence model … may use the sequence model to generate bot responses, including bot messages and bot actions” [0097]. See specifically Figure 7 that shows Centralized Server Device 720 comprising Bot Server 525 and Natural-Language Machine Learning Component 550. The natural-language machine learning surely provides parsing as required by the claim. Thus, Blandin fully discloses the claimed server-side parsing and clustering mechanism that outputs suggestions as required.
The references of Shanmugam and Smullen are not relied upon to teach these features, as they are fully disclosed by Blandin. Shanmugam is relied upon to teach API fallbacks, which are fully disclosed on paragraph [0035]. Analogously, the reference of Smullen is relied upon to teach JSON structure, and webhooks discloses which are fully disclosed on paragraphs [0150], [0180], [0311]. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981 ); In re Merck & Co., 800 F.2d 1091,231 USPQ 375 (Fed. Cir. 1986). See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the motivation used to combine the references is from the references themselves and is not improper.
◊ With respect to claims 2 and 12, the applicant argues that the combination of references –“do not disclose a scenario builder that receives author input or provides editable conditional flows. The "triggers" in Blandin correspond to model-training events and data inputs, not user-defined conditional branches within an authoring environment. Likewise, Blandin's deletion or adjustment of data points (para. [0102]) concerns pruning training examples from a corpus, not removing scenario elements within an authoring GUI as expressly required by the claims.”
The arguments are not persuasive. Once again it is noted that the specification does not properly provides the support for the limitations of claims 2 and 12. The applicant is interpreting the specification to come up with a conclusion that IF/THEN logic triggers a removal of elements. Such statement is only an assumption that is not based on any facts or support and thus, can be flawed. Still, if the IF/THEN logic somehow allows for removal of elements upon user selection, then the delete Control icon/button, disclosed by Blandin in F3C:357 surely allows for the same.
With respect to the limitation - wherein the scenario builder further comprises a front end and a backend infrastructure connected to a networked database, Blandin fully teaches the front end components in F2A-B, 3A-C and F5. Any of skill in the art would easily comprehend a front end client interface and back end chat bot server processing. Thus, Blandin fully discloses claims 2 and 12 as required.
◊ With respect to claims 3 and 13, the applicant argues that the combination of references – “fails to disclose storage that "saves" or "adjusts" authored scenarios as claimed.”
The arguments are not persuasive and are baseless. Bachrach in the cited paragraphs clearly teaches – “messaging bot may be annotated and used as examples for the messaging bot in the future. Live examples that resulted in failure may be edited to show how the messaging bot should have behaved, then annotated and used as examples for the messaging bot” [0033]. Editing scenarios and using them in the feature fully discloses a requirements of claims 3 and 13.
The applicant further argues that Bachrach fails to disclose - (ii) communicates through defined APIs and webhooks to synchronize those scenarios within a networked authoring environment. However, it seems once again, the applicant is interpreting the specification and the claims. There is not requirement for defined APIs and webhooks to synchronize those scenarios within a networked authoring environment, and thus, such unsubstantiated arguments are moot.
◊ With respect to claims 4 and 14, it is respectfully noted that the term “webhooks” are only mentioned once in the specification in the paragraph [0028] with a bare minimum disclosure – “Query Matching (405), the present embodiments may call back their API (402) to send a webhook back to the channel provider with an adequate response, trigger or fallback action”. Yet, there are three claims that seems to require this functionality. Therefore, any claim that require a webhook functionality are examined in view of the support provided by the paragraph [0028]. Wherein Shanmugam in [0035] and Smullen in [0150], [0180], [0311] fully disclose issuing and receiving API calls and webhooks that trigger actions in the scenario built by the first user. The applicant argues “author-facing API layer”, which is not required by the claims.
◊ With respect to claims 8-9 and 18-19, and the Blandin reference the applicant argues that the combination of references – “do not teach a browser-resident authoring tool capable of uploading or embedding multimedia content”; “combination therefore fails to teach or suggest the claimed authoring functionality.”
The arguments are not persuasive. It is first noted that the claims once again are examined in view of the specification. There is only a single paragraph [0028] that provides such support – “content sent by the end user may include any type of test message (408), cards including a combination of multimedia data (411), tokens (409), actions or triggers, links (413) or any other type of content or activity that is enabled via channel provider delivering chat widget.” There is no support for the uploading or sending media elements according to the scenario. In view of the specification it’s the end user who sends the messages, thus it is not clear of how the media is sent by the end user in such accordance. Still, Smullen clearly teaches in paragraph [0100] various multimedia examples published as messages and obviate the teachings of Bachrach. Please further note that additional, previously cited reference of Tapuhi et al. (US 20170118336) analogously discloses claims 8 and 18 as indicated int eh updated rejection to the claims above. The uploading of media content is a well-known and obvious functionality.
◊ With respect to claims 5 and 15, the applicant argues – “None of the cited references teaches or suggests such integration or functional purpose”; “The reference does not disclose any SBERT embedding, tagging, or classification pipeline like the one recited in claims 5 and 15 and expressly depicted in Figure 7 of Applicant's drawings. Nor does Sastre Martinez identify chat content, tokens, or question-answer categories, its clustering applies to abstract data points.”
The arguments are not persuasive. Once again, the claims are examined in view of the specification. The specification is silent on such functionality. The applicant cites paragraph [0038], which is irrelevant to the min/max chat size. The applicant also mentions “interactive suggestion library” which is not required by the claims, and thus, will not be addressed. Still, Sastre Martinez and Bachrach fully disclose claims 5 and 15 as required.
◊ With respect to claims 6 and 16, the applicant argues – “Blandin's paragraphs [0097]-0122], by contrast, relate to model-training and message-sequence generation based on predicted probabilities, not user-defined conditions.”; “None of these references teaches a frontend authoring interface that issues commands to cease or reassign a scenario through interaction with backend infrastructure, as recited.”
The arguments are not persuasive. Blandin clearly teaches that the developer can modify the scenarios in ([0026], [0030], [0059]-[0060], F3A-C). Tapuhi is meant to disclose reassigning the scenario if the response of the second user does not match the scenario configured by the first user and cease the scenario sending upon direct request from the first user sent by the user interface, which is fully disclosed in the paragraphs [0079]-[0080], [0085], [0089], [0096] as required.
◊ With respect to claims 7 and 17, and the Tapuhi, Lee, and Bachrach references the applicant argues that Blandin – “do not disclose or suggest author- defined conditional triggers based on human-language analysis or similarity metrics”; “Bachrach's paragraph [0062] refers to Levenshtein distance as a text- matching function used in dialog optimization, not as an author-configurable trigger condition for launching scenario branches”, “None of the cited references teaches or suggests a framework in which a human author can configure and test multiple branching paths, select among exact, similar, or interpreted values, and perform A/B testing within a single authoring interface as part of scenario creation.”
The arguments are not persuasive. Lee fully discloses a well-known Sorensen-dice coefficient ([0022]) and a well-known functionality of A/B testing on the content defined by the first user ([0073]), as required.
◊ With respect to claim 10, and the Kim reference the applicant argues –
“Kim, it is used to post-process conversations to enhance retrieval, categorization, or summarization, not to provide context-aware authoring support for conversation scenario building with as of the claimed subject matter.”
The arguments are not persuasive. Kim fully teaches independent communication items with a cosine similarity larger than 0.75 in paragraphs [0039], [0045], [0047]-[0048], [0063] as required.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is indicated on PTO-892.
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 February 21, 2026