CA2204132C - A network-based telephone system providing coordinated voice and data delivery - Google Patents
A network-based telephone system providing coordinated voice and data delivery Download PDFInfo
- Publication number
- CA2204132C CA2204132C CA002204132A CA2204132A CA2204132C CA 2204132 C CA2204132 C CA 2204132C CA 002204132 A CA002204132 A CA 002204132A CA 2204132 A CA2204132 A CA 2204132A CA 2204132 C CA2204132 C CA 2204132C
- Authority
- CA
- Canada
- Prior art keywords
- data
- msap
- call
- gdi
- received
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
- H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0029—Provisions for intelligent networking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13072—Sequence circuits for call signaling, ACD systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13527—Indexing scheme relating to selecting arrangements in general and for multiplex systems protocols - X.25, TCAP etc.
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13541—Indexing scheme relating to selecting arrangements in general and for multiplex systems routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
- H04Q2213/13546—Intelligent Peripheral
Abstract
A method of processing a phone call from a caller (112) in a network-based telephone system (100), the network-based telephone system (100) including a plurality of switches (108) and an intelligent peripheral (IP) (104) for interfacing the plurality of switches (108) to a service control point (SCP) (102). When a phone call is received at one of the plurality of switches (108), the call is sent to the IP (104). The IP (104) then requests that the SCP (102) perform a call processing request. Service logic within the SCP
(102) is accessed in order to process the phone call according to the call processing request. The service logic then requests and receives account information from one or more external systems (106). The phone call is routed to a selected telephone (117) based on the account information received from the one or more external systems (106). The received account information is routed to the selected telephone (117).
(102) is accessed in order to process the phone call according to the call processing request. The service logic then requests and receives account information from one or more external systems (106). The phone call is routed to a selected telephone (117) based on the account information received from the one or more external systems (106). The received account information is routed to the selected telephone (117).
Description
A Network-Based Telephone System Providing Coordinated Voice and Data Delivery Description Background of the Invention The present invention relates generally to the field of network-based telephone systems, and more specifically to the problems of interaction between a caller and a network-based telephone system, accessing data from external systems, and providing data to a service agent.
U.S. Patent Nos. 5,450,480 ("A Method of Creating a Telecommunication Service Specification") and 5,511,116 ("Method of Creating and Accessing Value Tables in a Telecommunication Service Creation and Execution Environment") describe a system and method for creating customized telecommunication services and instantiating and maintaining the services in a call processing network. The system includes a Service Provisioning and Creation Environment (SPACE, a registered trademark of Bellcore) application, which creates call processing records (CPRs). CPRs define how a received telephone call is processed for a particular customer. The CPRs are transferred to service control points (SCPs) to implement the services.
Switches in the network needing information to process a call send queries to the SCPs. A Multi-Services Application Platform (MSAP) in the SCP accesses a CPR based on a "key" .
associated with the call. MSAP processes the nodes cf the CPR and issues corresponding call processing instructions back to the switch. The switch routes the call based on the instructions.
While executing a CPR, the SCP may request information from the caller using certain nodes. The type of information which the SCP can request is somewhat limited, however. For example, the SCP can request the caller to insert a PIN
number. This limited interaction between a caller and the SCP may be inadequate to complete the call, requiring a.
service agent to intervene and handle the call manually. Of course, manual call processing is typically slower and more costly than automated call processing.
Other than these inputs from a caller, MSAP cannot access information from external systems. Instead, MSAP can only access information that is available at the SCP running MSAP. Again, this information may be inadequate to properly execute the call processing.
Accordingly, it is desirable to increase the intelligence of a system for processing telephone calls.
It is also desirable to increase the flexibility in a system for processing telephone calls.
It is also desirable to provide greater interaction between a caller and a system for processing telephone calls.
It is also desirable to provide greater accessibility to information from external systems by a system for processing telephone calls.
It is also desirable to augment the existing process of directing calls to service agents.
It is also desirable to route a caller to the appropriate agent based on information about the caller.
WO 96/14704 PG"T/US95114089 It is also desirable to provide routing of a call to the appropriate agent while routing data associated with the call to a display terminal of the same agent.
It is also desirable to provide network reliability in routing a caller to the appropriate agent.
Additional desires of the invention will be set forth in the description which follows, and, in part, will be apparent from the description or may be learned by practice of the invention. The advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.
Disclosure of the Invention To achieve the foregoing desires and objects, and in accordance with the purposes of the invention as embodied and broadly described herein, a method of processing a phone call of the present invention comprises the steps of receiving the phone call at a switch, requesting call processing instructions from the SCP, accessing, at the SCP, service logic which specifies handling of the phone call corresponding to the call processing instructions, requesting, at the SCP, data from one or more external systems according to the service logic, receiving, at the SCP, data from the one or more external systems according to the service logic, routing the phone call to an appropriate agent based on the data received from the one or more external systems, and routing the data to the same agent.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.
Brief D~scription of tha Draxiaaa The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate presently preferred implementations of this invention and, together with the general description given above and the detailed 4 PC"f/US95/14089 description of the preferred implementations given below, serve to explain the principles of the invention.
In the drawings:
Fig. 1 is a block diagram of a network-based telephone system in accordance with the present invention;
Fig. 2 is a block diagram of a service control point (SCP) in accordance with the present invention;
Fig. 3 shows the internal interfaces of a peripheral interface (PI) in accordance with the present invention;
Fig. 4 is a schematic representation of software modules corresponding to a PI in accordance with the present invention;
Fig. 5 shows a configuration having a plurality of intelligent peripherals (IPs) interfaced with a plurality of PIs in accordance with a preferred embodiment of the present invention;
Fig. 6 illustrates internal tables which interface with a generic data interface (GDI) in accordance with the present invention;
Fig. 7 is a flowchart illustrating an operation of a GDI
in accordance with a preferred embodiment of the present invention;
Fig. 8 illustrates sub-requests in an Outstanding Request Table in accordance with the present invention;
Fig. 9 illustrates an example of a call processing record in accordance with the present invention;
Fig. 10 is a flowchart showing the operation of ACD 108;
Fig. 11 is a flowchart showing the operation of ACD
protocol handler 125; and Fig. 12 is a flowchart showing the operation of agent protocol handler 127.
Best Mode for Carr~rina Out he Inveatioa As shown in Fig. 1, a preferred embodiment of a network-based telephone system 100 of the present invention includes the conventional elements of the public switched network 110, a plurality of telephones 112 (only one shown), an automatic call distributor (ACD) 108, an intelligent peripheral (IP) 104, a service control point (SCP) 102, external systems 106, an agent workstation network 115, a plurality of agent workstations 116 (only one shown) each having a telephone 117 and a display terminal 119.
public switched network 110 is connected to ACD 108 and IP 104. ACD 108 is connected to telephones 117 of agent workstations 116 and SCP 102. IP 104 is connected to public switched network 110 and is also connected to SCP 102, which is connected to external systems 106 and agent workstation network 115. Agent workstation network 115 is connected to display terminals 119 of agent workstations 116.
A call placed by a caller on telephone 112 is received by public switched network 110 and forwarded to IP 104. One of the functions of the IP 104 is to interface as an intelligent speech peripheral with the caller on telephone 112. For example, IP 104 can preferably play digitized announcements to a caller, prompt the caller to enter call processing information, and collect call processing information.
When a call is routed to IP 104 from public switched network 110, IP 104 requests instructions from SCP 102 on how to handle the call. As described in more detail below, the SCP 102 provides interface instructions to the IP 104 based on a call processing record. The caller-to-IP 104 connection, therefore, becomes an intelligent interactive communication, with the SCP 102 providing instructions to the IP 104 in response to information provided by the caller.
The use of the SCP 102 in conjunction with IP 104 automates the call processing and substantially reduces agent time for handling routine tasks.
If necessary, the SCP may instruct the IP 104 to route the caller 112 to ACD 108. The SCP 102 will instruct the IP
104 as to the desired ultimate destination for the caller 112 .(i.e., a particular agent or group of agents). The ACD 108 will then manage the connection of the caller 112 to an agent's telephone 117 based on various criteria. As the caller progresses through the ACD 108, ACD 108 informs the SCP 102 of this progress. In a preferred embodiment, ACD 108 is an AT&T 5ESS Pinnacle'" ACD, however, any known type of ACD
could be used.
Preferably, IP 104 also provides additional functions s~~ch a.s au~tomat.ic e~xthound r?i.alin.g; cahere IP 104 plscea a call to an outside telephone 112 according to instructions received from SCP 102.
In a preferred embodiment, IP 104 is a Periphonics VPS
9000 or Bellcore Intelligent Services Peripheral (ISP~, vets.
2Ø
External systems 106 preferably include databases or other network-based systems, which contain data that is useful in processing a call, including, for example, account status data, repair information, customer profile data, and ordering information. Account status data may indicate whether a customer is in good standing or whether the customer's service has been suspended for nonpayment. Repair information may indicate the repairs that have been made to a particular telephone line, whether a particular line is in service, and the type of problems a particular line is experiencing. Customer profile data may contain information about the customer that may be useful in directing the customer's call, such as the type of services that are installed and the geographical location of his telephone line. Ordering information may include, for example, the costs of services and the availability of services to particular customers. External systems 106 may comprise various hardware structures, including, for example, an IBM
TN-3270 database.
As described above, ACD 108 may also distribute the call to an agent workstation 116 according to instructions received by SCP 102. An agent at agent workstation 116 may be a regular service agent capable of handling various customer needs or a specialized service agent capable of handling specific customer needs. Based on information received from IP 104 and external systems 106, SCP 102 may SEP 17 '96 10~44RM HELLC~E 2018292366 P.3 - r~r~us 95m4~~g9 1 7 StN 1996 direct ACD 108 to distribute the call to an appropriate agent workstation 116. For example, a caller may be routed to the i collections department it the caller's account hss been suspended for non-payment. Or, a caller may be routed to an agent specializing in "work-at-home' accounts if the caller s i line is used is a home office. In handling a call, an agent may have access to data stored in external systems.
Fig. 2 shows a block diagram of SCP 102 architecture i according to a preferred embodiment of the present invention.
As shown, the SPACE 118 application interfaces with the MSAP
application 120. Although SPACE is shown outside SCP 102, in an alternate embodiment, SPACE may be included in SCP 102. MSAP
120 communicates with Message Delivery interface (MDT) ,122, which delivers rnessaQes from MSAP 120 to either peripheral interface (PI) 128 or generic data interface (GDI) 124. MSAP
120, an application that is resident in the SCP 102, executes the service logic of the accessed call processing record and issues instructions to the other elements of the system I00.
PI 128 interfaces IP 104 to SCP 102 and allows these two devices to communicate. GDI 124 transmits reguesta for data to the appropriate external systems 106 via protocol handlers 126 and packages the data received from the external systems 106 into a message to be transmitted to and used MSAP 120. t~DI
124 can also send data resident in, or retrieved by, SCP 102 to the external systems. In addition, GDI 124 sends and retrieves data to and from ACD 10B and agent workstation network 115 via ACD protocol handler 125 and agent protocol handler 127, respectively. PI 128 and GDI 124 are described in detail below.
PI 128 establishes and maintains a data network communication link between IP 104 and SCP 102. Pz 128 handles asynchronous transmission of messages between IP 104 and SCP
102. Further, PI 128 translates messages into a format understood by either IP 104 or SCP 102. In a preferred embodiment, the message formats supported by PI 128 are I described in published Bellcore Documents TR-TSY-000402, A;~ENDED SHEET
SEP 17 '96 10:45RM HELLCORE 2018292366 ~1~~5 9 5 ~.l 4 Q
July 1989 (hereinafter TR402 format) and TA-NWT-001129, October 1992 (hereinafter TA1129+ format), which are understood by IP
i 104 and SCP 102, respectfully. However, other message formats could be used by IP 104 and SCP 102.
i During normal operation, PI 128 is simultaneously waiting for messages from IP 104 and MSAP 120. Messages I received by PI I28 are added to a queue 129, while messages transmitted from PI 128 are removed from the queue 129.
Fig. 3 shows the internal interfaces of PI 128, including Node Manager Application Programming Interface (API) 130, Node Administration API 132. Maintenance Operations Console (MOC) API 134, Transmission Control Protocol/Internet Protocol (TCP/IP) API 136, Configuration File 138, and Message Delivery (MD) 122.
Node Manager API 130 is responsible for maintaining the reliability of SCP 102 by monitoring the statue of the nodes in SCP 102. Node Administration API 132 contains information regarding the configuration of SCP 102 such as the addresses of each IP 104 connected to SCP 102. MOC API 134 interfaces a I, computer terminal, not shown in the drawings, with SCP 102 to ~, permit, for example, a technician to conduct maintenance on SCP
102. TCP/IP API 136 provides and interface between SCP 102 and IP 104 using the TCP protocol.
Configuration File 138 contains information relevant to the operations of PI 128. This information includes parameters '~ for configuring PI 128, such as identifying the addressee of I' IPs 104 and specifying the priority of a message in queue~129.
I Changes to the configuration file 138 are preferably effected upon initialization of PI 128.
In a preferred embodiment, PI 128 is implemented as software, Fig. 4 depicts a block diagram of the preferred I software modules of PI 128. In PI 128, a message is then validated by module 142 and encoded by module 144 to a format 'I understandable by MSAP 120. Module 146 transmits to and receives messages from MSAP 120. Module 146 transmits to and receives messages from MSAP 120 through MD 122. Module 14B
i ', validates a message received from MSAP 120 and module 150 AMEND~D SHEET
- g -encodes the message in a format understood by IP 104. Module 152 provides the message to IP 104.
In processing a received message, PI 128 determines whether a translation is required. If so, PI 128 decodes the received message and determines whether the message is valid.
FI 128 then converts the message to a format understood by the receiving device using conversion tables (not shown).
For example, a message being received by IP 104 from SCP 102 is converted from TR402 format into TA1129+ format and vice-versa.
If PI 128 receives an invalid message from IP 104, the message is dropped and further processing of the message ceases. Timers in IP 104 then either resend the message or transfer the call. If PI 128 receives an improperly formatted message from MSAP 120, PI 128 returns an error message to MSAP 120.
Fig. 5 shows a preferred embodiment of the present invention having redundant connections between a plurality of IPs 104 and SCP 102 to provide high system reliability. SCP
102 distributes transactions in a "round-robin" fashion to each of a plurality of PIs 128. PIs 128 are configured to make redundant connections with one or more IPs 104. Thus, in the case of a failed connection, a message can still be transmitted between IP 104 and SCP 102.
Each PI 128 attempts to keep all configured connections, including redundant connections, active at all times. PI 128 logs the general status of each of its circuit connections, indicating whether the connection is good, degraded, or poor.
A good connection indicates that all the configured connections are active; a degraded connection indicates that at least one, but not all, connections have failed; and a poor connection indicates that all connections have failed.
When any connections have failed, a periodic timer mechanism in PI 128 causes PI 128 to make another attempt to establish the connection after a predetermined time. When all the configured circuits are active, PI 128 deactivates its periodic timer mechanism. When an active circuit returns an unexpected error, that circuit is considered failed and the periodic timer of PI 128 reactivates and attempts are made to reestablish the circuit. A badly formed message ' received over a circuit is considered to be a circuit failure, resulting in activation of the periodic timer of PT
i23.
GDI 124 gives MSAP 120 transparent real time access to information stored in external systems 106 by allowing MSAP
120 to request information without knowledge of the source of that information.
Fig. 6 illustrates internal tables stored in GDI 124 for handling requests for information from MSAP 120. These tables include Data Elements Table 154, GDI Queues Table 156, External Systems Table 158, and Outstanding Request Table 160. Data Elements Table 154 is used by GDI 124 to forward a request for data to the appropriate external systems 106.
GDI Queues Table 156 is used by GDI 124 and protocol handlers 126 to determine what queue names to use for exchanging messages. External Systems Table 158 is used by protocol handlers 126 to obtain addressing information for communicating with external systems. Outstanding Request Table 160 is used to maintain a list of outstanding requests by GDI 124.
Protocol handlers 126 manage the physical and logical connections to external systems 106 and interact with external systems 106 to retrieve information. In a preferred embodiment, each external system 106 has a corresponding protocol handler 126.
ACD protocol handler 125 manages the physical and logical connection to ACD 108 and interacts with ACD 108 to receive status information on calls queued within ACD 108.
ACD protocol handler 125 is discussed in more detail below.
Agent protocol handler 127 manages the physical and logical connection to agent workstation network 115 and interacts with agent workstation network 115 to send information needed to serve a call to the display terminal 119 of the agent workstation 116 to which the call is routed . CA 02204132 1997-07-29 SEP 17 '96 10:45AM BELLCORE 2018292366 P.5 _ _ ~CT/US 9 5 ~ ~ ~. (l g 9 ~P~/~$ ~ 7 SEP 1996 by ACD 108 at the time that the call is routed to that agent workstation 116. Agent protocol handler 127 is discussed in more detail below.
With reference to flowchart 162 shown in Fig. 7, the manner in which GDI 124 handles a request for data from MSAP
120 will now be described. Initially, GDI 124 receives a GetData request, described in detail below, from MSAP 120 (step 163). GDI 124 decodes the GetData request to determine the specific data elements being z~equested by MSAP 120 (step 164).
Using Data Elements Table 154, GDI 124 determines which external systems 106 should be accessed to obtain the requested data elements (step 165). Data Elements Table 154 is a lookup table which identifies which of external systems 106 the specific data elements are located. Thus, once GDI 124 has decoded the GetData request and determined the specific data elements requested by MSAP 120, GDI 124 may look up the external system corresponding to each specific data element in Data Elements Table 154. GDI 124 then forwards "sub-requests"
requesting the data elements to protocol handlers associated with the appropriate external systems (step 166). Outstanding Request Table is updated to keep track of the outstanding ~sub-requests" (step 167).
GDI 124 then determines whether a reply has been received (step 168). If a reply is received by GDI 124 from external systems 106, Outstanding Request Table is updated to keep track of the partial completions (step 169).
GDI 124 then determines if all of the replies to the sub-requests have not been returned (step 170). If not, GDI 124 waits for additional replies. If all of the replies have been received, GDI 124 returns the completed message to MSRP 120 (step 172).
If at step 168 GDI 124 determines that a reply has not been received, the message will also be returned to MSRP 120 (step 172) if a predetermined time passes (step 171). Thus, a message is returned to MSAP 120 when all of the outstanding sub-reauests have been responded to or timed out.
AMENDED SHEET
Fig. 8 depicts the GDI Outstanding Request Table 160.
Blocks A, B, and C represent outstanding requests received by GDI 124 from MSAP 120. Blocks A1, A2, and A3; Bl, B2, and B3; and C1, C2, and C3 represent sub-requests created from outstanding requests A, B, and C, respectively. Blocks A1R, A2R, and B3R represent responses received by GDI 124 in response to sub-requests A1, A2, and B3, respectively.
Outstanding Request Table 160 is constructed and updated as each request for information from MSAP 120 is received by GDI 124. Upon receiving a request from MSAP 120, GDI 124 creates sub-requests, which are forwarded to the appropriate protocol handler. GDI 124 awaits a response for each outstanding sub-request.
Three types of responses may be stored in Outstanding Request Table 160. First, GDI 124 may store response A1R
from external systems 106, indicating that a result was received in response to the sub-request. Second, GDI 124 may store response A2R from external systems 106, indicating that an error was received from external systems 106. Such an error may indicate that external systems 106 are unable to process the sub-request. Finally, GDI 124 may store response B3R, indicating that no response was received from external systems 106 within a predetermined time.
Nodes are the basic units that define the logical operations to be performed during call processing. MSAP 120 processes the nodes and issues corresponding requests or instructions to the other elements of system 100. U.S.
Patent Nos. 5,450,480 and 5,511,116 describe various nodes supported by MSAP 120 including GetData, SendData, and WaitForEvent nodes. In a preferred embodiment of the present invention, the GetData, SendData, and WaitForEvent nodes may be modified as described below. Also, the present invention contemplates a TransferCall node, also described below.
The GetData node allows MSAP 120 to request data from external systems 106 for a particular account. A GetData request issued by MSAP 120 includes a handle call variable, accounts ID, and a list of call variables. The handle call variable identifies a GetData request and is used to retrieve the requested information and check the status of the request. The account ID identifies the caller's account.
The list of call variables specify the data requested by MSAP
120 from the external systems I06.
Upon receiving a GetData request from MSAP 120, GDI 124 determines which external systems 106 contain the requested data as described above. GDI 124 formats and transmits sub-requests based on the GetData request received from MSAP 120 to the appropriate external systems. GDI 124 waits for a response for each of the sub-requests before returning all of the requested information to MSAP 120. If GDI 124 does not receive a reply to all of the sub-requests after a predetermined time, an error indication is returned to MSAP
120 along with the data that was received. While information may be returned to MSAP 120 from GDI 124, the information is not available for use by MSAP 120 until after MSAP 120 executes a WaitForEvent node.
The SendData node allows MSAP 120 to send data to external systems 106 and agent workstation network 115. A
SendData request issued by MSAP 120 to external systems 106 contains a handle call variable, account ID, and a list of call variables along with corresponding data. The handle call variable identifies a SendData request and is used to obtain the status of the request. The information corresponding to the list of call variables is stored in the external systems 106 according to the account ID.
Upon receiving a SendData request from MSAP 120, GDI 124 determines where it should send the data. GDI 124 formats the data from the received SendData request and transmits the formatted data to the appropriate protocol handlers. GDI 124 waits for positive acknowledgment from the protocol handlers indicating that the data has been accepted before sending a status reply to MSAP 120. However, the status of the SendData request is not available to MSAP 120 until after MSAP 120 executes a WaitForEvent node.
The WaitForEvent node gives MSAP 120 access to the data or status of a GetData or SendData request. The WaitForEvent instruction specifies a handle call variable, which corresponds to a handle call variable specified in a GetData or SendData request. All requests returned to MSAP 120 from a GetData or SendData request are not available to MSAP 120 until after MSAP 120 executes a WaitForEvent node. When a WaitForEvent instruction has been issued, no further instructions are executed by MSAP 120 until the requested information has been returned. When a reply has been returned, the information is assigned to the call variables specified in the request and the status of the request is returned.
While the GDI 124 is retrieving the requested information, MSAP 120 may issue additional instructions to IP
104, for example, to obtain additional information from the caller or to play digitized messages before a WaitForEvent request is issued. In this way, caller 112 is not simply waiting for MSAP 120 to receive a reply to a request.
The TransferCall node allows MSAP 120 to instruct public switched network 110 to route a call to an agent workstation 116, together with data about caller 112. The TransferCall instruction, preferably including a transfer number and account number, can be transmitted, for example, to ACD 108 where the call is queued and subsequently routed to a specialized agent workstation 116 identified by the transfer number.
To illustrate the operation of system 100, Fig. 9 shows an example of a call processing record designated by numeral 210. In this example, call processing record 210 routes the caller to a "specialized" agent based on the caller's profile.
After a received call has been routed to IP 104, IP 104 requests call processing instructions from SCP 102. Based on predetermined information in the call, such as the account number or telephone number, SCP 102, under the control of MSAP 120, executes a corresponding call processing record 210.
As shown in the example of Fig. 9, PlayAnnouncement node 180 instructs IP 104 to welcome the caller with a digitized announcement. GetDigits node 182 causes IP 104 to ask the caller to enter the calier'S account number or telephone number. MSAP checks the result of the digit collection request to decide if the caller responded to the prompt because, for example, the caller may not have touch tone. If the result is a "1," indicating that the entered telephone number is in error, MSAP 120 executes RouteToWithData node .
184, causing the call to be routed to a "regular" (i.e. non-specialized) representative. If the result is a "2,"
indicating that the telephone number has been verified by MSAP 120, MSAP 120 executes a GetData node 186, requesting customer profile information from GDI 124.
If the result to the GetData request is a "1,"
indicating that the caller is a particular market customer, SendData node 187 and RouteToWithData node 188 are executed, sending the collected data and routing the caller to an agent specialized in handling the particular market customer.
If the result to the GetData request is a "2,"
indicating that the caller "works at home," SendData node 189 and RouteToWithData node 190 are executed, sending the collected data and routing the caller to an agent specialized in handling customers who "work at home."
If the result to the GetData request is a "3,"
indicating that the account is a residential account, GetDigits node 192 is executed, causing IP 104 to prompt the caller to choose between a residential agent or automated application. If the caller inputs a "0" choosing a residential agent, the caller is routed to an agent specializing in residential accounts by RouteToWithData node 194 and the associated data is also sent to this agent by SendData node 193. If the caller presses any other key, indicating automated applications, Handover node 196 is executed, causing the call to be handled by another call processing record.
If the result to the GetData request is a "4,"
indicating that the account has been suspended for nonpayment, SendData node 199 and RouteToWithData node 200 are executed, sending the ~:uilected data and routing the call to the collections department.
Finally, if the result to the GetData request is a "5,"
indicating that the customer profile does not satisfy any of the other choices, the caller is routed to a "regular"
representative by RouteToWithData node 202 and the collected data is sent to this agent by SendData node 201.
The manner in which the obtained data and the call are routed to agent workstation 116 will now be described with reference to Figs. 10-12. Fig. 10 is a flowchart showing the operation of ACD 108. Fig. 11 is a flowchart showing the operation of ACD protocol handler 125. Fig. 12 is a flowchart showing the operation of agent protocol handler 127.
ACD 108 generally waits for calls to be routed (step 300). When IP 104 receives an instruction from SCP 102 to route a call to a particular agent or group of agents, the IP
104 utilizes the Public Switched Telephone Network to transfer the call to the ACD 108. When the ACD 108 receives the call, it places the call in a queue established for the appropriate agent or group of agents that provide the requested service (step 302). The ACD queue includes the telephone number provided by the caller, an internal caller ID, the status of the queued call, and the time the call was entered into the queue. Once the call is entered in the queue, ACD 108 sends a PROMPT message to ACD protocol handler 125 (step 304) including the account number entered by the caller and the internal caller ID.
ACD 108 then maintains the call in the queue until one of the following events occurs: (1) an agent becomes available to take the call (step 306); or (2) the caller abandons the call (step 314).
When an agent becomes available, ACD 108 routes the call to that agent workstation 116. At the same time, ACD 108 updates the status of the call in the queue from "waiting" to "connected" (step 307) and sends a CONNECT message to ACD
protocol handler 125 (step 308) including the internal call ID and the position ID of the agent workr~tation 116 to which the ACD 108 routed the call.
ACD 108 informs ACD protocol handler 125 when a call is completed by issuing a DISC message to ACD protocol handler 125 (step 312), including the internal caller ID. In the event a caller abandons a call, ACD 108 sends an AHAND
message (step 316) including the internal caller ID to ACD
protocol handler 125.
Referring to Fig. 11, in response to a PROMPT message (step 400), ACD protocol handler 125 maps the received account number and internal caller ID in a table (step 402).
If ACD protocol handler 125 does not receive a prompt message (step 400) and after step 402, ACD protocol handler 125 looks for a CONNECT message (step 404). Upon receiving the CONNECT
message, ACD protocol handler 125 forwards the agent position ID and the corresponding account number to agent protocol handler 127 (step 406). ACD protocol handler 125 then determines whether a DISC message has been received (step 412). If so, it translates the internal caller ID to the corresponding account number (step 409) and instructs agent protocol handler 127 to discard any buffered data associated with that account number (step 410). ACD protocol handler 125 contains processing by determining whether an ABAND
message has been received (step 408). If so, it converts the internal caller ID to the corresponding account number (step 407) and instructs agent protocol handler 127 to discard any buffered data associated with the corresponding account number (step 410).
Referring now to Fig. 12, when agent protocol handler 127 receives an instruction from GDI 124 to send data to an agent (step 500), agent protocol handler 127 buffers the received data in correspondence with the account number provided by the caller (step 502).
In response to an instruction to forward data from ACD
protocol handler 125 (step 504), agent protocol handler 127 obtains a workstation Internet Protocol address corresponding to the agent position ID utilizing a Domain Name Service (DNS) (step 506). The agent protocol handler 127 then sends the collected data corresponding to the account number received from ACD protocol handler 125, to agent workstation network 115.
Agent workstation network 115 reads the address attached to the data message and routes the information to the display terminal 119 of the agent workstation 116 to whom ACD 108 routed the call. In this manner, delivery of data to the workstation of agent workstation 116 can be coordinated with the routing of the call to the same service agent. Thus, service agents may serve customers more effectively and efficiently.
Because the data to be sent to an agent may be too lengthy to include in a single TCAP message sent from MSAP
120 to GDI 124, it may be necessary for MSAP 120 to send the data to GDI 124 in a series of messages. In this case, any messages required after the first messages are sent preferably include a tag identifying the subsequent messages as a continuation of the previously sent message. Agent protocol handler 127 accumulates the data contained in these multiple messages, strips the tag number attached to the subsequent messages, and sends the data to the agent workstation network 115 in a single message.
Agent protocol handler 127 maintains the data in the buffer until a message is received from ACD protocol handler 127 instructing agent protocol handler 127 to discard the data (step 508) or until a predefined period of time expires during which the data has been buffered (step 512). In either event, agent protocol handler 127 discards the buffered data (step 510).
The purpose of the time limit, as well as that of the other time limits discussed above, is to ensure that the queues and buffers do not become overloaded due to queued calls and buffered data that, for some reason, were not properly discarded when a call was abandoned or discontinued.
The times entered into the various queues of the abo~~e described system may be provided by a common time server.
Preferably, a Network Time Protocol (NTP) is utilized to synchronize off a coon time server.
While there has been illustrated and described what are at present considered to be preferred implementations and methods of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the invention.
For example, although the present invention has been described utilizing a separate agent telephone 117 and agent display terminal 119, as well as separate communications links connecting the system to the agent telephone 117 and agent display terminal 119, those of ordinary skill in the art will appreciate that agent telephone 117 and agent display terminal may be integrated in a single communication terminal, and that the voice signals from the caller and the data from SCP 102 may be delivered over a single Integrated Services Digital Network (ISDN) line.
In addition, many modifications may be made to adapt a particular element, technique or implementation to the teachings of the present invention without departing from the central scope of the invention. Therefore, it is intended that this invention nct be limited to the pø--vticular embodiments and methods disclosed herein, b~4: that the invention include all embodiments falling within the scope of the appended claim.
U.S. Patent Nos. 5,450,480 ("A Method of Creating a Telecommunication Service Specification") and 5,511,116 ("Method of Creating and Accessing Value Tables in a Telecommunication Service Creation and Execution Environment") describe a system and method for creating customized telecommunication services and instantiating and maintaining the services in a call processing network. The system includes a Service Provisioning and Creation Environment (SPACE, a registered trademark of Bellcore) application, which creates call processing records (CPRs). CPRs define how a received telephone call is processed for a particular customer. The CPRs are transferred to service control points (SCPs) to implement the services.
Switches in the network needing information to process a call send queries to the SCPs. A Multi-Services Application Platform (MSAP) in the SCP accesses a CPR based on a "key" .
associated with the call. MSAP processes the nodes cf the CPR and issues corresponding call processing instructions back to the switch. The switch routes the call based on the instructions.
While executing a CPR, the SCP may request information from the caller using certain nodes. The type of information which the SCP can request is somewhat limited, however. For example, the SCP can request the caller to insert a PIN
number. This limited interaction between a caller and the SCP may be inadequate to complete the call, requiring a.
service agent to intervene and handle the call manually. Of course, manual call processing is typically slower and more costly than automated call processing.
Other than these inputs from a caller, MSAP cannot access information from external systems. Instead, MSAP can only access information that is available at the SCP running MSAP. Again, this information may be inadequate to properly execute the call processing.
Accordingly, it is desirable to increase the intelligence of a system for processing telephone calls.
It is also desirable to increase the flexibility in a system for processing telephone calls.
It is also desirable to provide greater interaction between a caller and a system for processing telephone calls.
It is also desirable to provide greater accessibility to information from external systems by a system for processing telephone calls.
It is also desirable to augment the existing process of directing calls to service agents.
It is also desirable to route a caller to the appropriate agent based on information about the caller.
WO 96/14704 PG"T/US95114089 It is also desirable to provide routing of a call to the appropriate agent while routing data associated with the call to a display terminal of the same agent.
It is also desirable to provide network reliability in routing a caller to the appropriate agent.
Additional desires of the invention will be set forth in the description which follows, and, in part, will be apparent from the description or may be learned by practice of the invention. The advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.
Disclosure of the Invention To achieve the foregoing desires and objects, and in accordance with the purposes of the invention as embodied and broadly described herein, a method of processing a phone call of the present invention comprises the steps of receiving the phone call at a switch, requesting call processing instructions from the SCP, accessing, at the SCP, service logic which specifies handling of the phone call corresponding to the call processing instructions, requesting, at the SCP, data from one or more external systems according to the service logic, receiving, at the SCP, data from the one or more external systems according to the service logic, routing the phone call to an appropriate agent based on the data received from the one or more external systems, and routing the data to the same agent.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.
Brief D~scription of tha Draxiaaa The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate presently preferred implementations of this invention and, together with the general description given above and the detailed 4 PC"f/US95/14089 description of the preferred implementations given below, serve to explain the principles of the invention.
In the drawings:
Fig. 1 is a block diagram of a network-based telephone system in accordance with the present invention;
Fig. 2 is a block diagram of a service control point (SCP) in accordance with the present invention;
Fig. 3 shows the internal interfaces of a peripheral interface (PI) in accordance with the present invention;
Fig. 4 is a schematic representation of software modules corresponding to a PI in accordance with the present invention;
Fig. 5 shows a configuration having a plurality of intelligent peripherals (IPs) interfaced with a plurality of PIs in accordance with a preferred embodiment of the present invention;
Fig. 6 illustrates internal tables which interface with a generic data interface (GDI) in accordance with the present invention;
Fig. 7 is a flowchart illustrating an operation of a GDI
in accordance with a preferred embodiment of the present invention;
Fig. 8 illustrates sub-requests in an Outstanding Request Table in accordance with the present invention;
Fig. 9 illustrates an example of a call processing record in accordance with the present invention;
Fig. 10 is a flowchart showing the operation of ACD 108;
Fig. 11 is a flowchart showing the operation of ACD
protocol handler 125; and Fig. 12 is a flowchart showing the operation of agent protocol handler 127.
Best Mode for Carr~rina Out he Inveatioa As shown in Fig. 1, a preferred embodiment of a network-based telephone system 100 of the present invention includes the conventional elements of the public switched network 110, a plurality of telephones 112 (only one shown), an automatic call distributor (ACD) 108, an intelligent peripheral (IP) 104, a service control point (SCP) 102, external systems 106, an agent workstation network 115, a plurality of agent workstations 116 (only one shown) each having a telephone 117 and a display terminal 119.
public switched network 110 is connected to ACD 108 and IP 104. ACD 108 is connected to telephones 117 of agent workstations 116 and SCP 102. IP 104 is connected to public switched network 110 and is also connected to SCP 102, which is connected to external systems 106 and agent workstation network 115. Agent workstation network 115 is connected to display terminals 119 of agent workstations 116.
A call placed by a caller on telephone 112 is received by public switched network 110 and forwarded to IP 104. One of the functions of the IP 104 is to interface as an intelligent speech peripheral with the caller on telephone 112. For example, IP 104 can preferably play digitized announcements to a caller, prompt the caller to enter call processing information, and collect call processing information.
When a call is routed to IP 104 from public switched network 110, IP 104 requests instructions from SCP 102 on how to handle the call. As described in more detail below, the SCP 102 provides interface instructions to the IP 104 based on a call processing record. The caller-to-IP 104 connection, therefore, becomes an intelligent interactive communication, with the SCP 102 providing instructions to the IP 104 in response to information provided by the caller.
The use of the SCP 102 in conjunction with IP 104 automates the call processing and substantially reduces agent time for handling routine tasks.
If necessary, the SCP may instruct the IP 104 to route the caller 112 to ACD 108. The SCP 102 will instruct the IP
104 as to the desired ultimate destination for the caller 112 .(i.e., a particular agent or group of agents). The ACD 108 will then manage the connection of the caller 112 to an agent's telephone 117 based on various criteria. As the caller progresses through the ACD 108, ACD 108 informs the SCP 102 of this progress. In a preferred embodiment, ACD 108 is an AT&T 5ESS Pinnacle'" ACD, however, any known type of ACD
could be used.
Preferably, IP 104 also provides additional functions s~~ch a.s au~tomat.ic e~xthound r?i.alin.g; cahere IP 104 plscea a call to an outside telephone 112 according to instructions received from SCP 102.
In a preferred embodiment, IP 104 is a Periphonics VPS
9000 or Bellcore Intelligent Services Peripheral (ISP~, vets.
2Ø
External systems 106 preferably include databases or other network-based systems, which contain data that is useful in processing a call, including, for example, account status data, repair information, customer profile data, and ordering information. Account status data may indicate whether a customer is in good standing or whether the customer's service has been suspended for nonpayment. Repair information may indicate the repairs that have been made to a particular telephone line, whether a particular line is in service, and the type of problems a particular line is experiencing. Customer profile data may contain information about the customer that may be useful in directing the customer's call, such as the type of services that are installed and the geographical location of his telephone line. Ordering information may include, for example, the costs of services and the availability of services to particular customers. External systems 106 may comprise various hardware structures, including, for example, an IBM
TN-3270 database.
As described above, ACD 108 may also distribute the call to an agent workstation 116 according to instructions received by SCP 102. An agent at agent workstation 116 may be a regular service agent capable of handling various customer needs or a specialized service agent capable of handling specific customer needs. Based on information received from IP 104 and external systems 106, SCP 102 may SEP 17 '96 10~44RM HELLC~E 2018292366 P.3 - r~r~us 95m4~~g9 1 7 StN 1996 direct ACD 108 to distribute the call to an appropriate agent workstation 116. For example, a caller may be routed to the i collections department it the caller's account hss been suspended for non-payment. Or, a caller may be routed to an agent specializing in "work-at-home' accounts if the caller s i line is used is a home office. In handling a call, an agent may have access to data stored in external systems.
Fig. 2 shows a block diagram of SCP 102 architecture i according to a preferred embodiment of the present invention.
As shown, the SPACE 118 application interfaces with the MSAP
application 120. Although SPACE is shown outside SCP 102, in an alternate embodiment, SPACE may be included in SCP 102. MSAP
120 communicates with Message Delivery interface (MDT) ,122, which delivers rnessaQes from MSAP 120 to either peripheral interface (PI) 128 or generic data interface (GDI) 124. MSAP
120, an application that is resident in the SCP 102, executes the service logic of the accessed call processing record and issues instructions to the other elements of the system I00.
PI 128 interfaces IP 104 to SCP 102 and allows these two devices to communicate. GDI 124 transmits reguesta for data to the appropriate external systems 106 via protocol handlers 126 and packages the data received from the external systems 106 into a message to be transmitted to and used MSAP 120. t~DI
124 can also send data resident in, or retrieved by, SCP 102 to the external systems. In addition, GDI 124 sends and retrieves data to and from ACD 10B and agent workstation network 115 via ACD protocol handler 125 and agent protocol handler 127, respectively. PI 128 and GDI 124 are described in detail below.
PI 128 establishes and maintains a data network communication link between IP 104 and SCP 102. Pz 128 handles asynchronous transmission of messages between IP 104 and SCP
102. Further, PI 128 translates messages into a format understood by either IP 104 or SCP 102. In a preferred embodiment, the message formats supported by PI 128 are I described in published Bellcore Documents TR-TSY-000402, A;~ENDED SHEET
SEP 17 '96 10:45RM HELLCORE 2018292366 ~1~~5 9 5 ~.l 4 Q
July 1989 (hereinafter TR402 format) and TA-NWT-001129, October 1992 (hereinafter TA1129+ format), which are understood by IP
i 104 and SCP 102, respectfully. However, other message formats could be used by IP 104 and SCP 102.
i During normal operation, PI 128 is simultaneously waiting for messages from IP 104 and MSAP 120. Messages I received by PI I28 are added to a queue 129, while messages transmitted from PI 128 are removed from the queue 129.
Fig. 3 shows the internal interfaces of PI 128, including Node Manager Application Programming Interface (API) 130, Node Administration API 132. Maintenance Operations Console (MOC) API 134, Transmission Control Protocol/Internet Protocol (TCP/IP) API 136, Configuration File 138, and Message Delivery (MD) 122.
Node Manager API 130 is responsible for maintaining the reliability of SCP 102 by monitoring the statue of the nodes in SCP 102. Node Administration API 132 contains information regarding the configuration of SCP 102 such as the addresses of each IP 104 connected to SCP 102. MOC API 134 interfaces a I, computer terminal, not shown in the drawings, with SCP 102 to ~, permit, for example, a technician to conduct maintenance on SCP
102. TCP/IP API 136 provides and interface between SCP 102 and IP 104 using the TCP protocol.
Configuration File 138 contains information relevant to the operations of PI 128. This information includes parameters '~ for configuring PI 128, such as identifying the addressee of I' IPs 104 and specifying the priority of a message in queue~129.
I Changes to the configuration file 138 are preferably effected upon initialization of PI 128.
In a preferred embodiment, PI 128 is implemented as software, Fig. 4 depicts a block diagram of the preferred I software modules of PI 128. In PI 128, a message is then validated by module 142 and encoded by module 144 to a format 'I understandable by MSAP 120. Module 146 transmits to and receives messages from MSAP 120. Module 146 transmits to and receives messages from MSAP 120 through MD 122. Module 14B
i ', validates a message received from MSAP 120 and module 150 AMEND~D SHEET
- g -encodes the message in a format understood by IP 104. Module 152 provides the message to IP 104.
In processing a received message, PI 128 determines whether a translation is required. If so, PI 128 decodes the received message and determines whether the message is valid.
FI 128 then converts the message to a format understood by the receiving device using conversion tables (not shown).
For example, a message being received by IP 104 from SCP 102 is converted from TR402 format into TA1129+ format and vice-versa.
If PI 128 receives an invalid message from IP 104, the message is dropped and further processing of the message ceases. Timers in IP 104 then either resend the message or transfer the call. If PI 128 receives an improperly formatted message from MSAP 120, PI 128 returns an error message to MSAP 120.
Fig. 5 shows a preferred embodiment of the present invention having redundant connections between a plurality of IPs 104 and SCP 102 to provide high system reliability. SCP
102 distributes transactions in a "round-robin" fashion to each of a plurality of PIs 128. PIs 128 are configured to make redundant connections with one or more IPs 104. Thus, in the case of a failed connection, a message can still be transmitted between IP 104 and SCP 102.
Each PI 128 attempts to keep all configured connections, including redundant connections, active at all times. PI 128 logs the general status of each of its circuit connections, indicating whether the connection is good, degraded, or poor.
A good connection indicates that all the configured connections are active; a degraded connection indicates that at least one, but not all, connections have failed; and a poor connection indicates that all connections have failed.
When any connections have failed, a periodic timer mechanism in PI 128 causes PI 128 to make another attempt to establish the connection after a predetermined time. When all the configured circuits are active, PI 128 deactivates its periodic timer mechanism. When an active circuit returns an unexpected error, that circuit is considered failed and the periodic timer of PI 128 reactivates and attempts are made to reestablish the circuit. A badly formed message ' received over a circuit is considered to be a circuit failure, resulting in activation of the periodic timer of PT
i23.
GDI 124 gives MSAP 120 transparent real time access to information stored in external systems 106 by allowing MSAP
120 to request information without knowledge of the source of that information.
Fig. 6 illustrates internal tables stored in GDI 124 for handling requests for information from MSAP 120. These tables include Data Elements Table 154, GDI Queues Table 156, External Systems Table 158, and Outstanding Request Table 160. Data Elements Table 154 is used by GDI 124 to forward a request for data to the appropriate external systems 106.
GDI Queues Table 156 is used by GDI 124 and protocol handlers 126 to determine what queue names to use for exchanging messages. External Systems Table 158 is used by protocol handlers 126 to obtain addressing information for communicating with external systems. Outstanding Request Table 160 is used to maintain a list of outstanding requests by GDI 124.
Protocol handlers 126 manage the physical and logical connections to external systems 106 and interact with external systems 106 to retrieve information. In a preferred embodiment, each external system 106 has a corresponding protocol handler 126.
ACD protocol handler 125 manages the physical and logical connection to ACD 108 and interacts with ACD 108 to receive status information on calls queued within ACD 108.
ACD protocol handler 125 is discussed in more detail below.
Agent protocol handler 127 manages the physical and logical connection to agent workstation network 115 and interacts with agent workstation network 115 to send information needed to serve a call to the display terminal 119 of the agent workstation 116 to which the call is routed . CA 02204132 1997-07-29 SEP 17 '96 10:45AM BELLCORE 2018292366 P.5 _ _ ~CT/US 9 5 ~ ~ ~. (l g 9 ~P~/~$ ~ 7 SEP 1996 by ACD 108 at the time that the call is routed to that agent workstation 116. Agent protocol handler 127 is discussed in more detail below.
With reference to flowchart 162 shown in Fig. 7, the manner in which GDI 124 handles a request for data from MSAP
120 will now be described. Initially, GDI 124 receives a GetData request, described in detail below, from MSAP 120 (step 163). GDI 124 decodes the GetData request to determine the specific data elements being z~equested by MSAP 120 (step 164).
Using Data Elements Table 154, GDI 124 determines which external systems 106 should be accessed to obtain the requested data elements (step 165). Data Elements Table 154 is a lookup table which identifies which of external systems 106 the specific data elements are located. Thus, once GDI 124 has decoded the GetData request and determined the specific data elements requested by MSAP 120, GDI 124 may look up the external system corresponding to each specific data element in Data Elements Table 154. GDI 124 then forwards "sub-requests"
requesting the data elements to protocol handlers associated with the appropriate external systems (step 166). Outstanding Request Table is updated to keep track of the outstanding ~sub-requests" (step 167).
GDI 124 then determines whether a reply has been received (step 168). If a reply is received by GDI 124 from external systems 106, Outstanding Request Table is updated to keep track of the partial completions (step 169).
GDI 124 then determines if all of the replies to the sub-requests have not been returned (step 170). If not, GDI 124 waits for additional replies. If all of the replies have been received, GDI 124 returns the completed message to MSRP 120 (step 172).
If at step 168 GDI 124 determines that a reply has not been received, the message will also be returned to MSRP 120 (step 172) if a predetermined time passes (step 171). Thus, a message is returned to MSAP 120 when all of the outstanding sub-reauests have been responded to or timed out.
AMENDED SHEET
Fig. 8 depicts the GDI Outstanding Request Table 160.
Blocks A, B, and C represent outstanding requests received by GDI 124 from MSAP 120. Blocks A1, A2, and A3; Bl, B2, and B3; and C1, C2, and C3 represent sub-requests created from outstanding requests A, B, and C, respectively. Blocks A1R, A2R, and B3R represent responses received by GDI 124 in response to sub-requests A1, A2, and B3, respectively.
Outstanding Request Table 160 is constructed and updated as each request for information from MSAP 120 is received by GDI 124. Upon receiving a request from MSAP 120, GDI 124 creates sub-requests, which are forwarded to the appropriate protocol handler. GDI 124 awaits a response for each outstanding sub-request.
Three types of responses may be stored in Outstanding Request Table 160. First, GDI 124 may store response A1R
from external systems 106, indicating that a result was received in response to the sub-request. Second, GDI 124 may store response A2R from external systems 106, indicating that an error was received from external systems 106. Such an error may indicate that external systems 106 are unable to process the sub-request. Finally, GDI 124 may store response B3R, indicating that no response was received from external systems 106 within a predetermined time.
Nodes are the basic units that define the logical operations to be performed during call processing. MSAP 120 processes the nodes and issues corresponding requests or instructions to the other elements of system 100. U.S.
Patent Nos. 5,450,480 and 5,511,116 describe various nodes supported by MSAP 120 including GetData, SendData, and WaitForEvent nodes. In a preferred embodiment of the present invention, the GetData, SendData, and WaitForEvent nodes may be modified as described below. Also, the present invention contemplates a TransferCall node, also described below.
The GetData node allows MSAP 120 to request data from external systems 106 for a particular account. A GetData request issued by MSAP 120 includes a handle call variable, accounts ID, and a list of call variables. The handle call variable identifies a GetData request and is used to retrieve the requested information and check the status of the request. The account ID identifies the caller's account.
The list of call variables specify the data requested by MSAP
120 from the external systems I06.
Upon receiving a GetData request from MSAP 120, GDI 124 determines which external systems 106 contain the requested data as described above. GDI 124 formats and transmits sub-requests based on the GetData request received from MSAP 120 to the appropriate external systems. GDI 124 waits for a response for each of the sub-requests before returning all of the requested information to MSAP 120. If GDI 124 does not receive a reply to all of the sub-requests after a predetermined time, an error indication is returned to MSAP
120 along with the data that was received. While information may be returned to MSAP 120 from GDI 124, the information is not available for use by MSAP 120 until after MSAP 120 executes a WaitForEvent node.
The SendData node allows MSAP 120 to send data to external systems 106 and agent workstation network 115. A
SendData request issued by MSAP 120 to external systems 106 contains a handle call variable, account ID, and a list of call variables along with corresponding data. The handle call variable identifies a SendData request and is used to obtain the status of the request. The information corresponding to the list of call variables is stored in the external systems 106 according to the account ID.
Upon receiving a SendData request from MSAP 120, GDI 124 determines where it should send the data. GDI 124 formats the data from the received SendData request and transmits the formatted data to the appropriate protocol handlers. GDI 124 waits for positive acknowledgment from the protocol handlers indicating that the data has been accepted before sending a status reply to MSAP 120. However, the status of the SendData request is not available to MSAP 120 until after MSAP 120 executes a WaitForEvent node.
The WaitForEvent node gives MSAP 120 access to the data or status of a GetData or SendData request. The WaitForEvent instruction specifies a handle call variable, which corresponds to a handle call variable specified in a GetData or SendData request. All requests returned to MSAP 120 from a GetData or SendData request are not available to MSAP 120 until after MSAP 120 executes a WaitForEvent node. When a WaitForEvent instruction has been issued, no further instructions are executed by MSAP 120 until the requested information has been returned. When a reply has been returned, the information is assigned to the call variables specified in the request and the status of the request is returned.
While the GDI 124 is retrieving the requested information, MSAP 120 may issue additional instructions to IP
104, for example, to obtain additional information from the caller or to play digitized messages before a WaitForEvent request is issued. In this way, caller 112 is not simply waiting for MSAP 120 to receive a reply to a request.
The TransferCall node allows MSAP 120 to instruct public switched network 110 to route a call to an agent workstation 116, together with data about caller 112. The TransferCall instruction, preferably including a transfer number and account number, can be transmitted, for example, to ACD 108 where the call is queued and subsequently routed to a specialized agent workstation 116 identified by the transfer number.
To illustrate the operation of system 100, Fig. 9 shows an example of a call processing record designated by numeral 210. In this example, call processing record 210 routes the caller to a "specialized" agent based on the caller's profile.
After a received call has been routed to IP 104, IP 104 requests call processing instructions from SCP 102. Based on predetermined information in the call, such as the account number or telephone number, SCP 102, under the control of MSAP 120, executes a corresponding call processing record 210.
As shown in the example of Fig. 9, PlayAnnouncement node 180 instructs IP 104 to welcome the caller with a digitized announcement. GetDigits node 182 causes IP 104 to ask the caller to enter the calier'S account number or telephone number. MSAP checks the result of the digit collection request to decide if the caller responded to the prompt because, for example, the caller may not have touch tone. If the result is a "1," indicating that the entered telephone number is in error, MSAP 120 executes RouteToWithData node .
184, causing the call to be routed to a "regular" (i.e. non-specialized) representative. If the result is a "2,"
indicating that the telephone number has been verified by MSAP 120, MSAP 120 executes a GetData node 186, requesting customer profile information from GDI 124.
If the result to the GetData request is a "1,"
indicating that the caller is a particular market customer, SendData node 187 and RouteToWithData node 188 are executed, sending the collected data and routing the caller to an agent specialized in handling the particular market customer.
If the result to the GetData request is a "2,"
indicating that the caller "works at home," SendData node 189 and RouteToWithData node 190 are executed, sending the collected data and routing the caller to an agent specialized in handling customers who "work at home."
If the result to the GetData request is a "3,"
indicating that the account is a residential account, GetDigits node 192 is executed, causing IP 104 to prompt the caller to choose between a residential agent or automated application. If the caller inputs a "0" choosing a residential agent, the caller is routed to an agent specializing in residential accounts by RouteToWithData node 194 and the associated data is also sent to this agent by SendData node 193. If the caller presses any other key, indicating automated applications, Handover node 196 is executed, causing the call to be handled by another call processing record.
If the result to the GetData request is a "4,"
indicating that the account has been suspended for nonpayment, SendData node 199 and RouteToWithData node 200 are executed, sending the ~:uilected data and routing the call to the collections department.
Finally, if the result to the GetData request is a "5,"
indicating that the customer profile does not satisfy any of the other choices, the caller is routed to a "regular"
representative by RouteToWithData node 202 and the collected data is sent to this agent by SendData node 201.
The manner in which the obtained data and the call are routed to agent workstation 116 will now be described with reference to Figs. 10-12. Fig. 10 is a flowchart showing the operation of ACD 108. Fig. 11 is a flowchart showing the operation of ACD protocol handler 125. Fig. 12 is a flowchart showing the operation of agent protocol handler 127.
ACD 108 generally waits for calls to be routed (step 300). When IP 104 receives an instruction from SCP 102 to route a call to a particular agent or group of agents, the IP
104 utilizes the Public Switched Telephone Network to transfer the call to the ACD 108. When the ACD 108 receives the call, it places the call in a queue established for the appropriate agent or group of agents that provide the requested service (step 302). The ACD queue includes the telephone number provided by the caller, an internal caller ID, the status of the queued call, and the time the call was entered into the queue. Once the call is entered in the queue, ACD 108 sends a PROMPT message to ACD protocol handler 125 (step 304) including the account number entered by the caller and the internal caller ID.
ACD 108 then maintains the call in the queue until one of the following events occurs: (1) an agent becomes available to take the call (step 306); or (2) the caller abandons the call (step 314).
When an agent becomes available, ACD 108 routes the call to that agent workstation 116. At the same time, ACD 108 updates the status of the call in the queue from "waiting" to "connected" (step 307) and sends a CONNECT message to ACD
protocol handler 125 (step 308) including the internal call ID and the position ID of the agent workr~tation 116 to which the ACD 108 routed the call.
ACD 108 informs ACD protocol handler 125 when a call is completed by issuing a DISC message to ACD protocol handler 125 (step 312), including the internal caller ID. In the event a caller abandons a call, ACD 108 sends an AHAND
message (step 316) including the internal caller ID to ACD
protocol handler 125.
Referring to Fig. 11, in response to a PROMPT message (step 400), ACD protocol handler 125 maps the received account number and internal caller ID in a table (step 402).
If ACD protocol handler 125 does not receive a prompt message (step 400) and after step 402, ACD protocol handler 125 looks for a CONNECT message (step 404). Upon receiving the CONNECT
message, ACD protocol handler 125 forwards the agent position ID and the corresponding account number to agent protocol handler 127 (step 406). ACD protocol handler 125 then determines whether a DISC message has been received (step 412). If so, it translates the internal caller ID to the corresponding account number (step 409) and instructs agent protocol handler 127 to discard any buffered data associated with that account number (step 410). ACD protocol handler 125 contains processing by determining whether an ABAND
message has been received (step 408). If so, it converts the internal caller ID to the corresponding account number (step 407) and instructs agent protocol handler 127 to discard any buffered data associated with the corresponding account number (step 410).
Referring now to Fig. 12, when agent protocol handler 127 receives an instruction from GDI 124 to send data to an agent (step 500), agent protocol handler 127 buffers the received data in correspondence with the account number provided by the caller (step 502).
In response to an instruction to forward data from ACD
protocol handler 125 (step 504), agent protocol handler 127 obtains a workstation Internet Protocol address corresponding to the agent position ID utilizing a Domain Name Service (DNS) (step 506). The agent protocol handler 127 then sends the collected data corresponding to the account number received from ACD protocol handler 125, to agent workstation network 115.
Agent workstation network 115 reads the address attached to the data message and routes the information to the display terminal 119 of the agent workstation 116 to whom ACD 108 routed the call. In this manner, delivery of data to the workstation of agent workstation 116 can be coordinated with the routing of the call to the same service agent. Thus, service agents may serve customers more effectively and efficiently.
Because the data to be sent to an agent may be too lengthy to include in a single TCAP message sent from MSAP
120 to GDI 124, it may be necessary for MSAP 120 to send the data to GDI 124 in a series of messages. In this case, any messages required after the first messages are sent preferably include a tag identifying the subsequent messages as a continuation of the previously sent message. Agent protocol handler 127 accumulates the data contained in these multiple messages, strips the tag number attached to the subsequent messages, and sends the data to the agent workstation network 115 in a single message.
Agent protocol handler 127 maintains the data in the buffer until a message is received from ACD protocol handler 127 instructing agent protocol handler 127 to discard the data (step 508) or until a predefined period of time expires during which the data has been buffered (step 512). In either event, agent protocol handler 127 discards the buffered data (step 510).
The purpose of the time limit, as well as that of the other time limits discussed above, is to ensure that the queues and buffers do not become overloaded due to queued calls and buffered data that, for some reason, were not properly discarded when a call was abandoned or discontinued.
The times entered into the various queues of the abo~~e described system may be provided by a common time server.
Preferably, a Network Time Protocol (NTP) is utilized to synchronize off a coon time server.
While there has been illustrated and described what are at present considered to be preferred implementations and methods of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the invention.
For example, although the present invention has been described utilizing a separate agent telephone 117 and agent display terminal 119, as well as separate communications links connecting the system to the agent telephone 117 and agent display terminal 119, those of ordinary skill in the art will appreciate that agent telephone 117 and agent display terminal may be integrated in a single communication terminal, and that the voice signals from the caller and the data from SCP 102 may be delivered over a single Integrated Services Digital Network (ISDN) line.
In addition, many modifications may be made to adapt a particular element, technique or implementation to the teachings of the present invention without departing from the central scope of the invention. Therefore, it is intended that this invention nct be limited to the pø--vticular embodiments and methods disclosed herein, b~4: that the invention include all embodiments falling within the scope of the appended claim.
Claims (11)
1. A method of processing a phone call from a caller in a telephone network, the telephone network including a plurality of switches and an intelligent peripheral (IP) for interfacing the plurality of switches with a service control point (SCP), the method comprising the steps of:
receiving the phone call at one of the plurality of switches;
forwarding the phone call to the IP;
requesting, by the IP, that the SCP perform a call processing request;
accessing service logic within the SCP, the service logic specifying handling of the phone call according to the call processing request;
requesting, by the service logic, data from one.or more external systems;
receiving, at the SCP, data from the one or more external systems in response to the service logic request;
routing the phone call to a selected telephone based on the data received from the one or more external systems; and routing the received data to the selected telephone.
receiving the phone call at one of the plurality of switches;
forwarding the phone call to the IP;
requesting, by the IP, that the SCP perform a call processing request;
accessing service logic within the SCP, the service logic specifying handling of the phone call according to the call processing request;
requesting, by the service logic, data from one.or more external systems;
receiving, at the SCP, data from the one or more external systems in response to the service logic request;
routing the phone call to a selected telephone based on the data received from the one or more external systems; and routing the received data to the selected telephone.
2. The method of claim 1, wherein the data received from the one or more external systems includes any of account status data, repair information, customer profile data, and ordering information.
3. The method of claim 1, wherein the step of accessing the service logic is performed by a Multi-Services Application Platform (MSAP), and the step of requesting data from the external systems is initiated by the MSAP and comprises the substeps of:
the MSAP issuing a data request to a generic data interface (GDI), the MSAP and GDI being connected through a message delivery interface (MDI), the GDI performing the steps of:
forming sub-requests from the received data request;
forwarding the sub-requests to the one or more external systems;
receiving replies to the sub-requests from the one or more external systems; and returning a message to the MSAP containing the requested data.
the MSAP issuing a data request to a generic data interface (GDI), the MSAP and GDI being connected through a message delivery interface (MDI), the GDI performing the steps of:
forming sub-requests from the received data request;
forwarding the sub-requests to the one or more external systems;
receiving replies to the sub-requests from the one or more external systems; and returning a message to the MSAP containing the requested data.
4. The method of claim 1, wherein the SCP includes a Mufti-Services Application Platform (MSAP) and a message delivery interface (MDI) for interfacing the MSAP to a generic data interface (GDI), and wherein the step of accessing the service logic is performed by the MSAP, and includes a step of sending data initiated by the MSAP comprising the substeps of:
the MSAP issuing a send data request to the GDI;
the GDI forming sub-requests in response to the received send data request;
the GDI forwarding the sub-requests to one of the external systems;
the GDI receiving status information concerning each sub-request; and the GDI returning a message to the MSAP containing a status of the send data request.
the MSAP issuing a send data request to the GDI;
the GDI forming sub-requests in response to the received send data request;
the GDI forwarding the sub-requests to one of the external systems;
the GDI receiving status information concerning each sub-request; and the GDI returning a message to the MSAP containing a status of the send data request.
5. The method of claim 1, further comprising the steps of:
entering the received phone call in a queue; and storing the received data, wherein the received data is routed to the selected telephone at substantially the same time that the call is routed to the selected telephone.
entering the received phone call in a queue; and storing the received data, wherein the received data is routed to the selected telephone at substantially the same time that the call is routed to the selected telephone.
6. The method of claim 5, further comprising the steps of:
discarding the stored data when the received phone call is disconnected or abandoned.
discarding the stored data when the received phone call is disconnected or abandoned.
7. The method of claim 1, further comprising the steps of:
playing recorded voice messages to the caller when the phone call is received; and receiving caller information from the caller.
playing recorded voice messages to the caller when the phone call is received; and receiving caller information from the caller.
8. The method of claim 1, wherein the step of routing the data to the selected telephone comprises the substeps of:
waiting for a message indicating that the received phone call has been connected to the selected telephone, the message including an account number corresponding to the received data and an identifier of the selected telephone to which the telephone call has been routed;
obtaining a network address for the selected telephone to which the telephone call has been routed based upon the identifier included in tho message; and forwarding the received data to the selected telephone at the obtained network address.
waiting for a message indicating that the received phone call has been connected to the selected telephone, the message including an account number corresponding to the received data and an identifier of the selected telephone to which the telephone call has been routed;
obtaining a network address for the selected telephone to which the telephone call has been routed based upon the identifier included in tho message; and forwarding the received data to the selected telephone at the obtained network address.
9. The method of claim 1, further including the steps of: outputting, from the SCP, interface instructions to the IP;
and performing, by the IP, the interface instructions.
and performing, by the IP, the interface instructions.
10. The method of claim 9, wherein the interface instructions include information requests to tho caller.
11. The method of claim 1, wherein the telephone network includes an automatic calling device (ACD), and the method further includes the step of the SCP instructing the IP to route the telephone call to the ACD.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/334,120 US5533115A (en) | 1994-01-31 | 1994-11-04 | Network-based telephone system providing coordinated voice and data delivery |
US334,120 | 1994-11-04 | ||
PCT/US1995/014089 WO1996014704A1 (en) | 1994-11-04 | 1995-10-18 | A network-based telephone system providing coordinated voice and data delivery |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2204132A1 CA2204132A1 (en) | 1996-05-17 |
CA2204132C true CA2204132C (en) | 2000-05-16 |
Family
ID=23305674
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002204132A Expired - Fee Related CA2204132C (en) | 1994-11-04 | 1995-10-18 | A network-based telephone system providing coordinated voice and data delivery |
Country Status (5)
Country | Link |
---|---|
US (1) | US5533115A (en) |
EP (1) | EP0789963A4 (en) |
JP (1) | JP3058450B2 (en) |
CA (1) | CA2204132C (en) |
WO (1) | WO1996014704A1 (en) |
Families Citing this family (149)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5703940A (en) * | 1993-11-12 | 1997-12-30 | Intervoice, Inc. | Method and apparatus for delivering calling services |
HU220989B1 (en) * | 1994-05-05 | 2002-07-29 | Sprint Communications Company, LP | Method and telecommunications system for processing telecommunication calls |
US6631133B1 (en) * | 1994-05-05 | 2003-10-07 | Sprint Communications Company L.P. | Broadband telecommunications system |
US6031840A (en) * | 1995-12-07 | 2000-02-29 | Sprint Communications Co. L.P. | Telecommunications system |
US5991301A (en) | 1994-05-05 | 1999-11-23 | Sprint Communications Co. L.P. | Broadband telecommunications system |
US5920562A (en) | 1996-11-22 | 1999-07-06 | Sprint Communications Co. L.P. | Systems and methods for providing enhanced services for telecommunication call |
US6430195B1 (en) * | 1994-05-05 | 2002-08-06 | Sprint Communications Company L.P. | Broadband telecommunications system interface |
US6181703B1 (en) | 1995-09-08 | 2001-01-30 | Sprint Communications Company L. P. | System for managing telecommunications |
US5926482A (en) * | 1994-05-05 | 1999-07-20 | Sprint Communications Co. L.P. | Telecommunications apparatus, system, and method with an enhanced signal transfer point |
FI99187C (en) * | 1994-11-24 | 1997-10-10 | Tecnomen Oy | A method and apparatus for adding intelligent functions to a telecommunications network |
US6463149B1 (en) * | 1995-04-10 | 2002-10-08 | Edify Corporation | Web page synchronization system and method |
US6301350B1 (en) * | 1995-06-30 | 2001-10-09 | Qwest Communications International, Inc. | System and method for call handling |
US5619557A (en) * | 1995-07-10 | 1997-04-08 | Rockwell International Corporation | Telephone switching system and method for controlling incoming telephone calls to remote agents and for collecting and providing call data |
US5761290A (en) * | 1995-10-11 | 1998-06-02 | Bell Atlantic Network Services, Inc. | Alternate service activation |
US6130933A (en) * | 1996-02-02 | 2000-10-10 | Genesys Telecommunications Laboratories, Inc. | Apparatus and methods for coordinating telephone and data communications |
GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
AU2257097A (en) * | 1996-02-02 | 1997-08-22 | Sprint Communications Company, L.P. | Atm gateway system |
US5784451A (en) * | 1996-04-03 | 1998-07-21 | Cogito Economic Systems, Inc. | Virtual telephony data message system and process |
US6064673A (en) * | 1996-08-02 | 2000-05-16 | 3Com Corporation | Communications system having distributed control and real-time bandwidth management |
AUPO214096A0 (en) * | 1996-09-04 | 1996-09-26 | Telefonaktiebolaget Lm Ericsson (Publ) | A telecommunications system and method for automatic call recognition and distribution |
US6243398B1 (en) * | 1996-10-21 | 2001-06-05 | Vocaltec Communications Ltd. | System and method for personal multimedia communication over a packet switched network |
US6366575B1 (en) * | 1996-11-01 | 2002-04-02 | Teloquent Communications Corporation | Extended access for automatic call distributing system |
US5915001A (en) | 1996-11-14 | 1999-06-22 | Vois Corporation | System and method for providing and using universally accessible voice and speech data files |
US20060002949A1 (en) | 1996-11-14 | 2006-01-05 | Army Govt. Of The Usa, As Rep. By Secretary Of The Office Of The Command Judge Advocate, Hq Usamrmc. | Transcutaneous immunization without heterologous adjuvant |
US6002689A (en) * | 1996-11-22 | 1999-12-14 | Sprint Communications Co. L.P. | System and method for interfacing a local communication device |
NZ335503A (en) * | 1996-11-22 | 2000-05-26 | Sprint Comm Company Lp | Detecting a call trigger in a telecommunications network without requiring a service platform to remain connected to the call |
US6667982B2 (en) * | 1996-11-22 | 2003-12-23 | Sprint Communications Company, L.P. | Broadband telecommunications system interface |
US5883946A (en) * | 1996-11-27 | 1999-03-16 | Bell Communications Research, Inc. | Method and apparatus for provisioning customized telecommunications services |
US6014660A (en) * | 1996-12-09 | 2000-01-11 | Sun Microsystems, Inc. | Method and apparatus for client-sensitive name resolution using DNS |
FI105134B (en) * | 1996-12-20 | 2000-06-15 | Ericsson Telefon Ab L M | Telephone system and method for that |
US6014437A (en) * | 1997-02-03 | 2000-01-11 | International Business Machines Corporation | Multi service platform architecture for telephone networks |
US6104802A (en) | 1997-02-10 | 2000-08-15 | Genesys Telecommunications Laboratories, Inc. | In-band signaling for routing |
US6480600B1 (en) | 1997-02-10 | 2002-11-12 | Genesys Telecommunications Laboratories, Inc. | Call and data correspondence in a call-in center employing virtual restructuring for computer telephony integrated functionality |
US5995615A (en) * | 1997-02-10 | 1999-11-30 | Genesys Telecommunications Laboratories, Inc. | External positivistic forward transfer in call-routing systems |
US5946387A (en) * | 1997-02-10 | 1999-08-31 | Genesys Telecommunications Laboratories, Inc, | Agent-level network call routing |
US7031442B1 (en) | 1997-02-10 | 2006-04-18 | Genesys Telecommunications Laboratories, Inc. | Methods and apparatus for personal routing in computer-simulated telephony |
US6064667A (en) * | 1997-02-10 | 2000-05-16 | Genesys Telecommunications Laboratories, Inc. | Apparatus and methods enhancing call routing to and within call centers |
DE69816594T2 (en) * | 1997-02-20 | 2004-06-03 | Hewlett-Packard Co. (N.D.Ges.D.Staates Delaware), Palo Alto | SERVICE POINT FOR THE DELIVERY OF TELECOMMUNICATION SERVICES |
US6775264B1 (en) | 1997-03-03 | 2004-08-10 | Webley Systems, Inc. | Computer, internet and telecommunications based network |
US6785266B2 (en) * | 1998-03-02 | 2004-08-31 | Robert Swartz | Internet controlled telephone system |
US6046762A (en) | 1997-04-01 | 2000-04-04 | Cosmocom, Inc. | Multimedia telecommunication automatic call distribution system |
US5999609A (en) * | 1997-04-04 | 1999-12-07 | Sun Microsystems, Inc. | Computer-telephony (CT) system including an electronic call request |
US6094479A (en) * | 1997-05-06 | 2000-07-25 | Telefonaktiebolaget Lm Ericsson | Computer telephony integration gateway |
US6044142A (en) * | 1997-05-06 | 2000-03-28 | Telefonaktiebolaget L M Ericsson | Method and arrangement for integrating intelligent network services with operator assisted services |
US5995610A (en) * | 1997-05-06 | 1999-11-30 | Telefonaktiebolaget Lm Ericsson | Cooperative call processing across public and private intelligent networks |
US6178170B1 (en) * | 1997-05-13 | 2001-01-23 | Sprint Communications Company, L. P. | System and method for transporting a call |
US5933489A (en) * | 1997-06-30 | 1999-08-03 | Telcordia Technologies, Inc. | Method and apparatus for handling subscription and administrative requests in a local service management system |
US6373835B1 (en) | 1997-08-13 | 2002-04-16 | Ede Phang Ng | Method and apparatus for making a phone call connection over an internet connection |
US6243376B1 (en) | 1997-08-13 | 2001-06-05 | Mediaring.Com Ltd. | Method and apparatus for making a phone call connection over the internet connection |
SE522481C2 (en) | 1997-09-02 | 2004-02-10 | Ericsson Telefon Ab L M | Method and apparatus in telecommunication networks |
US6122359A (en) * | 1997-09-04 | 2000-09-19 | Lucent Technologies Inc. | System for coordinating calls between an adjunct device and a switching system |
WO1999016229A1 (en) * | 1997-09-23 | 1999-04-01 | Intervoice Limited Partnership | Dynamic distributions of applications and associated resource utilization |
US6711611B2 (en) | 1998-09-11 | 2004-03-23 | Genesis Telecommunications Laboratories, Inc. | Method and apparatus for data-linking a mobile knowledge worker to home communication-center infrastructure |
US6295345B1 (en) | 1997-09-30 | 2001-09-25 | Alcatel Usa Sourcing, Inc. | Method and system for translating call processing requests |
US6985943B2 (en) | 1998-09-11 | 2006-01-10 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for extended management of state and interaction of a remote knowledge worker from a contact center |
WO1999026424A2 (en) | 1997-11-14 | 1999-05-27 | Genesys Telecommunications Laboratories, Inc. | Negotiated routing in telephony systems |
USRE46528E1 (en) | 1997-11-14 | 2017-08-29 | Genesys Telecommunications Laboratories, Inc. | Implementation of call-center outbound dialing capability at a telephony network level |
US6185565B1 (en) * | 1997-12-18 | 2001-02-06 | Nortel Networks Corporation | System and method for communication session disposition responsive to events in a telecommunications network and the internet |
US6496501B1 (en) * | 1997-12-29 | 2002-12-17 | At&T Corp. | Method and apparatus for screening computer-telephony calls |
US7907598B2 (en) | 1998-02-17 | 2011-03-15 | Genesys Telecommunication Laboratories, Inc. | Method for implementing and executing communication center routing strategies represented in extensible markup language |
US6332154B2 (en) | 1998-09-11 | 2001-12-18 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for providing media-independent self-help modules within a multimedia communication-center customer interface |
NO313027B1 (en) | 1998-03-06 | 2002-07-29 | Ericsson Telefon Ab L M | Steps to improve a network structure, especially an intelligent network |
EP1062820B1 (en) | 1998-03-20 | 2007-08-22 | BRITISH TELECOMMUNICATIONS public limited company | Service in a communications network |
US6831914B1 (en) * | 1998-03-27 | 2004-12-14 | Verizon Services Corp. | Services control point selection in an advanced intelligent network |
US6496567B1 (en) | 1998-05-07 | 2002-12-17 | Mci Communications Corporation | Interactive voice response service node with advanced resource management |
US6389126B1 (en) * | 1998-05-07 | 2002-05-14 | Mci Communications Corporation | Service provisioning system for interactive voice response services |
US6427002B2 (en) * | 1998-05-07 | 2002-07-30 | Worldcom, Inc. | Advanced interactive voice response service node |
US6647111B1 (en) | 1998-05-07 | 2003-11-11 | Mci Communications Corporation | System for executing advanced interactive voice response services using service-independent building blocks |
US6418205B2 (en) | 1998-05-07 | 2002-07-09 | Mci Communications Corporation | Call and circuit state machine for a transaction control layer of a communications signaling gateway |
US6366658B1 (en) | 1998-05-07 | 2002-04-02 | Mci Communications Corporation | Telecommunications architecture for call center services using advanced interactive voice responsive service node |
US6493353B2 (en) | 1998-05-07 | 2002-12-10 | Mci Communications Corporation | Communications signaling gateway and system for an advanced service node |
US7006620B1 (en) | 1998-06-12 | 2006-02-28 | Sbc Properties, L.P. | System and method for routing both toll-free and caller-paid telephone calls to call service centers |
EP0973313A1 (en) * | 1998-07-16 | 2000-01-19 | Ascom Hasler AG | Circuit and method for operating a call-center |
US6128380A (en) * | 1998-08-24 | 2000-10-03 | Siemens Information And Communication, Networks, Inc. | Automatic call distribution and training system |
USRE46153E1 (en) | 1998-09-11 | 2016-09-20 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus enabling voice-based management of state and interaction of a remote knowledge worker in a contact center environment |
EP0998153A3 (en) * | 1998-10-28 | 2001-01-03 | Priority Call Management, Inc. | System and method for ubiquitous services on a packet switched network |
US6212195B1 (en) | 1998-12-01 | 2001-04-03 | 3Com Corporation | Telecommunication apparatus and method for forwarding packets using separate collision domains |
US6967963B1 (en) | 1998-12-01 | 2005-11-22 | 3Com Corporation | Telecommunication method for ensuring on-time delivery of packets containing time-sensitive data |
US6262979B1 (en) | 1998-12-01 | 2001-07-17 | 3Com Corporation | Telecommunication conferencing system and method |
US6714217B2 (en) * | 1998-12-18 | 2004-03-30 | Sprint Communication Company, L.P. | System and method for providing a graphical user interface to, for building, and/or for monitoring a telecommunication network |
US6597701B1 (en) * | 1998-12-22 | 2003-07-22 | Sprint Communications Company L.P. | System and method for configuring a local service control point with a call processor in an architecture |
US7079530B1 (en) * | 1999-02-25 | 2006-07-18 | Sprint Communications Company L.P. | System and method for caching toll free number information |
US7133510B1 (en) * | 1999-03-30 | 2006-11-07 | Cisco Technology, Inc. | Managing access to resources and services utilizing call information |
US7103068B1 (en) | 1999-05-04 | 2006-09-05 | Sprint Communication Company L.P. | System and method for configuring bandwidth transmission rates for call connections |
US6895088B1 (en) | 1999-05-21 | 2005-05-17 | Sprint Communications Company L.P. | System and method for controlling a call processing system |
DE19954224A1 (en) * | 1999-11-05 | 2001-05-10 | Deutsche Telekom Ag | Expanding functionality of telecommunications network designed as intelligent network, by routing via service control point using information transferred via control interface |
US6816497B1 (en) * | 1999-11-05 | 2004-11-09 | Sprint Communications Company, L.P. | System and method for processing a call |
US20050175971A1 (en) * | 1999-11-16 | 2005-08-11 | Knowlagent, Inc., Alpharetta, Ga | Method and system for scheduled delivery of training to call center agents |
US6628777B1 (en) | 1999-11-16 | 2003-09-30 | Knowlagent, Inc. | Method and system for scheduled delivery of training to call center agents |
US20040202309A1 (en) * | 1999-11-16 | 2004-10-14 | Knowlagent, Inc. | Managing the rate of delivering performance interventions in a contact center |
US20060233346A1 (en) * | 1999-11-16 | 2006-10-19 | Knowlagent, Inc. | Method and system for prioritizing performance interventions |
US20040202308A1 (en) * | 1999-11-16 | 2004-10-14 | Knowlagent, Inc. | Managing the selection of performance interventions in a contact center |
US7929978B2 (en) | 1999-12-01 | 2011-04-19 | Genesys Telecommunications Laboratories, Inc. | Method and apparatus for providing enhanced communication capability for mobile devices on a virtual private network |
US7149509B2 (en) * | 1999-12-06 | 2006-12-12 | Twenty Year Innovations, Inc. | Methods and apparatuses for programming user-defined information into electronic devices |
US8170538B2 (en) | 1999-12-06 | 2012-05-01 | Solocron Media, Llc | Methods and apparatuses for programming user-defined information into electronic devices |
US6496692B1 (en) | 1999-12-06 | 2002-12-17 | Michael E. Shanahan | Methods and apparatuses for programming user-defined information into electronic devices |
US6704314B1 (en) * | 1999-12-15 | 2004-03-09 | Sprint Communications Company, L.P. | Method and apparatus to control cell substitution |
US6785377B1 (en) * | 2000-01-19 | 2004-08-31 | Sprint Communications Company L.P. | Data calls using both constant bit rate and variable bit rate connections |
US6721705B2 (en) | 2000-02-04 | 2004-04-13 | Webley Systems, Inc. | Robust voice browser system and voice activated device controller |
US7516190B2 (en) | 2000-02-04 | 2009-04-07 | Parus Holdings, Inc. | Personal voice-based information retrieval system |
US6775377B2 (en) | 2001-09-10 | 2004-08-10 | Knowlagent, Inc. | Method and system for delivery of individualized training to call center agents |
US7043193B1 (en) * | 2000-05-09 | 2006-05-09 | Knowlagent, Inc. | Versatile resource computer-based training system |
US7269160B1 (en) | 2000-05-26 | 2007-09-11 | Buffalo International, Inc. | Voice over internet call center integration |
US8873730B2 (en) | 2001-02-27 | 2014-10-28 | Verizon Patent And Licensing Inc. | Method and apparatus for calendared communications flow control |
EP1368975A1 (en) | 2001-03-09 | 2003-12-10 | Ayman L.L.C. | Universal point of contact identifier system and method |
US20020010715A1 (en) * | 2001-07-26 | 2002-01-24 | Garry Chinn | System and method for browsing using a limited display device |
US7174010B2 (en) * | 2001-11-05 | 2007-02-06 | Knowlagent, Inc. | System and method for increasing completion of training |
US7245716B2 (en) | 2001-12-12 | 2007-07-17 | International Business Machines Corporation | Controlling hold queue position adjustment |
US7003466B2 (en) * | 2001-12-12 | 2006-02-21 | International Business Machines Corporation | Destination device initiated caller identification |
US9088645B2 (en) | 2001-12-12 | 2015-07-21 | International Business Machines Corporation | Intermediary device initiated caller identification |
US7167551B2 (en) * | 2001-12-12 | 2007-01-23 | International Business Machines Corporation | Intermediary device based callee identification |
US7103172B2 (en) * | 2001-12-12 | 2006-09-05 | International Business Machines Corporation | Managing caller profiles across multiple hold queues according to authenticated caller identifiers |
US7443970B2 (en) | 2001-12-17 | 2008-10-28 | International Business Machines Corporation | Logging calls according to call context |
US7106847B1 (en) * | 2002-01-15 | 2006-09-12 | Sprint Communications Company L.P. | Telecommunication network that provides caller-entered information to a call destination |
US9392120B2 (en) | 2002-02-27 | 2016-07-12 | Verizon Patent And Licensing Inc. | Methods and systems for call management with user intervention |
US7372952B1 (en) | 2002-03-07 | 2008-05-13 | Wai Wu | Telephony control system with intelligent call routing |
US7272133B2 (en) * | 2002-08-12 | 2007-09-18 | Telcordia Technologies, Inc. | Method and system for implementing standard applications on an intelligent network service control point through an open services gateway |
EP1396990B1 (en) | 2002-09-06 | 2007-10-31 | Siemens Enterprise Communications GmbH & Co. KG | Method for data management in an automatic call distribution |
US7590696B1 (en) * | 2002-11-18 | 2009-09-15 | Aol Llc | Enhanced buddy list using mobile device identifiers |
CA2507092A1 (en) * | 2002-11-25 | 2004-06-10 | Telesector Resources Group, Inc. | Methods and systems for multiuser selective notification |
US20040148226A1 (en) * | 2003-01-28 | 2004-07-29 | Shanahan Michael E. | Method and apparatus for electronic product information and business transactions |
US7551199B2 (en) * | 2003-05-05 | 2009-06-23 | Microsoft Corporation | Computer camera system and method for reducing parallax |
US20040240650A1 (en) * | 2003-05-05 | 2004-12-02 | Microsoft Corporation | Real-time communications architecture and methods for use with a personal computer system |
US7221331B2 (en) | 2003-05-05 | 2007-05-22 | Microsoft Corporation | Method and system for auxiliary display of information for a computing device |
US7443971B2 (en) * | 2003-05-05 | 2008-10-28 | Microsoft Corporation | Computer system with do not disturb system and method |
US7424740B2 (en) * | 2003-05-05 | 2008-09-09 | Microsoft Corporation | Method and system for activating a computer system |
US7827232B2 (en) | 2003-05-05 | 2010-11-02 | Microsoft Corporation | Record button on a computer system |
US20040222978A1 (en) * | 2003-05-05 | 2004-11-11 | Bear Eric Gould | Control and communications panel for a computer system |
US20040235520A1 (en) | 2003-05-20 | 2004-11-25 | Cadiz Jonathan Jay | Enhanced telephony computer user interface allowing user interaction and control of a telephone using a personal computer |
US20060056399A1 (en) * | 2003-08-06 | 2006-03-16 | Christie Joseph M | Telecommunication tandem system for circuit-based traffic |
US7158628B2 (en) * | 2003-08-20 | 2007-01-02 | Knowlagent, Inc. | Method and system for selecting a preferred contact center agent based on agent proficiency and performance and contact center state |
US7359918B2 (en) * | 2003-09-26 | 2008-04-15 | American Tel-A-Systems, Inc. | System and method for intelligent script swapping |
US7548255B2 (en) * | 2003-09-30 | 2009-06-16 | Microsoft Corporation | Method and system for capturing video on a personal computer |
US7440556B2 (en) * | 2003-09-30 | 2008-10-21 | Microsoft Corporation | System and method for using telephony controls on a personal computer |
US7216221B2 (en) * | 2003-09-30 | 2007-05-08 | Microsoft Corporation | Method and system for unified audio control on a personal computer |
US20050132271A1 (en) * | 2003-12-11 | 2005-06-16 | International Business Machines Corporation | Creating a session document from a presentation document |
US7113981B2 (en) * | 2003-12-29 | 2006-09-26 | Mixxer, Inc. | Cellular telephone download locker |
US20060072739A1 (en) * | 2004-10-01 | 2006-04-06 | Knowlagent Inc. | Method and system for assessing and deploying personnel for roles in a contact center |
US7581034B2 (en) * | 2004-11-23 | 2009-08-25 | Microsoft Corporation | Sending notifications to auxiliary displays |
US7711868B2 (en) | 2004-11-23 | 2010-05-04 | Microsoft Corporation | Waking a main computer system to pre-fetch data for an auxiliary computing device |
US7634780B2 (en) * | 2004-11-23 | 2009-12-15 | Microsoft Corporation | Method and system for exchanging data between computer systems and auxiliary displays |
US7784065B2 (en) | 2005-02-07 | 2010-08-24 | Microsoft Corporation | Interface for consistent program interaction with auxiliary computing devices |
US20060242590A1 (en) * | 2005-04-21 | 2006-10-26 | Microsoft Corporation | Simple content format for auxiliary display devices |
US7517355B2 (en) * | 2005-09-08 | 2009-04-14 | Medafor, Incorporated | Method of supporting and/or applying particulate materials |
US9008075B2 (en) | 2005-12-22 | 2015-04-14 | Genesys Telecommunications Laboratories, Inc. | System and methods for improving interaction routing performance |
US20080227520A1 (en) * | 2007-03-15 | 2008-09-18 | Konami Gaming Incorporated | Gaming machine checking color of symbol on reel |
US20080249933A1 (en) * | 2007-04-06 | 2008-10-09 | Rethorn Michael K | Real-time indication of remittance sender that remittance transaction fails |
US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
US8503472B2 (en) * | 2010-02-23 | 2013-08-06 | Intel Corporation | Partial bandwidth request techniques in wireless networks |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5008930A (en) * | 1989-10-24 | 1991-04-16 | At&T Bell Laboratories | Customer definable integrated voice/data call transfer technique |
US5058152A (en) * | 1989-12-12 | 1991-10-15 | The Telephone Connection | Anonymous interactive telephone system having direct connect feature |
US5241588A (en) * | 1990-12-18 | 1993-08-31 | Bell Communications Research, Inc. | Systems and processes providing programmable or customized customer telephone information services |
US5241580A (en) * | 1990-12-18 | 1993-08-31 | Bell Communications Research, Inc. | Method for validating customized telephone services |
US5136636A (en) * | 1991-02-07 | 1992-08-04 | At&T Bell Laboratories | Telephone connection to a nearby dealer |
US5208848A (en) * | 1991-08-26 | 1993-05-04 | At&T Bell Laboratories | Telecommunications call processing |
US5259026A (en) * | 1991-12-18 | 1993-11-02 | Bell Communications Research, Inc. | Method for speed calling automatic update |
US5452350A (en) * | 1992-03-09 | 1995-09-19 | Advantis | Subscriber call routing processing system |
US5359646A (en) * | 1992-04-30 | 1994-10-25 | Bell Communications Research, Inc. | Testing of distributed communications networks |
-
1994
- 1994-11-04 US US08/334,120 patent/US5533115A/en not_active Expired - Lifetime
-
1995
- 1995-10-18 CA CA002204132A patent/CA2204132C/en not_active Expired - Fee Related
- 1995-10-18 WO PCT/US1995/014089 patent/WO1996014704A1/en active Search and Examination
- 1995-10-18 EP EP95939663A patent/EP0789963A4/en not_active Withdrawn
- 1995-11-01 JP JP8515383A patent/JP3058450B2/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
WO1996014704A1 (en) | 1996-05-17 |
CA2204132A1 (en) | 1996-05-17 |
EP0789963A4 (en) | 2000-08-23 |
JPH10506766A (en) | 1998-06-30 |
JP3058450B2 (en) | 2000-07-04 |
US5533115A (en) | 1996-07-02 |
EP0789963A1 (en) | 1997-08-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2204132C (en) | A network-based telephone system providing coordinated voice and data delivery | |
CA2179498C (en) | A network-based telephone system having interactive capabilities | |
US5987116A (en) | Call center integration with operator services databases | |
US5572581A (en) | Method and apparatus for delivering calling services | |
US7266192B2 (en) | Retrieval of data related to a call center | |
US5706286A (en) | SS7 gateway | |
US6038309A (en) | Apparatus and method for externally controlling processing of a service call | |
US6188757B1 (en) | System and method for automatic provision customer selection, and deactivation of temporary advance intelligent network services | |
US5991389A (en) | Programmable service architecture for call control processing | |
US5546450A (en) | System and method for providing switch translations | |
US6768793B1 (en) | Telecommunications resource connection and operation using a service control point | |
US6831972B1 (en) | System and method for automated provision and customer selection of temporary advanced intelligent network services | |
US6493433B2 (en) | Multi-threaded database system for an interactive voice response platform | |
WO1998025392A9 (en) | Call center services for local calls using local number portability | |
KR100633716B1 (en) | NPA split management in intelligent network environment | |
EP0661891B1 (en) | An apparatus for managing an element manager for a telecommunications switch | |
US6088443A (en) | Intelligent services network adjunct processor | |
CA2242094C (en) | Call center integration with operator services databases | |
EP0950324A1 (en) | A method and a system for providing connections | |
US6343124B1 (en) | Telephone networking system | |
EP1269734B1 (en) | Communications | |
CA2275092A1 (en) | Method for providing telecommunications services as well as switching nodes, service control nodes and switching system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKLA | Lapsed |