The present invention relates to an integrated information and communication network, and more particularly the invention relates to real-time communications that are conducted over a packet-switched network.
Large business enterprises often maintain a communication network, such as a PBX-based telephone network, and an information network, such as a LAN. The communication network is typically a circuit-switched network that includes multiple telephones that are individually connected to a proprietary PBX system. The communication network enables real-time communications (e.g., voice conversations) between two or more parties. The information network is typically a packet-switched network that is connected to desktop terminals, file servers, and other data network devices.
In order to eliminate the need to maintain two separate networks, integrated networks have been developed that can support real-time communications between two or more parties, as well as non-time-critical data transmissions. The integrated networks are packet-switched networks which typically utilize the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of network protocols to transfer packets. Some of the integrated networks still utilize proprietary PBX systems to provide traditional PBX features such as operator services, call waiting, call forward, call conference, call transfer, and camping. Other integrated networks provide traditional PBX features completely within a packet-based environment.
An example of an integrated network that utilizes packet switching to enable real-time communications and non-time-critical data transfers is disclosed in U.S. Pat. No. 5,742,596, issued to Baratz et al. (hereinafter Baratz). The Baratz system enables packets to be exchanged between two devices to accomplish real-time voice communications in conjunction with non-time-critical data transfers. The Baratz system incorporates many PBX features, including call transferring and call forwarding, and telephone system applications, such as voicemail, interactive voice response (IVR), automatic call distribution (ACD), and automatic message distribution (AMD), into an entirely packet-based system.
In the course of a single call conducted over an integrated network (e.g., the Baratz system), there may be interaction with more than one application that supports real-time communications. For example, a call may initially interact with an ACD application, then be transferred to an IVR application, and then be transferred to a voicemail application. In conventional integrated networks such as Baratz, an active call interacts with each application in isolation from the other applications. That is, the voicemail application does not share information with the IVR application or the ACD application and vice versa. In addition, call-specific information gathered by one application is not readily accessible by another application, either while the call is active or after the call is completed. Lack of communication between applications that support real-time communications can reduce the quality of service provided to a calling party when, for example, the called party is asked for redundant information or put through redundant steps. Enabling communication between different applications can be difficult because applications are often incompatible.
In view of the problems involved with applications that do not, or cannot, communicate with each other, what is needed is an integrated information and communication network that enables different applications to share information, especially while a real-time communication is active on the integrated network.
A method and a system for supporting a real-time communication on an integrated packet-based network involve accumulating information about the communication, referred to as signature data, while the communication is in progress and storing the signature data in a database that is openly accessible to any applications that are connected to the network.
Once signature data regarding an active real-time communication is accumulated, portions of the signature data may be utilized to further process the active real-time communication. In addition, the signature data may be updated during the communication setup, at any time during the course of the real-time communication, or after the real-time communication is complete. Providing an openly accessible communication profile that is accumulated and accessible while the communication is in progress allows applications to provide a higher level of service by tailoring actions to the profile of the specific communication.
In an embodiment, real-time communications conducted on an integrated network are supported by a signature service that is connected to the integrated network. The integrated network may include a gateway, a gatekeeper, application servers, terminals, and the signature service. The integrated network may also be connected to a circuit-based PSTN through a gateway. The signature service may reside on a single server that is connected to the integrated network. The signature service can alternatively be distributed throughout the network, with portions of the,signature service being supported by various devices or systems. For example, the signature service can be integrated with any of the gateway, gatekeeper, application servers, and/or terminals.
The signature service is preferably a database that stores information in, for example, a relational or object format. The database has an open format that allows data to be accessed by any application. The signature service is preferably a passive element that can be continually updated throughout the active life of a call. Throughout the specification, the term xe2x80x9ccallxe2x80x9d is used to represent a real-time communication between two parties, with the two parties interfacing with the integrated network through devices such as telephones or the terminals. A call may also represent a real-time communication between one party and a network application. For example, one party interacting with a voicemail system is a real-time communication between one party and an application. Real-time communications may also involve multiple parties, for example, a conference call between more than two parties. Real-time communications may also involve multimedia communications, such as video conferencing and white-boarding.
The function of the signature service in relation to a party-to-party communication that is conducted in real-time is described herein. The party-to-party communication may be, for example, two parties engaged in a conventional voice conversation that is at least partially supported by the packet-based network. In the first step a call setup routine is initiated to establish a connection between the calling party and the called party. Once the call setup is complete and the call is connected, packets containing voice information are exchanged between the calling party and the called party. The exchange of packets continues until the call between the calling party and called party is ended.
During the time when the call between the two parties is active, or xe2x80x9cin parallelxe2x80x9d with the active call, signature data may be generated. The signature data may be generated by the gateway, the gatekeeper, the application server, the terminals, and/or some other devices or systems. The content of the signature data is primarily non-voice data that may include, for example, the identification of the calling party, the call origin, the call type, the reason for transferring the call, the application type, the time/date of the call, and/or the duration of the call. Signature data may also be generated during call setup. Regardless of where the signature data is generated or the content of the signature data, if signature data is generated, signature data is used to update the signature service. As stated above, the signature service is an openly accessible database that stores received signature data in a relational or object manner. If signature data is not generated during the call between the two parties, the signature service is not updated and the call eventually ends. Once the call has ended, new signature data may be generated. For example, the ending time of the call or the bandwidth consumed by the call may be provided to the signature service as signature data. The signature data related to the call is maintained by the signature service and is available beyond the active life of the call.
The function of the signature service is also described in relation to a party-to-application communication that is conducted in real-time. A party-to-application communication is a communication in which a party interacts with one of the real-time communications applications that are available on the integrated network. An example of a party-to-application communication is a calling party interacting with an IVR application or an ACD application. The party-to-application communication may occur at any point during the active life of a real-time communication, for example, the party-to-application communication may occur before or after a party-to-party communication as described above.
In a first step, a call setup routine is initiated to establish a connection between a calling party and the application. Once the call setup is complete and the call is connected, packets containing information, such as voice or keypad entries, are transmitted to the application from the called party. Packets containing information such as computer-generated voice data may be transmitted to the calling party from the application in order to conduct the real-time communication. The exchange of packets continues until the call between the calling party and the application ends.
During the time when the call is active, or in parallel with the active call, multiple interactions with the signature service are possible. Before interaction with the application begins, it is possible that some signature data may be generated. If signature data is generated, the signature data is used to update the signature service. Once interaction with the application begins, the application may benefit from accessing a portion of the signature data that is maintained by the signature service. If the application requests some piece of signature data, the signature data is fetched from the signature service. Also during interaction with the application, some signature data may be generated. If signature data is generated, the generated signature data can be used to update the signature service. It should be noted that while the application is exchanging signature data with the signature service, the real-time communication between the calling party and the application continues in parallel. That is, packets of data involved with transmitting the real-time communication are separate and distinct from packets of data involved with transmitting the signature data to and from the signature service.
Once the interaction with the application is complete, there is another opportunity to generate signature data. Whether or not signature data is generated, when the exchange of real-time communication packets between the calling party and the application is completed, the call is ended. However, after the call has ended, signature data may again be generated.
In another method of the signature service, a single call may interact with many applications or parties during the active life of the call. In this case, during each interaction there is an opportunity to exchange signature data with the signature service. For example, an application may fetch particular signature data from the signature service in order to tailor the function of the application. Alternatively or additionally, an application may generate new signature data that is to be deposited within the signature service.
An advantage of the signature service is that during the life of the call, signature data stored within the signature service creates a call history, or call profile, concerning the call. Having a call history available to the various applications that may interact with a call enables the applications to provide a higher level of service to the called party by making decisions that are at least partially based on the history of the call. In addition, because the signature service operates utilizing a network protocol suite such as TCP/IP, the signature service can be easily integrated into the network.
USPTO Backgrounds
USPTO Backgrounds