CROSS-REFERENCE TO RELATED DOCUMENTS This application is a Continuation of co-pending U.S. patent application Ser. No. 10/861,078, filed Jun. 04, 2004, the disclosure of which is incorporated by reference herein.
That application claims priority to Provisional Application Ser. No. 60/558,921, filed on Apr. 02, 2004, and is a Continuation In Part (CIP) of co-pending U.S. patent application Ser. No. 10/835,444, filed Apr. 28, 2004, the disclosures of which are also incorporated by reference herein. U.S. patent application Ser. No. 10/835,444 claims priority to Provisional Application Ser. No. 60/532,271, filed on Dec. 22, 2003, the disclosure of which is also incorporated by reference herein.
TECHNICAL FIELD The present invention is in the area of voice application software systems and pertains particularly to systems for developing and managing voice files linked for service to a voice application deployment system.
BACKGROUND A speech application is one of the most challenging applications to develop, deploy and maintain in a communications environment. Expertise required for developing and deploying a viable VXML application, for example, includes expertise in computer telephony integration (CTI) hardware and software or a data network telephony (DNT) equivalent, voice recognition software, text-to-speech software, and speech application logic.
With the relatively recent advent of voice extensive markup language (VXML) the expertise require to develop a speech solution has been reduced somewhat. VXML is a language that enables a software developer to focus on the application logic of the voice application without being required to configure underlying telephony components. Typically, the developed voice application is run on a VXML interpreter that resides on and executes on the associated telephony system to deliver the solution.
Voice prompting systems in use to day range from a simple interactive voice response system for telephony to the more state-of-art VXML application system known to the inventors. Anywhere a customer telephony interface may be employed, there may also be a voice interaction system in place to interact with callers in real time. Data network telephony (DNT) equivalents of voice delivery systems also exist like VoIP portals and the like.
Often in both VXML compliant and non-VXML systems, such as computer telephony integrated (CTI) IVRs, voice messaging services and the like, voice prompts are sometimes prerecorded in a studio setting for a number of differing business scenarios and uploaded to the enterprise system server architecture for access and deployment during actual interaction with clients. Pre-recording voice prompts instead of dynamically creating them through software and voice synthesis methods is many times performed when better sound quality, different languages, different voice types, or a combination of the above are desired for the presentation logic of a particular system.
In very large enterprise architectures there may be many thousands of prerecorded voice prompts stored for use by a given voice application. Some of these may not be stored in a same centralized location. One with general knowledge of voice file management will attest that managing such a large volume of voice prompts can be very complicated. For example, in prior-art systems management of voice prompts includes recording the prompts, managing identification of those prompts and manually referencing the required prompts in the application code used in developing the application logic for deployment of those prompts to a client interfacing system. There is much room for error in code referencing and actual development, recording, and sorting batches of voice files can be error prone and time consuming as well.
The inventor knows of a software interface for managing audio resources used in one or more voice applications. The software interface includes a first portion for mapping the audio resources from storage to use-case positions in the one or more voice applications, a portion for accessing the audio resources according to the mapping information and for performing modifications a portion for creating new audio resources; and a portion for replication of modifications across distributed facilities. In a preferred application a developer can modify or replace existing audio resources and replicate links to the application code of the applications that use them.
VXML-compliant and other types of voice systems may frequently need to be modified or updated, sometimes multiple times per day due to fast-paced business environments, rapidly evolving business models, special temporary product promotions, sales discounts and so on. For example, if a product line goes obsolete, existing voice prompts related to that product line that are operational in a deployed voice application may need to be modified, replaced or simply deleted. Moreover, configuration settings of a voice application interaction system may also need to be updated or modified from time to time due to addition of new hardware, software, and so on.
The software application mentioned above as known to the inventor for managing audio resources enables frequent modifications of existing voice applications in a much improved and efficient manner than in the current art. However, when changing over from an existing configuration to a new configuration the running voice application is typically suspended from service while the changes are implemented. Shutting down service for even a temporary period can result in monetary loss that can be significant depending on the amount of time the system will be shut down. In some cases a backup system may be deployed while the primary system is being reconfigured. However this approach requires more resources that would be required to run one application.
What is clearly needed is a software routine or application for facilitating a one-click or single-action deployment and implementation of voice application system changes.
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 is a logical overview of a voice interaction server and voice prompt data store according to prior-art.
FIG. 2 is a block diagram illustrating voice prompt development and linking to a voice prompt application according to prior art.
FIG. 3 is a block diagram illustrating a voice prompt development and management system according to an embodiment of the present invention.
FIG. 4 illustrates an interactive screen for a voice application resource management application according to an embodiment of the present invention.
FIG. 5 illustrates an interactive screen having audio resource details and dependencies according to an embodiment of the present invention.
FIG. 6 illustrates an interactive screen for an audio resource manager illustrating further details and options for editing and management according to an embodiment of the present invention.
FIG. 7 is a process flow diagram illustrating steps for editing or replacing an existing audio resource and replicating the resource to distributed storage facilities.
FIG. 8 is architectural overview of a communications network wherein automated voice application system configuration is practiced according to an embodiment of the present invention.
FIG. 9 is an exemplary screenshot illustrating application of modifications to a voice dialog according to an embodiment of the present invention.
FIG. 10 is a block diagram illustrating components of an automated voice application configuration application according to an embodiment of the present invention.
FIG. 11 is a process flow chart illustrating steps for receiving and implementing a change-order according to an embodiment of the present invention.
DETAILED DESCRIPTION The inventor provides a system for managing voice prompts in a voice application system. Detail about methods, apparatus and the system as a whole are described in enabling detail below.
FIG. 1 is a logical overview of a voice interaction server and voice prompt data store according to prior art.FIG. 2 is a block diagram illustrating voice prompt development and linking to a voice prompt application according to prior art. Avoice application system100 includes adeveloper101, a voicefile storage medium102, a voice portal (telephony, IVR)103, and one of possibly hundreds or thousands ofreceiving devices106.
Device106 may be a LAN-line telephone, a cellular wireless, or any other communication device that supports voice and text communication over a network. In this example,device106 is a plane old telephone service (POTS) telephone.
Device106 has access through a typical telephone service network, represented herein by avoice link110, to avoice system103, which in this example is a standard telephony IVR system.IVR system103 is the customer access point for callers (device106) to any enterprise hosting or leasing the system.
IVR103 has a database/resource adapter109 for enabling access to off-system data. IVR also hasvoice applications108 accessible therein and adapted to provide customer interaction and call flow management.Applications108 include the capabilities of prompting a customer, taking input from a customer and playing prompts back to the customer depending on the input received.
Telephony hardware andsoftware107 includes the hardware and software that may be necessary for customer connection and management of call control protocols.IVR103 may be a telephony switch enhanced as a customer interface byapplications108. Voice prompts executed withinsystem103 may include only prerecorded prompts. A DNT equivalent may use both prerecorded prompts and XML-based scripts that are interpreted by a text-to-speech engine and played using a sampled voice.
IVR system103 has access to a voicefile data store102 via adata link104, which may be a high-speed fiber optics link or another suitable data carrier many of which are known and available.Data store102 is adapted to contain prerecorded voice files, sometimes referred to as prompts. Prompts are maintained, in this example, in asection113 ofdata store102 adapted for the purpose of storing them. Avoice file index112 is illustrated and provides a means for searchingstore section113 to access files for transmission overlink104 toIVR system103 to be played by one ofapplications108 during interaction with a client.
In thiscase IVR system102 is a distributed system such as to a telephony switch location in a public switched telephone network (PSTN) and therefore is not equipped to store many voice files, which take up considerable storage space if they are high quality recordings.
Data store111 has a developer/enterprise interface111 for enabling developers such asdeveloper101 access for revising existing voice files and storing new and deleting old voice files from the data store.Developer101 may create voice applications and link stored voice files to the application code for each voice application created and deployed. Typically, the voice files themselves are created in a separate studio from script provided by the developer.
As was described with reference to the background section, for a large enterprise there may be many thousands of individual voice prompts, many of which are linked together in segmented prompts or prompts that are played in a voice application wherein the prompts contain more than one separate voice file. Manually linking the original files to the application code when creating the application provides enormous room for human error. Although the applications are typically tested before deployment, errors may still get through causing monetary loss at the point of customer interface.
Another point of human management is between the studio and the developer. The studio has to manage the files and present them to the developer in a fashion that the developer can manipulate in an organized fashion. As the number of individual prerecorded files increases, so does the complexity of managing those prerecorded files.
Referring now toFIG. 2,developer101 engages in voiceapplication development activity201. Typically voice files are recorded from script. Therefore, for aparticular application developer101 createsenterprise scripts202 and sends them out to a studio (200) to be recorded. An operator withinstudio200 receivesscripts202 and creates recorded voice files203. Typically, the files are single segments, some of which may be strategically linked together in a voice application to play as a single voice prompt to a client as part of a dialog executed from the point ofIVR103, for example.
The enterprise must insure that voice files203 are all current and correct and that the parent application has all of the appropriate linking in the appropriate junctions so that the files may be called up correctly during execution.Developer101uploads files203 when complete todata store102 and the related application may also be uploaded todata store102. When a specific application needs to be run at a customer interface, it may be distributed without the voice files to the point of interface, in thiscase IVR103. There may be many separate applications or sub-dialogs that use the same individual voice files. Often there will be many instances of the same voice file stored indata store102 but linked to separate applications that use the same prompt in some sequence.
FIG. 3 is an expanded view ofIVR103 ofFIG. 2 illustrating a main dialog and sub-dialogs of a voice application according to prior art. In many systems, amain dialog300 includes a staticinteractive menu301 that is executed as part of the application logic for every client that calls in. During playing ofmenu300, a client may provideinput302, typically in the form of voice for systems equipped with voice recognition technology. Asystem response303 is played according toinput302.
System response303 may include as options, sub-dialogs304(a-n). Sub-dialogs304(a-n) may link any number of prompts, or voice files305(a-n) illustrated logically herein for each illustrated sub-dialog. In this case prompt305bis used in sub-dialog304aand in sub-dialog304b.Prompt305cis used in all three sub-dialogs illustrated. Prompt305ais used in sub-dialog304band in sub-dialog304b.Prompts are created at the time of application creation and deployment. Therefore prompts305b, c,andjare stored in separate versions and locations for each voice application.
FIG. 4 illustrates aninteractive screen400 for a voice application resource management application according to an embodiment of the present invention.Screen400 is a GUI portion of a software application that enables a developer to create and manage resources used in voice applications. Resources include both audio resources and application scripts that may be voice synthesized. For the purpose of this example, the inventor focuses on management of audio resources, which in this case, include voice file or prompt management in the context of one or more voice file applications.
Screen400 takes the form of a Web browser type interface and can be used to access remote resources over a local area network (LAN), wide area network (WAN), or a metropolitan area network (MAN). In this example, a developer operating throughscreen400 is accessing a local Intranet.
Screen400 has atoolbar link403 that is labeled workspace.Link403 is adapted to open, upon invocation, a second window or changes the primary window to provide an area for working and audio management and creation tools for creating and working with audio files and transcripts or scripts.
Screen400 has atoolbar link404 that is labeled application.Link404 is adapted to open, upon invocation, a second window or changes the primary window to provide an area for displaying and working with voice application code and provides audio resource linking capability.Screen400 also has a toolbar link for enabling an administration view of all activity.
Screen400 hasadditional toolbar links406 adapted for navigating to different windows generally defined by label. Reading from left to right intoolbar options406, there is Audio, Grammar, Data Adapter, and Thesaurus. The option Audio enables a user to view all audio-related resources. The option Grammar enables a user to view all grammar-related resources. The option Data Adapter enables a user to view all of the available adapters used with data sources, including adapters that might exist between disparate data formats. The option Thesaurus is self-descriptive.
In this example, a developer has accessed the audio resource view, which provides inwindow409 aninteractive data list411 of existing audio resources currently available in the system.List411 is divided into two columns acolumn408 labeled “name” and acolumn410 labeled “transcript”. In this example there are three illustrated audio prompts reading from top to bottom fromlist411column408 they are “howmuch”, “mainmenu”, and “yourbalance”. An audio speaker icon next to each list item indicates the item is an audio resource and enable a developer to. Each audio resource is associated with the appropriate transcript of the resource as illustrated incolumn410. Reading from top to bottom incolumn410 for the audio resource “howmuch” the transcript is “How much do you wish to transfer?”. For “mainmenu”, the transcript is longer, therefore it in not reproduced in the illustration but may be assumed to be provided in full text. A scroll function may be provided to scroll a long transcript associated with an audio resource. For the audio resource “yourbalance”, the transcript is “Your balance is [ ]. The brackets enclose a variable used in a voice system prompt response to a client input interpreted by the system.
In one embodiment there may be additional options forviewing list411, for example, separate views ofdirectory411 may be provided in different languages. In one embodiment, separate views ofdirectory411 may be provided for the same resources recorded using different voice talents. In the case of voice files that are contextually the same, but are recorded using different voice talents and or languages, those files may be stored together and versioned according to language and talent.
Window409 can be scrollable to reach any audio resources not viewable in the immediate screen area. Likewise, in some embodiments a left-side navigation window may be provided that contains both audio resource andgrammar resource indexes401 and402 respectively to enable quick navigation through the lists. Aresource search function411 is also provided in this example to enable keyword searching of audio and grammar resources.
Screen400 has operational connectivity to a data store or stores used to where house the audio and grammar resources and, in some cases, the complete voice applications. Management actions initiated through the interface are applied automatically to the resources and voice applications.
A set oficons407 defines additional interactive options for initiating immediate actions or views. For example, accounting from left to right a first icon enables creation of a new audio resource from a written script. Invocation of this icon brings up audio recording and editing tools that can be used to create new audio voice files and that can be used to edit or version existing audio voice files. A second icon is a recycle bin for deleting audio resources. A third icon ingrouping407 enables an audio resource to be copied. A fourth icon ingrouping407 enables a developer to view a dependency tree illustrating if where and when the audio file is used in one or more voice dialogs. The remaining two icons are upload and download icons enabling the movement of audio resources from local to remote and from remote to local storage devices.
In one embodiment of the present invention, the functions of creating voice files and linking them to voice applications can be coordinated throughinterface400 by enabling an author of voice files password protected local or remote access for downloading enterprise scripts and for uploading new voice files to the enterprise voice file database. By marking audio resources inlist410 and invoking theicon407 adapted to view audio resource dependencies, an operator calls up a next screen illustrating more detail about the resources and further options for editing and management as will be described below.
Screen400, in this example, has and audioindex display area401 and a grammardisplay index area402 strategically located in a left scrollable sub-window ofscreen400. As detailed information is viewed for a resource inwindow409, the same resource may be highlighted in the associatedindex401 or402 depending on the type of resource listed.
FIG. 5 is illustrates aninteractive screen500 showing audio resource details and dependencies according to an embodiment of the present invention.Screen500 has a scrollablemain window501 that is adapted to display further details about audio resources previously selected for view.Previous options406 remain displayed inscreen500. In this example each resource selected inscreen400 is displayed in list form. In thisview audio resource504 has a resource name “howmuch”. Theresource504 is categorized according to Dialog, Dialog type, and where the resource is used in existing voice applications. In the case ofresource504, the dialog reference is “How Much”, the resource type is a dialog, and the resource is used in a specified dialog prompt. Only one dependency is listed foraudio resource504, however all dependencies (if more than one) will be listed.
Resource505, “mainmenu” has dependency to two main menus associated with dialogs. In the first listing the resource is used in a standard prompt used in the first listed dialog of the first listed main menu. In the second row it is illustrated that the same audio resource also is used in a nomatch prompt used in a specified dialog associated with the second listed main menu. For the purpose of this specification a nomatch prompt is one where the system does not have to match any data provided in a response to the prompt. A noinput prompt is one where no input is solicited by the prompt. It is noted herein that for a general application prompt definitions may vary widely according to voice application protocols and constructs used. The dependencies listed forresource505 may be associated with entirely different voice applications used by the same enterprise. They may also reflect dependency of the resource to two separate menus and dialogs of a same voice application.
No specific ID information is illustrated in this example, but may be assumed to be present. For example, there may be rows and columns added for displaying a URL or URI path to the instance of the resource identified. Project Name, Project ID, Project Date, Recording Status (new vs. recorded), Voice Talent, and Audio Format are just some of the detailed information that may be made available inwindow501. There may be a row or column added for provision of a general description of the resource including size, file format type, general content, and so on.
Resource506, “yourbalance” is listed with no dependencies found for the resource. This may be because it is a newly uploaded resource that has not yet been linked to voice application code. It may be that it is a discarded resource that is still physically maintained in a database for possible future use. The lack of information tells the operator that the resource is currently not being used anywhere in the system.
Screen500, in this example, has audioindex display area401 and a grammardisplay index area402 strategically located in a left scrollable sub-window ofscreen500 as described with reference to screen400 ofFIG. 4 above. As detailed information is viewed for a resource inwindow501, the same resource may be highlighted in the associatedindex401 or402 depending on the type of resource listed.
FIG. 6 illustrates aninteractive screen600 of an audio resource manager illustrating further details and options for editing and management according to an embodiment of the present invention.Screen600 enables a developer to edit existing voice files and to create new voice files. Adialog tree window602 is provided and is adapted to list all of the existing prompts and voice files linked to dialogs in voice applications. The information is, in a preferred embodiment, navigable using a convenient directory and file system format. Any voice prompt or audio resource displayed in themain window601 is highlighted in the tree ofwindow602.
In one embodiment of the present invention fromscreen500 described above, a developer can download a batch of audio resources (files) from a studio remotely, or from local storage and can link those into an existing dialog, or can create a new dialog using the new files. The process, in a preferred embodiment, leverages an existing database program such as MS Excel™ for versioning and keeping track of voice prompts dialogs, sub-dialogs, and other options executed during voice interaction.
In one embodiment of the present invention a developer can navigate using the mapping feature through all of the voice application dialogs referencing any selected voice files. In a variation of this embodiment the dialogs can be presented in descending or ascending orders according to some criteria specified like date, number of use positions, or some other hierarchical specification. In still another embodiment, a developer accessing an audio resource may also have access to any associated reference files like coaching notes, contextual notes, voice talent preferences, language preferences, and pronunciation nuances for different regions.
In a preferred embodiment, using the software of the present invention multiple links do not have to be created to replace an audio resource used in multiple dialog prompts of one or more voice applications. For example, after modifying a single voice file, one click may cause the link to the stored resource to be updated across all instances of the file in all existing applications. In another embodiment where multiple storage sites are used, replication may be ordered such that the modified file is automatically replicated to all of the appropriate storage sites for local access. In this case, the resource linking is updated to each voice application using the file according to the replication location for that application.
Screen600 illustrates a prompt604 being developed or modified. The prompt in this example is named “Is that correct?” and has variable input fields of City and State. The prompt604 combines audio files to recite “You said [City: State]:: If that is correct, say Yes: If in correct, Say No: The prompt may be used in more than one dialog in more than one voice application. The prompt may incorporate more than one individual prerecorded voice file.
Awindow605 contains segment information associated with the prompt “Is that correct?” such as the variable City and State and the optional transcripts (actual transcripts of voice files). New voice files and transcripts describing new cities and states may be added and automatically liked to all of the appropriate prompt segments used in all dialogs and applications.
Typically, audio voice files of a same content definition, but prerecorded in one or more different languages and/or voice talents will be stored as separate versions of the file. However, automated voice translation utilities can be used to translate an English voice file into a Spanish voice file, for example, on the fly as the file is being accessed and utilized in an application. Therefore, in a more advanced embodiment multiple physical prerecorded voice files do not have to be maintained.
Screen600 has a set ofoptions603 for viewing creating or editing prompts, rules, nomatch prompts, and no-input prompts. Options for help, viewing processor details, help with grammar, and properties are also provided within option set603. Workspace provides input screen or windows for adding new material and changes. The workspace windows can be in the form of an excel worksheet as previously described.
In one embodiment of the present invention linking voice files to prompts in application can be managed across multiple servers in a distributed network environment. Voice files, associated transcripts, prompt positions, dialog positions, and application associations are all automatically applied for the editor eliminating prior-art practice of re-linking the new resources in the application code. Other options not illustrated in this example may also be provided without departing from the spirit and scope of the present invention. For example, when a voice file used in several places has been modified, the editor may not want the exact version to be automatically placed in all use instances. In this case, the previous file is retained and the editor simply calls up a list of the use positions and selects only the positions that the new file applies to. The system then applies the new linking for only the selected prompts and dialogs. The old file retains the linking to the appropriate instances where no modification was required.
In another embodiment, voice file replication across distributed storage systems is automated for multiple distributed IVR systems or VXML portals. For example, if a developer makes changes to voice files in one storage facility and links those changes to all known instances of their use at other client access points, which may be widely distributed, then the distributed instances may automatically order replication of the appropriate audio resources from the first storage facility to all of the other required storage areas. Therefore, for voice applications that are maintained at local client-access facilities of a large enterprise that rely on local storage of prerecorded files can, after receiving notification of voice file linking to a new file or files can execute and order to retrieve those files from the original storage location and deposit them into their local stores for immediate access. The linking then is used as a road map to insure that all distributed sites using the same applications have access to all of the required files. In this embodiment audio resource editing can be performed at any network address wherein the changes can be automatically applied to all distributed facilities over a WAN.
FIG. 7 is a process flow diagram700 illustrating steps for editing or replacing an existing audio resource and replicating the resource to distributed storage facilities. Atstep701, the developer selects an audio resource for edit or replacement. The selection can be based on a search action for a specific audio resource or from navigation through a voice application dialog menu tree.
Atstep702 all dialogs that reference the selected audio resource are displayed. Atstep703, the developer may select the dialogs that will use the edited or replacement resource by marking or highlighting those listed dialogs. In one embodiment all dialogs may be selected. The exact number of dialogs selected will depend on the enterprise purpose of the edit or replacement.
Atstep704, the developer edits and tests the new resource, or creates an entirely new replacement resource. Atstep705, the developer saves the final tested version of the resource. Atstep706, the version saved is automatically replicated to the appropriate storage locations referenced by the dialogs selected instep703.
In this exemplary process, steps702, and step706 are automated results of the previous actions performed.
The methods and apparatus of the present invention can be applied on a local network using a central or distributed storage system as well as over a WAN using distributed or central storage. Management can be performed locally or remotely, such as by logging onto the Internet or an Intranet to access the software using password protection and/or other authentication procedures.
The methods and apparatus of the present invention greatly enhance and streamline voice application development and deployment and according to the embodiments described, can be applied over a variety of different network architectures including DNT and POTS implementations.
One-Touch System Configuration Routine
According to one aspect of the present invention a software routine is provided that is capable of receiving a configuration package and of implementing the package at a point of voice interaction in order to effect system changes and voice application changes without suspending a system or application that is running and in the process of interaction with clients.
FIG. 8 is architectural overview of acommunications network800 wherein automated voice application system configuration is practiced according to an embodiment of the present invention.Communications network800 encompasses a wide-area-network (WAN)801, a public-switched-telephone-network (PSTN)802, and a communications host illustrated herein as anenterprise803.
Enterprise803 may be any type of enterprise that provides services to clients, which are accessible to a call-in center or department.Enterprise803, in this example, maintains voice interaction access points to voice services.Enterprise803 may be assumed to contain a communications-center type environment wherein service agents interact with clients calling into the enterprise.
Enterprise803 has a local-area-network (LAN)820 provided therein and adapted for supporting a plurality of agent-operated workstations for communication and data sharing.LAN820 has communications access toWAN801 and toPSTN802. A central telephony switch (CS)821 is provided withinenterprise803 and is adapted to receive calls routed thereto fromPSTN802 via atelephony trunk branch817 from a local switch in the network illustrated herein as switch (LS)804.LS804 may be a private-branch type of exchange (PBX), and automated-call-distributor (ACD), or any other type of telephone switch capable of running calls.
CS821 has an interactive voice system peripheral (VS)822 connected thereto by a CTI link.VS822 also has connection toLAN820.VS822 is adapted to interact with callers routedCS821 according to voice application dialogs therein.VS822 may be an IVR system or a voice recognition system (VRS) without departing from the spirit and scope of the present invention.VS822 is a point of deployment for voice applications used for client interaction. In this example, incoming calls routed toCS821 fromLS800 from withinPSTN802 are illustrated ascalls805 incoming intoLS804 from anywhere withinPSTN805.
Enterprise803 has a voice application server (VAS)824 provided therein and connected toLAN820.VAS824 is adapted for storing and serving voice applications created by an administrator (ADMN)823 represented herein by a computer icon also shown connected toLAN820.Administrator823 uses a client software application (AS)825 to create voice applications and manage voice files, voice prompts, and voice dialogs of those applications.
Once applications are created they may be deployed byVAS824 toVS822 for immediate service. In one embodiment of the present invention,system822 stores voice applications locally (storage not shown). In another embodiment of thepresent invention system822 retrieves voice applications fromsystem824 overLAN820 when those applications are required in interaction with clients. AS825 installed onworkstation823 is analogous to an application described further above respect toscreenshots400,500, and600 ofFIGS. 4, 5, and6 respectively. One exception is that AS825 is enhanced according to an embodiment of the present invention with a utility for enabling configuration and one touch deployment of voice application or system modification updates to voice applications or settings active atVS822. In some embodiments of the present invention, updates created and deployed from workstation823are applied to voice applications while those applications are active in interaction without a requirement for shutting down or suspending those applications from service.
Voice application server824, in this embodiment, has connection toWAN801 via aWAN access line814.WAN801 may be the well-known Internet, an Intranet, or a corporate WAN, among other possibilities.LAN access line814 may be a 24/7 connection or a connection through a network service provider.WAN801 has anetwork backbone812 extending there through, which represents all of the lines, equipment, and access points making up the entire WAN as a whole.
Backbone812 has a voice system (VS)813 connected thereto, which represents a data-network-telephony (DNT) version ofVS822.System813 uses voice applications to interact with clients accessing the system from anywhere inWAN801 or any connected sub networks. It is noted herein, thatnetworks802 and801 are bridged to gather for communication via agateway816.Gateway816 is adapted translating telephony protocols into data network protocols and in reverse order enabling, for example, IP telephony callers to place calls to PSTN destinations, and PSTN telephony callers to place calls to WAN destinations. In one embodiment,gateway816 may be an SS-7 Bell core system, or some other like system. Therefore, it is possible for PSTN callers to access voice interaction provided bysystem813 and for WAN callers to access voice interaction provided bysystem822.
A remote administrator is illustrated in this example as aremote administrator818.Administrator818 may be operating from a remote office, from a home, or from any physical location providing telephone and network-access services. A personal computer icon representing aworkstation819 further definesadministrator818.Workstation819 is analogous in this embodiment toworkstation823 except that it is a remote workstation and not LAN-connected in this example.
Workstation819 has asoftware application825aprovided thereto, which is analogous toapplication825 installed onworkstation823 withinenterprise803.Voice systems822 and813 have instances of a configuration order routine (COR),826 forVS822, and826aforVS813 installed thereon. COR (826,826a) is adapted to except a configuration order package from AS825 and/or AS825arespectively. COR (826,826a) excepts and implements configuration orders created byadministrators823 or819 and automatically applies those configuration orders to their respective voice systems.
In a preferred embodiment of the present invention,administrator823 utilizesapplication software825 create necessary updates to existing voice applications including any required settings changes.Voice application server824 contains the actual voice applications in this case, which may be served tovoice system822 when required. In one embodiment however,voice system822 may store voice applications for immediate access. After making the required edits,administrator823 may initiate a one-touch deployment action that causes a change-order to be implemented by change-order routine826 running inVS822. It is noted herein that a change-order for a voice application that is running may automatically extract and implement itself while the application is still running. A change-order may also be implemented to an application that is not currently running without departing from the spirit and scope of the present invention.
WhenVS822 receives a change-order fromadministrator823,application826 executes and implements the change-order. In the case of a running application, there may be a plurality of callers queued for different dialog prompts or prompt sequences of the same application. In this case,COR826 monitors the state of the running application and implements the changes so that they do not negatively affect caller interaction with the application. More detail about how this is accomplished is provided later in this specification.
Remote administrator819 may also create and implement change-orders to applications running invoice system822 from a remote location. For example, utilizing AS825a,administrator819 may connect toISP809 throughLS804 viatrunk806 andtrunk branch808.ISP809 may then connectadministrator819 tobackbone812, from whereVS824 is accessible vianetwork line814.Administrator819 may therefore perform any of the types of edits or changes to applications running inVS822 or to any settings ofVS822 thatadministrator823 could configure for the same. Moreover,administrators823 and819 may generate updates for any voice applications running onvoice system813 connected tobackbone812 inWAN801.
Calls805 may represent PSTNcallers accessing CS821 throughtrunk806 andtrunk branch817.Calls805 may also include callers operatingcomputers accessing VS813 throughISP809 viatrunk branch808 andnetwork line810, or throughgateway816 viatrunk branch807 andnetwork line815. Although the architecture in this example illustrates tethered access,callers805 may also represent wireless users.
FIG. 9 is an exemplaryinteractive screen900 illustrating application of modifications to a voice dialog according to an embodiment of the present invention.Screen900 illustrates capability for creating a change-order or update to voice application dialog in this example.Screen900 is a functional part ofAS825 or825adescribed above with reference toFIG. 8.Screenshot900, in a preferred embodiment, stems from the same parent application hostinginteractive screens400,500, and600, described further above.
Interactive screen900 contains aworkspace902, and aworkspace903.Space902 contains aportion904 of a dialog D-01 (logical representation only) illustrated in expanded view as adialog901, which is accessible from a dialog menu illustrated at far left ofscreen900. A dialog search box is provided for locating any particular dialog that needs to be updated.
Withinworkspace902,dialog portion904 is illustrated in the form of an original configuration. In this example, a prompt906 and a prompt908 ofdialog portion904 will be affected by an update.Dialog portion900 is illustrated withinworkspace903 as an editedversion905.Workspace903 is a new configuration workspace.
Prompt906 inworkspace902 is to be replaced. Inworkspace903, the affected prompt is illustrated as a dotted rectangle containing an R signifying replacement. In this example, prompt906 is replaced with aprompt sequence907.Sequence907 contains three prompts labeled A signifying addition. Prompt908 fromworkspace902 is illustrated as a deleted prompt909 in workspace903 (dotted rectangle D).
Thenew configuration905 can be “saved-to-file” by activating asave button910, or can be saved and deployed by activating a deploybutton911. A reset button is also provided for resettingnew configuration905 to the form of the original theconfiguration904. Interactive options for selecting prompts and for selecting attributes are provided for locating the appropriate new files link to the dialog. Eachworkspace902 and903 has a prompt-view option enabling an administrator to select any prompt in the tree and expand that prompt for play-back purposes or for viewing transcripts, author data, and so on.
When an original configuration has been updated to reflect a new configuration, selecting the deployoption911 causes the update package to be deployed to the appropriate VS system (if stored therein) or to the VAS if the application is executed from such a server. The exact point of access for any voice system will depend on the purpose and design of the system. For example, referring back toFIG. 8, if a voice system and switch are provided locally within an enterprise, then the actual voice applications may be served to clients through the voice system, the application hosted on a separate machine, but called in to service when needed. In one embodiment,VS824 distributes the voice applications to the respective interaction points or hosts, especially if the interaction host machine is remote.
FIG. 10 is a block diagram illustrating components of automated voice application configuration routine (826,826a) according to an embodiment of the present invention.Application826 contains several components that enable automated configuration of updates or edits to voice applications that may be in the process of assisting clients.
Application826 has aserver port interface1000 adapted to enable the application to detect when a change-order or update has arrived at the voice system. A hostmachine running application826, in a preferred embodiment, will have a cache memory or data queue adapted to contain incoming updates to voice applications, some of which may be running when the updates have arrived.
Application826 has a scheduler component provided therein and adapted to receive change-orders from a cache memory and schedule those change-orders for task loading. It is noted herein that a change-order may have its own schedule for task loading. In thiscase scheduler1002 parses the schedule of the change-order and will not load the order until the correct time has arrived.Application826 has atask loader1003 provided therein and adapted to accept change-orders fromscheduler1002 for immediate implementation.
In one embodiment of the present invention,application826 receives change-orders that include both instructions and the actual files required to complete the edits. In another embodiment of thepresent invention application826 receives only the instructions, perhaps in the form of an object map or bitmap image, wherein the actual files are preloaded in identifiable fashion into a database containing the original files of the voice application or voice system settings. For updating voice applications, the actual implementation will depend on whether the voice files used to update the application are stored locally (within the VS) or are accessed from a separate machine such as a VAS.
Application826 has a voice application (VA)locator1004 provided therein, and adapted to find, in the case of voice application update, the correct application that will be updated. It is possible that the application being updated is not in use currently. It is also possible that the application being updated is currently in use. In either instance,VA locator1004 is responsible for finding the location of the application and its base files.
VA locator1004 has connection to a database orserver base interface1006 provided therein and adapted to enableVA locator1004 to communicate externally from the host system or VS. Therefore, if a particular voice application is being stored on a voice application server separate from voice system that uses the interaction, the voice application locator running on the voice system can locate correct application on the external machine.
Application826 has a voice application (VA)state monitor1005 provided therein and adapted to monitor state of any voice application identified byVA locator1004 that is currently running and serving clients during the time of update.State monitor1005 has connection to adialog controller interface1009. A dialog controller is used by the voice system to execute a voice application. The dialog controller manages the caller access and dialog flow of any voice application in use by the system and therefore has state information regarding the number of clients interacting with the application and their positions in the dialog hierarchy.
Application826 has a sub-task scheduler/execution module1007 provided therein, and adapted to execute a change-order task according to instructions provided byVA state monitor1005.Module1007 contains anorphan controller1008.Orphan controller1008 is adapted to maintain a functioning state in a voice application of certain prompts or prompt sequences that are to be deleted or replaced with new files used by a new configuration.
It is important that the current client load using the voice application under modification is not inconvenienced in any way during the flow of the application and that clients traversing a new dialog will have the prompts in place so that the application does not crash. For this reason, orphans are maintained from the top down while changes to the application are built from the bottom up. In one embodiment of the present invention a new configuration is an object tree wherein the objects are prompts and prompt sequences. Similarly, the voice application that is to be modified has a similar object tree. The objects or nodes are links to the actual files that are applied in voice interaction. Likewise, there are objects or nodes in a voice application tree that represent functional code responsible for the direction of the application determined according to user response.
Module1007 cooperates with VA state monitor1005 to perform a change-order to a voice application usingorphan controller1008 to maintain functional orphans until all of the new objects are in place and callers are cleared from the orphan tree. In actual practice, the voice application being modified continues to function as a backup application while it is being modified. Replacement files and code modules associated with the change-order are, in a preferred embodiment, available in a same data store and memory partition that the original application files and code reside having been loaded therein either from cache or directly. In one embodiment, the files representing changes may be preloaded into the same storage hosting the old files such that as change-order is implemented byapplication826 the change files are caused to take the place of the original files as required. The subtask scheduler portion ofmodule1007 works withVA state monitor1005, which in turn has connection to the application dialog controller, which in turn has connection to the telephony hardware facilitating client connection to voice applications. Thereforemodule1007 can apply changes to the application and maintain orphan state until all of the accessing callers are interacting with the new configuration in a seamless matter. At that point the orphans (old files and settings) may be purged from the system.
Application826 has a task state/completion notification module1010 provided therein and adapted to send notification of the completed task to the task author or administrator throughserver port interface1000.Module1010 also has connection to change-order cache interface1001 for the purpose of purging the cache of any data associated with a task that has been completed successfully.
In one embodiment of the present invention,module1010 may send, throughinterface1000, an error notification or an advisory notification related to a change-order task that for some reason has not loaded successfully or that cannot be implemented efficiently. In the latter case, it may be that due to an unusually heavy call load using an existing application a change-order may be better scheduled during a time when there are not as many clients accessing the system. However, this is not required in practice the present invention as during change-order implementation, nodes are treated individually in terms of caller access and as long as the new changes are implemented from the bottom up callers may be transferred from an orphan, for example, to a new object in a dialog tree until such time that that orphan may be replaced or deleted and so on.
Application826 may be provided as a software application or routine that takes instruction directly from the change-orders it receives. In one embodiment of thepresent invention application826 may be provided to run on a piece of dedicated hardware as firmware, the hardware having connection to the voice system. There are much possible variant architecture that may be used without departing from the spirit and scope of the present invention.
FIG. 11 is aprocess flow chart1100 illustrating steps or receiving and implementing a change the according to an embodiment of the present invention. Atstep1101, a change-order is received by the system. Instep1101, the actual files of the change-order may be cached in a cache memory and the change-order instructions, which in one embodiment are of the form of an executable bitmap or object model, are loaded into a task loader analogous toloader1003 ofFIG. 10 for processing.
Atstep1102, the system locates the voice application that is the target of the change-order. In one embodiment of the present invention, the target voice application may not be in current use. In this case, the changes may be implemented without concern for active state of the application interaction with clients. In another embodiment the target voice application may be currently in use with one or more of callers interacting with it. Assuming the latter case atstep1103, the system prepares for execution of the change implementation task. Atstep1104, the current running state of the voice application is acquired. This information may include the total number of callers currently interacting with the application and their current positions of interaction with the application.Step1104 is an ongoing step meaning that the system constantly receives current application state with respect to the number of callers and caller position in the dialog flow of the application.
Atstep1105, execution of the change-order begins. Atstep1106, any orphans in the old application are identified and maintained from the top or root node of the application down the hierarchy until they are idle or not in a current state of access from one or more clients. Atstep1107, any new objects being applied to the application are built into the application from the bottom up toward the root node of the application. Instep1106, orphan control is established with respect to all of the components of the application that will be replaced or modified. Establishing orphan control involves identifying the components of the application that will be deleted, replaced, or modified, and establishing an orphan state of those components. The orphan state enables clients that are already queued for interaction with those components to traverse those components in a seamless manner.
Atstep1108, the state of each orphan established in the target voice application is continually checked for an opportunity to purge the orphan and allow a new object to take over that position in the dialog. Atstep1109, it is decided whether those orphans checked have any callers interacting with them. Atstep1110, if an orphan has callers interacting, the process reverts back to step1108 for that orphan. All established orphans might, in one embodiment, be monitored simultaneously. Atstep1108, if an orphan does not have calls interacting then atstep1109 that orphan may be purged if the new component associated therewith is already in place to take over from the orphan as a result ofstep1107.
In one embodiment of the present invention, a change is implemented only when a last maintained orphan of a tree is free of calls. Then the next orphan up is continually monitored instep1108 until it is free of calls. In one embodiment however, if a change-order is only to modify certain content or style of one or more voice prompts of an application but does not change the intent or direction of the interaction flow with respect to caller position, then any orphan in the tree may be purged atstep1110 when it is not in a current interaction state. Atstep1110, a new object associated with an orphan immediately takes over when an orphan is purged. If an orphan has no replacement node it is simply purged when it is not currently in use.
In a preferred embodiment of the present invention atsteps1106 and1107, the code portion of the new configuration provides all of the required linking functionality for establishing transient or temporary linking orders from prompt to prompt in a dialog. Therefore, an orphan that is still in use, for example, may be temporarily linked to a new node added further down the dialog tree. When that orphan is purged, a new object (if in place) takes over the responsibilities of caller interaction and linking to further objects. Atstep1111, the system reports status of task implementation.
In one embodiment of the present invention, files are actually swapped from cache to permanent storage during configuration. For example, a new component may not be inserted into the voice application until the final orphan being maintained in the tree is cleared of callers for a sufficient amount of time to make the change over and load the actual file or files representing the new object. The next orphan above a newly inserted object may be automatically linked to the new component so that existing callers interacting with that orphan can seamlessly traverse to the new component in the application enabling lower orphan nodes to be purged. This process may evolve up tree of the voice application until all of the new objects are implemented and all orphans are purged.
In a preferred application of the present invention, new objects are installed immediately after orphans are established atstep1106. In this embodiment, the new objects are installed side-by-side with the established orphans accept in the case where an orphan is deleted with no modification or replacement plan. In this case, the new components are selected to immediately take over during a lull in interaction when there are currently no callers interacting with that portion of the tree. New objects may also be added that do not replace or conflict with any existing files of a voice application. In this case no orphan control is required. Code and linking instruction in a new configuration is applied to the old configuration in the same manner as voice file prompts.
In one embodiment, transitory links are established in a new configuration for the purpose of maintaining application dialog flow while new objects are installed. For example, 2 links, one to an orphan and one to the new component may be provided to an existing component that will be affected. If an orphan has current callers but the node below it has none, the orphan can automatically link to the new object even though it is still being used.
One with skill in the art will recognize that the process order offlowchart1100 may very according to the type of implementation. For example, if a change-order includes the physical voice files and code replacements and those are handled by the application, then atstep1107 installing new objects may include additional subroutines involving moving the objects from cache memory to permanent or semi-permanent storage. If the physical voice files and code replacements are preloaded into a database and then accessed during the configuration implementation, then step1107 may proceed regardless of orphan status, however the new components are activated only according to orphan status.
The method and apparatus of the present invention can be implemented within or on a local area network, or from a remote point of access to a wide area network including the Internet network without departing from the spirit and scope of the present invention. The software of the present invention can be adapted to any type of voice portal that users may interact with and that plays voice files according to a pre-determined order. The method and apparatus of the present invention, in light of many possible embodiments, some of which are described herein should be afforded the broadest possible scope under examination. The spirit and scope of the present invention is limited only by the following claims.