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 .
DETAILED ACTION
Claims 1-2, 4-9, 11-16, and 18-20 are pending. Claims 1, 8 and 15 are independent and are amended.
This Application was published as U.S. 20250159079.
Apparent priority: 14 November 2023.
Applicant’s amendments and arguments are considered but are either unpersuasive or moot in view of the new grounds of rejection.
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 2/6/2026 has been entered.
Response to Amendments and Argument
Applicant’s arguments are moot in view of the new grounds of rejection.
Independent Claim 1 is amended as follows (and the other independent Claims 8 and 15, similarly):
1. A system for conversion of real-time voice logs to user interface logs for debugging of Interactive Voice Response (IVR) interactions, comprising:
at least one processing device;
at least one memory device; and
a module stored in the at least one memory device comprising executable instructions that when executed by the at least one processing device, cause the at least one processing device to:
determine that a user has initiated a real-time voice interaction with a voice interaction processing platform associated with an entity;
generate a real-time voice log associated with the real-time voice interaction, wherein the real-time voice log comprises voice interactions between the user and the voice interaction platform, wherein the real-time voice log is a Voice Extensible Markup Language (VXML) log file;
parse the real-time voice log, via a real-time parser, by reading and processing the Voice Extensible Markup Language (VXML) log file;
convert, in real-time via a real-time converter, the parsed voice log to a real-time user interface log;
identify a role associated with the user within the entity in real-time based on unique user identification information provided by the user during the real-time voice interaction;
determine a type of role;
generate a real-time user interface comprising the real-time user interface log based on the type of the role associated with the user identified in real-time; and
display the real-time user interface comprising the real-time user interface log to the user for debugging the real-time voice interaction.
Applicant refers to [0047]-[0048] as Support for the amendments. These paragraphs and additional ones are provided in the Conclusion section for reference.
Applicant’s arguments are along two lines:
1) The added VXML log file is not taught by the references. (Response 10).
2) Identifying the user role based on the identification information provided by the user during the real-time voice interaction is not taught by the references. (Response 10).
In Reply to (1): VXML is a well-known file format for storing and conveying voice and for generating voice interfaces and as a general rule cannot help a claim toward allowability.
In Reply to (2), the previously cited Bhargava clearly taught that the role of the user is determinative in the GUI generated and presented by the system. Current amendments add that the role is determined based on user identification. Previously cited Lingam teaches that the role of the user was determined based on the identification information of the user either provided in his profile or directly by him.
One feature of identifying the user role is the real-time nature of it which was emphasized in the primary reference Gao which includes 26 occurrences of real-time in 10 pages of specification.
While 4 references are combined, the last two are to teach that the user role is determined from his ID and that the files are in VXML. Gao and Bhargava teach the main part of the Claim with significant overlap.
Consider including the substance of [0048] of the Specification that is highlighted below into the independent Claims.
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, 5-8, 12-15, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gao (U.S. 10212283) in view of Bhargava (U.S. 20240028934) and further in view of Dean (U.S. 20020152244) and Polcyn (U.S. 20070203708).
Regarding Claim 1, Gao teaches:
1. A system for conversion of real-time voice logs to user interface logs for debugging of Interactive Voice Response (IVR) interactions, comprising:
at least one processing device; [Gao. Figure 7, “processor 701.”]
at least one memory device; and [Gao. Figure 7, “Non-Volatile Memory 707.”]
a module stored in the at least one memory device comprising executable instructions that when executed by the at least one processing device, cause the at least one processing device to: [Gao. Figure 7, “Call logging/Monitoring Tool 709.”]
determine that a user has initiated a real-time voice interaction with a voice interaction processing platform associated with an entity; [Gao. Figure 1, “IVR Call Handler 110.” Figure 3, “place call to IVR telephone number 310.” “Interactive voice response (“IVR”) units (or simply “IVRs”) are commonly used in contact centers to receive a call, play an announcement to the caller, present the caller with a set of menu options, and frequently collect a caller response to a menu option….” 1:5-11. “Once the CLDT is configured to monitor the IVR application (specifically, the IVR Menu Control module), a call can be placed to the telephone number associated with the IVR in operation 310. Typically, the developer uses a telephone in close proximity to the computer, so that the developer can both call the IVR using the telephone and view in real time the values of the variables presented by the CLDT, as represented in operation 315….” 9:23-30.] associated with an entity; [Gao Figure 2 shows the IVR menu at a banking entity contact center: “This IVR call flow 200 shows a simplified call flow for a banking customer service application, which allows the caller (in part) to check the balance of their savings account and/or checking accounts, in addition to certain other functions, such as requesting to speak to an agent.” 5:33-38.]
generate a real-time voice log associated with the real-time voice interaction, [Gao. Figure 1, “IVR Call logging and Debugging Tool 125.” Figure 3, “Monitor IVR variables/logs displayed 315.” “A call monitoring and debugging tool is disclosed that allows a developer to test an interactive voice response (“IVR”) application comprising a plurality of menu modules. The developer can initiate a call to the IVR and is presented on a computer display a set of variable identifies and corresponding values used by the IVR application in real time…. The developer can also view a current set of variable identifiers used by the IVR and their corresponding values in real time….” Abstract.] wherein the real-time voice log comprises voice interactions between the user and the voice interaction platform, wherein the real-time voice log is a Voice Extensible Markup Language (VXML) log file; [Gao. Figure 2 showing the interaction of the user with the IVR of a bank. “An example of a menu structure …. Turning to FIG. 2, an example of a very limited portion of a hypothetical IVR call flow is shown. This IVR call flow 200 shows a simplified call flow for a banking customer service application, which allows the caller (in part) to check the balance of their savings account and/or checking accounts, in addition to certain other functions, such as requesting to speak to an agent. ….” 5:29-45.]
parse the real-time voice log, via a real-time parser, by reading and processing the Voice Extensible Markup Language (VXML) log file; [Gao takes into account the type of question and picks the location in the IVR menu based on the question and while does not expressly include the term “parse” this process at the least suggests the parsing of the call log: “Turning to FIG. 2, an incoming call 201 is logically represented as reaching the IVR at an initial menu module. This situation may be referred to as the “IVR receiving the call”, or may be referred to as “where the call enters the menu structure.” Because the overall menu structure comprises a grouping of menu modules, a call (or caller) can be referred to as “being” at a particular “location,” which refers to the relative menu module that is currently servicing the call. Thus, reference to terms such as “location” or “point” refer to the current menu module handling the call. Similarly, the “call” or “caller” can both be referred to as “being” in a particular location in the menu structure.” 6:4-15.]
convert, in real-time via a real-time converter, the parsed voice log to a real-time user interface log; [Gao. Figure 5 shows the “IVR Live Call Monitor and Debugger 500” shown on the GUI of the IVR CLDT including the “Interaction log 540” shown at the bottom of the screen.]
identify a role associated with the user within the entity in real-time based on unique user identification information provided by the user during the real-time voice interaction;
determine a type of role; [In Gao it is always the Developer who is looking at the call log to debug the IVR. Role = Developer.]
generate a real-time user interface comprising the real-time user interface log based on the type of the role associated with the user identified in real-time; and [Gao. Figure 5 shows the GUI of the IVR CLDT which is used for debugging. “As will be discussed below, the CLDT can in effect control the rate at which the IVR Menu Control module steps through actions in a menu module. In this example, it is set to 10 seconds for each action, which allows the user that amount of time to view the values of the variables in real time before they may change.” 11:58-63. “While a user can test an IVR solely by interacting with the application using a telephone, the CLDT allows the user to test the IVR using a live call faster and more efficiently. The user can view in real time what any variable is set to, which announcement have been played, they can visually see where they are in the overall IVR menu structure and can directly control the navigation in ways that may not be allowed using the telephone.” 14:37-34.]
display the real-time user interface comprising the real-time user interface log to the user for debugging the real-time voice interaction. [Gao. Figure 1, “IVR Call logging and Debugging Tool 125” is connected to the “Computer 130.” Figure 3, “Monitor IVR variables/logs displayed 315.” “FIG. 3 illustrates, at a high level, a process 300 for using the CLDT to debug or monitor a live call to the IVR.” 9:13-14. Figure 5 shows the GUI of the IVR CLDT which is used for debugging. Cols. 11-14. “It should be evident that by using this debugging tool, the user can initiate an actual call into the IVR and observe the value of variables, the actions performed, view where the call is relative to the overall menu structure, and control how the call will be processing in the IVR. This provides sufficient tools for the user to debug or monitor the operation of a call in an IVR, while knowing what happens at each step in the IVR.” 14:4-11. “As a call progresses through the IVR modules (i.e., navigates through the menu structure), the value of the variables displayed in the variable viewing pane may change value. The variables displayed may be all the variables, or a subset of all the variables, depending on how the CLDT is configured. The current value of a variable is shown to the user along with the name of that variable, so the user can view the value of the variable at any given time. This allows the user to detect any anomalies or unexpected values during processing of the call. The user may invoke the “snapshot” function to capture values of interest.” 12:21-31. “The function pane 510 provides the user with the ability to invoke various functions related to the operation of the CLDT. One function is the “Snapshot” function 511 that allows the user to save the values of the variables in the IVR at an indicated moment in time. This is useful because it allows the user to selectively save the values when desired, which may be easier than reviewing a log of all the values over a time period to ascertain the value at a particular point.” 11:37-47. “…For debugging purposes, the user needs real-time visibility to the IVR's variables and actions. For monitoring purposes, the user may find the log more useful.” 9:7-11.]
Gao teaches the conversion of the IVR voice interaction to text that is shown on a GUI to the user (Who is always the Developer) as shown in Figure 5 of Gao. Gao does not teach identifying the role of a user as designer, developer, etc.
Bhargava teaches:
1. A system for conversion of real-time voice logs to user interface logs for debugging of Interactive Voice Response (IVR) interactions, comprising:
at least one processing device;
at least one memory device; and
a module stored in the at least one memory device comprising executable instructions that when executed by the at least one processing device, cause the at least one processing device to:
determine that a user has initiated a real-time voice interaction with a voice interaction processing platform associated with an entity; [Bhargava is directed to “conversations” which may be chats as opposed to voice calls but does include: “[0064] … In some embodiments, the system implements a chatbot or interactive voice response (IVR) where the system goes through some standard sequence (e.g., based on human direction). However, the system figures out who particular calls (e.g., recommended actions) should go to and then directs messages in the chat directly to the target users.” Voice interaction of IVR is inherently real-time. “[0015] The message processing system 110 utilizes various information stored in the message database 108 for guiding intelligent conversational artificial intelligence (AI) that involves user approval and intervention. Such conversational AI may include chats or conversations with computer-generated notifications that include, for example, instructions for performing servicing of the IT assets 106 in the IT infrastructures 105. In some embodiments, the message processing system 110 is used for an enterprise system. For example, an enterprise may subscribe to or otherwise utilize the message processing system 110 for processing computer-generated notifications (e.g., generated by ones of the IT assets 106) within conversational AI chats or conversations. The conversational AI chats or conversations are then provided to target users (e.g., of client devices 102) for playback to facilitate servicing of the IT assets 106.”] (Note that the instant Application pertains to IVR: “Embodiments of the present invention provide a system for conversion of real-time voice logs to user interface logs for debugging of Interactive Voice Response (IVR) interactions….” Abstract.)
generate a real-time voice log associated with the real-time voice interaction, wherein the real-time voice log comprises voice interactions between the user and the voice interaction platform, wherein the real-time voice log is a Voice Extensible Markup Language (VXML) log file; [Bhargava, the voice log file of the Claim is taught by “message flow” of Bhargava. Figure 2, 200. “[0038] … The process begins with step 200, identifying one or more message flows. A given one of the one or more message flows comprises two or more messages associated with management of a given one of the IT assets 106 in the IT infrastructure 105.” See also “[0062]… For a “developer” role, more context may be provided on the technical details that will be useful for debugging (e.g., collect logs and provide them)….” See also “message database 108” of Figure 1.]
parse the real-time voice log, via a real-time parser, by reading and processing the Voice Extensible Markup Language (VXML) log file; [Bhargava, the voice log file of the Claim is taught by “message flow” of Bhargava. Figure 2, 202. “[0039] In step 202, the given message flow is parsed to identify one or more branches in a sequence of the two or more messages….”]
convert, in real-time via a real-time converter, the parsed voice log to a real-time user interface log; [Bhargava, Figure 5, 501: “determine urgency” and 503: present options to user.” The operation is not necessarily real-time because it is based on an urgency. “[0015] … The conversational AI chats or conversations are then provided to target users (e.g., of client devices 102) for playback to facilitate servicing of the IT assets 106.” “[0063] FIG. 5 shows a process flow 500 for execution of a conversational AI chat for one or more input notifications 510, with the conversational AI chat taking place between a machine 515 (e.g., that is to be serviced) and a user device 520 (e.g., of a user responsible for servicing the machine 515). In step 501, the machine 515 determines and communicates an urgency (e.g., a “need-by” time or ETA for responding to the notifications 510) to the user device 520….”]
identify a role associated with the user within the entity in real-time based on unique user identification information provided by the user during the real-time voice interaction; [Bhargava teaches that the user skill and role is determined based on his responses to the conversational AI. Figure 1, “role classification and association logic 114.” Figure 5, 504. “[0063] .. In step 504, the machine 515 analyzes user responses in the chat to determine the user's skill level (e.g., which may be used to update or adjust the options presented and/or the content of messages sent to the user during the conversation)….”]
determine a type of the role; and [Bhargava, “[0049] The technical solutions described herein may also utilize a role classification engine to identify the roles of different users. Based on the action to be performed by the user, the role classification engine will identify the role of the user and classify the user as belonging to one or more user groups. Such role classification may be based at least in part on user activity performed for certain actions, in response to detecting various events, etc. Based on this and other information, users may be classified into user groups (e.g., developer, manager, product manager, executive, etc.). The DAGs thus go through continuous learning and updates.” Note that the roles taught by Bhargava pertain to roles of people within an organization or entity. “[0066] The technical solutions described herein enable an organization or other enterprise to improve the productivity of its employees or other users. The technical solutions can be deployed across a variety of products, including support products that provide support for service engineers in data centers. Such support products may include cloud-based support tools.”
PNG
media_image1.png
362
534
media_image1.png
Greyscale
]
generate the real-time user interface based on the type of the role associated with the user identified in real-time, and [Bhargava: Figure 5, 505: “[0063] … In step 505, the machine 515 informs the user device 520 of a recommended action and waits for the user of the user device 520 to complete that recommended action….” “[0062] The level of detail to be presented to the user during a particular chat or conversation may vary, such as based on the skill level or role of the user. For a “need to know” or “higher authority basis” role, more details may be obtained for business level decision making (e.g., involving time, effort, next potential action, etc.). For “low skill” (e.g., manager) versus “high skill” (e.g., technologist) roles, more details on context may be provided for low skill users to help such users' understanding, whereas high skill users may be given the actual problem in a crisp and succinct manner. For a “developer” role, more context may be provided on the technical details that will be useful for debugging (e.g., collect logs and provide them). The level of detail may also include providing an initial hypothesis of the problem (e.g., a user interface bug).”]
display the real-time user interface comprising the real-time user interface log to the user for debugging the real-time voice interaction. [Bhargava, Figure 5, 503 and 505,506, 507 are all presentations to the user for debugging before and after the user has suggested an action. “[0063] … Once a branch in the DAG is reached, the machine 515 in step 503 presents options to the user device 520 (e.g., rankings of the different paths that may be followed from that branch). … In step 505, the machine 515 informs the user device 520 of a recommended action and waits for the user of the user device 520 to complete that recommended action. In step 506, the machine 515 analyzes the response(s) in the chat to look ahead for potential rejection or failure, and to inform the user beforehand. In step 507, the machine 515 escalates (e.g., to a higher level user) if actions are not performed on time, if all paths of the DAG are exhausted and issues still exist, etc.”]
Gao and Bhargava pertain to debugging IVR systems and it would have been obvious to add the parsing of the voice log from Bhargava with the system of Gao which likely includes the same step but does not expressly state it to arrive at an IVR debugger from voice logs. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Taking into account the role of the caller within the organization /entity is not taken into account by the above references.
Dean teaches:
identify a role associated with the user within the entity in real-time based on unique user identification information provided by the user during the real-time voice interaction; [Dean teaches that users are assigned roles which gives them access to different GUIs and that the user role is determined based on his identification. “[0169] When launching the GUI interface, the user enters a user name and password. Based on the roles assigned, the user is authorized to create certain types of documents. Only authorized document types appear in the user's GUI. For example, someone outside of accounting would not be authorized to create a bill.” “[0115] Users are assigned roles in the system and each role, in turn, is assigned specific document types. A user assigned to an edit role can only create or modify a document assigned to that role. When the user selects a document type to create or edit, the Content Editor 702 reads in the DTD and automatically constructs an interface based on that document structure. A user assigned to a publish role can only publish a document assigned to that role.”]
Gao/Bhargava and Dean pertain to IVR systems and it would have been obvious to modify the system of combination with the teachings of Dean such that the roles are tied to identifications of the users. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Because Gao/Bhargava and Dean pertain to IVR systems and deal with voice the use of VXML is natural.
Polcyn teaches:
parse the real-time voice log, via a real-time parser, by reading and processing the Voice Extensible Markup Language (VXML) log file; [Polcyn: “[0020] FIG. 1 is an overview of a prior art IVR system using a VoiceXML (VXML) browser. Application server 13 is typically responsible for the logic controlling the top level of the application. Server 13 provides a script to the browser. The script is a collection of mark-up statements (or process steps) that are provided to the browser in response to requests from the browser. This script could be, for example, a series of audio prompts, and voice (or DTMF) recognition requests. Assuming a voice recognition request, the voice recognition will be performed by speech server 12 in response to a request from the browser, which, in turn, operates from the script provided from the application server. Note that while the VXML protocol is discussed herein, any protocol, such as Speech Application Language Tags (SALT), mark-ups, api access, etc., can be used.” “[0008] In addition to logging commands that pass from device to device it is necessary to also log the audio spoken by the user in response to a prompt and to be able to associate that audio file with the recognition event that analyzed the utterance, and with the commands and status that were sent pertaining to this particular audio file. …”]
Gao/Bhargava/Dean and Polcyn pertain to IVR systems and it would have been obvious to modify the system of combination with the teachings of Polcyn to use VXML files for the voice logs as one known type of file for this application. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Regarding Claim 5, Gao teaches:
5. The system according to claim 1, wherein the real-time voice interaction is associated with a first voice flow. [Gao teaches a voice flow that could be generated by the developer himself in order to debug the IVR program and this can be called the “first voice flow”: “A call monitoring and debugging tool is disclosed that allows a developer to test an interactive voice response (“IVR”) application comprising a plurality of menu modules. The developer can initiate a call to the IVR and is presented on a computer display a set of variable identifies and corresponding values used by the IVR application in real time. The developer can view a graphical representation of a subset of the plurality of menu modules and view a representation of the navigation of the caller through the IVR application. The developer can also view a current set of variable identifiers used by the IVR and their corresponding values in real time. Finally, the developer can invoke one of several navigation control functions to force navigation of the call in the IVR application, including forcing the call to a previously encountered menu module.” Abstract.]
Regarding Claim 6, Gao teaches:
6. The system according to claim 5, wherein the executable instructions cause the at least one processing device to allow the user to initiate a second voice flow after completion of the first voice flow during the real-time voice interaction. [Gao does not include any limitations on the number of successive voice flows. The IVR call handler 110 of Figure 1 can handle several calls simultaneously but the call monitor with the GUI shown in Figure 5 can present the log of one call at a time.]
Regarding Claim 7, Gao teaches:
7. The system according to claim 1, wherein the executable instructions cause the at least one processing device to generate a real-time utterance transcription associated with the real-time voice interaction. [Gao, Figure 5: “Finally, the log viewing pane 540 displays a log of the actions performed by a menu module. These actions may involve processing inputs, playing announcements, querying a source for information, etc. Whatever the actions that are defined in a menu module can be recorded in the log allowing the user to review the actions taken. In the example shown in FIG. 5, a first label 541 indicates the name of the current module. The next line 542 indicates that an announcement was played, and replicates in text the substance of the announcement. The next line 543 indicates an input was received, and its value. The next line 544 also indicates an announcement was played, and the last line 545 reflects the caller's response. If more lines need to be reviewed, the “open window” function 546 allows a separate and larger window to be used for viewing the logged results. In other embodiments, the logged results can be exported as a file, which can be reviewed using conventional editors or similar application programs.” 13:53 to 14:3.]
Claim 8 is a computer program product system claim with limitations corresponding to the limitations of method Claim 1 and is rejected under similar rationale.
Claim 12 is a computer program product system claim with limitations corresponding to the limitations of method Claim 5 and is rejected under similar rationale.
Claim 13 is a computer program product system claim with limitations corresponding to the limitations of method Claim 6 and is rejected under similar rationale.
Claim 14 is a computer program product system claim with limitations corresponding to the limitations of method Claim 7 and is rejected under similar rationale.
Claim 15 is a method claim with limitations corresponding to the limitations of Claim 1 and is rejected under similar rationale.
Claim 19 is a method claim with limitations corresponding to the limitations of Claim 5 and is rejected under similar rationale.
Claim 20 is a method claim with limitations corresponding to the limitations of Claim 6 and is rejected under similar rationale.
Claims 2, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Gao, Bhargava, Dean, Polcyn in view of Shrestha (U.S. 20240195687).
Regarding Claim 2, Gao teaches:
2. The system according to claim 1, wherein the executable instructions cause the at least one processing device to:
automatically identify, via an artificial intelligence engine, an error associated with the real-time voice interaction; [Gao’s system is used to dipsy the log including errors which are identified by the designer who is monitoring the logs and corrected by him as shown in Figure 3, 315 monitoring by the developer and 320 input provided by the developer, Figure 4, and 5. “In many instances, the IVR may have a sophisticated menu structure, providing for various levels of menus. This structure may reflect normal (e.g., non-error) user interactions with the IVR. In addition, the IVR may be programmed to account for each of the various possible types of errors that a user may cause during a call. Such errors may include entering a non-allowed input, entering a series of digits too quickly, waiting too long to respond to a prompt, etc.” 1:15-23.]
generate one or more recommendations, via the artificial intelligence engine; and
display the error and the one or more recommendations in the real-time user interface log.
Gao permits the developer/user to debug the IVR using the voice log that is presented to him on a GUI. Gao does not include another system that recommends the corrections.
Polcyn teaches: “[0016] FIG. 3 shows an embodiment of the invention as used for manual correction of recognition errors;”
Gao, Bhargava, Dean, Polcyn do not teach the use of AI to generate the corrections.
Shrestha teaches:
automatically identify, via an artificial intelligence engine, an error associated with the real-time voice interaction; [Shrestha, “[0176] These capabilities are shown in FIG. 13, which presents a drawing illustrating an example of communication between components in computer system 104 (FIG. 1). In FIG. 13, an intelligence engine (which may be implemented using artificial intelligence and/or machine learning) in computer system 104 may selectively invoke dynamic collection of additional (detailed) data when certain network problems occur, and may take corrective and/or avoidance actions based at least in part on the additional data.”
generate one or more recommendations, via the artificial intelligence engine; and [Shrestha, Figure 2, “detect a network problem 212” and “determine a recommended configuration change 214.” “[0177] Notably, the intelligence engine may use artificial intelligence and/or machine learning to collect distributed data from the intermediate or edge electronic devices. This intelligence engine may be centralized or distributed and may be implemented in a local computer system and/or a cloud-based computer system. Using the data from edge electronic devices, the intelligence engine may confirm or detect an anomaly. Then, the intelligence engine may enable electronic devices in specific functional area(s) or region(s) by sending control and management triggers that will instantiate or activate agents in these electronic devices to collect the additional (detailed) data.” “[0171] Artificial intelligence/machine learning-based insights may be implemented using analytical services and tools in a network. These capabilities may allow users to get the details about anomalies in their deployed network….” “[0174] However, there are many scenarios where corrective or avoidance actions taken on electronic devices in a network (such as on access points, switches, routers, controllers and/or data planes) may overcome a fault and/or may prevent a subsequent instance of the fault. Notably, intelligence may be provided using artificial intelligence/machine-learning techniques to aid these electronic devices (e.g., via secure messaging) to mitigate or overcome a network problem and/or to make sure that the network problem does not reoccur. For example, corrections for detected incidents or anomalies and/or mitigation or avoidance of future incidents or anomalies may be implemented by sending feedback or a remedial action to particular electronic devices….”]
display the error and the one or more recommendations in the real-time user interface log. [Shrestha: “[0001] The described embodiments relate to techniques for dynamically assessing communication performance in a network and selectively providing remediation recommendations (such as a configuration change) to improve the communication performance or to prevent an occurrence of a network problem. Alternatively or additionally, the described embodiments relate to an interactive user interface that allows a user or an operator of a network to dynamically assess communication performance of the network.” “[0011] Additionally, the computer system may provide the recommended configuration change, e.g., in a user interface. Then, the computer system may receive user-interface activity specifying a user selection associated with the recommended configuration change. In response to the user selection, the computer system may implement the recommended configuration change.”]
Gao, Bhargava, Dean, Polcyn and Shrestha pertain to or include the use of IVR systems and it would have been obvious to modify the system of combination to include the AI implemented debug method of Shrestha as a more advanced method. (Shrestha: “[0174] … The artificial intelligence/machine-learning feedback and/or corrective system may significantly improve a mean time to repair (MTTR). These capabilities may improve the user experience, which may be important for market segments such as hospitality, restaurants, etc.”) This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Claim 9 is a computer program product system claim with limitations corresponding to the limitations of method Claim 2 and is rejected under similar rationale.
Claim 16 is a method claim with limitations corresponding to the limitations of Claim 2 and is rejected under similar rationale.
Claims 4, 11, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gao, Bhargava, Dean, Polcyn in view of Patel (U.S. 20080088698).
Regarding Claim 4, Gao, Bhargava, Dean, Polcyn do not discuss masking of the callers or users personal data.
Patel teaches:
4. The system according to claim 1, wherein the executable instructions cause the at least one processing device to:
identify unique identification information provided by the user during the during the real-time voice interaction; and [Patel, Figure 3 shows that the conference participant who may be coming through an IVR is providing his identification information 33. Figure 4, 46: system queries participant for his/her identity. “[0015] In the embodiment shown, video conference server 20 includes a digital signal processor (DSP) or firmware/software-based system that mixes and/or switches audio/video signals received at its input ports under the control of server 20. The audio/video signals received at the conference server ports originate from each of the conference or meeting participants (e.g., individual conference participants using endpoint devices 12 & 14), and possibly from an interactive voice response (IVR) system (not shown). ….”]
mask the unique identification information associated with the user provided during the real-time voice interaction. [Patel, “[0025] In another embodiment, the actual contact details such as IM, telephone number, or email address of one or more conference participants may be suppressed or hidden from view during certain types of conferences or meetings. For example, in a large conference call or public meeting individual participants may choose to keep their contact information private to all participants. Additionally, certain participants (e.g., a CEO participating in a public briefing) may choose to disable user interface-initiated communications entirely. Both of these features may be implemented by a user preference setting that hides or masks identification information of that user during a conference session.”]
Gao, Bhargava, Dean, Polcyn and Patel pertain to or include the use of IVR systems and it would have been obvious to modify the system of combination to include the masking of the PII in order to keep the information of callers confidential from the developers or designers of the IVR system. This combination falls under combining prior art elements according to known methods to yield predictable results or use of known technique to improve similar devices (methods, or products) in the same way. See MPEP 2141, KSR, 550 U.S. at 418, 82 USPQ2d at 1396.
Claim 11 is a computer program product system claim with limitations corresponding to the limitations of method Claim 4 and is rejected under similar rationale.
Claim 18 is a method claim with limitations corresponding to the limitations of Claim 4 and is rejected under similar rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
VXML:
Plocyn (U.S. 20070203708):
[0019] FIG. 8 shows a portion of a VXML document giving an example of how correlation IDs could be embedded in the communication between the browser and the speech server.
Kulkarni (U.S. 10291776):
“A system for interactive voice response system crawling, comprising an IVR crawler that may be VXML, design specification, DTMF or ASR/NLSR speech-based in nature and traverses an IVR menu to discover possible interaction paths and produces test cases based on those paths, and a database that stores test cases produced by the IVR crawler during operation, and a method for using an IVR crawler to perform a system migration.” Abstract.
Komissarchik (U.S. 20170337923) adjusts a GUI according to the category of user and states that it can be used in Call centers and IVRs. “[0013] This invention can be used in multiple situations where a user talks to an electronic device. Areas such as Intelligent Assistant, Smartphones, Auto, Internet of Things, Call Centers, IVRs and voice-based CRMs are samples of applicability of the robust dialogs described in this invention.”, Figure 4 shows that the user is a Designer and Figure 5 shows that the user is a User. “[0074] The human-machine interface system 19 is designed to provide designer of voice-based dialog system feedback on what kind of changes the designer can make to improve quality of recognition and thus usability of the system being designed. The feedback is based on the idea.”, “[0010] In view of the aforementioned drawbacks of previously known systems and methods, the present invention provides a system and methods that anticipate what would be problematic in pronunciation and speech recognition for all users or for some categories of users and how to use this knowledge to build more robust user interface….”]
Applicant refers to [0047]-[0048] as Support for the amendments:
[0047] As shown in block 510, the system generates a real-time voice log associated with the real-time voice interaction. The real-time voice log may be a Voice Extensible Markup Language (VXML) log file, where the real-time voice log comprises voice interactions between the user and the voice interaction processing platform. In some embodiments, the real-time voice log may comprise other information including, but not limited to, type of channel to initiate the interaction, user information, unique identification information (e.g., Social Security Number, username, account number, employee ID number, password, access codes, or the like), user device information associated with the user device used to initiate the interaction, inputs provided by the user during the interaction, timestamps associated with the inputs, application server, IVR server information, caller ID, and/or the like. In some embodiments, where the user provides unique identification information (e.g., Social Security Number, or the like) or any other confidential information or sensitive information, the system identifies such information and masks the unique identification information, confidential information, sensitive information, and/or the like. In some embodiments, masking of information may be based on a role associated with the user. The system identifies the role associated with the user, determines a type of the role, and performs masking based on the type of the role. For example, the system may mask personal information for all users. In another example, the system may mask access codes for testers and designers. In some embodiments, the system may also identify availability of data for the user based on the type of the role for user.
[0048] As shown in block 515, the system parses the real-time voice log, via real-time parser. Parsing the real-time voice log comprises reading and/or processing the Voice Extensible Markup Language log file generated by the system in block 510. The system may parse the real-time voice log based on the type of the role associated with the user. For example, the system may parse only a first set of information, a second set of information, and a third set of information from the real-time voice log instead of processing the entire real-time voice log based on the role of the user testing a functionality associated with the voice interaction processing platform.
See also:
[0051] As shown in block 530, the system displays the real-time user interface comprising the real-time user interface log to the user for debugging the real-time voice interaction. In some embodiments, the system may display a modified real-time user interface to each user viewing the real-time user interface for debugging the real-time voice interaction. In some embodiments, the system identifies the role associated with the user, determines the type of the role, and generates the real-time user interface based on the type of the role associated with the user. For example, the system may determine, based on the unique user identification information provided by the user during the real-time voice interaction, that the user is an application developer, and may instantaneously modify the real-time user interface to create a custom user interface for application developers, wherein information displayed on the real-time user interface may comprise server ID, application server, IVR server information, version, logger statements call ID, Dialogue nodes, session ID, runtime errors, and/or the like. In another example, the system may determine, based on the unique user identification information provided by the user during the real-time voice interaction, that the user is an application designer, and may instantaneously modify the real-time user interface to create a custom user interface for application designers, wherein information displayed on the real-time user interface may comprise dialogue nodes, utterance ID, utterance, server name, call ID, language details, and/or the like. For example, the system may determine, based on the unique user identification information provided by the user during the real-time voice interaction, that the user is an application tester, and may instantaneously modify the real-time user interface to create a custom user interface for application testers, wherein information displayed on the real-time user interface may comprise call ID, call nodes, logging statements, prompts wording, dialogue nodes, application errors, and/or the like. In some embodiments, the system may generate a real-time utterance transcription associated with the real-time voice interaction and display the real-time utterance transcription in the real-time user interface.
[0054] … The selection engine 370 may select one or more parameters for processing the real-time voice interaction, where the one or more parameters may be based on the role of the user and the type of the role of the user….
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FARIBA SIRJANI whose telephone number is (571)270-1499. The examiner can normally be reached on 9 to 5, M-F.
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, Pierre Desir can be reached on 571-272-7799. 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.
/Fariba Sirjani/
Primary Examiner, Art Unit 2659