Methods of interacting between mobile devices and voice response systems

Background

Current methods for assisting customers at a mobile device often require a call to a call center and retrieval of data from a network. For example, a subscriber may dial an information number from their mobile device, such as "411." Once the subscriber dials the number, an automated system (or an operator) may answer the call and provide the subscriber with a menu of options. The subscriber selects an option from the menu by pressing buttons on the mobile device or by saying the option. Once the subscriber requests data by selecting an option, the automated system retrieves the data from a network and delivers the data to the subscriber over the mobile device.

In many cases calls to information, customer assistance, or other numbers are answered by automated voice response systems. Typically, automated systems attempt to interact with subscribers by sending prerecorded questions and waiting for responses. These systems may be limited in how they interact with subscribers.

These and other problems exist with respect to assisting users of wireless devices.

Brief description of the drawings

FIG. 1 is a schematic diagram illustrating a mobile device on which interactive voice response navigation methods can be implemented.

FIG. 2 is a schematic diagram illustrating a suitable environment for implementing interactive voice response navigation methods.

FIG. 3 is a block diagram illustrating an enhanced IVR system and the flow of data between elements.

FIGS. 4A-B are data flow diagrams illustrating data and voice transmission channels between network elements.

FIG. 5A is a process flow illustrating an interaction between one or more scripts running on a mobile device and an interactive voice response system.

FIG. 5B is a process flow illustrating an alternative interaction between scripts running on a mobile device and an interactive voice response system.

FIG. 6A is example process flow for determining if a dialed number has enhanced voice capabilities.

FIG. 6B is a process flow illustrating interactions between an IVR system and other components upon receiving a call from a mobile device.

FIG. 7A is an example process flow illustrating a script initiating interactions with an IVR system.

FIG. 7B is an example of display screens used in the example of FIG. 7A.

FIG. 8 illustrates a routine for accessing mobile device information via unique identification.

FIG. 9 is an example of a computer display showing device information and configuration data as used by a call center agent and/or IVR system.

Detailed description

A method and system of interacting with voice recognition systems such as IVR systems using a mobile device is disclosed. Subscribers may dial one or more predetermined numbers on their respective mobile device. Software on the mobile device determines whether the number corresponds to one of the predetermined numbers (such as a number known to be associated with an IVR system). The device may initiate a script when the number is dialed, before or after the call has gone through, while the call is on hold, and so on. For example, if the number dialed matches a known voice enhanced number, the mobile device executes a script that facilitates interactions between the mobile device and an IVR system related to the voice enhanced number.

In some examples, the system performs one or more actions during an ongoing voice call between a user and an IVR system. For example, a mobile device may visually display to a user content associated with information provided to the user over the voice channel by the IVR system. The device may facilitate interactions between the user and the IVR system by using input received from the user in response to the visually displayed content. For example, the device may display one or more options related to a posed inquiry by the IVR system, receive user input selecting one of the options, and transmit the user selections to the IVR system, navigating the IVR system for the user. In some cases, the device may generate and send DTMF tones to the IVR system in response to user input, enabling the device to navigate the voice response aspects of the IVR system.

In some examples, the device may transmit identification information about the user and/or mobile device to a workflow system associated with an IVR system at a customer support or other assistance center. For example, the device may transmit diagnostic information related to the configuration of the device, initiate a call to an IVR system, and navigate the IVR system using simulated audio commands (e.g., DTMF tones). The device may do so with or without user interaction or knowledge.

The technology will now be described with respect to various embodiments. The following description provides specific details for a thorough understanding of, and enabling description for, these embodiments of the technology. However, one skilled in the art will understand that the technology may be practiced without many of these details. In other instances, well-known structures and functions have not been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments of the technology.

It is intended that the terminology used in the description presented below be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the technology. Certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this Detailed Description section.

Suitable System

FIG. 1 illustrates a mobile device 100 on which IVR interactions can be implemented in accordance with several embodiments of the technology. A receiver/demodulator 104 receives a transmitted signal via an antenna 102 and reconstructs the original transmitted signal. The transmitted signal is sent to a microcontroller 106, which consists of a decoder 108, a processor 112, and RAM (Random Access Memory) 114. The decoder 108 translates the signals into meaningful data and interfaces to other devices. Decoded data, along with subscriber inputs 110, are sent to the processor 112. In addition, the mobile device may include optional components, such as an automated data collection 120 unit linked to the processor 112, which can include an automated RFID (Radio Frequency Identification) tag reader, a magnetic card swipe reader, a bar code reader, and others. Additionally, or alternatively, the mobile device may include a biometric reader (e.g., thumbprint reader, voice fingerprint recognition functionality, etc.), and/or a media output device (e.g., MP3 player, television tuner/player, etc.) 120. The mobile device 100 may also include a subscriber identity module (SIM) 122. The output of the processor 112 can be stored in a programmable non-volatile memory 116 or in the RAM memory 118. The mobile device 100 may also include user output components, such as a display screen, speakers, and other components that enable a user to interact with the mobile device. The user may interact via input components, such as a keypad, via the screen (using touch-based interfaces), via voiced inputs, and so on.

Additionally, the subscriber identity module, or SIM card, may contain any or all of the processing components, memory components or storage components described herein. To that end, the device may perform SIM card based processing, memory, or storage.

FIG. 1 and the discussion herein provide a brief, general description of a suitable telecommunications or computing environment in which the technology can be implemented. Although not required, aspects of the technology are described in the general context of computer-executable instructions, such as routines executed by a general-purpose computer, e.g., a server compute or personal computer. Those skilled in the relevant art will appreciate that the technology can be practiced with other communications, data processing, or computer system configurations, including: Internet appliances, hand-held devices (including personal digital assistants (PDAs)), wearable computers, all manner of cellular or mobile phones, multi-processor systems, microprocessor-based or programmable consumer electronics, set-top boxes, network PCs, mini-computers, mainframe computers, and the like. Indeed, the terms "computer," "host," and "host computer," and "mobile device" and "handset" are generally used interchangeably herein, and refer to any of the above devices and systems, as well as any data processor.

Aspects of the technology can be embodied in a special purpose computing device or data processor that is specifically programmed, configured, or constructed to perform one or more of the computer-executable instructions explained in detail herein. Aspects of the technology may also be practiced in distributed computing environments where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network (LAN), Wide Area Network (WAN), or the Internet. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Aspects of the technology may be stored or distributed on computer-readable media, including magnetically or optically readable computer discs, hard-wired or preprogrammed chips (e.g., EEPROM semiconductor chips), nanotechnology memory, biological memory, or other data storage media. Indeed, computer implemented instructions, data structures, screen displays, and other data under aspects of the technology may be distributed over the Internet or over other networks (including wireless networks), on a propagated signal on a propagation medium (e.g., an electromagnetic wave(s), a sound wave, etc.) over a period of time, or they may be provided on any analog or digital network (packet switched, circuit switched, or other scheme). Those skilled in the relevant art will recognize that portions of the technology reside on a server computer, while corresponding portions reside on a client computer such as a mobile or portable device, and thus, while certain hardware platforms are described herein, aspects of the technology are equally applicable to nodes on a network. In an alternative embodiment, the mobile device or portable device may represent the server portion, while the server may represent the client portion.

FIG. 2 illustrates an environment 200 in which IVR interaction methods may be implemented. The environment 200 may include components within a mobile device 210 and/or network accessible components 220 that communicate with the components within the mobile device via a network 205. The components within the mobile device 210 may include executable software, software configurations, hardware configurations and controls, and handset operating system interfaces. As disclosed herein, executable software may include, without limitation, any software program stored on the mobile device or associated memory device, both permanently and temporarily connected via hardware or wireless connectivity. The mobile device 100 may include an authentication system 211 (e.g., via a SIM), a hardware interface 212, a report system 213, a script interface 214, a script platform 215, an IVR interaction component 216, data 217, and scripts 218. The network accessible components 220 may include a mobile network component 221, a customer service component 222 which may include a IVR component 223, a host information management component 224, a database of updated scripts 225, and a database of report data 226.

The components within the mobile device 210 allow the device to provide and/or implement handset-based services and network-based services. The authentication component 211 may implement SIM (Subscriber Identity Module) card-based or standalone authentication to meet network requirements for desired levels of security. Authenticating a system to meet network requirements may not be required but is often recommended.

The hardware interface component 212 may retrieve or receive data regarding actions performed by the mobile device 210, status information regarding the functionality of the mobile device, and so on. For example, the component 212 may receive information related to changing volume, changing frequency, retrieving SIM (Subscriber Identity Module) ID, connection status from the SIM or radio hardware, and others. The report component 213 may collect and forward the data reported by the mobile device to the network 206. The report component 213 may also encrypt the handset identification information to provide increased security. For example, the report component may encrypt the information so that only the host information management component 224 can decipher any transmitted handset identification information.

The script interface 214 serves as a standard application programming interface for executing scripts 218. More specifically, the script interface 214 provides an interface between scripts 218 and the various hardware-specific and executable, program-specific functions. The script interface 214 allows a single customer service script to be deployed across multiple operating systems and hardware configurations. In addition, the script interface 214 includes a standard API (Application Programming Interface) for both the hardware/OS side and the script interface.

The script platform 215 authenticates, runs, and updates all scripts 218, manages reporting updates and changes, communicates with the host information management component 224, communicates with a GUI (Graphical User Interface), and manages customer surveys and interviews. The script platform 215 can mix and match calls through the script interface to acquire information, to change or correct settings on the phone, and to perform additional functions as described below. The host information management component 224 can push a notification to the script platform 215 via USSD (Unstructured Supplementary Services Data), SMS (Short Message Service), IP (Internet Protocol), or any other network connectivity that the mobile device supports. The script platform 215 can run the scripts 218 after authentication, and the scripts 218 can be authenticated to via the network accessible components 205 or to the phone. The scripts 218 may be any application, routine, snippet of code, binary sequence, binary code instructions, or other executable data that executes on the mobile device 210 to cause the mobile device to perform an action, such as to provide enhanced interaction with an IVR system.

The network accessible components 220 enable the mobile device 210 to communicate with and to retrieve data from outside the device, such as from a customer support center having an IVR system. The network accessible components 220 may include wired and wireless components. The mobile network component 221 may perform many services, including billing, CRM (Customer Relationship Management), provisioning, and others. Furthermore, the mobile network component 221 may return data calls made by mobile devices via standard network protocols (e.g., IP, DTMF (Dual Tone Multiple Frequency), SMS, USSD, etc.).

The mobile network operator customer service component 222 may also consist of one or more systems relating to customer service, including billing, CRM, provisioning, and others. The customer service component 222 may also include an IVR component 223 that receives voiced communications (or other audio communications) from a user of the mobile device 210 and responds to the voiced communications. The host information management component 224 controls interactions between the mobile device 210 and the customer service component 222. The host information management component 224 may transmit updates to the mobile device 210. The mobile device 210 typically employs a unique handset ID or serial number, and a mobile phone number. The report data database 226 provides storage for report information gathered from the mobile device 210. The updated scripts database 225 stores scripts that the customer service component 222 or other network accessible components provide to the mobile device. The updated scripts 225 database may be managed and versioned as desired by the host information management component 224, can be targeted at specific subscribers or groups of subscribers, and can include requests for reports and customer interview surveys.

Further details regarding components within the mobile device 210 and/or components accessible to the mobile device over a network may be found in U.S. patent application Ser. No. 11/672,499, filed on Feb. 7, 2007, entitled A METHOD AND SYSTEM OF ENHANCING VOICE CALLS, SUCH AS ENHANCING VOICE CALLS WITH DATA SERVICES, which is incorporated by reference in its entirety.

Referring to FIG. 3, a block diagram illustrating an enhanced IVR system 300 is shown. A user 310 operates a mobile device or mobile equipment (ME) 315 running IVR enabling scripts (not shown). The user 310 and device 315 may use audio channels 317 and/or data channels 319 over a network 320 to connect to an IVR interaction component 330. The IVR interaction component 330 may transmit and/or receive data from a data server 350 or a customer support agent 360 utilizing a customer service center server 365 via a workflow component 340 that facilitates the exchange of data between the IVR interaction component 330 and other components within the system 300.

The enhanced IVR system 300 provides both voice-based and data-based services over some or all channels between system components 310, 315, 330, 340, 350, 360 and/or 365. For example, the user 310, via the mobile device 315, may transmit and receive audio-based communications from the IVR system 330 or the customer support agent 360. These communications may be voice communications or touchtone communications (such as DTMF tones, computer recognized voice grammar, computer recognized utterances, and so on). The mobile device 315 may also communicate with the IVR system 330 via DTMF tones or other recognized audio signals generated by scripts executing on the mobile device 315.

The IVR system 330 may communicate with the workflow component 340 via various data channels. For example, the workflow component 340 may run applications that act to facilitate communications between humans and computers. Examples include voice XML, CCXML, OpenVXI, and so on. The workflow component 340 receives audio-based data and converts that data to information understandable by the other components. Additionally, the workflow component 340 may also receive data-based information from the other components and convert that information to voice-based data.

In some cases, the mobile device 315 may communicate directly with the workflow system 340 or with customer support data server 350 over data channels 319.

Referring to FIGS. 4A-B, data flow diagrams illustrating data and voice transmission channels between network elements are shown. For example, FIG. 4A illustrates example analog transmission types between network components, such as IVR system 330, the customer service representative 360, the user 310, and/or the mobile device 315. The user 310 may communicate to a customer service representative 360 via a voice channel 410. The customer service representative 360 may communicate to the user 310 via voice channel 412. The IVR system 330 may communicate to the user via a voice channel 414. The voice channel 414 may use TTS synthesized communications or prerecorded playback. The user 310 may communicate to the IVR system 330 via a voice channel 416. Utterances or other spoke grammar may be recognized and/or recorded by the IVR system 330. The user may also communicate to the IVR system 330 via a voice channel 418 using DTMF tones. The DTMF tones may be manually produced by the user (such as the user pressing buttons on a keypad). The mobile device 315 may communicate to the IVR system 330 via a voice channel 420 using DTMF tones. The DTMF tones may be automatically produced by the script running on the mobile device 315. The IVR system may communicate to the mobile device 315 via voice channel 422 using DTMF tones.

Alternatively, or additionally, transmission channels may be digital channels. FIG. 4B illustrates example digital transmission types between network elements, such as a local script cache 490 on the mobile device 315, a mobile device 315, a workflow or network server 340, and a database server 491. For example, mobile device 315 may send messages or documents over channel 430 to workflow or network server 340. The server 340 may send scripts, messages, or document over channel 432 to the mobile device 315. The server 340 may use channel 434 to store data in database server 491 or query database server 491. The database server 491 may respond via channel 436. The mobile device 315 may save scripts to a local scripts database 490 via channel 438 and may load scripts from database 490 via channel 440. The mobile device 315 may also store data to database server 491 via channel 442 or may query database 491 via channel 442. The server 491 may respond to queries via channel 444.

Interacting with Voice Response Systems

The system described herein provides mobile devices and users of mobile devices enhanced functionality when interacting with voice recognition systems. Such enhanced functionality may include efficient user interfaces, automated repairs or updates of components of the device, automated responses, and so on. For example, the system allows users of mobile devices to visually interact with an interactive voice response (IVR) system while also verbally interacting with the IVR system (or in some cases instead of verbally interacting with the system). During such an interaction, the system may perform background tasks, such as repairing configuration problems, providing information to be later used in presented tutorials about a feature of the mobile device, and so on.

Scripts running on a mobile device allow an interactive voice response (IVR) system to perform actions on the mobile device. In some cases, one or more scripts (such as those described herein) enable a mobile device to receive commands from an IVR system over a voice or data channel communicatively linking the mobile device and the IVR system. These IVR system originating commands may cause actions to be performed on the mobile device, such as coordinating content displayed to the user via a graphical user interface (GUI) with voiced commands received from the IVR system. The content displayed to the user may be stored on the mobile device, transmitted from the IVR system, or retrieved from another network location. The mobile device, via executing scripts, may also send commands back to the IVR system or to other associated components.

In some cases, scripts running on the mobile device may initiate the dialing of an IVR number (such as a number known to be associated with an interactive voice response system). Once connected to the IVR system associated with the dialed number, the scripts may then communicate with the IVR system by sending dual tone multiple frequency (DTMF) tones to the IVR system. In some cases, the scripts use the DTMF tones to cause the IVR system to transmit voiced commands back to the mobile device.

Referring to FIG. 5A, a process flow illustrating an interaction between scripts running on a mobile device and an interactive voice recognition system is shown as routine 500. In block 510, a user of a mobile device initiates a voice call (such as dialing a number and pressing "connect"). In decision block 520, the system determines if the destination number of the voice call is IVR enhanced (that is, if the number provides IVR capabilities and/or may be enhanced with script instructions). If the system determines the number is not IVR enhanced, the routine proceeds to block 515, else the routine proceeds to block 525. At block 515, when the number is not IVR enhanced, the routine ends and the voice call proceeds as a typical voice call. Details describing the determination of voice enhanced numbers will now be discussed with respect to FIG. 6A.

Referring to FIG. 6A, an example process flow for determining if a dialed number has enhanced voice capabilities, such as in block 520, is shown as routine 600. Upon detecting a dialed number, the system, in block 610, looks to a local database 615 of IVR enhanced numbers and scripts and attempts to match the number with one of the locally stored numbers. Alternatively, or additionally, the system may compare the dialed number with a range of numbers (such as a range of numbers known to be voice enhanced) or may look to a portion of the number itself (such as looking at the number for a specific sequence of alphanumeric characters).

The database 615 may be in the local memory of the mobile device. The system may periodically update the database 615 after IVR workflow changes, IVR communications, and so on.

If the system matches the dialed number a number stored in the local database 615 (or matches a range of numbers or numbers having a certain sequence of characters), the routine 600 proceeds to block 640 and the system determines the dialed number is voice enhanced.

If the number is not stored in the local database 615 (or, does not otherwise indicate voice enhancement), the routine 600 proceeds to block 620. In block 620, the system looks to a database 625 of IVR enhanced numbers and scripts contained on a SIM card and attempts to match the dialed number with one of the numbers stored in the SIM card database 625. Further details with respect to the storage of numbers and/or scripts on SIM cards are discussed in commonly assigned PCT Application No. US2007/080351, filed on Oct. 3, 3007, entitled SYSTEMS AND METHODS FOR STORING OR PERFORMING FUNCTIONS WITH REMOVABLE MEMORY, SUCH AS A SUBSCRIBER IDENTITY MODULE OF A MOBILE DEVICE, which is incorporated by reference in its entirety. Of course, numbers could be stored elsewhere in the device.

If the dialed number is matched to a number stored in the SIM database 625 (or is matched to a range of numbers or numbers having a certain sequence of characters), the routine 600 proceeds to block 640 and the system determines the dialed number is voice enhanced.

If the number is not stored in the SIM database 625 (or, does not otherwise indicate voice enhancement), the routine 600 proceeds to block 630. In block 630, the system looks to a database 635 and/or a database 636 contained at a network server and attempts to match the dialed number with a number stored in one of databases 635, 636. The system may connect with the databases over a network 632, such as the Internet or other network. The system may look to a public database, such as a mobile service center (MSC) having a database 635. Database 635 may be an HLR, a VLR, or other public or accessible databases. The system may also look to a server specific database 636 (at a customer support server or at the workflow server, and so on) that contains additional known IVR enhanced numbers and scripts. If the system matches the dialed number to a number stored in one of the network databases 635, 636, the routine 600 proceeds to block 640 and the system determines the dialed number is voice enhanced. If the number does not match, the routine proceeds to block 650, and the system determines the dialed number is not voice enhanced. Of course, the system may employ other methods when determining if a number is IVR enhanced. For example, different combinations of steps 610, 620, and/or 630 may be employed by the system.

Referring back to FIG. 5A, at block 525, when the system determines the number is voice enhanced, the system loads and executes one or more scripts related to IVR communications. In block 530, the system processes the script. In processing the script, the system may perform some or all of the actions or functions described in blocks 531-538. The system may perform the described actions in various sequences and orders, other than those shown in FIG. 5A.

The system may, in block 532, synthesize a DTMF or other type of tone sequence, play back other audio such as a prerecorded audio file, or perform other audio-based actions on an analog line. The system may, in block 533, recognize and/or interact with a DTMF tone sequence (or other audio transmissions, such as human voice) received on an analog line. The system may, in block 534, send data or commands to a workflow server. The system may, in block 535, receive data or commands from a workflow server. In sending and/or receiving data or commands from a workflow server, the system may connect with the workflow server over a number of data channels, such as an SMS channel, an IP or IP6 channel, a USSD channel, and so on.

The system may, in block 536, update a display or other GUI on or related to the mobile device. For example, the system may present a user with a menu on the GUI related to audio communications received from the IVR system. The system may, in block 537, receive user input from button presses, soft button presses on a GUI, and so on. In block 538, the system may perform other scripted or enhanced actions (such as other actions described herein). Additionally, the system may, in block 531, disconnect an analog connection line as one of the actions. Once script instructions are processed and actions are performed, the routine proceeds from any or all of blocks 531-538 to block 540, and the system ends script processing.

Referring to FIG. 5B, a process flow illustrating an alternative interaction between scripts running on a mobile device and an interactive voice recognition system is shown as routine 550. In this example, in block 555, an application or script running on a mobile device wishes to interact with an IVR system. For example, a script running on the mobile device may detect an incorrect configuration and attempt to automatically notify the workflow server without alerting the user. In block 560, the system initiates a voice call to the IVR system, and the routine proceeds to block 530, where the script processing described above begins.

In some cases, the application or script sends data to a workflow server before initiating the voice call to the IVR system, and appends a unique identifier that provides identification information to the called number of the IVR system. The identifier may identify a database entry in the workflow server, the device, the SIM, and/or other related components. For example, the application may send diagnostic information related to the configuration of the device to the workflow server, and initiate a call to a customer assistance number to correct the configuration. Once called, the IVR system determines the identity of the mobile device using the identification information and retrieves the diagnostic information sent to the workflow system. The IVR system may receive instructions from the device to transmit an audio-based menu of options over the voice channel to allow the user to better understand the problem, take action to correct the problem by sending commands to the workflow component, or to perform other actions. Further details related to workflow servers and identifiers will be described herein.

Referring to FIG. 6B, a flow diagram illustrating interactions between the IVR system 330 and other network components upon receiving a call from a mobile device is shown as routine 680. In block 681, the IVR system receives an incoming call, such as a call from a mobile device running an IVR enhancement script. In some cases, the system receives an identifier along with the incoming call, such as extended dialing digits with caller ID information. Further details with respect to unique identifiers will be described herein.

In block 682, the system fetches instructions, such as VXML instructions. Although VXML instructions are shown in this example, the instructions may be implemented in other languages. In some cases, the system may communicate, via http or other channels, with a workflow server when fetching instructions. The workflow server may send or receive data from the mobile device over a data channel (such as an SMS channel, a USSD channel, an SS7 channel, an intermediate server such as customer support data server 350, and so on).

In block 683, the IVR system determines that the incoming call is still connected, and proceeds to block 685, else proceeds to block 684 and ends. In block 685, the system processes the fetched instructions. The processed instructions may initiate some or all of the actions shown in blocks 686-691. The system may initiate the actions in orders or sequences not shown in FIG. 6B.

In block 686, the instructions may cause the system to read or write data across the network. The system may use data sent or received in blocks 695 and 696 when reading or writing data. The system may also retrieve CGI scripts (such as those returned by GET, POST, and so on). Additionally, the system may perform other actions not shown in FIG. 6.

In block 687, the instructions may cause the system to recognize received utterances and touch tones (such as DTMF Tones). Caller ID or extended dialing digits may also be recognized to identify a caller or to recognize a unique identifier used to retrieve a data record stored on a workflow server. In block 688, the instructions may cause the system to play an audio file. In block 689, the instructions may cause the system to synthesize text to speech. In block 690, the instructions may cause the system to disconnect or transfer a call. In block 691, the instructions may cause the system to record some or all of an audio stream. After performing some or all of the actions in blocks 686-691, the routine proceeds to block 920 to await further instructions. Additionally, other instructions may be performed, such as mathematic, conditional, and/or logic operations, and so on.

An example of enhanced IVR navigation, as discussed above, will now be described. In this example, a mobile phone user wants to change his/her billing address. He dials his service provider's customer service number, such as "611."

The dialing of the number (or, when the device receives an indication that the user is attempting to connect to the number) triggers a script running in a background layer of the user's mobile device. The script scans a local database of IVR enhanced numbers for the dialed number. In this example, a match is found, and an associated IVR enhancement script loads and performs relevant actions.

At the destination, associated with the number, an IVR system answers the call with a prerecorded message. In this example, the system plays the following message to the user: "Welcome to Vector Mobile customer support." At this point, there may be a brief pause to allow the mobile device script to load and prepare for response.

The script, at the mobile device, synthesizes and sends a DTMF sequence to the IVR system that indicates to the IVR system the user's number (or, other identification information) and that the script is active on the mobile device.

The IVR system receives the DTMF sequence, decodes the user information (such as user account information, user login information, and so on), determines that the mobile device is running an IVR enhancement script, and plays another prerecorded message to the user, such as: "Dear Mr. Smith, please make a menu selection by either saying the desired menu option or look to your phone's display to see the options graphically." The IVR system then voices the menu options for the user and/or causes the mobile device to graphically present related menu options to the user via the user's mobile phone display.

The user sees the menu option "change my billing address" on the mobile phone's display, and selects the option using a directional button and/or softkey navigation.

The IVR system receives the menu selection by the user, sends the user a change billing address form to the user's display, and terminates the voice connection. The user then fills in the form using softkey navigation, and sends the form to a workflow server associated with the IVR system. For example, the running script sends an SMS message containing the address request change and the new address to the workflow server after receiving the form information from the user. The workflow server validates the address as a valid address and sends an SMS message to the mobile device signaling the validation of the address.

Upon receiving the return SMS message, the script dials a phone number, such as "6112345," and displays to the user a message such as "Now connecting with a customer service representative to verify your address. Please listen."

A customer service representative answers the call. At or near the same time, the representative receives information about the user and information about how to verify the user (such as the user's password, social security number, mother's maiden name, and so on). The representative uses the received information and verifies the user.

Upon verification, the customer service representative sends the updated billing address to a business support system. The customer service representative also causes an SMS message to be sent to the mobile device. The script may then receive the message, update the mobile device address book, and display a message to the user, such as: "Address update completed. Thank you for using Vector Mobile." The script then terminates.

FIGS. 7A-B present additional examples of enhanced IVR navigation. Referring to FIG. 7A, an example process flow illustrating the initiation of a call to an IVR associated number by a script is shown as routine 700. In this example, in block 710, a script running on the mobile device intercepts an SMS from the user's service provider to the user. The script may display an indication to the user, such as display balloon 711, asking the user if he/she would like to read the message. Upon receiving a positive indication 712 from the user, the routine proceeds to block 1720. Upon receiving a negative indication 713, the routine ends and sets a reminder 714 to trigger the user at a later time.

In block 720, the device presents the message to the user. In this example, the message relates to a special offer from the service provider. In decision block 730, if the user wishes to connect to the offer (i.e., the system receives a positive indication from the user 732), the routine proceeds to block 734, else the routine proceeds to block 740, 742, or block 743. In block 740, the user indicates that he/she is not interested at that time, and the system, in block 741, triggers a reminder, and ends. In block 742, the user indicates a request for more information, and the system may send the user an information page 743. The user may then input a positive indication 744, a negative indication 745, or may indicate a return 746 to the offer. In block 747, the user indicates a lack of interest in the offer, and the routine ends 748.

In block 734, the device, after receiving a positive indication from the user in blocks 732 or 744, initiates a voice call to an IVR system 330 and enters a promotional code for the offer. In some cases, the system will enter the IVR enhanced number and the promotional code for the user. For example, the system may enter the promotional code using DTMF tone sequence synthesis.

The description continues in the full USPTO document.