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 .
This is a response to U.S. Patent Application No. 18/955,970 filed on 11/21/2024 in which Claim 1 was filed for examination. In a preliminary amendment dated 02/03/2025, Applicant canceled Claim 1 and added Claims 2 – 21.
This U.S. Patent Application No. 18/955,970 is a Continuation of U.S. Patent Application No. 18/306,141 which is now U.S. Patent No. 12,182,383.
Status of the Claims
Claims 2 – 21 are rejected on the ground of nonstatutory double patenting, Claims 2, 5 – 7, 9, 12 – 14, 16, 19 and 20 are rejected under 35 U.S.C. 102(a)(1)/102(a)(2), and Claims 3, 4, 8, 10, 11, 15, 17, 18 and 21 are rejected under 35 U.S.C. 103.
Examiner Note
The Examiner cites particular columns, line numbers and/or paragraph numbers in the references as applied to the claims below for the convenience of the Applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 03/10/2025 have been entered and considered by the examiner.
Specification
The disclosure is objected to because of the following informalities:
Par [0001] recites “This application is a continuation of U.S. Patent Application 18/306,141, filed April 24, 2023,…”
This paragraph should be amended to indicated that U.S. Patent Application 18/306,141 is now U.S. Patent No. 12,182,383.
Appropriate correction is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 2, 3, 5 – 7, 9, 10, 12 – 14, 16, 17, 19 and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over Claims 1, 2, 5 – 9, 12, - 16, 19 and 20 of U.S. Patent No. 12,182,383. Although the claims at issue are not identical, they are not patentably distinct from each other because the patent anticipates all limitations of the pending claims as shown below (See table with corresponding claim mappings).
Claims 2, 3, 5 – 7, 9, 10, 12 – 14, 16, 17, 19 and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over Claims 1, 2, 5 – 7, 10, 11 and 14 – 16 of U.S. Patent No. 11,662,888. Although the claims at issue are not identical, they are not patentably distinct from each other because the patent anticipates all limitations of the pending claims as shown below (See table with corresponding claim mappings).
Instant Application No. US 18/955970
U.S. Patent
No. 12,182,383
U.S. Patent
No. 11,662,888
2, 9, 16
1, 8, 15
1, 10
3, 10, 17
2, 9, 16
2, 11
4, 11, 18
5, 12, 19
5, 12, 19
5, 14
6, 13, 20
6, 13
6, 15
7, 14
7, 14, 20
7, 16
8, 15, 21
Regarding Claims 2, 3, 5 – 7, 9, 10, 12 – 14, 16, 17, 19 and 20, Claims 1, 2, 5 – 9, 12, - 16, 19 and 20 of U.S. Patent No. 12,182,383 recites a computer-implemented method, a non-transitory computer-readable storage medium and a system being capable of executing every step carried out by the instant application. One of ordinary skill in the art would conclude that the Claims of U.S. Patent No. 12,182,383 anticipates the invention as defined in the claims at issue.
Regarding Claims 2, 3, 5 – 7, 9, 10, 12 – 14, 16, 17, 19 and 20, Claims 1, 2, 5 – 7, 10, 11 and 14 – 16 of U.S. Patent No. 11,662,888 recites a computer-implemented method and a non-transitory computer-readable storage medium being capable of executing every step carried out by the instant application. One of ordinary skill in the art would conclude that the Claims of U.S. Patent No. 11,662,888 anticipates the invention as defined in the claims at issue.
Claims 4, 8, 11, 15, 18 and 21 are rejected on the ground of nonstatutory double patenting as being unpatentable over Claims 7, 14 and 20 of U.S. Patent No, 12,182,383 (hereinafter, Pat 383) in view of Barkol et al. (US 2020/0258511) (hereinafter, Barkol).
Regarding Claims 4, 11, 18. Pat 383 discloses the generation and presentation of a collaboration interface that presents options for values that the user may select for the each of the attributes of the collaboration (See Pat 383 Claims 7, 14 and 20). However, Pat 383 does not specifically disclose “selecting a UI template based on the determined intent form a plurality of pre-generated UI templates”
Barkol in par 0056, teaches the care provider devices (e.g., care provider device 134) may store user interface templates in memory that include placeholders for relevant information stored on server system 102. For example, care provider device 134 may store a user interface template for a patient dashboard that a user of care provider device 134 may configure with placeholders for desired patient information. Barkol in par 0066 and Fig. 3 teaches that a dashboard 300 that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to a user input to the communication thread 200, for example by selecting a link within medical information displayed in communication thread, as explained above, or in response to selection of the dashboard button 208. Barkol in par 0070, further teaches that a user interface control button 308 is shown that, when selected, may allow the care provider viewing dashboard 300 to view and interact with the communication thread.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Pat 383 to create different templates based on the intent as disclosed in Barkol. The motivation for doing so would have been to effectively provide an interface that is easy to navigate to access desired information (See Barkol’s par 0023).
Regarding Claims 8, 15 and 21. Pat 383 discloses that the method repeats for every communication and generating and presenting a collaboration interface that presents options for values that the user may select for the each of the attributes of the collaboration (See Pat 383 Claims 7, 14 and 20). However, Pat 383, does not specifically disclose “dynamically modifying the intractable UI element to a new UI element corresponding to the new intent”. Barkol in par 0056, teaches the care provider devices (e.g., care provider device 134) may store user interface templates in memory that include placeholders for relevant information stored on server system 102. For example, care provider device 134 may store a user interface template for a patient dashboard that a user of care provider device 134 may configure with placeholders for desired patient information. Barkol in par 0066 and Fig. 3 teaches that a dashboard 300 that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to a user input to the communication thread 200, for example by selecting a link within medical information displayed in communication thread, as explained above, or in response to selection of the dashboard button 208. Barkol in par 0070, further teaches that a user interface control button 308 is shown that, when selected, may allow the care provider viewing dashboard 300 to view and interact with the communication thread.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Pat 383 to create different templates based on the intent as disclosed in Barkol. The motivation for doing so would have been to effectively provide an interface that is easy to navigate to access desired information (See Barkol’s par 0023).
Claims 4, 8, 11, 15, 18 and 21 are rejected on the ground of nonstatutory double patenting as being unpatentable over Claims 7 and 16 of U.S. Patent No, 11,662,888 (hereinafter, Pat 888) in view of Barkol et al. (US 2020/0258511) (hereinafter, Barkol).
Regarding Claims 4, 11, 18. Pat 888 discloses the generation and presentation of a collaboration interface that presents options for values that the user may select for the each of the attributes of the collaboration (See Pat 888 Claims 7 and 16). However, Pat 888 does not specifically disclose “selecting a UI template based on the determined intent form a plurality of pre-generated UI templates”
Barkol in par 0056, teaches the care provider devices (e.g., care provider device 134) may store user interface templates in memory that include placeholders for relevant information stored on server system 102. For example, care provider device 134 may store a user interface template for a patient dashboard that a user of care provider device 134 may configure with placeholders for desired patient information. Barkol in par 0066 and Fig. 3 teaches that a dashboard 300 that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to a user input to the communication thread 200, for example by selecting a link within medical information displayed in communication thread, as explained above, or in response to selection of the dashboard button 208. Barkol in par 0070, further teaches that a user interface control button 308 is shown that, when selected, may allow the care provider viewing dashboard 300 to view and interact with the communication thread.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Pat 888 to create different templates based on the intent as disclosed in Barkol. The motivation for doing so would have been to effectively provide an interface that is easy to navigate to access desired information (See Barkol’s par 0023).
Regarding Claims 8, 15 and 21. Pat 888 also discloses that the method repeats for every communication and generating and presenting a collaboration interface that presents options for values that the user may select for the each of the attributes of the collaboration (See Pat 88 Claim 7 and 16). However, Pat 888, does not specifically disclose “dynamically modifying the intractable UI element to a new UI element corresponding to the new intent”. Barkol in par 0056, teaches the care provider devices (e.g., care provider device 134) may store user interface templates in memory that include placeholders for relevant information stored on server system 102. For example, care provider device 134 may store a user interface template for a patient dashboard that a user of care provider device 134 may configure with placeholders for desired patient information. Barkol in par 0066 and Fig. 3 teaches that a dashboard 300 that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to a user input to the communication thread 200, for example by selecting a link within medical information displayed in communication thread, as explained above, or in response to selection of the dashboard button 208. Barkol in par 0070, further teaches that a user interface control button 308 is shown that, when selected, may allow the care provider viewing dashboard 300 to view and interact with the communication thread.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify Pat 888 to create different templates based on the intent as disclosed in Barkol. The motivation for doing so would have been to effectively provide an interface that is easy to navigate to access desired information (See Barkol’s par 0023).
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 2, 5 – 7, 9, 12 – 14, 16, 19 and 20 are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by Ekambaram et al. (US 2019/0340574) (hereinafter, Ekambaram) (cited in IDS dated 03/10/2025).
Regarding Claim 2, Ekambaram teaches a computer-implemented method (See Ekambaram’s Abstract) comprising:
receiving one or more messages communicated among a plurality of users in a messaging application (Ekambaram in par 0017 – 0018, teaches that when a user has a problem or requires assistance, the user contacts a customer service center or help desk. This contact is generally a user writing an email or accessing a customer service or help desk application and filling out a form that requests information. The customer service center or help desk receives the email or other communication and a person responsible for directing the ticket to the appropriate group or person reads the communication, determines the problem and manually assign the ticket to a resolver team);
applying a language model to the one or more messages to determine an intent of the messages and one or more attributes associated with the intent (Ekambaram in par 0018, further teaches that the system analyzes problem descriptions and communication content to determine the appropriate resolver group. One system uses previously assigned tickets to determine the most relevant assignee of the ticket. For example, the system may determine that all tickets that have particular words are assigned to a particular resolver group. Thus, any subsequent ticket having one or more of those words would be assigned to that same resolver group. The systems may also use classifiers to determine the correct resolver group. Ekambaram in par 0030, further teaches that using the historical communications the system may extract intents, concepts, key phrases, sender information, location, severity information, and the like, from a corpus of historical communications. Ekambaram in par 0031, further teaches that the model may identify information, or key nuggets, that should be included in the body of the communication. These key nuggets may include information that is used by the resolver group to resolve the request);
displaying an interactable user interface (UI) element in the messaging application, the UI element comprising a set of suggested values for each of the associated attributes, the suggested values are selectable by the plurality of users (Ekambaram in par 0017, teaches that generally a user writing an email or accessing a customer service or help desk application and filling out a form that requests information. The form usually includes a free form section where the user can provide details related to the request or problem to be resolved. The customer service center or help desk receives the email or other communication and a person responsible for directing the ticket to the appropriate group or person reads the communication, determines the problem, and manually assigns the ticket to a resolver team, or a team that provides assistance in resolving a request. Ekambaram in par 0030, further teaches that using the historical communications the system may extract intents, concepts, key phrases, sender information, location, severity information, and the like, from a corpus of historical communications);
receiving, from at least one of the plurality of users, a selected value for at least one of the associated attributes (Ekambaram in par 0029, further teaches that the model may identify information that is needed or desired by a resolver group to resolve a request. For example, the model may identify that a travel resolver group requires not only the location and time of travel, but also proof of manager approval for the travel. As another example, the model may identify that an application error resolver group requires a screenshot of the error, identification of the version of the application, identification of the version of an associated application, the date of error, and the like. Each model is specific to a resolver group. In other words, the model used for one resolver group may identify information different than that of the model used for a different resolver group. Ekambaram in par 0030, further teaches that using the historical communications the system may extract intents, concepts, key phrases, sender information, location, severity information, and the like, from a corpus of historical communications);
resolving the intent using the selected value of the at least one associated attribute (Ekambaram in par 0027, further teaches that the system may use historical information to learn patterns regarding which communications have been assigned to particular resolver groups. For example, the system may parse historical communications and identify keywords or intents included in the communications. The system may then identify particular keywords or intents as being directed to a particular resolver group. Ekambaram in par 0034 – 0035, further teaches that the system may identify a difference exists if a communication includes an attachment that has a relevance level below the relevance threshold identified in the model. For example, the user may accidentally attach the incorrect file to the communication. The system may determine the relevance of the attachment to the communication by comparing information identifying the intent of the communication body to information extracted from the attachment. The system may then compute a relevance score between the communication body and the attachment. The relevance score may then be compared to a relevance score or relevance threshold identified in the model. If the relevance score, when compared to the model relevance score or relevance threshold, is below the threshold, the system may suggest a modification that the attachment be removed from the communication or request the user verify that this is the intended attachment, thereby addressing the determined difference); and
identifying, based on the resolved intent, an action to be performed by a software application on at least one user device that belongs to the plurality of users, wherein performing the action fulfills the resolved intent (Ekambaram in par 0034 – 0035, further teaches that the system may identify a difference exists if a communication includes an attachment that has a relevance level below the relevance threshold identified in the model. For example, the user may accidentally attach the incorrect file to the communication. The system may determine the relevance of the attachment to the communication by comparing information identifying the intent of the communication body to information extracted from the attachment. The system may then compute a relevance score between the communication body and the attachment. The relevance score may then be compared to a relevance score or relevance threshold identified in the model. If the relevance score, when compared to the model relevance score or relevance threshold, is below the threshold, the system may suggest a modification that the attachment be removed from the communication or request the user verify that this is the intended attachment, thereby addressing the determined difference).
Regarding Claim 5, Ekambaram teaches the limitations contained in parent Claim 2. Ekambaram further teaches:
wherein resolving the intent comprises obtaining a set of attribute values for the one or more associated attributes that are needed by the user device to perform the action (Ekambaram in par 0035, further teaches an example attachment relevance analysis. The system parses the communication body 201 to determine that the email intent is "Sales Invoice" 204 and that the intended recipient is "Sales" 205, corresponding to the Sales resolver group. The system may also parse the attachment. The system not only parses the label of the attachment, but also parses the attachment itself, for example, using an image parsing technique, text parsing technique, or the like. The system may determine that the invoice attachment 202A has a high relevance to the communication. When the system compares this relevance to the relevance threshold of the model corresponding to the Sales resolver group, the system determines that the invoice attachment 202A meets the relevance threshold 203A. However, the system may determine that while the second attachment 202B has a name of "Invoice2.jpg" the actual attachment does not correspond to an invoice. The system may determine that the relevance of this attachment 202B is lower than the relevance threshold identified in the corresponding Sales resolver group model 203B. Therefore, the system may provide a tip 206 or suggested modification that the second attachment 202B does not seem relevant and should be removed).
Regarding Claim 6, Ekambaram teaches the limitations contained in parent Claim 2. Ekambaram further teaches:
further comprising performing the action by displaying an option for the plurality of users to initiate the software application within the messaging application (Ekambaram in par 0034 – 0035, further teaches the system may determine the relevance of the attachment to the communication by comparing information identifying the intent of the communication body to information extracted from the attachment. The system may then compute a relevance score between the communication body and the attachment. The relevance score may then be compared to a relevance score or relevance threshold identified in the model. If the relevance score, when compared to the model relevance score or relevance threshold, is below the threshold, the system may suggest a modification that the attachment be removed from the communication or request the user verify that this is the intended attachment, thereby addressing the determined difference).
Regarding Claim 7, Ekambaram teaches the limitations contained in parent Claim 2. Ekambaram further teaches:
further comprising providing to a user device of each of the plurality of users, a collaboration interface that presents options for values that are selectable for each of the associated attributes (Ekambaram in par 0017, teaches that generally a user writing an email or accessing a customer service or help desk application and filling out a form that requests information. The form usually includes a free form section where the user can provide details related to the request or problem to be resolved. The customer service center or help desk receives the email or other communication and a person responsible for directing the ticket to the appropriate group or person reads the communication, determines the problem, and manually assigns the ticket to a resolver team, or a team that provides assistance in resolving a request. Ekambaram in par 0030, further teaches that using the historical communications the system may extract intents, concepts, key phrases, sender information, location, severity information, and the like, from a corpus of historical communications).
Regarding Claim 9, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 2. Accordingly, Ekambaram discloses/teaches every limitation of Claim 9, as indicated in the above rejection of Claim 2.
Regarding Claim 12, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 5. Accordingly, Ekambaram discloses/teaches every limitation of Claim 12, as indicated in the above rejection of Claim 5.
Regarding Claim 13, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 6. Accordingly, Ekambaram discloses/teaches every limitation of Claim 13, as indicated in the above rejection of Claim 6.
Regarding Claim 14, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 7. Accordingly, Ekambaram discloses/teaches every limitation of Claim 14, as indicated in the above rejection of Claim 7.
Regarding Claim 16, this claim merely recites a computer system comprising: one or more computer processors for executing computer program instructions; and a non-transitory computer-readable storage medium comprising stored instructions (See Ekambaram’s par 0003), when executable, cause the one or more computer processors to execute instructions as similarly recited in Claim 2. Accordingly, Ekambaram discloses/teaches every limitation of Claim 16, as indicated in the above rejection of Claim 2.
Regarding Claim 19, this claim merely recites a computer system comprising: one or more computer processors for executing computer program instructions; and a non-transitory computer-readable storage medium comprising stored instructions (See Ekambaram’s par 0003), when executable, cause the one or more computer processors to execute instructions as similarly recited in Claim 5. Accordingly, Ekambaram discloses/teaches every limitation of Claim 19, as indicated in the above rejection of Claim 5.
Regarding Claim 20, this claim merely recites a computer system comprising: one or more computer processors for executing computer program instructions; and a non-transitory computer-readable storage medium comprising stored instructions (See Ekambaram’s par 0003), when executable, cause the one or more computer processors to execute instructions as similarly recited in Claim 6. Accordingly, Ekambaram discloses/teaches every limitation of Claim 20, as indicated in the above rejection of Claim 6.
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 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ekambaram in view of Lane at al. (US 2016/0342665) (hereinafter, Lane) (cited in IDS dated 03/10/2025).
Regarding Claim 3, Ekambaram teaches the limitations contained in parent Claim 2.
However, Ekambaram does not specifically wherein displaying an interactable UI element comprises generating a JavaScript Object Notation (JSON) document including JSON objects for the associated attributes.
Lane teaches a collaborative communication system that may interface with one or more command resources (See Lane’s Abstract). Lane in par 0038, teaches a unified communication platform 105 is a communication system/service that provides a collaborative environment for users to communicate and collaborate. Lane in par 0120 – 0122 and Fig. 4B, further teaches that the third-party service registers with a collaborative communication system/service. Application agents (e.g., application agents 106d) may interface with external resources 114 such as third-party services using webhooks in order to facilitate integration between a unified communication platform and third-party services. APIs may enable interaction between a collaborative communication system/service and third-party services to enable transmission of registration data. Flow proceeds to operation 424 where parameters are generated that define a command associated with a command handler. Flow then proceeds to operation 426 where the third-party service registers the command handler with the collaborative communication system/service. In examples, a third party service may interface with the collaborative communication system service, through webhooks, APIs, and any other type of requests/responses such as (HTTP requests, JSON requests, etc.).
Therefore, it would have been obvious to one of ordinary skill in the before the effective filing date to utilize the teachings as in Lane with the teaching as in Ekambaram to include data in JSON format. The motivation for doing so would have been to provide data in a standardized format, thus saving user resources and providing faster execution (See Lane’s par 0120 – 0122).
Regarding Claim 10, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 3. Accordingly, Ekambaram in view of Lane discloses/teaches every limitation of Claim 10, as indicated in the above rejection of Claim 3.
Regarding Claim 17, this claim merely recites a computer system comprising: one or more computer processors for executing computer program instructions; and a non-transitory computer-readable storage medium comprising stored instructions (See Ekambaram’s par 0003), when executable, cause the one or more computer processors to execute instructions as similarly recited in Claim 3. Accordingly, Ekambaram discloses/teaches every limitation of Claim 17, as indicated in the above rejection of Claim 3.
Claims 4, 8, 11, 15, 18 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Ekambaram in view of Barkol et al. (US 2020/0258511) (hereinafter, Barkol).
Regarding Claim 4, Ekambaram teaches the limitations contained in parent Claim 2.
However, Ekambaram does not specifically disclose wherein displaying an interactable UI element comprises selecting a UI template based on the determined intent from a plurality of pre-generated UI templates, the UI template comprising the interactable UI element.
Barkol teaches a system and method for presenting aggregate data in response to a natural language user input (See Barkol’s Abstract). Barkol in par 0056, teaches the care provider devices (e.g., care provider device 134) may store user interface templates in memory that include placeholders for relevant information stored on server system 102. For example, care provider device 134 may store a user interface template for a patient dashboard that a user of care provider device 134 may configure with placeholders for desired patient information. When the dashboard is displayed on the care provider device, the relevant patient information may be retrieved from server system 102 and inserted in the placeholders. Barkol in par 0059, further teaches that collaborative system interface 500 further includes links to patient communication thread-dashboard pairs. For example, FIG. 5 shows links to communication thread-dashboard pairs for patient ID 0123, patient ID 1111, patient ID 1234, and patient ID 1235. Barkol in par 0066 and Fig. 3 teaches that a dashboard 300 that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to a user input to the communication thread 200, for example by selecting a link within medical information displayed in communication thread, as explained above, or in response to selection of the dashboard button 208. Barkol in par 0070, further teaches that a user interface control button 308 is shown that, when selected, may allow the care provider viewing dashboard 300 to view and interact with the communication thread.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in Barkol with the teachings as in Ekambaram to provide an interface in Ekambaram as disclosed in Barkol. The motivation for doing so would have been to effectively provide an interface that is easy to navigate to access desired information (See Barkol’s par 0023).
Regarding Claim 8, Ekambaram teaches the limitations contained in parent Claim 2. Ekambaram further teaches:
further comprising:
receiving an additional message communicated among the plurality of users in the messaging application (Ekambaram in par 0017 – 0018, teaches that when a user has a problem or requires assistance, the user contacts a customer service center or help desk. This contact is generally a user writing an email or accessing a customer service or help desk application and filling out a form that requests information. The customer service center or help desk receives the email or other communication and a person responsible for directing the ticket to the appropriate group or person reads the communication, determines the problem and manually assign as the ticket to a resolver team);
determining a new intent based on the additional message (Ekambaram in par 0018, further teaches that the system analyzes problem descriptions and communication content to determine the appropriate resolver group. One system uses previously assigned tickets to determine the most relevant assignee of the ticket. For example, the system may determine that all tickets that have particular words are assigned to a particular resolver group. Thus, any subsequent ticket having one or more of those words would be assigned to that same resolver group. The systems may also use classifiers to determine the correct resolver group. Ekambaram in par 0030, further teaches that using the historical communications the system may extract intents, concepts, key phrases, sender information, location, severity information, and the like, from a corpus of historical communications); and
However, Ekambaram does not specifically disclose dynamically modifying the interactable UI element to a new UI element corresponding to the new intent.
Barkol in par 0029, teaches that when viewing communication thread 104 and/or dashboard 106 via a display of a care provider device, a care provider may enter input. where the user input is a selection of a link or user interface control button of the dashboard, the user input may trigger display of the communication thread, trigger progression to a desired state of the dashboard (e.g., trigger display of desired patient medical information), trigger updates to the configuration of the dashboard, or other actions. Barkol in par 0059, further teaches that collaborative system interface 500 further includes links to patient communication thread-dashboard pairs. For example, FIG. 5 shows links to communication thread-dashboard pairs for patient ID 0123, patient ID 1111, patient ID 1234, and patient ID 1235. Barkol in par 0066 and Fig. 3 teaches that a dashboard 300 that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to a user input to the communication thread 200, for example by selecting a link within medical information displayed in communication thread, as explained above, or in response to selection of the dashboard button 208. Barkol in par 0070, further teaches that a user interface control button 308 is shown that, when selected, may allow the care provider viewing dashboard 300 to view and interact with the communication thread.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to utilize the teachings as in Barkol with the teachings as in Ekambaram to provide an interface in Ekambaram as disclosed in Barkol. The motivation for doing so would have been to effectively provide an interface that is easy to navigate to access desired information (See Barkol’s par 0023).
Regarding Claim 11, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 4. Accordingly, Ekambaram in view of Lane discloses/teaches every limitation of Claim 11, as indicated in the above rejection of Claim 4.
Regarding Claim 15, this claim merely recites a non-transitory computer readable storage medium comprising stored program code, the program code comprising instructions, the instructions when executed cause a processor system to execute instructions as similarly recited in Claim 8. Accordingly, Ekambaram in view of Lane discloses/teaches every limitation of Claim 15, as indicated in the above rejection of Claim 8.
Regarding Claim 18, this claim merely recites a computer system comprising: one or more computer processors for executing computer program instructions; and a non-transitory computer-readable storage medium comprising stored instructions (See Ekambaram’s par 0003), when executable, cause the one or more computer processors to execute instructions as similarly recited in Claim 4. Accordingly, Ekambaram discloses/teaches every limitation of Claim 18, as indicated in the above rejection of Claim 4.
Regarding Claim 21, this claim merely recites a computer system comprising: one or more computer processors for executing computer program instructions; and a non-transitory computer-readable storage medium comprising stored instructions (See Ekambaram’s par 0003), when executable, cause the one or more computer processors to execute instructions as similarly recited in Claim 8. Accordingly, Ekambaram discloses/teaches every limitation of Claim 21, as indicated in the above rejection of Claim 8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIEL MERCADO VARGAS whose telephone number is (571)270-1701. The examiner can normally be reached M-F 8:00am - 4:00pm.
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, Scott Baderman can be reached at 571-272-3644. 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.
/ARIEL MERCADO-VARGAS/Primary Examiner, Art Unit 2118
