IVR Server Audio Data Integration via Non-Audio Protocols
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing IVR methods are limited to specific audio data communication, restricting their use to only voice applications and databases, and require redevelopment for non-audio interactions, limiting access to diverse services and information sources.
Innovation Solution
A method and system that utilize a data transmission protocol not specific to audio, allowing software applications to interact with networks using program elements specific to voice, enabling integration with existing applications and databases, and allowing new IVR applications to be integrated into packet-mode telecommunications networks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If IVR methods use audio-specific protocols and dedicated voice applications, then audio data processing is reliable and standardized, but the system cannot access diverse services and information sources from non-audio applications
Solution Approach 1:
The patent applies universality by enabling a single IVR system to handle both audio-specific protocols (like RTCP) and general data transmission protocols (like TCP/IP). The server can process audio data streams while simultaneously accessing non-audio services and databases through standard network protocols, making the system multi-functional without requiring separate dedicated systems for each type of interaction
Solution Approach 2:
The patent introduces an intermediary layer (the IVR server with its communication module) that mediates between audio data streams and general network services. This intermediary translates and bridges audio-specific communications with standard network protocols, allowing audio applications to access diverse information sources without direct integration complexity
2Productivity
If dedicated voice applications are developed in special-purpose languages, then audio processing is optimized and reliable, but redevelopment is required for every non-audio interaction
Solution Approach 1:
The system achieves universality by allowing a single IVR application to serve multiple purposes - handling traditional audio interactions (voice commands, DTMF) while simultaneously supporting non-audio interactions through standard protocols. This eliminates the need to create separate dedicated applications for different interaction types, reducing redevelopment time while maintaining audio processing efficiency
Solution Approach 2:
The patent applies dynamics by making the IVR system adaptable and flexible in handling different types of data interactions. The system can dynamically switch between processing audio data streams and handling general network communications, adjusting its behavior based on the interaction type without requiring complete reconfiguration or redevelopment
3Reliability
If IVR applications are designed for circuit-switched networks, then audio communication is stable and reliable, but integration with packet-mode networks is difficult
Solution Approach 1:
The patent applies universality by designing an IVR system that can operate across multiple network types - maintaining stable audio communication on circuit-switched networks while simultaneously integrating with packet-mode networks like the Internet. The server handles both traditional telephony protocols and modern IP-based protocols, enabling seamless multi-network operation without sacrificing reliability or adaptability
Data Source
AI summary
A method of processing a data stream comprising audio data exchanged over a network between a server (SERV) and at least one telephone terminal, the data stream corresponding to a telephone call from said terminal during which a user has produced at least one event. The method comprises a step a) consisting in extracting from the stream audio data (INST2) corresponding to each event, and a step b) consisting in executing at least one task relating to the extracted audio data (INST2) and executable by a software application (AL), the software application being designed to interact with the network by using a data transmission protocol that is not specifically audio. The method further comprises a step c) of introducing into said software application (AL) at least one instruction (INST2′) relating to the extracted audio data (INST2) and adapted to activate the step b).