WO2000059237A1

WO2000059237A1 - Control node with intelligent network

Info

Publication number: WO2000059237A1
Application number: PCT/CA2000/000268
Authority: WO
Inventors: John Lawrence Brunet; Roman R. Romaniuk; Csaba C. Csaki; Bao M. Nguyen
Original assignee: Nortel Networks Limited
Priority date: 1999-03-26
Filing date: 2000-03-14
Publication date: 2000-10-05
Also published as: AU3140500A

Abstract

An Interchange device is disclosed that is connected to both an Intelligent Network (IN) within a publicly switched telephone network and an Internet Protocol (IP) network. This device allows the IN to use IN queries to initiate a service program on the device which sends control commands to the Internet and further allows the IP network to use IP signals to initiate a service program on the device which triggers IN operations on the IN. The Interchange device operates with the combination of a Transaction Capability Application Part (TCAP) algorithm, a Java Telephony Application Programming Interface (JTAPI) algorithm, a service manager, and a number of service programs. One such service program is an Internet Call Waiting program.

Description

CONTROL NODE WITH INTELLIGENT NETWORK FIELD OF THE INVENTION

This invention relates generally to the use of Intelligent Network (IN) technology and more specifically to an apparatus for combining IN and data transfer networks. BACKGROUND OF THE INVENTION

Recently, the development and implementation of Intelligent Network (IN) technology within Publicly Switched Telephone Networks (PSTN) has facilitated the generation of large numbers of varied network-wide services as will be described herein below. In an Intelligent Network, each switching element, known as a Service Switching Point (SSP) , may interrupt call processing and exchange messages with a central control computer, known as a Service Control Point (SCP), to obtain instructions for completing the call.

The messages are exchanged by way of out-of-band signalling systems such as Signalling System No. 7 (SS7), also known as Common Channel Signalling No. 7 (CCS7). Such signalling systems exchange Transaction Capability Application Part (TCAP) messages or queries between the SSPs and the SCP to deploy selected services. In addition, the SS7 system carries ISDN-User Part (ISUP) messages between SSPs in order to setup and route calls. Hence, the TCAP and ISUP messages are handled by a data communication system separate from the trunks which carry the calls themselves.

This Intelligent Network setup allows for the implementation of telephone services without utilizing traditional voice trunks for control signalling. Hence, the telephone services can be designed with considerable control signalling without reducing the call capacity of the actual telephone network. This is more important as a larger number of complex telephone services are designed that require increasing amounts of network signalling.

Services that have been implemented through use of Intelligent Network technology include call waiting which notifies a user of an incoming call during an active telephone voice call, calling name display which indicates the name and phone number corresponding to a calling party, and call answer which is an automated call answering service that allows calling parties to leave messages. Each of these services is a feature in which a telephone user can subscribe to and which according to current designs can be controlled within SCPs. An SCP implemented with these features performs numerous operations including a look-up to determine if a particular user has subscribed to the particular feature that is to be triggered along with other control operations as one skilled in the art would understand to be necessary to provide the desired features. For instance, a triggered call answer function would require the initiation of forwarding signals to reroute the telephone call to a voice mail service.

There are a number of key problems associated with the current implementation of Intelligent Network technology. One key limitation associated with stand alone Intelligent Network technology implementations is the limited access for users to modify their particular service options. Changes to the options must be made at the SCPs which can typically only be accessed by the telephone company, hence making it difficult to adjust the options associated with the services due to dynamic considerations such as the time of day or the location of the user. To overcome this and other limitations, a number of implementations of Intelligent Network technology have been contemplated that have a limited use of the Internet. One such implementation is disclosed within U.S. Patent Application 08/994014 entitled "System and Method for Centrex Translation" by Rasmussen, filed on December 18, 1997 and assigned to the assignee of the present application. In the '014 application, a centralized centrex translation server connected to the Intelligent Network by a TCP/IP transport mechanism is utilized to store a database of telephone extension numbers and their corresponding telephone directory numbers. The centralized server and the TCP/IP transport mechanism replaces the functionality of previous designs that utilized SCPs with similar databases along with the SS7 network of links. Hence, the implementation of the ^Λ014 application reduces the necessary traffic within the SS7 network. Further, with the use of a web interface, the ^λ014 application can allow for users to directly modify their telephone directory numbers to compensate for their current location. Another implementation of Intelligent Network technology with a limited use of the Internet can be seen in FIGURE 1. In this setup, an SCP 102 is coupled both to the PSTN 104 via the SS7 network and the Internet 106 via a database 108 and a TCP/IP connection. The SCP 102 is a computing device running a control software that comprises an SS7 interface 110 for forwarding TCAP messages, a TCAP algorithm 112 for transferring the TCAP messages into IN messages, and an Application Programming Interface (API) 114 that is used to run one of a series of services 116,118 that may be offered by the particular SCP 102 once triggered by a TCAP message. In the sample shown, the API 114 is coupled to the database 108 that includes each user's service options and the database 108 is further coupled to the Internet 106. A user's modem 120 is also coupled to the Internet 106 through the PSTN 104 and an Internet Service Provider (ISP) 121 that provides a modem pool for connecting the PSTN 104 to the Internet 106. The user's modem 120 is further coupled to the user's computer 122 and telephone 124. The user has access to his/her corresponding entry within the database 108 via the user's computer and modem, the PSTN 104, the ISP 121 and the Internet 106. Therefore, through a web browser a user can adjust his/her telephone service options remotely. All the user in such a situation requires is Internet access, along with his/her identification number and password. In the setup of FIGURE 1, the API 104 does a database look-up to determine the options chosen by a particular user when requested by a service feature.

One key limitation that exists in these known implementations is the lack of dynamic control for the user of the telephone services. Although the user in these setups can modify his/her feature options remotely, the system does not allow for the user to have discretion when considering particular situations in which he/she may wish to choose one service option over another.

For one particular service, that being Internet Call Waiting (ICW) , known telephone networks do allow for limited dynamic control of incoming telephone calls. This ICW service allows someone who subscribes to the service to be alerted of an incoming call even when the user is on the Internet. Therefore, the user can accept or decline the incoming call as the calling party waits for a response. The accepting of the call with this service causes the user' s Internet session to be terminated and the call to be established.

One known telephone network implemented with an ICW service comprises numerous switches along with a Primary Rate Interface (PRI) ICW node; the PRI ICW node comprising an independent add-on component to an existing switch. The switches of this telephone network may have IN capability, but the ICW service implemented with use of the PRI ICW node does not utilize this IN functionality. The operation of this known telephone network during an ICW situation begins when a calling party attempts to initiate a telephone session with a called party that has subscribed to the ICW service and whose telephone line is busy due to his/her modem being connected to the Internet. Previous to the development of ICW, the calling party would receive a busy signal or be forwarded to the called party' s voice mail account, the call could not be completed and possibly the Internet connection with the called party' s modem would become corrupted, hence requiring the called party to reinitiate the Internet connection.

With the establishment of the PRI ICW node, the call is diverted to the PRI ICW node in the occurrence that the called party's telephone line is busy. This requires the establishment of a physical trunk between the calling party's telephone and the PRI ICW node, via numerous other switches. Once the PRI ICW function receives the notification of the calling party's request, the PRI ICW node determines if the called party is logged into the Internet and, if so, notifies him/her of the calling party' s request to initiate a telephone session by initiating an alert window on the called party's computer. The called party then must then decide whether to accept or decline the incoming telephone call. If the called party declines the call, the PRI ICW node returns a busy signal to the calling party. If the called party accepts the call, an ICW script running on the called party's computer automatically disconnects the called party' s computer from the Internet and the PRI ICW node connects the call between the PRI ICW node and the called party's telephone.

There are a number of key problems with this known setup that does not utilize an IN control network. For one, if the called party accepts the call, the connection between the calling party and called party will be setup through the PRI ICW node even if the two parties are physically close and the PRI ICW node is at a remote location. Secondly, even if the called party rejects the call or is not logged into the Internet, the connection between the calling party and the PRI ICW node utilizes valuable network resources that could be used for voice trunks. Thirdly, the PRI ICW node has limited flexibility to run numerous other services beyond an ICW function. A proposal has been made for a telephone network that utilizes some of the flexibility of the Intelligent Network control signalling system to establish an ICW service. The ICW service, in this proposed network, is implemented with use of a standard SCP and an external ICW server. The SCP and the ICW server in this proposed implementation are connected via a

Session Initiation Protocol (SIP) over the Internet while the ICW server is further connected to the Internet in a similar manner to the PRI ICW node of the previously described telephone network. The operation of this proposed implementation of the ICW service, from the user's point of view, is similar to that described herein above for the implementation using the PRI ICW node. The key differences in the implementations lie at the telephone network routing and control signalling levels. During operation of this telephone network, the SCP receives an IN query indicating that a calling party wishes to initiate a telephone session with a called party. The SCP then forwards this query to the ICW server via the Internet, at which time the ICW server alerts the called party of the calling party' s request if the called party has subscribed to the ICW service and if he/she is logged into the Internet. In the case that the called party is alerted of the incoming call and selects an accept option, the ICW server is notified of this selection and subsequently forwards this message to the SCP with use of the SIP over the Internet. The SCP then establishes the call at the same time as an ICW script on the called party' s computer disconnects the called party from the Internet.

There are a number of key disadvantages with this proposed implementation of the ICW capability that result from using a standard SCP and an ICW server. For one, the use of a separate ICW server connected to an SCP via the Internet requires security through use of a firewall to prevent hacking into the SCP and the ICW server. As well, when retaining the standard SCPs, the ICW service has also maintained the currently limited flexibility and functionality of the SCPs with regard to the Internet. While adding the capability of an ICW service with the addition of the ICW server, this increased functionality is limited to the specific ICW service described herein above. Further to these disadvantages, the addition of an additional server in the form of the ICW server will require further maintenance and network support resources of the server and the connection between the server and the SCP.

Another proposal that has been made for a telephone network that utilizes some of the flexibility of the Intelligent Network is disclosed in U.S. patent application No. 08/933,952 entitled "SS7 Mediation for Data Network Call Setup and Services Interworking" by Turner et al, filed September 19, 1997 and assigned to the assignee of the present invention. This proposal discloses an interface between an Intelligent Network and a data network access server (NAS) that is predominantly to be utilized for unidirectional call setup control. It does not disclose an interface used for the implementation of dynamic service programs such as an ICW service.

Hence, a device is required that would allow the implementation of an ICW service that overcomes the disadvantages of the PRI ICW node while not requiring the addition of an external ICW server. This device should further allow for the flexibility of the Internet to be directly accessible to the Intelligent Network control signalling system so that the device acts as a flexible and dynamic interface between the telephone network and a data transfer network such as the Internet. Hence, this device should not be limited to an ICW service. SUMMARY OF THE INVENTION It is an object of the present invention to overcome at least one of the disadvantages of the prior art and, in particular, to provide a node, system and method by which the flexibility of combined Intelligent Network (IN) control networks and data transfer network systems is increased. The present invention, in one broad aspect, is a control node that controls call signalling information in a switched telephone network through an Intelligent Network (IN) and a data transfer network. In this aspect, the control node includes an IN port connected to the IN, a data transfer network port connected to the data transfer network, and a processor that runs a control program and a service program. The control program responding to and generating IN signals at the IN port and the service program responding to and generating data transfer signals at the data transfer network port. In exemplary embodiments of the first aspect, the control program includes a Transaction Capability Application Part (TCAP) algorithm, a Java Telephony Application Programming Interface (JTAPI) algorithm, and a service manager.

Preferably, the data transfer network is an Internet Protocol (IP) network, though in other embodiments it is an Intranet, Asynchronous Transfer Mode (ATM) network, or other such network. Also preferably, the switched telephone network is a publicly switched telephone network.

The present invention, according to a further aspect, is a method of controlling calls in a switched telephone network through an Intelligent Network (IN) and a data transfer network.

This method includes the steps of receiving a first IN signal from an IN and performing a first service function. The first service function preferably includes generating and outputting a first data transfer signal to the data transfer network in response to the first IN signal. The method also includes the steps of receiving a second data transfer signal from the data transfer network and performing a second service function. The second service function includes generating and outputting a second IN signal to the IN in response to the second data transfer signal.

Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures. BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention are described with reference to the following figures, in which: FIGURE 1 is a block diagram illustrating a known telephone network that allows user initiated modifications to service options; and

FIGURE 2 is a block diagram illustrating a preferred embodiment telephone network.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A preferred embodiment of the present invention, described herein below, is implemented within a control node connected to the Internet that can respond to and initiate Intelligent Network (IN) control signals. It should be understood that this preferred embodiment is not meant to limit the scope of the present invention and in fact, the present invention can be implemented in many ways while still allowing a control node connected to a data transfer network and the Intelligent Network (IN) control signalling within the PSTN, hereinafter referred to simply as an IN, to allow at least one of the data transfer network and the IN to control a portion of the other network.

With reference to FIGURE 2, a preferred embodiment of the present invention is now described. Depicted in FIGURE 2 is a control node 202 according to a preferred embodiment, hereinafter referred to as an Interchange device, a PSTN 204 that has IN technology implemented, an SS7 interface block 206 coupled between an IN port 207 within the Interchange device 202 and the PSTN 204, and an Internet network 208 with which an IP port 209 within the Interchange device 202 is coupled. The SS7 interface block 206, according to a preferred embodiment, comprises an SS7 interface card 210 coupled to the PSTN 204 via an SS7 connection and an SS7 protocol stack 212 coupled between the SS7 interface card 210 and the IN port 207 within the Interchange device 202. In a preferred embodiment, the SS7 interface card 210 and the SS7 protocol stack 212 together comprise a Connect7 product produced by ADC Newnet of Shelton, Connecticut. It is noted that the SS7 connection to the PSTN 204 is a connection to the control signalling portion of the PSTN 204 and not to the actual voice trunk telephone network.

In a preferred embodiment, the Interchange device 202 is a personal computer that runs a control software written in a Java programming language with an operating system of Windows NT produced by Microsoft Corporation of Redmond, Washington. However, one skilled in the art would understand that the

Interchange device 202, according to this preferred embodiment, could be implemented on any computing apparatus that allows for exchange of data control signals with both a telephone Intelligent Network (IN) and a data transfer network such as the Internet.

The control software, in a preferred embodiment depicted in FIGURE 2, comprises a TCAP algorithm 214, a Java Telephony API (JTAPI) algorithm 216, a service manager 218, one or more service programs 222,224 and a service administrator 220. In a first operation of this preferred embodiment, the TCAP algorithm 214 inputs, via the IN port 207, SS7 messages from the SS7 stack 212 that correspond to IN queries from the PSTN 204, processes the SS7 messages, and maps them onto IN operations that are subsequently forwarded to the JTAPI algorithm 216. The JTAPI algorithm 216 inputs and processes the IN operations and outputs JTAPI events to the service manager 218 in response to the input IN operations. The service manager 218 inputs the JTAPI events and forwards them to an appropriate service program 222 or 224 running on the Interchange device 202.

According to a second operation of this preferred embodiment, the service programs 222,224 running on the Interchange device 202 send JTAPI calls to the JTAPI algorithm 216. Although not explicitly shown in FIGURE 2, these JTAPI calls can be sent, in an exemplary embodiment, directly from the service programs 222,224 to the JTAPI algorithm 216 without traversing the service manager 218. In response to the sent JTAPI calls, the JTAPI algorithm 216 subsequently processes the events and outputs corresponding IN messages to the TCAP algorithm 214. The TCAP algorithm 214 further processes the IN messages and outputs, via the IN port, corresponding SS7 messages to the SS7 interface block 206 that are then sent as IN responses to the PSTN 204.

In exemplary versions of this preferred embodiment, both the first and second operations described herein above are supported, though it should be understood that this is not meant to limit the scope of the present invention. Alternative versions of this preferred embodiment are possible that only support one of the two general operations described above. The service administrator 220 is an interface for a human operator of the Interchange device 202 which allows the operator to add and/or subtract service programs from the Interchange device 202.

It is noted that the TCAP algorithm 214 is similar to that utilized in known SCPs (eg. SCP 102 in FIGURE 1) while the JTAPI algorithm 216 is an implementation of a standard interface produced by Sun Microsystems, Inc. of Palo Alto, California. A similar JTAPI algorithm has previously been implemented in systems that require a telephone to be directly coupled to a personal computer such as at a customer service desk. One should understand that in alternative embodiments, the JTAPI algorithm could be replaced with another API that the service programs can communicate with.

In FIGURE 2, first and second service programs 222,224 are shown to be coupled to the service manager 218, though it should be understood that a large number of service programs, hereinafter referred to collectively as the service logic, could be implemented within the Interchange device 202.

According to a preferred embodiment, one or more service programs 222,224 on the Interchange device 202 are coupled to the Internet 208 via the IP port 209. This is to allow, in a preferred embodiment, a user of a telephone service to make dynamic decisions, through use of a web browser or other Internet connected application, concerning a particular service program that has been initiated by an IN query from the PSTN 206 with use of the first operation of the control software within the Interchange device 202. Further, according to an exemplary embodiment, a user is able to initiate a service program that in turn is capable of initiating the sending of an IN response to the PSTN 206 with use of the second operation of the control software. Some embodiments of the present invention have service programs 222,224 coupled to the Internet 208 in order to allow the service program to be controlled by Internet based software programs and/or to control Internet based software programs.

Additionally, according to an exemplary version of a preferred embodiment, the service manager 218, as depicted in FIGURE 2, is also coupled to the Internet 208 via the IP port 209. This allows the service manager 218 to initiate a remote service logic 226 that is not installed on the particular

Interchange device 202, but is instead installed on another device coupled to the Internet 208. This is an additional flexibility of the Interchange device 202 which would allow it to function with a well known ICW server as was described in detail herein above. Hence, service programs are not required to be added directly onto a particular Interchange device 202 if they are accessible on the Internet 208. In some exemplary embodiments, a service program within an Interchange device 202 is coupled to the Internet 208 in order to allow other Interchange devices (not shown) to access the program without having to install the actual program software locally.

Although not depicted in FIGURE 2, one skilled in the art would understand that a firewall should be implemented between the Interchange device 202 and the Internet 206 for protection of the Interchange device 202 against hacking.

Depicted within FIGURE 2, the first service program 222 can be seen to be directly coupled to the Internet 208 while a user' s modem 228 and computer 230 are coupled to the Internet 208 through the PSTN 204 and an ISP 231. Also depicted within FIGURE 2 is a user's telephone 232 coupled to the modem 228 and another telephone coupled to the PSTN 204, these telephones 232,234 being referred to herein below as the called party and the calling party respectively.

In the example shown and described herein below, the first service program 222 is an Internet Call Waiting (ICW) program, described in detail herein below, that allows the user (the called party) to accept or reject incoming telephone calls that would otherwise get a busy signal due to the user' s telephone line being utilized by the connection of the computer 228 to the Internet 208. To illustrate the full operation of the Interchange device 202 and some of the advantages of such an implementation, the operation of the ICW program 222, according to a preferred embodiment of the present invention, is now described with reference to FIGURE 2. The operation of the ICW service program 222 begins with the calling party attempting to initiate a telephone call with the called party. This attempt triggers a Termination Attempt Trigger (TAT) query to be sent to the Interchange device 202 from the PSTN 204. The TAT is a well known IN query that is sent prior to a telephone being rung within an IN controlled

PSTN. In traditional usage, this trigger is used for services such as calling name display. It comprises the calling party's telephone number, the called party's telephone number, and a number of other well known parameters. Within the setup depicted in FIGURE 2, the TAT query is input to the SS7 interface block 206 which subsequently forwards the TAT query, via the IN port 207, to the TCAP algorithm 214 within the Interchange device 202. The TCAP algorithm 214 processes the TAT query and maps it to an IN operation which is then output to the JTAPI algorithm 216. The JTAPI algorithm 216 processes the IN operation and outputs a JTAPI event to the service manager 218. The service manager 218 recognizes that the ICW service program 222 is to be input with all JTAPI events generated by TAT queries and subsequently outputs the JTAPI event to the ICW service program 222.

In a preferred embodiment, the ICW service program 222, once input with the JTAPI event, determines whether the called party has logged into the particular service. According to this preferred embodiment, a user of the ICW service program 222, that being the called party in this situation, when connected to the Internet, can initiate a Java program, connect to the IP address of the service program 222, and login with use of a unique identifier and password. In alternative embodiments, the user simply registers for the service program 222 with his/her telephone provider. In these alternative embodiments, each time the ICW service program 222 operates, the service program 222 must determine whether the user's computer 230 with the IP address of the called party is currently logged into the Internet 208. If the called party is logged into the ICW service program 222, the service program 222 initiates an ICW client program on the called party's computer 230. This ICW client program pops up a notification window on the screen of the called party's computer 230 upon receiving a message from the ICW service program 222. The notification window, according to a preferred embodiment, illustrates to the called party the name of the calling party and his/her corresponding telephone number, as well as providing two options, those being accept and decline . If the called party selects the accept option, the ICW client program sends an IP packet indicating the choice to the ICW service program 222 and then proceeds to disconnect the user from the Internet 208. In a preferred embodiment, the selection of the accept/decline option is done with the user clicking on a corresponding button with his/her mouse. The ICW service program 222, after receiving the IP packet, subsequently processes the IP packet and generates a corresponding JTAPI call that is output to the JTAPI algorithm 216. The JTAPI algorithm 216 then processes the call and outputs an IN message to the TCAP algorithm 214 which subsequently processes the message and generates an Authorize Termination (AuthTerm) response to be forwarded by the SS7 interface block 206 to the PSTN 204. This response causes the PSTN 204 to connect a telephone session between the calling party's telephone 234 and the called party's telephone 232.

If the called party selects the decline option, a JTAPI event is forwarded and processed through the Interchange device 202, as described above for the accept button being pressed. This results in a response being sent to the PSTN 204 that causes the default call behaviour to resume which may either connect the calling party to a voice mail account corresponding to the called party or send a busy signal to the calling party's telephone 234 to indicate to the calling party that the line is busy. In a preferred embodiment of the present invention the

TCAP algorithm 214 has a timer (not shown) that determines the length of time that has passed from the time of arrival of an IN query. If a predetermined maximum allowable time is surpassed, the TCAP algorithm 214 sends, according to a preferred embodiment, a response to the PSTN 204 similar to that if the called party had declined the telephone call.

There are a number of advantages of the ICW service implementation according to the embodiment of the present invention described above over the known ICW implementations. Firstly, compared to the described ICW implementation that uses a PRI ICW node, the implementation of the present invention has similar advantages to that of the described ICW implementation that uses a standard SCP along with an ICW server. For instance, the connection of the calling party to the called party, in the event of an acceptance of the call by the called party, is done directly with normal routing techniques rather than through a particular node such as the PRI ICW node.

The ICW implementation according to the embodiment of the present invention described above has further advantages over the ICW implementation that uses a standard SCP with an external ICW server. For one, the implementation according to the preferred embodiments of the present invention does not require an Internet connection between the ICW service program and the IN. This connection contributes a number of disadvantages to the overall ICW implementation. The extra transmission of control signals over the Internet between the SCP and the ICW server reduces the reliability and speed compared to the transmission over a direct connection, via the service manager, in the preferred embodiments of the present invention. As well, an additional firewall would be required between the ICW server and the SCP for protection from hacking that is not required in the preferred embodiments. Additionally, another key advantage of the Interchange device 202 compared to the standard SCP and ICW server is that the Interchange device 202 can be utilized for numerous other services that bridge a data transfer network such as the Internet and the IN within the PSTN.

It is noted that the known telephone network depicted within FIGURE 1 could be implemented with services that have accept and decline options. The key difference between this implementation and that of the preferred embodiments of the present invention is that the user must select to always accept or always decline incoming calls with this system; possibly changing the option within the database at selected points of time. The service does not allow for the user to have dynamic control and, hence, discretion over which calls to accept and which to decline.

Although the described implementation of the present invention is for an ICW service program 222, it is recognized that numerous other service programs could operate on the Interchange device 202 of the preferred embodiments. One important advantage of the Interchange device 202 is in fact its flexibility to operate many different services including one or more services that operate as a control interface between a data transfer network such as the Internet and the IN.

The present invention has been described herein above for an embodiment in which a control node which can initiate and respond to IN queries and IP packets. This allows a user connected to the Internet to have a limited control over signalling within IN telephone networks and for signalling within IN telephone networks to have a limited control over software running on devices connected to the Internet.

It should be understood that alternative embodiments of the present invention are contemplated that would utilize other data transfer networks other than the Internet that are accessible to individual users such as Intranets, Asynchronous Transfer Mode (ATM) networks, or even networks not yet designed that allow for users and/or software running on the network to send control signals to and/or respond to control signals sent from a device similar to the Interchange device described herein above.

According to the present invention, it should be understood that an Interchange device as described herein above can operate in a number of different ways and still remain within the scope of the present invention. In a first broad operation, the control node is input with an IN signal from an IN within the PSTN, processes the IN signal, and outputs a data transfer signal to a data transfer network such as the Internet in response to the IN signal. It is noted that the control signal in this operation could, among other things, be directed to software run on the data transfer network, be used to initiate a software program on the data transfer network, and/or be directed to a human operator connected to the data transfer network. In a second broad operation, the control node is input with a data transfer signal from a data transfer network such as the Internet, processes the data transfer signal, and outputs an IN signal to an IN within the PSTN in response to the data transfer signal. The data transfer signal, in this operation, may have been generated by a software and/or user connected to the data transfer network. The operation of the telephone network of FIGURE 2 described herein above for the ICW service can be seen as a combination of the first broad operation of the control node followed by the second broad operation.

Although the control node or Interchange device 202 for the preferred embodiment described herein above is implemented as software within a personal computer, this is not meant to limit the scope of the present invention. In fact, the Interchange device 202 could be implemented with discrete components for all or a portion of the software algorithms running within the Interchange device 202. Hence, including one or more of a TCAP device, JTAPI device, service manager device, and service program device.

Persons skilled in the art will appreciate that there are yet more alternative implementations and modifications possible to use an apparatus similar to that described above to implement a dynamic control interface between an Intelligent Network and a data transfer network, and that the above implementation is only an illustration of this embodiment of the invention. The scope of the invention, therefore, is only to be limited by the claims appended hereto.

Claims

CLAIMS :

1. A control node for controlling call signalling information in a switched telephone network through an Intelligent Network (IN), the control node comprising: an IN port for connection to the IN; a data transfer network port for connection to a data transfer network; and a processor, connected to the IN port and the data transfer network port, that is operable to run a control program that responds to and generates IN signals at the IN port and to run at least one service program that responds to and generates data transfer signals at the data transfer network port; whereby the call signalling information may also be controlled through the data transfer network.

2. A control node according to claim 1, wherein the control program operates to receive a first IN signal from the IN port, process the first IN signal, and output a first control signal to the service program in response to the first IN signal; and the service program operates to receive the first control signal and perform a service function comprising outputting a first data transfer signal to the data transfer network port in response to the first control signal; and wherein the service program further operates to receive a second data transfer signal from the data transfer network port and perform a function comprising outputting a second control signal to the control program in response to the second data transfer signal; and the control program further operates to receive the second control signal, process the second control signal, and output a second IN signal to the IN port in response to the second control signal.

3. A control node according to claim 2, wherein the control program comprises a Transaction Capability Application Part (TCAP) algorithm, an Application Programming Interface (API) algorithm, and a service manager.

4. A control node according to claim 3, wherein the TCAP algorithm operates to receive the first IN signal from the IN port, process the first IN signal, and output a first IN message in response to the first IN signal; the API algorithm operates to receive the first IN message, process the first IN message, and output a first API event, that corresponds to the first control signal, in response to the first IN message; and the service manager operates to receive the first API event, process the first API event, and forward the first API event to the service program; and wherein the API algorithm further operates to receive a second API event that corresponds to the second control signal, process the second API event, and output a second IN message in response to the second API event; and the TCAP algorithm operates to receive the second IN message, process the second IN message, and output the second IN signal to the IN port in response to the second IN message.

5. A control node according to claim 4, wherein the service manager further operates to receive the second API event from the service program and forward the second API event to the API algorithm.

6. A control node according to claim 4, wherein the API algorithm is a Java Telephony API (JTAPI) algorithm.

7. A control node according to claim 4, wherein the service manager further operates to forward a third API event through the data transfer network port to a service program running on the data transfer network; and wherein the service manager receives a fourth API event through the data transfer network port from the service program running on the data transfer network.

8. A control node according to claim 4, wherein the data transfer network operates with use of Internet Protocol (IP) and the control node is an IP server; wherein the service program comprises an Internet Call

Waiting (ICW) service program and the first IN signal indicates that a calling party is attempting to initiate a telephone connection with a called party; wherein the first data transfer signal output to the data transfer network port is arranged to initiate an alert window on the called party' s computer screen that includes first and second options; and wherein, if the called party selects the first option, the second data transfer signal received at the ICW service program from the data transfer network port indicates a first operation to be taken and the second IN signal triggers the first operation; and, if the calling party selects the second option, the second data transfer signal received at the ICW service program from the data transfer network port indicates a second operation to be taken and the second IN signal triggers the second operation.

9. A control node according to claim 8, wherein the first and second options are accept and decline options, the first operation is for connecting the calling party with the called party, and the second operation is for one of connecting the calling party to a voice mail associated with the called party and providing a busy signal to the calling party.

10. A control node according to claim 3, wherein the control program further comprises an administrative program that operates to add and remove service programs from the control node.

11. A control node according to claim 1, wherein the data transfer network operates with use of Internet Protocol (IP) and the control node is an IP server.

12. . A control node according to claim 1, wherein the IN port comprises a Signalling System No. 7 (SS7) interface apparatus .

13. An Internet Protocol (IP) server for controlling calls in a publicly switched telephone network through an Intelligent Network (IN) , the IP server comprising: an IN port for connecting to the IN; an IP port for connecting to an IP network; and a processor, connected to the IN port and the data transfer network port, that is operable to run a control program that responds to and generates IN signals at the IN port and to run at least one service program that responds to and generates IP signals at the IP port; whereby the calls may also be controlled through the IP network.

14. An IP server according to claim 13, wherein the control program operates to receive a first IN signal from the IN port, process the first IN signal, and output a first control signal to the service program in response to the first IN signal; and the service program operates to receive the first control signal and perform a service function comprising outputting a first IP signal to the IP port in response to the first control signal; and wherein the service program further operates to receive a second IP signal from the IP port and perform a function comprising outputting a second control signal to the control program in response to the second IP signal; and the control program further operates to receive the second control signal, process the second control signal, and output a second IN signal to the IN port in response to the second control signal .

15. An IP server according to claim 14, wherein the control program comprises a Transaction Capability Application Part (TCAP) algorithm, a Java Telephony Application Programming Interface (JTAPI) algorithm, and a service manager.

16. An IP server according to claim 15, wherein the TCAP algorithm operates to receive the first IN signal from the IN port, process the first IN signal, and output a first IN message in response to the first IN signal; the JTAPI algorithm operates to receive the first IN message, process the first IN message, and output a first JTAPI event, that corresponds to the first control signal, in response to the first IN message; and the service manager operates to receive the first JTAPI event, process the first JTAPI event, and forward the first JTAPI event to the service program; and wherein the JTAPI algorithm further operates to receive a second JTAPI event that corresponds to the second control signal, process the second JTAPI event, and output a second IN message in response to the second JTAPI event; and the TCAP algorithm operates to receive the second IN message, process the second IN message, and output the second IN signal to the IN port in response to the second IN message.

17. An IP server according to claim 16, wherein the service manager further operates to receive the second JTAPI event from the service program and forward the second JTAPI event to the JTAPI algorithm.

18. An IP server according to claim 15, wherein the control program further comprises an administrative program that operates to add and remove service programs from the IP server.

19. An IP server according to claim 13, wherein the IN port comprises a Signalling System No. 7 (SS7) interface apparatus .

20. A method of controlling calls in a switched telephone network through an Intelligent Network (IN) , the method comprising the steps of: receiving a first IN signal from an IN and performing a service function comprising generating and outputting a first data transfer signal to a data transfer network in response to the first IN signal; and receiving a second data transfer signal from the data transfer network and performing a service function comprising generating and outputting a second IN signal to the IN in response to the second data transfer signal; whereby the calls may also be controlled through the data transfer network.

AMENDED CLAIMS

[received by the International Bureau on 1 August 2000 (01.08.00); original claims 1-20 replaced by new claims 1 -25 (8 pages)]

1. A control node for controlling call signalling information in a switched telephone network through an Intelligent Network (IN), the control node comprising: an IN port for connection to the IN; a data transfer network port for connection to a data transfer network; and a processor, connected to the IN port and the data transfer network port, that is operable to run a control program, the control program comprising an IN interface algorithm that responds to and generates IN signals at the IN port, a service manager that controls at least one service program that responds to and generates data transfer signals at the data transfer network port, and an Application Programming Interface (API) algorithm that interfaces between the IN interface algorithm and the service manager; whereby the call signalling information may also be controlled through the data transfer network.

2. A control node according to claim 1, wherein the control program operates to receive an IN signal from the IN port, process the IN signal, and output a control signal to the service program in response to the IN signal; and the service program operates to receive the control signal and perform a service function comprising outputting a data transfer signal to the data transfer network port in response to the control signal.

3. A control node according to claim 2, wherein the IN interface algorithm operates to receive the IN signal from the IN port, process the IN signal and output an IN message in response to the IN signal; the API algorithm operates to

AMENDED SHEET CAKπθ£ 19> receive the IN message, process the IN message and output an API event, that corresponds to the control signal, in response to the IN message; and the service manager operates to receive the API event, process the API event and forward the API event to the service program.

4. A control node according to claim 1, wherein the service program operates to receive a data transfer signal from the data transfer network port and perform a function comprising outputting a control signal to the control program in response to the data transfer signal; and the control program further operates to receive the control signal, process the control signal, and output an IN signal to the IN port in response to the control signal.

5. A control node according to claim 4, wherein the API algorithm operates to receive an API event that corresponds to the control signal, process the API event, and output an IN message in response to the API event; and the IN interface algorithm operates to receive the IN message, process the IN message, and output the IN signal to the IN port in response to the IN message.

6. A control node according to claim 5, wherein the service manager operates to receive the API event from the service program and forward the API event to the API algorithm.

7. A control node according to claim 1, wherein the control program operates to receive a first IN signal from the IN port, process the first IN signal, and output a first control signal to the service program in response to the

AMENDED SHEET (ART1&E 19) first IN signal; and the service program operates to receive the first control signal and perform a service function comprising outputting a first data transfer signal to the data transfer network port in response to the first control signal; and wherein the service program further operates to receive a second data transfer signal from the data transfer network port and perform a function comprising outputting a second control signal to the control program in response to the second data transfer signal; and the control program further operates to receive the second control signal, process the second control signal, and output a second IN signal to the IN port in response to the second control signal .

8. A control node according to claim 7, wherein the IN interface algorithm operates to receive the first IN signal from the IN port, process the first IN signal, and output a first IN message in response to the first IN signal; the API algorithm operates to receive the first IN message, process the first IN message, and output a first API event, that corresponds to the first control signal, in response to the first IN message; and the service manager operates to receive the first API event, process the first API event, and forward the first API event to the service program; and wherein the API algorithm further operates to receive a second API event that corresponds to the second control signal, process the second API event, and output a second IN message in response to the second API event; and the IN interface algorithm operates to receive the second IN message, process the second IN message, and output the second IN signal to the IN port in response to the second IN

AMENDED SHEET (AHTICtE 19) message .

9. A control node according to claim 8, wherein the service manager further operates to receive the second API event from the service program and forward the second API event to the API algorithm.

10. A control node according to claim 8, wherein the service manager further operates to forward a third API event through the data transfer network port to a service program running on the data transfer network; and wherein the service manager receives a fourth API event through the data transfer network port from the service program running on the data transfer network.

11. A control node according to claim 7, wherein the data transfer network operates with use of Internet Protocol

(IP) and the control node is an IP server; wherein the service program comprises an Internet Call Waiting (ICW) service program and the first IN signal indicates that a calling party is attempting to initiate a telephone connection with a called party; wherein the first data transfer signal output to the data transfer network port is arranged to initiate an alert window on the called party' s computer screen that includes first and second options; and wherein, if the called party selects the first option, the second data transfer signal received at the ICW service program from the data transfer network port indicates a first operation to be taken and the second IN signal triggers the first operation; and, if the calling party selects the second option, the second data transfer signal received at the ICW service program from the data transfer network port indicates a second operation to be taken and the second IN signal triggers the second operation.

12. A control node according to claim 11, wherein the first and second options are accept and decline options, the first operation is for connecting the calling party with the called party, and the second operation is for one of connecting the calling party to a voice mail associated with the called party and providing a busy signal to the calling party.

13. A control node according to claim 1, wherein the control program further comprises an administrative program that operates to add and remove service programs from the control node.

14. A control node according to claim 1, wherein the data transfer network operates with use of Internet Protocol (IP) and the control node is an IP server.

15. A control node according to claim 1, wherein the IN port comprises a Signalling System No. 7 (SS7) interface apparatus .

16. A control node according to claim 1, wherein the API algorithm is a Java Telephony API (JTAPI) algorithm.

17. A control node according to claim 1, wherein the IN interface algorithm is a Transaction Capability Application

Part (TCAP) algorithm.

AMENDED SHEET (AHTOE 19)

18. An Internet Protocol (IP) server for controlling calls in a publicly switched telephone network through an Intelligent Network (IN), the IP server comprising: an IN port for connecting to the IN; an IP port for connecting to an IP network; and a processor, connected to the IN port and the IP port, that is operable to run a control program, the control program comprising a Transaction Capability Application Part (TCAP) algorithm that responds to and generates IN signals at the IN port, a service manager that controls at least one service program that responds to and generates IP signals at the IP port, and a Java Telephony Application Programming Interface (JTAPI) algorithm that interfaces between the TCAP algorithm and the service manager; whereby the calls may also be controlled through the IP network.

19. An IP server according to claim 18, wherein the control program operates to receive a first IN signal from the IN port, process the first IN signal, and output a first control signal to the service program in response to the first IN signal; and the service program operates to receive the first control signal and perform a service function comprising outputting a first IP signal to the IP port in response to the first control signal; and wherein the service program further operates to receive a second IP signal from the IP port and perform a function comprising outputting a second control signal to the control program in response to the second IP signal; and the control program further operates to receive the second control signal, process the second control signal, and output a second IN signal to the IN port in response to the second

AMENDS) SHEET < KTlCi£ 19) control signal.

20. An IP server according to claim 19, wherein the TCAP algorithm operates to receive the first IN signal from the IN port, process the first IN signal, and output a first IN message in response to the first IN signal; the JTAPI algorithm operates to receive the first IN message, process the first IN message, and output a first JTAPI event, that corresponds to the first control signal, in response to the first IN message; and the service manager operates to receive the first JTAPI event, process the first JTAPI event, and forward the first JTAPI event to the service program; and wherein the JTAPI algorithm further operates to receive a second JTAPI event that corresponds to the second control signal, process the second JTAPI event, and output a second IN message in response to the second JTAPI event; and the TCAP algorithm operates to receive the second IN message, process the second IN message, and output the second IN signal to the IN port in response to the second IN message.

21. An IP server according to claim 20, wherein the service manager further operates to receive the second JTAPI event from the service program and forward the second JTAPI event to the JTAPI algorithm.

22. An IP server according to claim 18, wherein the control program further comprises an administrative program that operates to add and remove service programs from the IP server.

23. An IP server according to claim 18, wherein the IN port comprises a Signalling System No. 7 (SS7) interface

AMENDED SHEET (AHΪIO-E 19) apparatus .

24. A method of controlling calls in a switched telephone network through an Intelligent Network (IN) , the method comprising the steps of: receiving a first IN signal from an IN, processing the first IN signal to generate a first Application Programming Interface (API) event and performing a service function comprising generating and outputting a first data transfer signal to a data transfer network in response to the first API event; and receiving a second data transfer signal from the data transfer network, processing the second data transfer signal to generate a second API event and performing a service function comprising generating and outputting a second IN signal to the IN in response to the second API event ; whereby the calls may also be controlled through the data transfer network.

25. A method according to claim 24, wherein the first and second API events are first and second Java Telephony API (JTAPI) events respectively.

AMENOED SHEET {ARTICLE 19)