DETAILED ACTION
This communication is in response to the Amendments and Arguments filed on 29 January 2026. Claims 1-5, 7-18, and 20-22 are pending and have been examined. The Applicants’ amendment and remarks have been carefully considered, but are not persuasive. Hence, this Action has been made FINAL.
All previous objections and rejections directed to the Applicant’s disclosure and claims not discussed in this Office Action have been withdrawn by the Examiner.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 29 January 2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Amendments and Arguments
The Applicant’s arguments have been considered but are moot because the new ground of rejection (Dai et al.) does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claim(s) 1-4, 6, 8-17, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9936066, hereinafter referred to as Mammen et al., in view of US 20220392451, hereinafter referred to as Dai et al.
Regarding claim 1 (Currently Amended), Mammen et al. discloses a system for generating an event driver (“The “alert_trigger” field 2420 indicates whether the presence of the particular topic should trigger an alert of some form. For example, certain keywords may cause an immediate alert notification to be sent,” Mammen et al., col. 55, lines 25-28. Here, the event is interpreted as an alert and the event driver as an alert trigger.), comprising:
a processor (Mammen et al., Fig. 29(2901)); and
a memory storing computer-executable instructions that, upon execution by the processor, causes the system to perform a set of operations (Mammen et al., Fig. 29(2906)(2907)), the set of operations comprising:
obtaining communication data associated with a communication between a plurality of sources (“FIG. 1 illustrates one embodiment of a call center architecture 100 that may be used in accordance with the various technologies disclosed herein. The call center shown in FIG. 1 may process voice calls that are inbound-only, outbound-only, or a combination of both (sometimes referred to as a “blended” call center). Although many aspects of call center operation are disclosed in the context of voice calls, in various embodiments, the call center may process other forms of communication such as, for example, facsimiles, emails, text messages, video calls, and chat messages. That is, the call center may be considered a contact center. Thus, although a contact center has been referenced above, for the purposes of the remainder of this disclosure, the term “call center” is used throughout, although it is understood that the two are synonymous to the extent that they both handle voice call, Mammen et al., col. 12, line 55 – col. 56, line 3.);
determining an event for the communication (Mammen et al., col. 55, lines 25-28. And, “Event (a.k.a. “speech event”)—detection by an RTSA system of a keyword uttered in the speech, typically involving one of an agent or remote party in a voice call. Events are typically reported, and hence reporting an event is indicating the occurrence of the event as detected by the RTSA system,” Mammen et al., col. 5, lines 54-59.);
segmenting the communication data into a set of data segments, wherein each data segment of the set of data segments is associated with the determined event (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call. Thus call (i.e., communication) data segments are associated with various alerts (i.e., events).);
determining, for each data segment of the set of data segments, a topic of the data segment, thereby generating a set of topics (“FIG. 22 represents one embodiment of a process flow for allowing review of information related to topics detected during a call,” Mammen et al., col. 3, lines 29-31.);
generating, in a communication data store, an association between the set of topics and the event, to generate an event driver for the event of the communication (“The “alert_trigger” field 2420 indicates whether the presence of the particular topic should trigger an alert of some form. For example, certain keywords may cause an immediate alert notification to be sent,” Mammen et al., col. 54, lines 30-46. The record 2400 is a communication data store.), wherein the association causes storage of at least part of the communication data (Mammen et al., col. 54, lines 30-46. The record structure 2400 stores a record of communications and associated actions.), and wherein the event driver represents a cause for the event ( The alert trigger (i.e., event driver) causes the alert (i.e., alert).);
generating, using the event driver, a recommended action, wherein the recommended action is predicted to reduce the occurrence of the determined event (“Turning to FIG. 14B, the same screen shot 1400 is shown but with an added icon and text 1470. This comprises a warning symbol and text that reflects the speech condition that was detected for this checkpoint. This allows feedback to the agent to reinforce speech that is not desired for whatever reason. In this embodiment, the icon and text 1470 remains displayed until the agent acknowledges the alert,” Mammen et al., col. 35, lines 16-22.), and wherein the recommended action comprises generating at least one of a notification, a dashboard, or a report (Mammen et al., fig. 14B – screen presented to agent.); and
providing an indication of the notification, the dashboard, or the report to a computing device (Mammen et al., fig. 14B – screen presented to agent.).
Mammen et al., though, does not disclose receiving an indication to accept the recommended action; and in response to receiving this indication, implementing the recommended action.
Dai et al. is cited to disclose receiving an indication to accept the recommended action (“An example, of an action is the next best action to be performed by an agent participating in a conversation. An action may represent determining a workflow to be performed in a given context within a conversation and recommending the workflow or recommending an action based on the workflow to an agent participating in the conversation. In an embodiment, the action module 250 includes a rule based system that triggers various actions based on result of AI analysis. For example, a rule may specify that if the intent has a specific value, certain workflow is triggered. A rule may specify that if the sentiment has a specific value, specific types of responses are generated,” Dai et al., para [0037]. And, “As shown in FIG. 5B, the user interface 505, the online system 100 initiates a workflow 520 based on the intent and shows the initiated workflow 515 to the agent. The agent confirms the workflow 520 to approve the workflow, for example, by clicking on the accept button 523,” Dai et al., para [0050]. See also Fig. 5B.); and
in response to receiving this indication, implementing the recommended action (Dai et al., para [0037] and [0050]. See also Fig. 5B.). Dai et al. benefits Mammen et al. by allowing the recipient (i.e., agent) of communication recommendations to acknowledge the receipt of the recommendation and to implement the specific recommendations, thereby providing feedback to the conversation system that the agent is performing the recommended action. Therefore, it would be obvious for one skilled in the art to combine the teachings of Mammen et al. with those of Dai et al. to provide the contact center with feedback on its recommendations.
As to claim 14, CRM claim 14 and system claim 1 are related as system and CRM of using same, with each claimed element’s function corresponding to the system step. Accordingly claim 14 is similarly rejected under the same rationale as applied above with respect to system claim.
Regarding claim 2 (Original), Mammen et al., as modified by Dai et al., discloses the system of claim 1, wherein the event is one of a system-driven event, a context-driven event, or a conversation-driven event (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40. Here, the alert is a conversation-driven (i.e., call-driven) event.).
As to claim 15, CRM claim 15 and system claim 2 are related as system and CRM of using same, with each claimed element’s function corresponding to the system step. Accordingly claim 15 is similarly rejected under the same rationale as applied above with respect to system claim.
Regarding claim 3 (Original), Mammen et al., as modified by Dai et al., discloses the system of claim 1, wherein communication data is segmented into the set of data segments based on at least one of a quantity of data segments or a segmentation granularity associated with a type of the determined event (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call. Thus call (i.e., communication) data segments are associated with various alerts (i.e., events).).
As to claim 16, CRM claim 16 and system claim 3 are related as system and CRM of using same, with each claimed element’s function corresponding to the system step. Accordingly claim 16 is similarly rejected under the same rationale as applied above with respect to system claim.
Regarding claim 4 (Original), Mammen et al., as modified by Dai et al., discloses the system of claim 1, wherein the event is determined based on at least one of the communication data or metadata associated with the communication (“FIG. 23 represents one embodiment of an architecture for processing a call wherein topic meta-data records are generated in response to detecting the topic by a real-time speech analytics system,” Mammen et al., col. 3, lines 32-35. And, “FIG. 24 represents one embodiment of a record in the topic meta-data file, wherein the record comprises various elements,” Mammen et al., col. 3, lines 36-38. Fig. 24 shows a record associating meta-data with an alert (i.e., event).).
As to claim 17, CRM claim 17 and system claim 4 are related as system and CRM of using same, with each claimed element’s function corresponding to the system step. Accordingly claim 17 is similarly rejected under the same rationale as applied above with respect to system claim.
Claim 6 canceled.
Regarding claim 8 (Currently Amended), Mammen et al. discloses a computer-implemented method for generating an event driver for communication data (“The “alert_trigger” field 2420 indicates whether the presence of the particular topic should trigger an alert of some form. For example, certain keywords may cause an immediate alert notification to be sent,” Mammen et al., col. 55, lines 25-28. Here, the event is interpreted as an alert and the event driver as an alert trigger.), the method comprising:
obtaining a set of event drivers associated with one or more communications of a contact center (Mammen et al., col. 55, lines 25-28.), wherein each event driver of the set of event drivers includes an association between:
an event of a conversation (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call. Thus call (i.e., communication) data segments are associated with various alerts (i.e., events).); [[and]]
a topic for a segment of the conversation that preceded the event (“FIG. 22 represents one embodiment of a process flow for allowing review of information related to topics detected during a call,” Mammen et al., col. 3, lines 29-31.); and
wherein the association included in an event driver represents a cause for the event (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40.) and causes storage of at least part of the one or more communications (Mammen et al., col. 54, lines 30-46. The record structure 2400 stores a record of communications and associated actions.);
generating, based on the set of event drivers, a report that includes:
an event type for one or more events of the set of event drivers (“Continuing with the record fields, the next field is the “scan_host” field 2412 which is the name of the particular RTSA server detecting the keyword. The next field is the “omit_phrase” field 2414, which indicates whether a particular phrase was detected or omitted (not detected) during the call. This can be used to determine if the agent did not say something there were required to say,” Mammen et al., col. 55, lines 13-19. The field 2414 represents an event type.), wherein the set of event drivers is a first set of event drivers, and the report includes a comparison between the first set of event drivers and a second set of event drivers that are associated with a different time period than the first set of event drivers (Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call, thereby providing a composite report for the call. Thus call (i.e., communication) data segments are associated with various alerts (i.e., events).); and
one or more topics that are associated with the one or more events (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call. The next field is the “alert_count” field 2408 which indicates how many times alerts corresponding to the topic_name were received. The next field is the “phrase_id” field 2410 which identifies which one of several particular phrases that is associated with the topic was detected. (The “phrase_id” correlates to the aforementioned “keyword.”),” Mammen et al., col. 54, lines 30-46.); [[and]]
one or more recommended actions generated by the set of event drivers (“Turning to FIG. 14B, the same screen shot 1400 is shown but with an added icon and text 1470. This comprises a warning symbol and text that reflects the speech condition that was detected for this checkpoint. This allows feedback to the agent to reinforce speech that is not desired for whatever reason. In this embodiment, the icon and text 1470 remains displayed until the agent acknowledges the alert,” Mammen et al., col. 35, lines 16-22.), and wherein the recommended action comprises generating at least one of a notification, a dashboard, or a report (Mammen et al., fig. 14B – screen presented to agent.);
receiving The display of the results could be a real-time indicator to the agent, and/or an end-of shift summary for the manager. Assuming that the manager is presented with a summary of all the agents, then the manager could provide further input to filter, qualify, or otherwise limit the results in operation 2525, which are displayed to the manager in operation 2530,” Mammen et al., col. 56, lines 33-38.); and
implementing the action to affect operation of contact center operations software for the contact center (“The display of the results could be a real-time indicator to the agent, and/or an end-of shift summary for the manager. Assuming that the manager is presented with a summary of all the agents, then the manager could provide further input to filter, qualify, or otherwise limit the results in operation 2525, which are displayed to the manager in operation 2530,” Mammen et al., col. 56, lines 33-38. Filtering the results is affecting an operation of contact center operations software.).
Mammen et al., though, does not disclose wherein the user input comprises a selected action from the one or more actions selected action to affect operation of contact center operations software for the contact center.
Dai et al. is cited to disclose wherein the user input comprises a selected action from the one or more actions (“An example, of an action is the next best action to be performed by an agent participating in a conversation. An action may represent determining a workflow to be performed in a given context within a conversation and recommending the workflow or recommending an action based on the workflow to an agent participating in the conversation. In an embodiment, the action module 250 includes a rule based system that triggers various actions based on result of AI analysis. For example, a rule may specify that if the intent has a specific value, certain workflow is triggered. A rule may specify that if the sentiment has a specific value, specific types of responses are generated,” Dai et al., para [0037]. And, “As shown in FIG. 5B, the user interface 505, the online system 100 initiates a workflow 520 based on the intent and shows the initiated workflow 515 to the agent. The agent confirms the workflow 520 to approve the workflow, for example, by clicking on the accept button 523,” Dai et al., para [0050]. See also Fig. 5B.)
implementing the selected action to affect operation of contact center operations software for the contact center (Dai et al., para [0037] and [0050]. See also Fig. 5B.). Dai et al. benefits Mammen et al. by allowing the recipient (i.e., agent) of communication recommendations to acknowledge the receipt of the recommendation and to implement the specific recommendations, thereby providing feedback to the conversation system that the agent is performing the recommended action. Therefore, it would be obvious for one skilled in the art to combine the teachings of Mammen et al. with those of Dai et al. to provide the contact center with feedback on its recommendations.
Regarding claim 9 (Currently Amended), Mammen et al., as modified by Dai et al., discloses the computer-implemented method of claim 8, wherein obtaining the set of event drivers comprises:
obtaining communication data associated with a communication (Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call.);
determining, for one or more data segments of the communication data that are associated with an event of the communication, a topic (Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call. Thus call (i.e., communication) data segments are associated with various alerts (i.e., events).); and
generating an event driver by generating an association between the determined topic and the event of the communication
Regarding claim 10 (Original), Mammen et al., as modified by Dai et al., discloses the computer-implemented method of claim 8, wherein the set of event drivers is obtained from a communication data store (“Each topic meta-data record stores information about the keyword detected during a call. Audio of the call itself may be stored separately, though it may be housed in a common processing system. The topic meta-data records contain information to provide the desired analysis of the keywords detected and also allow the appropriate snippets to be retrieved and played. A sample record structure is shown in FIG. 24. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40. Here, the record is a communication data store and contains alert triggers (i.e., event drivers). See also Mammen et al., fig. 24(2420).).
Regarding claim 11 (Original), Mammen et al., as modified by Dai et al., discloses the computer-implemented method of claim 8, wherein the event type is one of a system-driven event type, a context-driven event type, or a conversation-driven event type (“Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert. The next field is the “alert_id” field 2406, which is a numerical identifier of this particular alert. There may be more than one alert reported during a call, which accounts for there being more than one record per call,” Mammen et al., col. 54, lines 30-40. Here, the alert is a conversation-driven (i.e., call-driven) event.).
Regarding claim 12 (Original), Mammen et al., as modified by Dai et al., discloses the computer-implemented method of claim 8, wherein the indication is received in response to a recommendation that was generated based on the set of event drivers (Mammen et al., col. 35, lines 16-22.).
Regarding claim 13 (Original), Mammen et al., as modified by Dai et al., discloses the computer-implemented method of claim 8, wherein the set of event drivers is a first set of event drivers, and the report includes a comparison between the first set of event drivers and a second set of event drivers that are associated with a different time period than the first set of event drivers (Mammen et al., col. 54, lines 30-40. Here, a call may be analyzed and a report issued for each alert (i.e., event) in the course of the call, thereby providing a composite report for the call. Thus call (i.e., communication) data segments are associated with various alerts (i.e., events).).
Claim(s) 5 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9936066, hereinafter referred to as Mammen et al., in view of US 20220392451, hereinafter referred to as Dai et al., and further in view of US 20230315998, hereinafter referred to as Sundaram et al.
Regarding claim 5 (Original), Mammen et al., as modified by Dai et al., discloses the system of claim 1, wherein the set of topics is generated by using a topic identification model to generate a topic for each data segment of the set of data segments (“As described above, the topic meta-data file 2305 is populated by the RTSA system as a result of detecting keywords. This information may then be retrieved by the TMDAM and analyzed as appropriate. Each topic meta-data record stores information about the keyword detected during a call. Audio of the call itself may be stored separately, though it may be housed in a common processing system. The topic meta-data records contain information to provide the desired analysis of the keywords detected and also allow the appropriate snippets to be retrieved and played. A sample record structure is shown in FIG. 24. Turning to FIG. 24, the record structure 2400 begins with the call detail record (“CDR”) 2402, which is an identifier of the particular call involved. There may be more than one record generated per call, though each record would then reference the same CDR value. The next field is the “topic_name” field 2404, which is the human-readable name given for the particular topic that is associated with the alert,” Mammen et al., col. 54, lines 19-36.).
Mammen et al., though, does not explicitly disclose using a topic identification model to generate the topic(s). Sundaram et al. is cited to disclose using a topic identification model to generate the topic(s) (“The mined topics can be used to visualize trends in conversation topics, for example, as part of a topic dashboard component of an operations dashboard in a contact center. Further, the mined topic can be used to train machine learning models to more effectively spot topics in historical and real-time conversations,” Sundaram et al., para [0049].). Sundaram et al. benefits Mammen et al. by using the information mined from conversations in plethora of scenarios to enhance customer satisfaction, agent performance, and contact center operations (Sundaram et al., para [0049]). Therefore, it would be obvious for one skilled in the art to combine the teachings of Mammen et al. with those of Sundaram et al. to combine the teachings of Mammen et al. with those of Sundaram et al. to improve the reviewing of telephone call recordings in a contact center.
As to claim 18, CRM claim 18 and system claim 5 are related as system and CRM of using same, with each claimed element’s function corresponding to the system step. Accordingly claim 18 is similarly rejected under the same rationale as applied above with respect to system claim.
Claim(s) 7 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 9936066, hereinafter referred to as Mammen et al., in view of US 20220392451, hereinafter referred to as Dai et al., and in view of US 20220271962, hereinafter referred to as Patel et al.
Regarding claim 7 (Original), Mammen et al., as modified by Dai et al., discloses the system of claim 1, wherein the communication data is obtained from the communication data store (“Additionally, there may be a fourth call leg 223 from the call handler 120 to the file store 190. The file store may take a variety of forms, such as a file server, network file store, virtual file store, database, redundant array of interchangeable disks, archival storage, etc. The file store maintains storage of the speech of the call. As will be discussed later, the file store may store this information for a variety of formats, and allows selective retrieval of audio from an indicated call,” Mammen et al., col. 19, lines 6-14.).
Mammen et al., though, does not describe inclusion of a transcript of the communication. Patel et al. is cited to disclose inclusion of a transcript of the communication (“In some embodiments, the intelligent meeting assistant system 206 may additionally, or alternatively, transcribe the audio portion of the recorded meeting (e.g., the last minute of the recorded meeting, the last twenty seconds of the recorded meeting, the last fifteen seconds of the recorded meeting, and/or the like),” Patel et al., para [0043].). Patel et al. benefits Mammen et al. by providing a portion of the recorded meeting for user review which can be helpful to the user, particularly if the user is unable to listen to the recording (Patel et al., para [0043].). Therefore, it would be obvious for one skilled in the art to combine the teachings of Mammen et al. with those of Patel et al. to improve the reviewing of telephone call recordings in a contact center.
As to claim 20, CRM claim 20 and system claim 7 are related as system and CRM of using same, with each claimed element’s function corresponding to the system step. Accordingly claim 20 is similarly rejected under the same rationale as applied above with respect to system claim.
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 ANNE L THOMAS-HOMESCU whose telephone number is (571)272-0899. The examiner can normally be reached on Mon-Fri 8-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bhavesh Mehta can be reached on 5712727453. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANNE L THOMAS-HOMESCU/Primary Examiner, Art Unit 2656
Prosecution Insights