Method and system to extend functionality of voice processing systems

[0002] 1. Technical Field

[0003] The invention relates generally to computer software and more specifically to computer automated services. The invention relates even more specifically to automated voice processing systems.

[0004] 2. Description of Related Art

[0005] With today's explosive growth in both the computer and the telecommunications industries, companies are increasingly looking for ways in which to leverage their information systems operations by merging previously separate functions. A common example of such a technological marriage is the wide-ranging acceptance of voice processing systems that provide menuing and other automated services to callers. One such product in this field is DirectTalk; a cross-platform licensed program product used by private industry, colleges and universities, and government agencies. (DirectTalk is a trademark of International Business Machines Corporation in Armonk, N.Y.) However, as the demand for such products grows, customer-desired functionality sometimes jumps ahead of official product releases.

[0006] One limitation of these automated services involves the use of call archives. These archives are records of past calls, and often, the data contained in them is mission critical for the organization. In many cases, in fact, these logs present themselves as billable records, without which a customer organization would be unable to collect revenue from various clients. Here, unfortunately, a problem with the current designs presents itself. Calls may be archived in various time intervals, such as weekly, monthly, or any other desired period. However, the archived records can only be printed for the interval for which they have been archived.

[0007] At first, the problem with this may not be apparent. However, in considering that high-volume call centers find the need to archive call information daily, the dilemma begins to show itself. In such high-volume centers, the records have to be printed daily and inserted into physical files. Then, at the end of the billing cycle, the customer organization has to assign people the tedious task of manually adding up the call records from all of the daily printouts. This wasteful exercise has been a source of great frustration to organization customers and has reduced their satisfaction with these products.

[0008] A solution to this problem is so greatly desired that organization clients have spent tens of thousands of dollars on information technologist (IT) specialists to find a work-around. Therefore, it is desirable to have an automated caller service that has the ability to print phone activity records for any range of dates, regardless of the archiving frequency, thus freeing organization customers from menial tasks and saving them money.

[0009] The present invention provides a method for managing phone activity records in an automated voice processing system. In a preferred embodiment, phone activity data from the automated voice processing system is periodically written into a first file. The phone activity data corresponds to a period of time. Prior data in the first file is overwritten each new time phone activity data is written into the first file. Prior to data being overwritten in the first file, the phone activity data from the first file is placed into a master file with prior phone activity records. The master file provides a history of phone activity within the automated voice processing system.

[0010] The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:

[0011] FIG. 1 is a pictorial representation of a distributed data processing system in which the present invention may be implemented;

[0012] FIG. 2 depicts a block diagram of a data processing system that may be implemented as a server in accordance with the present invention;

[0013] FIG. 3 illustrates a block diagram of a data processing system in which the present invention may be implemented;

[0014] FIG. 4 is a flow chart illustrating a preferred embodiment for allowing phone activity records to be printed for any range of dates;

[0015] FIG. 5 is a flowchart illustrating a method for displaying requested user information contained in the master file; and

[0016] FIG. 6 depicts a sample of the contents of the master file.

[0017] With reference now to the figures, and in particular with reference to FIG. 1, a pictorial representation of a distributed data processing system is depicted in which the present invention may be implemented.

[0018] A network server 105, such as an IBM RS/6000, includes a voice processing system 110, such as DirectTalk for AIX or AIX DirectTalk/6000 products from International Business Machines Corporation (IBM). More information about DirectTalk for AIX may be found in “DirectTalk for AIX: General Information and Planning,” version 2, release 2, published by IBM Corporation; and more information about AIX DirectTalk/6000 may be found in “General Information and planning: AIX DirectTalk/6000” Release 6, published by IBM.

[0019] Voice processing system 110 receives voice information from telephone 101 via telephone network 103, which is connected to server 105. Voice processing software applications 110 interact with callers using spoken prompts. Callers interact with voice processing system 110 using speech or telephone 101 keypad. Voice processing system 110 accesses data from local database 120 in response to commands received from callers and also writes information to local database 120 based on responses received from the callers.

[0020] In addition to interacting with callers, voice processing system 110 automatically collects information about each call. The information includes how many calls access each application, where in the call flow a caller hangs up, and how often a specific event occurs. An event is anything that a user defines as an event, such as the caller pressing a key. Voice processing system 110 automatically logs this information for the user. The user can view the information online or have voice processing system 110 generate and print reports automatically at preset intervals or whenever a user desires.

[0021] Voice processing system 110 also maintains information about online usage, such as how much activity took place on each channel, what applications are being called, and statistics about the sessions and the links to all remote computers. These statistics include the maximum number of sessions available at any one time. The user can view all of this information online or in printed form, in the same way as the call information.

[0022] In addition to the pre-determined report formats that the user can view online or print, the user can also export the raw data from the database in which it is held and process it to produce reports of their own.

[0023] Voice processing system 110 also may access information and write data to databases located on remote computers, via network 140. Server 105 includes a communications facility 130 to facilitate communications between voice processing software 110 and remote computers.

[0024] Distributed data processing system 100 is a network of computers in which the present invention may be implemented. Distributed data processing system 100 contains network 140, which is the medium used to provide communications links between various devices and computers connected within distributed data processing system 100. Network 140 includes printer 150, client machines 145 and 147, and network servers 160 and 165. Network 140 may also include permanent connections, such as wire or fiber optic cables, or temporary connections made through telephone connections.

[0025] Network 140 may include more or fewer devices than are depicted in FIG. 1. Furthermore, network 140, as shown, is a local area network (“LAN”). However, network 140 may be other kinds of networks, such as, but not limited to, wide area networks (“WANs”).

[0026] FIG. 1 is intended as an example and not as an architectural limitation for the processes of the present invention.

[0027] Referring to FIG. 2, a block diagram of a data processing system which may be implemented as a server, such as server 105 in FIG. 1, is depicted in accordance with the present invention. Data processing system 200 may be a symmetric multiprocessor (SMP) system including a plurality of processors 202 and 204 connected to system bus 206. Alternatively, a single processor system may be employed. Also connected to system bus 206 is memory controller/cache 208, which provides an interface to local memory 209. I/O bus bridge 210 is connected to system bus 206 and provides an interface to I/O bus 212. Memory controller/cache 208 and I/O bus bridge 210 may be integrated as depicted.

[0028] Peripheral component interconnect (PCI) bus bridge 214 connected to I/O bus 212 provides an interface to PCI local bus 216. A number of modems 218-220 may be connected to PCI bus 216. Typical PCI bus implementations will support four PCI expansion slots or add-in connectors. Communications links to network computers 108-112 in FIG. 1 may be provided through modem 218 and network adapter 220 connected to PCI local bus 216 through add-in boards.

[0029] Additional PCI bus bridges 222 and 224 provide interfaces for additional PCI buses 226 and 228, from which additional modems or network adapters may be supported. In this manner, server 200 allows connections to multiple network computers. A memory mapped graphics adapter 230 and hard disk 232 may also be connected to I/O bus 212 as depicted, either directly or indirectly.

[0030] Those of ordinary skill in the art will appreciate that the hardware depicted in FIG. 2 may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The depicted example is not meant to imply architectural limitations with respect to the present invention.

[0031] The data processing system depicted in FIG. 2 may be, for example, an IBM RISC/System 6000, a product of International Business Machines Corporation in Armonk, N.Y., running the Advanced Interactive Executive (AIX) operating system.

[0032] With reference now to FIG. 3, a block diagram of a data processing system in which the present invention may be implemented is illustrated. Data processing system 300 is an example of a client computer such as client machines 145 and 147. Data processing system 300 employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures, such as Micro Channel and ISA, may be used. Processor 302 and main memory 304 are connected to PCI local bus 306 through PCI bridge 308. PCI bridge 308 may also include an integrated memory controller and cache memory for processor 302. Additional connections to PCI local bus 306 may be made through direct component interconnection or through add-in boards. In the depicted example, local area network (LAN) adapter 310, SCSI host bus adapter 312, and expansion bus interface 314 are connected to PCI local bus 306 by direct component connection. In contrast, audio adapter 316, graphics adapter 318, and audio/video adapter (A/V) 319 are connected to PCI local bus 306 by add-in boards inserted into expansion slots. Expansion bus interface 314 provides a connection for a keyboard and mouse adapter 320, modem 322, and additional memory 324. In the depicted example, SCSI host bus adapter 312 provides a connection for hard disk drive 326, tape drive 328, CD-ROM drive 330, and digital video disc read only memory drive (DVD-ROM) 332. Typical PCI local bus implementations will support three or four PCI expansion slots or add-in connectors.

[0033] An operating system runs on processor 302 and is used to coordinate and provide control of various components within data processing system 300 in FIG. 3. The operating system may be a commercially available operating system, such as OS/2, which is available from International Business Machines Corporation. “OS/2” is a trademark of International Business Machines Corporation. An object oriented programming system, such as Java, may run in conjunction with the operating system, providing calls to the operating system from Java programs or applications executing on data processing system 300. Instructions for the operating system, the object-oriented operating system, and applications or programs are located on a storage device, such as hard disk drive 326, and may be loaded into main memory 304 for execution by processor 302.

[0034] Those of ordinary skill in the art will appreciate that the hardware in FIG. 3 may vary depending on the implementation. For example, other peripheral devices, such as optical disk drives and the like, may be used in addition to or in place of the hardware depicted in FIG. 3. The depicted example is not meant to imply architectural limitations with respect to the present invention. For example, the processes of the present invention may be applied to multiprocessor data processing systems.

[0035] A flowchart illustrating a preferred embodiment for allowing phone activity records to be printed for any range of dates is depicted in FIG. 4. As each call is processed, voice processing system 110 records the information associated with the call, such as which applications were accessed, at what point in the call flow the caller hung up, the occurrences of specific events, and a time and date stamp indicating when the call took place and what the duration of the call was (step 410). An event is anything that a user defines as an event, such as the caller pressing a key. Voice processing system 110 creates an archive file (step 415) and a master file (step 420). The phone activity records are archived into the archive file on a periodic basis (step 425).

[0036] Each time the phone activity records are archived into the archive file, the archive file is appended to the master file (step 430). It should be noted that the archive file is overwritten each time the phone activity records are archived. Thus, by appending each archive file to the master file (step 430), all of the phone activity records are contained in one file; therefore, there is no need to manually add up call records from periodic printouts of the archive file. Thus, significant time and expense is saved.

[0037] Whenever a user desires to have selected events from the phone activity records displayed, the voice processing system parses through the master file to find the requested information (step 435). This information is then displayed to the user (step 440). Since the master file contains all of the phone activity records, a set of records can be displayed for a period of time not corresponding to any interval of archiving.

[0038] Turning now to FIG. 5, a flowchart illustrating a method for displaying requested user information contained in the master file is depicted. A user requests information about events and applications that occurred between a starting and an ending date (step 502). If any old files exist, they are moved to *.old so that they are not overwritten. The date entered by the user is reformatted, such that it is in the form yyyy.mm.dd, where yyyy is a four-digit number representing the year; mm is a number between “01” and “12,” representing the month of the year; and dd is the day of the month, a number between “01” and “31.” If the start date and the end date provided by the user are the same (step 504), then all records with the relevant date are pulled out of the master file and printed into an interim file (step 506).

[0039] If the end date and the start date are not the same, then the master file is searched for the desired dates (step 510), and the records for the end date are pulled out and printed into an interim file (step 512). The day of the month part of the date is decremented by one (step 514). If the day portion of the date chosen is “01,” it makes the next day “31”; otherwise, the day is the current day minus one. If the day has just been reset from “01” to “31,” then the month is decremented if the current month is not “01.” If the day has just been reset from “01” to “31,” and the current month is “01,” the month is reset to “12.” If the day was reset from “01” to “31,” and if the month was just reset from “01” to “12,” then the year is decremented by one.

[0040] Next, the records from the master file corresponding to the new decremented date are pulled out, and these records are printed into the interim file (step 516). Steps 514 and 516 are repeated until the records on the starting date have been printed into the interim file (step 518).

[0041] Once records for the entire range of dates requested has been printed to the interim file at step 518, then the interim file is parsed to turn the data into a finished, printable output (step 520). First, a history file is created (step 522). The history file shows which application names/event combinations have already been selected and placed into their respective files. Note that, if multiple application names have been selected, then a separate printout will exist for each company. Each printout will have all events for that application for the entire date range requested.

[0042] Beginning at the top of the interim file, the file is examined to determine whether the application name has already been seen, by looking into the history file (step 524). (Of course, the first time it will not have been seen). If it has not been seen before, then a formatted template is created for this company, where the template file is a separate file to be printed (step 528). In the new template file, a line item is created for this application and event type (step 534). All of the occurrences of this application and event combination are pulled out, and the number of occurrences of this application/event combination are added up and placed into the final formatted template file (step 536). Then, the next line in the interim file is processed (step 538).

[0043] Returning to step 526, if the application name has already been seen, then no new template file is needed (step 530). Next, it is determined whether this event associated with this application name has been seen before (step 532). If it has, the process flows to the next line in the interim file (step 538). If it has not been seen before, then a new line item is created in the formatted application template file for this application/event combination (step 534). Next, the number of occurrences of this application/event combination are totaled and placed into the final formatted template file (step 536). Once this has been completed, the process flows to the next line in the interim file (step 538)

[0044] Once the next line in the interim file has been reached (step 538), it must be determined if this is the end of file (step 540). If it is the end of the file (step 540), then the template files are printed and the user receiving the files is alerted that they are going to the printer (step 542). If it is not the end of the file (step 538), the process reverts to step 526, and the process is repeated for the next line in the interim file.

[0045] Turning now to FIG. 6, there is depicted a sample of the contents contained in the master file. The first line in the master file contains six entries: 605, 610, 615, 620, 625 and 630. Each entry corresponds to different information about a group of calls of a specified type received by the voice processing system on a specified day. The first entry 605 contains the name of the host machine that processed the group of calls. The host name may be anything the internal administrators wish to call a machine. Second entry 610 contains the date for which the group of specified types of calls was received. In this case, the date for line 1 is Jun. 13, 1998. Third entry 615 is a time stamp, which is not used because this file contains a compilation of all calls of a specified type that occurred on a specified date; therefore, the entry is 00:00:00. Fourth entry 620 contains the name of the client about whom the caller accessed information. In this case, the client name for line 1 is Best_Bank. Fifth entry 625 is the type of event that occurred. In the case of line 1, the recorded event is the cancellation of a credit card. The sixth and final entry 630 is the number of times that event occurred for that client on the specified day. For example, on Jun. 13, 1998, 40 callers called the voice processing system and cancelled credit cards for client Best_Bank. Each line contains the date and number of events for a different client/event pair. Other client information is also contained in this master file. For example, entry 635 lists the name of a different client—specifically, China_Trust2.

[0046] In a specific implementation of the present invention, three associated scripts perform the tasks required to extend the functionality of DirectTalk, a voice processing system from IBM. The three scripts are “dtmaster.ksh,” “dtprint.ksh,” and “dtbackend.ksh.” The script “dtmaster.ksh” runs in parallel with standard DirectTalk archiving. If archiving is run nightly, for example, then dtmaster.ksh would be run nightly as well. The purpose of this script is to concatenate the archive files into a master file containing open-ended historical data. “Dt.event.master” is the file created and maintained by “dtmaster.ksh.” A sample copy of this file is shown in FIG. 6. The master file is necessary because the DirectTalk-generated archive files, such as “/u/dirTalk/archive_dir/oamlog/Event.arc,” are overwritten as each round of archiving occurs.

[0047] “Dtprint.ksh” is the script called by the user for all print jobs. This is a user selection interface which, in turn, calls “dtbackend.ksh.” “Dtbackend.ksh” is the file that actually parses through the “Dt.event.master,” finds the requested events, formats them into a DirectTalk standard printout form, and sends them to the printer. One reason that the function is divided into “dtprint.ksh” and “dtbackend.ksh” is so that “dtbackend.ksh” may be called automatically by other scripts or crontab entries if desired by the user.

[0048] The following is a sample script for concatenating the archive files into a master file containing open-ended historical data.

[0049] The following is a sample script for that may be used as the file dtprint.ksh which is the script called by the user for all print jobs. This is a user-selection interface which in turn calls “dtbackend.ksh.”

[0050] The following is a sample script that may be used as “dtbackend.ksh.” This the file that actually parses through the “Dt.event.master,” finds the requested events, formats them into a DirectTalk standard printout form, and sends them to the printer. A flowchart illustrating the function of this script is shown in FIG. 5 which was described above.

[0051] It is important to note that while the present invention has been described in the context of a fully functioning data processing system, those of ordinary skill in the art will appreciate that the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions and a variety of forms and that the present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include recordable-type media such as a floppy disc, a hard disk drive, a RAM, and CD-ROMs and transmission-type media such as digital and analog communications links.

[0052] The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.