US5881144A - Graphical intelligent network (IN) subscription manager - Google Patents

Graphical intelligent network (IN) subscription manager Download PDF

Info

Publication number
US5881144A
US5881144A US08/785,853 US78585397A US5881144A US 5881144 A US5881144 A US 5881144A US 78585397 A US78585397 A US 78585397A US 5881144 A US5881144 A US 5881144A
Authority
US
United States
Prior art keywords
subscription data
service
ssls
ssl
subscriber
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 - Lifetime
Application number
US08/785,853
Inventor
Eric Havens
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ericsson Inc
Original Assignee
Ericsson Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Ericsson Inc filed Critical Ericsson Inc
Priority to US08/785,853 priority Critical patent/US5881144A/en
Assigned to ERICSSON, INC. reassignment ERICSSON, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HAVENS, ERIC
Priority to PCT/US1998/000888 priority patent/WO1998032292A1/en
Priority to EP98903534A priority patent/EP0954932B1/en
Priority to DE69816421T priority patent/DE69816421D1/en
Priority to AU60283/98A priority patent/AU744645B2/en
Application granted granted Critical
Publication of US5881144A publication Critical patent/US5881144A/en
Priority to NO993504A priority patent/NO993504L/en
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0062Provisions for network management
    • H04Q3/0075Fault management techniques
    • H04Q3/0079Fault management techniques involving restoration of networks, e.g. disaster recovery, self-healing networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q3/00Selecting arrangements
    • H04Q3/0016Arrangements providing connection between exchanges
    • H04Q3/0029Provisions for intelligent networking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13517SLEE - service logic execution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13525GUI - graphical user interface, inc. for service creation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13527Indexing scheme relating to selecting arrangements in general and for multiplex systems protocols - X.25, TCAP etc.
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04QSELECTING
    • H04Q2213/00Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13547Indexing scheme relating to selecting arrangements in general and for multiplex systems subscriber, e.g. profile, database, database access

Definitions

  • the present invention relates to a telecommunications system for providing subscriber features and, in particular, to the illustration and/or modification of intelligent network (IN) subscription using a graphical manager.
  • I intelligent network
  • SPC stored program-controlled
  • IN intelligent network
  • the goals of the IN are to centralize the service execution in a control node within a telecommunications network in order to provide rapid definition, testing and introduction of new services as well as the modification of existing services.
  • IN also provides greater flexibility in the design and development of new services in a multi-vendor environment with shorter lead time, and standard network interfaces.
  • the basic concept behind IN is to move the "intelligence" out of each local exchange or Service Switching Point (SSP) and centralize the services providing the intelligence in a Service Control Point (SCP).
  • SSP Service Switching Point
  • SCP Service Control Point
  • SIBs Service Independent Blocks
  • SSLs Service Script Logics
  • a specific IN service is then further developed and provided to telecommunications subscribers by utilizing (i.e., linking) one or more of the SSLs.
  • a number of SSLs are sequentially executed to provide the desired IN service.
  • Subscription data associated with a particular Intelligent Network (IN) subscriber are retrieved from the Service Management Application System (SMAS) associated with a serving Service Control Point (SCP).
  • a Service Script Logic (SSL) interpreter then analyzes the retrieved subscription data and ascertains the identities of the associated SSLs and the relationship therebetween for a given IN service.
  • a Graphical User Interface (GUI) then displays the relationship or hierarchy of the ascertained SSLs for that service.
  • a service provider may then alter the retrieved subscription data by making relational or hierarchical changes to the displayed graphical representation of the associated SSLs.
  • the interpreter thereafter interprets the graphical changes and changes the retrieved subscription data accordingly to reflect the indicated changes.
  • the changed subscription data are then communicated back to the SMAS.
  • the SMAS then down-loads the changed subscription data to the SSLs residing within the serving SCP to effectuate the changed IN service desired by the service provider.
  • FIG. 1 is a block diagram of an Intelligent Network (IN) telecommunications system providing IN services to subscribers;
  • I Intelligent Network
  • FIG. 2 is a block diagram of an IN system illustrating the association of a Service Management Application System (SMAS), Service Control Point (SCP), and Service Switching Point (SSP);
  • SMAS Service Management Application System
  • SCP Service Control Point
  • SSP Service Switching Point
  • FIG. 3 is a block diagram of an IN system illustrating an SCP interacting with an SSP to provide a particular IN service via a number of Service Script Logics (SSLs);
  • SSLs Service Script Logics
  • FIG. 4 is a block diagram of an IN system illustrating a Graphical User Interface (GUI) interacting with the SMAS in accordance with the teachings of the present invention
  • GUI Graphical User Interface
  • FIG. 5 is a graphical representation illustrating the relationship and hierarchy of associated SSLs for a particular IN service
  • FIG. 6 is a graphical representation illustrating the relationship and hierarchy of associated SSLs after a change has been made to the existing subscription data
  • FIG. 7 is a block diagram of an IN system illustrating the association of GUI, SMAS, SCP, and SSP in accordance with the teachings of the present invention.
  • FIG. 8 is a flowchart illustrating the steps performed by an IN system to represent and to modify subscription data associated with a particular IN service in accordance with the teachings of the present invention.
  • FIG. 1 shows an Intelligent Network (IN) 10 providing IN services to subscribers.
  • the basic concept behind IN is to move the intelligence out of each local exchange or Service Switching Points (SSPs) 20 and to centralize the services providing the intelligence in a Service Control Point (SCP) 30.
  • SSPs Service Switching Points
  • SCP Service Control Point
  • SCP Service Control Point
  • a new service can be added in only one place (i.e., the SCP) and provided to all subscribers connected to the multiple SSPs 20.
  • one SSP services multiple telecommunications subscribers or terminals 40
  • one SCP services multiple SSPs 20 or local switches.
  • the interfaces between the SSPs 20 are by links 50 utilizing the Signaling System No.
  • SS7 Transaction Capabilities Application Part
  • SCCP Signaling Control Connection Part
  • INP Intelligent Network Application Protocols
  • Hardware resources required to execute IN services are grouped and located separately from the SSP 20 in an Intelligent Peripheral (IP) 60.
  • IP Intelligent Peripheral
  • the purpose of such a separation is to allow multiple SSPs 20 to share the same resources, to decrease processor load in the SSPs 20 and the SCP 30, and to provide common functionality to all IN services.
  • the resources located in the IP 60 typically include, but are not limited to, announcement machines, speech synthesis, speech recognition, tone generators, voice mail, modems, e-mail, fax, and other operator resources.
  • the SCP 30 and the IP 60 are also connected via another TCAP or INAP based communications link 60.
  • the connections 70 between the IP 60 and the SSPs 20 are established using Integrated Service Digital Network (ISDN) User Part (ISUP) signals.
  • ISDN Integrated Service Digital Network
  • ISUP Integrated Service Digital Network
  • an incoming or outgoing call connection is initially received by a serving SSP 20 associated with a particular subscriber terminal 40. Since the SSP 20 has no "intelligence" to determine what kind of call treatment should be applied toward the received call connection, the SSP 20 performs a query requesting call treatment instructions to the associated SCP 30 over the connected TCAP link 50. In response to such a query, the SCP 30 retrieves the relevant subscriber data, ascertains the appropriate subscriber service to be provided, and instructs the IP 60 or the associated SSP 20 to effectuate the desired call treatment.
  • FIG. 2 is a block diagram of the IN system 10 illustrating the association of a Service Management Application System (SMAS) 130, SCP 30, and SSP 20.
  • SMAS Service Management Application System
  • SIBs Service Independent blocks
  • a specific IN service is then further developed and provided to telecommunications subscribers by utilizing one or more of the SSLs.
  • the control passes from a first SSL to a second SSL by utilizing network data associated with a particular call connection and/or subscription data 110 associated with an IN subscriber.
  • a Service Management Application System (SMAS) 130 is associated with the SCP 30.
  • the SMAS 130 is connected to the SCP 30 via a packet signaling link 120, such as an X.25 or Message Transfer Part (MTP) based signaling link.
  • the SMAS 130 is also associated with a centralized database for storing subscription data associated with its subscribers. Whenever a new IN service needs to be effectuated or subscription data need to be input to the serving SCP, the SMAS 130 communicates the instructions and/or data to the connected SCP over the X.25 communications link 120.
  • FIG. 3 illustrating an SCP 30 interacting with an SSP 20 to provide a particular IN service via a number of SSLs 100.
  • the SSP 20 initially receives an outgoing or incoming call connection 145. Such a call connection may also include service access, service request, or other non-speech communication from a subscriber terminal.
  • the SSP 20 transmits an Intelligent Network (IN) query 150 to the associated SCP 30.
  • An access SSL (not shown in FIG. 3) within the SCP 30 then retrieves the relevant subscription data, such subscription data associated with either the called party subscriber or calling party subscriber, and determines which IN service is be provided for the received incoming call.
  • the access SSL After selecting an appropriate IN service to be provided, the access SSL then invokes the first SSL 100A correlated with the selected IN service (signal 160). After the execution of the first SSL 100A, the execution control is then transferred (signal 170) over to the next SSL 100B to further effectuate the desired IN service.
  • the execution control is then transferred (signal 170) over to the next SSL 100B to further effectuate the desired IN service.
  • only two SSLs are shown correlated with a particular IN service in FIG. 3. However, it is to be understood that any number of needed SSLs may be correlated with a particular IN service.
  • a query result 180 is transmitted back to the requesting SSP 20 with necessary instructions to enable the SSP 20 to provide the determined call treatment to the received call connection 145.
  • Such an instruction may request the SSP 20 to reroute the received incoming call 145 to a different forward-to-number. It may further instruct the SSP 20 to complete the call connection 145 to a voicemail or announcement machine.
  • each SSL only knows the identity of the next SSL to be executed. By recursively executing one SSL and then identifying and invoking the next SSL, all of the associated SSLs for a particular IN service are sequentially executed.
  • FIG. 4 is a block diagram of an IN system illustrating a Graphical User Interface (GUI) 200 interacting with the SMAS 130 in accordance with the teachings of the present invention.
  • An application module (APPL) 210 associated with the GUI 200 requests subscription data associated with a particular subscriber from the SMAS 130 over a signaling connection 220.
  • the GUI 200 sits on top of an UNIX platform and communicates data and signal with the SMAS 130 using an X.25 packets, Transmission Control Protocol/Internet Protocol (TCP/IP) signal, or other packet signaling systems.
  • the database 140 stores data 115 and duplicates the subscription data 110 stored at the SCP 30.
  • the SMAS 130 retrieves and returns the relevant subscription data 115 to the requesting application module 210.
  • the application module 210 interprets the received subscription data 115 by simulating the executions performed by the SSLs 100 residing within the SCP 30 as fully described in FIG. 3, and identifies the sequence of SSLs associated with the retrieved subscription data for a given IN service.
  • each SSL is comprised of a plurality of SIBs.
  • Each SIB is associated with a particular data type. For example, A-SIB compares the time of the day associated with a particular incoming call connection with a predefined time of the data for routing purposes. Accordingly, when evaluating time of the day data within the retrieved subscription data, the application module 210 knows that A-SIB is associated with this type of data.
  • the application module 210 After identifying the associated SIB(s)(a particular data type may be associated with a number of SIBs), the application module 210 further identifies the SSL(s) using that particular SIB(s) (similarly, a single SIB can be associated with more than one SSL). Simulation of the identified SIB or SSL then indicates which SIB or SSL needs to be invoked next.
  • FIG. 5 illustrating the graphical representation depicting the relationship and hierarchy of associated SSLs displayed by the GUI in accordance with the teachings of the present invention.
  • the application module associated with the GUI is able to identify the particular SSLs (A-SSL, B-SSL, C-SSL, D-SSL, E-SSL, and F-SSL) associated with the retrieved subscription data for a given IN service. Since each SSL only knows the identity of the next SSL, by evaluating all of the retrieved subscription data and SSLs associated with each evaluated data, each SSL is paired up with its associated SSL. As a result, the left-hand side 300 of the displayed window illustrates the notational representation of the identified pairs of SSLs.
  • the first character on the left-hand side of the transitional notation ( ⁇ ) represents an SSL to be executed.
  • the second character on the right-hand side of the same notation represents the next SSL to be executed. If there is no second character on the right-hand side of a notation, it implies that the SSL represented by the left hand side SSL is the end of that sequence or link and a signal with the determined call treatment results needs to be passed back to the requesting SSP.
  • a graphical representation illustrating the relationship and hierarchy of all of the SSLs for that subscription data is shown on the right-hand side 310 of the displayed window. Since the A-SSL always calls other SSLs and is never invoked by other SSLs, it is determined that the A-SSL is the very first SSL that needs to executed. By link-listing or tracing the transition from one SSL to another, a full overview of all of the identified SSLs for that subscription data is produced as shown.
  • the IN subscription data and associated IN service illustrated by the graphical representation 310 routes incoming calls depending on the calling party directory number and the time of the call.
  • the SSP performs a query towards the associated SCP.
  • the SCP retrieves the subscription data associated with the called party directory number and determines which SSLs need to be invoked to provide the desired IN service.
  • the A-SSL is then identified as the first SSL to be executed.
  • the A-SSL ascertains the directory number associated with the calling party subscriber and determines which SSL to execute next. As an illustration, if an incoming call is from a first calling party subscriber, the B-SSL is invoked next (link 320).
  • the C-SSL is invoked (link 330).
  • the B-SSL is invoked for all incoming calls from calling party subscribers with the 214 area code.
  • the C-SSL is instead invoked.
  • the B-SSL attempts to determine the time of the day associated with this particular incoming call connection. Depending on the determined time of the day, either the D-SSL (link 340) or the E-SSL (link 350) is invoked next. Similarly, the C-SSL also has the option of either invoking the D-SSL (link 360) or F-SSL (link 370) depending on the time of the day associated with this particular incoming call connection. After the execution of the D-SSL, E-SSL, or F-SSL, the signal with the call routing instruction is returned back to the SSP.
  • a user is further able to introduce a new or different IN service merely by altering the displayed SSLs and their corresponding relationship. For example, the user no longer wishes to have incoming calls received during 8:00 AM to 12:00 PM to be given a certain call treatment and those calls should be handled in accordance with a regular treatment.
  • the user identifies the B-SSL responsible for making that determination and removes the link 340 associating the D-SSL with the B-SSL.
  • the D-SSL is the SSL for providing the particular call treatment for incoming calls received during 8:00 AM to 12:00 PM. Such an alteration can be made by graphically removing the link 340 to modify the subscriber data used by the selected SSL.
  • the alteration can be made by entering new subscription data to effectively remove the link 340 and the D-SSL.
  • the application module associated with the GUI interprets the changes made by the user and modifies the associated subscription data to reflect the indicated changes accordingly.
  • the user selects the link 340 from the window 310 and removes the association of the B-SSL with the D-SSL. Determining that a modification has been made to the existing graphical representation, the application module then identifies the transitional notation 340 corresponding to the removed link 340 from the window 300. The subscription data associated with the identified transitional notation 340 are then accordingly removed.
  • FIG. 6 illustrating the relationship and hierarchy of associated SSLs after a change has been made to the existing subscription data of FIG. 5. Due to the changes made to the relevant subscription data, the association (link) between the B-SSL to the D-SSL has been removed. Since D-SSL is no longer associated with any other SSLs, it is further removed from the picture.
  • the application module While the subscription data are removed, added, or altered to change the identity, relationship, functionality and/or hierarchy of the associated SSLs, the application module further performs various error detection functions. These functions are automatically performed to enforce certain pre-defined rules that dictate how individual and sequence of SSLs may be associated. For example, rules dictating that cycles (e.g., A ⁇ B ⁇ C ⁇ A) are not allowed between SSLs may be enforced while the user is altering the subscription data. Other rules or canons, such as a particular SSL needs to be proceeded or followed by a particular SSL, can similarly be enforced. A minimum or maximum depth of associated SSLs (the number of SSLs associated with any one link) for a particular IN service may further be guaranteed.
  • the user is able to test and confirm the changes made to the functionality, relationship, and/or hierarchy of the associated SSLs without actually executing the same SSLs located at the serving SCP.
  • the application module associated with the GUI requests and receives subscription data from the SMAS 130 and its associated database 140 at step 300.
  • the application module interprets the retrieved subscription data by simulating the SSLs associated with the serving SCP 30 at step 310.
  • the SSLs associated with the retrieved subscription data are then identified and their relationship ascertained.
  • the identified SSLs and their relationship and hierarchy are then displayed for that subscription data using a graphical representation at step 320.
  • a user is further able to modify the subscription data by altering the graphical representation displayed by the application module at step 330.
  • the application module interprets the changes made to the graphical representation and accordingly modifies the subscription data to reflect the same.
  • the altered subscription data are then communicated back to the SMAS 130 and stored at its associated database 140 at step 340. Since the serving SCP is a real-time telecommunications node, an appropriate time is selected and the altered subscription data are then down-loaded onto the serving SCP 30 at step 350.
  • the new subscription data are then incorporated by the existing SSLs to effectuate a new IN service towards a particular IN subscriber at step 360.
  • the SSP queries the SCP 30.
  • the SSLs within the SCP 30 utilizes the newly updated subscription data and provides the desired call treatment towards the received call connection at step 370.

Abstract

An application module associated with a Graphical User Interface retrieves data representing a particular Intelligent Network (IN) subscription from a Service Management Application System (SMAS). The application module thereafter interprets the retrieved subscription data by simulating the Service Script Logics (SSLs) residing within the serving Service Control Point (SCP). Relevant SSLs associated with the retrieved subscription data are identified and their relationship and hierarchy determined. The application module then displays the identified SSLs and their relationship using a graphical representation. A service provider or user is able to modify the graphical representation to make changes to the corresponding is subscription data to provide a different IN subscriber service.

Description

BACKGROUND OF THE INVENTION
1. Technical Field of the Invention
The present invention relates to a telecommunications system for providing subscriber features and, in particular, to the illustration and/or modification of intelligent network (IN) subscription using a graphical manager.
2. Description of Related Art
As stored program-controlled (SPC) switching systems have evolved, a wide variety of useful features have been developed to extend the communication capabilities such systems provide. Such services or features include call forwarding, "800" or toll free services, call screening, etc. Initially, all hardware and software modules required for providing a particular subscriber feature were placed and executed within a particular telecommunications exchange serving the service requesting subscriber terminal. As a result, each time a new subscriber feature or service was introduced, each and every one of the associated telecommunications exchanges inconveniently and inefficiently needed to be serviced and updated to support the service.
With the development and improvement of sophisticated telecommunications applications, the telecommunications industry has adopted the term "intelligent network" (IN) to denote a concept and architecture for providing vendor-independent and network-independent interfaces between the service logic and the transmission and switching system of a multi-enterprise telecommunications network. The goals of the IN are to centralize the service execution in a control node within a telecommunications network in order to provide rapid definition, testing and introduction of new services as well as the modification of existing services. IN also provides greater flexibility in the design and development of new services in a multi-vendor environment with shorter lead time, and standard network interfaces.
The basic concept behind IN is to move the "intelligence" out of each local exchange or Service Switching Point (SSP) and centralize the services providing the intelligence in a Service Control Point (SCP). By utilizing different combinations of basic building blocks, known as Service Independent Blocks (SIBs), a number of different Service Script Logics (SSLs) can be conveniently created. A specific IN service is then further developed and provided to telecommunications subscribers by utilizing (i.e., linking) one or more of the SSLs. As a result, utilizing subscription data associated with a particular subscriber, a number of SSLs are sequentially executed to provide the desired IN service.
Even with the centralization of IN services and subscription data within an associated SCP, reviewing and modifying IN subscription data associated with a particular subscriber within the existing IN system is still inconvenient and cumbersome. Subscription data are formatted in computer and/or application readable format and are difficult to read and understand. Furthermore each SSL incorporating the relevant subscription data only knows the identity of the next SSL that needs to be invoked. During run-time, each SSL executes the associated SIBs and then passes the control over to the next known SSL. Because the linked SSLs are executed in a chain-link-list fashion, where each SSL only knows the identity of the next SSL, it is difficult to obtain an overview of all of the associated SSLs. Unless a linking of all of the associated SSLs is manually performed, a service provider is unable to illustrate the association of a plurality of SSLs in a more readable and user-friendly format. Manual linking is tedious and inefficient. Moreover, since interpreting subscription data and their associated SSLs is difficult, making changes to the existing IN services and subscription data is further error-prone and time consuming. Accordingly, there is a need for a mechanism to interface a user with the serving IN network to enable the user to review and modify the existing IN services more efficiently and user-friendly.
SUMMARY OF THE INVENTION
Subscription data associated with a particular Intelligent Network (IN) subscriber are retrieved from the Service Management Application System (SMAS) associated with a serving Service Control Point (SCP). A Service Script Logic (SSL) interpreter then analyzes the retrieved subscription data and ascertains the identities of the associated SSLs and the relationship therebetween for a given IN service. A Graphical User Interface (GUI) then displays the relationship or hierarchy of the ascertained SSLs for that service. A service provider may then alter the retrieved subscription data by making relational or hierarchical changes to the displayed graphical representation of the associated SSLs. The interpreter thereafter interprets the graphical changes and changes the retrieved subscription data accordingly to reflect the indicated changes. The changed subscription data are then communicated back to the SMAS. The SMAS then down-loads the changed subscription data to the SSLs residing within the serving SCP to effectuate the changed IN service desired by the service provider.
BRIEF DESCRIPTION OF THE DRAWINGS
A more complete understanding of the method and apparatus of the present invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings wherein:
FIG. 1 is a block diagram of an Intelligent Network (IN) telecommunications system providing IN services to subscribers;
FIG. 2 is a block diagram of an IN system illustrating the association of a Service Management Application System (SMAS), Service Control Point (SCP), and Service Switching Point (SSP);
FIG. 3 is a block diagram of an IN system illustrating an SCP interacting with an SSP to provide a particular IN service via a number of Service Script Logics (SSLs);
FIG. 4 is a block diagram of an IN system illustrating a Graphical User Interface (GUI) interacting with the SMAS in accordance with the teachings of the present invention;
FIG. 5 is a graphical representation illustrating the relationship and hierarchy of associated SSLs for a particular IN service;
FIG. 6 is a graphical representation illustrating the relationship and hierarchy of associated SSLs after a change has been made to the existing subscription data;
FIG. 7 is a block diagram of an IN system illustrating the association of GUI, SMAS, SCP, and SSP in accordance with the teachings of the present invention; and
FIG. 8 is a flowchart illustrating the steps performed by an IN system to represent and to modify subscription data associated with a particular IN service in accordance with the teachings of the present invention.
DETAILED DESCRIPTION OF THE DRAWINGS
FIG. 1 shows an Intelligent Network (IN) 10 providing IN services to subscribers. The basic concept behind IN is to move the intelligence out of each local exchange or Service Switching Points (SSPs) 20 and to centralize the services providing the intelligence in a Service Control Point (SCP) 30. By centralizing the special subscriber services in the SCP 30, a new service can be added in only one place (i.e., the SCP) and provided to all subscribers connected to the multiple SSPs 20. Accordingly, one SSP services multiple telecommunications subscribers or terminals 40, and one SCP services multiple SSPs 20 or local switches. The interfaces between the SSPs 20 are by links 50 utilizing the Signaling System No. 7 (SS7) Transaction Capabilities Application Part (TCAP), or other Signaling Control Connection Part (SCCP) based application layer protocols. More specifically, Intelligent Network Application Protocols (INAP) sit on top of the TCAP protocols to establish a control dialogue between the SSPs 20 and the SCP 30.
Hardware resources required to execute IN services are grouped and located separately from the SSP 20 in an Intelligent Peripheral (IP) 60. The purpose of such a separation is to allow multiple SSPs 20 to share the same resources, to decrease processor load in the SSPs 20 and the SCP 30, and to provide common functionality to all IN services. The resources located in the IP 60 typically include, but are not limited to, announcement machines, speech synthesis, speech recognition, tone generators, voice mail, modems, e-mail, fax, and other operator resources. The SCP 30 and the IP 60 are also connected via another TCAP or INAP based communications link 60. In order to transport voice and data, the connections 70 between the IP 60 and the SSPs 20 are established using Integrated Service Digital Network (ISDN) User Part (ISUP) signals.
Utilizing the above architecture, an incoming or outgoing call connection is initially received by a serving SSP 20 associated with a particular subscriber terminal 40. Since the SSP 20 has no "intelligence" to determine what kind of call treatment should be applied toward the received call connection, the SSP 20 performs a query requesting call treatment instructions to the associated SCP 30 over the connected TCAP link 50. In response to such a query, the SCP 30 retrieves the relevant subscriber data, ascertains the appropriate subscriber service to be provided, and instructs the IP 60 or the associated SSP 20 to effectuate the desired call treatment.
FIG. 2 is a block diagram of the IN system 10 illustrating the association of a Service Management Application System (SMAS) 130, SCP 30, and SSP 20. A number of available basic building blocks, known as Service Independent blocks (SIBs, not shown in FIG. 2), are utilized by a Service Script Logic (SSL) 100 to effectuate a particular function or procedure within the SCP 30. A specific IN service is then further developed and provided to telecommunications subscribers by utilizing one or more of the SSLs. By utilizing a sequence of SSLs and SIBs, a new IN service can be easily introduced into the existing IN network without developing new instructions or executable codes. The control passes from a first SSL to a second SSL by utilizing network data associated with a particular call connection and/or subscription data 110 associated with an IN subscriber.
In order to install, change, delete, and audit subscription data and associated SSLs within the SCP 30, a application system known as a Service Management Application System (SMAS) 130 is associated with the SCP 30. The SMAS 130 is connected to the SCP 30 via a packet signaling link 120, such as an X.25 or Message Transfer Part (MTP) based signaling link. The SMAS 130 is also associated with a centralized database for storing subscription data associated with its subscribers. Whenever a new IN service needs to be effectuated or subscription data need to be input to the serving SCP, the SMAS 130 communicates the instructions and/or data to the connected SCP over the X.25 communications link 120.
Reference is now made to FIG. 3 illustrating an SCP 30 interacting with an SSP 20 to provide a particular IN service via a number of SSLs 100. As described above, the SSP 20 initially receives an outgoing or incoming call connection 145. Such a call connection may also include service access, service request, or other non-speech communication from a subscriber terminal. After making a determination that an IN service is associated with the received call connection, the SSP 20 transmits an Intelligent Network (IN) query 150 to the associated SCP 30. An access SSL (not shown in FIG. 3) within the SCP 30 then retrieves the relevant subscription data, such subscription data associated with either the called party subscriber or calling party subscriber, and determines which IN service is be provided for the received incoming call. After selecting an appropriate IN service to be provided, the access SSL then invokes the first SSL 100A correlated with the selected IN service (signal 160). After the execution of the first SSL 100A, the execution control is then transferred (signal 170) over to the next SSL 100B to further effectuate the desired IN service. For exemplary purposes, only two SSLs are shown correlated with a particular IN service in FIG. 3. However, it is to be understood that any number of needed SSLs may be correlated with a particular IN service.
After the execution of all associated SSLs, a query result 180 is transmitted back to the requesting SSP 20 with necessary instructions to enable the SSP 20 to provide the determined call treatment to the received call connection 145. Such an instruction may request the SSP 20 to reroute the received incoming call 145 to a different forward-to-number. It may further instruct the SSP 20 to complete the call connection 145 to a voicemail or announcement machine.
As illustrated in FIG. 3, utilizing the associated subscription data, each SSL only knows the identity of the next SSL to be executed. By recursively executing one SSL and then identifying and invoking the next SSL, all of the associated SSLs for a particular IN service are sequentially executed. However, there is conventionally no mechanism or method for graphically illustrating the relationship or hierarchy of all of the SSLs associated with a particular IN service towards a particular IN subscriber. As a result, a user is unable to easily understand and modify the associated subscription data controlling the execution of those SSLs.
FIG. 4 is a block diagram of an IN system illustrating a Graphical User Interface (GUI) 200 interacting with the SMAS 130 in accordance with the teachings of the present invention. An application module (APPL) 210 associated with the GUI 200 requests subscription data associated with a particular subscriber from the SMAS 130 over a signaling connection 220. Usually, the GUI 200 sits on top of an UNIX platform and communicates data and signal with the SMAS 130 using an X.25 packets, Transmission Control Protocol/Internet Protocol (TCP/IP) signal, or other packet signaling systems. The database 140 stores data 115 and duplicates the subscription data 110 stored at the SCP 30. The SMAS 130 retrieves and returns the relevant subscription data 115 to the requesting application module 210. The application module 210 then interprets the received subscription data 115 by simulating the executions performed by the SSLs 100 residing within the SCP 30 as fully described in FIG. 3, and identifies the sequence of SSLs associated with the retrieved subscription data for a given IN service. As an illustration, each SSL is comprised of a plurality of SIBs. Each SIB is associated with a particular data type. For example, A-SIB compares the time of the day associated with a particular incoming call connection with a predefined time of the data for routing purposes. Accordingly, when evaluating time of the day data within the retrieved subscription data, the application module 210 knows that A-SIB is associated with this type of data. After identifying the associated SIB(s)(a particular data type may be associated with a number of SIBs), the application module 210 further identifies the SSL(s) using that particular SIB(s) (similarly, a single SIB can be associated with more than one SSL). Simulation of the identified SIB or SSL then indicates which SIB or SSL needs to be invoked next.
Reference is now made to FIG. 5 illustrating the graphical representation depicting the relationship and hierarchy of associated SSLs displayed by the GUI in accordance with the teachings of the present invention. By simulating SSLs stored at the SCP, the application module associated with the GUI is able to identify the particular SSLs (A-SSL, B-SSL, C-SSL, D-SSL, E-SSL, and F-SSL) associated with the retrieved subscription data for a given IN service. Since each SSL only knows the identity of the next SSL, by evaluating all of the retrieved subscription data and SSLs associated with each evaluated data, each SSL is paired up with its associated SSL. As a result, the left-hand side 300 of the displayed window illustrates the notational representation of the identified pairs of SSLs. The first character on the left-hand side of the transitional notation (→) represents an SSL to be executed. The second character on the right-hand side of the same notation represents the next SSL to be executed. If there is no second character on the right-hand side of a notation, it implies that the SSL represented by the left hand side SSL is the end of that sequence or link and a signal with the determined call treatment results needs to be passed back to the requesting SSP.
After all of the SSLs are identified and paired up, a graphical representation illustrating the relationship and hierarchy of all of the SSLs for that subscription data is shown on the right-hand side 310 of the displayed window. Since the A-SSL always calls other SSLs and is never invoked by other SSLs, it is determined that the A-SSL is the very first SSL that needs to executed. By link-listing or tracing the transition from one SSL to another, a full overview of all of the identified SSLs for that subscription data is produced as shown.
For example, the IN subscription data and associated IN service illustrated by the graphical representation 310 routes incoming calls depending on the calling party directory number and the time of the call. Whenever an incoming call connection towards a particular IN directory number is received by the SSP (refer to FIG. 3), the SSP performs a query towards the associated SCP. The SCP retrieves the subscription data associated with the called party directory number and determines which SSLs need to be invoked to provide the desired IN service. The A-SSL is then identified as the first SSL to be executed. The A-SSL ascertains the directory number associated with the calling party subscriber and determines which SSL to execute next. As an illustration, if an incoming call is from a first calling party subscriber, the B-SSL is invoked next (link 320). On the other hand, for all other directory numbers, the C-SSL is invoked (link 330). For example, the B-SSL is invoked for all incoming calls from calling party subscribers with the 214 area code. For the rest of the incoming calls, the C-SSL is instead invoked.
The B-SSL then attempts to determine the time of the day associated with this particular incoming call connection. Depending on the determined time of the day, either the D-SSL (link 340) or the E-SSL (link 350) is invoked next. Similarly, the C-SSL also has the option of either invoking the D-SSL (link 360) or F-SSL (link 370) depending on the time of the day associated with this particular incoming call connection. After the execution of the D-SSL, E-SSL, or F-SSL, the signal with the call routing instruction is returned back to the SSP.
By viewing the overall structure and hierarchy of the associated SSLs for a particular IN service towards a particular subscriber, a service provider is easily able to understand the relationship and functionality of the associated SSLs.
Using the displayed graphical representation of the associated SSLs and their respective relationship, a user is further able to introduce a new or different IN service merely by altering the displayed SSLs and their corresponding relationship. For example, the user no longer wishes to have incoming calls received during 8:00 AM to 12:00 PM to be given a certain call treatment and those calls should be handled in accordance with a regular treatment. The user identifies the B-SSL responsible for making that determination and removes the link 340 associating the D-SSL with the B-SSL. The D-SSL is the SSL for providing the particular call treatment for incoming calls received during 8:00 AM to 12:00 PM. Such an alteration can be made by graphically removing the link 340 to modify the subscriber data used by the selected SSL. Alternatively, the alteration can be made by entering new subscription data to effectively remove the link 340 and the D-SSL. If the changes are directly made to the graphical representation, the application module associated with the GUI then interprets the changes made by the user and modifies the associated subscription data to reflect the indicated changes accordingly. As an illustration, the user selects the link 340 from the window 310 and removes the association of the B-SSL with the D-SSL. Determining that a modification has been made to the existing graphical representation, the application module then identifies the transitional notation 340 corresponding to the removed link 340 from the window 300. The subscription data associated with the identified transitional notation 340 are then accordingly removed.
Reference is now made to FIG. 6 illustrating the relationship and hierarchy of associated SSLs after a change has been made to the existing subscription data of FIG. 5. Due to the changes made to the relevant subscription data, the association (link) between the B-SSL to the D-SSL has been removed. Since D-SSL is no longer associated with any other SSLs, it is further removed from the picture.
While the subscription data are removed, added, or altered to change the identity, relationship, functionality and/or hierarchy of the associated SSLs, the application module further performs various error detection functions. These functions are automatically performed to enforce certain pre-defined rules that dictate how individual and sequence of SSLs may be associated. For example, rules dictating that cycles (e.g., A→B→C→A) are not allowed between SSLs may be enforced while the user is altering the subscription data. Other rules or canons, such as a particular SSL needs to be proceeded or followed by a particular SSL, can similarly be enforced. A minimum or maximum depth of associated SSLs (the number of SSLs associated with any one link) for a particular IN service may further be guaranteed.
Furthermore, by interpreting the altered subscription data within the GUI, the user is able to test and confirm the changes made to the functionality, relationship, and/or hierarchy of the associated SSLs without actually executing the same SSLs located at the serving SCP.
Reference is now made to both FIGS. 7 and 8 illustrating the steps performed by the IN system in accordance with the teachings of the present invention. The application module associated with the GUI requests and receives subscription data from the SMAS 130 and its associated database 140 at step 300. As fully described above, the application module then interprets the retrieved subscription data by simulating the SSLs associated with the serving SCP 30 at step 310. The SSLs associated with the retrieved subscription data are then identified and their relationship ascertained. The identified SSLs and their relationship and hierarchy are then displayed for that subscription data using a graphical representation at step 320. A user is further able to modify the subscription data by altering the graphical representation displayed by the application module at step 330. The application module interprets the changes made to the graphical representation and accordingly modifies the subscription data to reflect the same. The altered subscription data are then communicated back to the SMAS 130 and stored at its associated database 140 at step 340. Since the serving SCP is a real-time telecommunications node, an appropriate time is selected and the altered subscription data are then down-loaded onto the serving SCP 30 at step 350. The new subscription data are then incorporated by the existing SSLs to effectuate a new IN service towards a particular IN subscriber at step 360. As an illustration, in response to an incoming call connection 145 from the calling party subscriber 45, the SSP queries the SCP 30. The SSLs within the SCP 30 utilizes the newly updated subscription data and provides the desired call treatment towards the received call connection at step 370.
Although a preferred embodiment of the method and apparatus of the present invention has been illustrated in the accompanying Drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiment disclosed, but is capable of numerous rearrangements, modifications and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

Claims (20)

What is claimed is:
1. A method for illustrating and manipulating subscription data associated with a subscriber service within an Intelligent Network (IN) telecommunications network, wherein said subscriber service is associated with a plurality of Service Script Logics (SSLs), said plurality of SSLs utilizing said subscription data to effectuate said subscriber service to a particular subscriber, said method comprising the steps of:
a) retrieving subscription data associated with a particular subscriber;
b) interpreting first of said retrieved subscription data, wherein said step of interpreting includes the step of identifying a SSL associated with said first of said subscription data and simulating the actions performed by said SSL to determine the identity of the next SSL to be invoked;
c) repeatedly performing step b) until all of said retrieved subscription data have been interpreted and their associated SSLs identified; and
d) displaying a graphical representation illustrating the relationship and hierarchy of said identified SSLs for effectuating said subscriber service.
2. The method of claim 1 wherein said subscription data are retrieved from a Service Management Application System (SMAS) associated with a Service Control Point (SCP) effectuating said subscriber service.
3. The method claim 1 further including the steps of:
receiving an indication from a user to modify said relationship or hierarchy of said displayed SSLs to provide a different subscriber service;
interpreting said indication to change said retrieved subscription data to reflect the modifications made to said relationship or hierarchy of said displayed SSLs; and
communicating said changed subscription data to said associated SSLs to effectuate said different subscriber service to said subscriber.
4. The method of claim 3 wherein said step of communicating said changed subscription data further comprises the step of storing said changed subscription data to a Service Management Application System (SMAS) associated with a Service Control Point (SCP) effectuating said subscriber service.
5. The method of claim 4 further comprising the step of down-loading said stored subscription data from said SMAS to said SCP over a communication link to effectuate the provision of said different subscriber service by said SCP.
6. The method of claim 3 wherein said step of receiving said indication further comprises the steps of:
receiving an instruction from said user to select a particular one of said SSLs displayed within said graphical representation;
displaying subscription data associated with said selected SSL;
receiving new subscription data replacing said displayed subscription data associated with said selected SSL; and
re-displaying said graphical representation to illustrate the changes in said relationship and hierarchy of said identified SSLs in accordance with said received new subscription data.
7. A system for illustrating and manipulating subscription data associated with a particular subscriber for a particular Intelligent Network (IN) service within an IN telecommunications network, comprising:
a Service Control Point (SCP) comprising a plurality of Service Script Logics (SSLs) for effectuating said IN service towards said subscriber using said associated subscription data;
a management application module associated with said SCP for storing said subscription data and for providing said subscription data to said plurality of SSLs within said SCP for effectuating said IN service; and
an user interface module associated with said management application module, said user interface module further comprising:
means for retrieving said subscription data from said management application module;
means for analyzing said subscription data to determine the relationship and hierarchy of said plurality of SSLs associated with said subscription data; and
means for displaying said determined relationship and hierarchy of said determined SSLs using a graphical representation to a user.
8. The system of claim 7 further comprises a database wherein said management application module comprises a Service Management Application System (SMAS) connected to said SCP, said SMAS further connected to said database for storing said subscription data.
9. The system of claim 7 wherein said user interface module comprises a Graphical User Interface (GUI) system.
10. The system of claim 7 wherein said user interface module further comprises means for accepting an indication from said user to alter said displayed relationship or hierarchy of said SSLs associated with said subscription data.
11. The system of claim 10 further comprising means for analyzing said altered relationship or hierarchy of said SSLs and for changing said associated subscription data to reflect said alteration.
12. The system of claim 11 wherein said user interface module communicates said changed subscription data to said management application module.
13. The system of claim 12 wherein said management application module further comprises means for communicating said changed subscription data to said plurality of SSLs by down-loading said changed subscription data to said SCP.
14. A method for illustrating and manipulating an Intelligent Network (IN) service being provided within an IN telecommunications network, said IN service associated with a plurality of Service Script Logics (SSLs), each of said plurality of SSLs associated with 'subscription data for executing said SSL's internal instructions and for determining the next SSL associated with said SSL to effectuate said IN service, said method comprising the steps of:
retrieving subscription data associated with a particular subscriber for effectuating a particular IN service;
analyzing said subscription data to determine the identities of said plurality of SSLs associated with said subscription data to effectuate said particular IN service;
determining the execution sequence associated with said determined plurality of SSLs;
displaying the relationship and hierarchy of said determined execution sequence of SSLs using a graphical representation to a user, said graphical representation enabling said user to overview the overall execution sequence of said plurality of SSLs needed for effectuating said IN service to said subscriber.
15. The method of claim 14 further comprising the steps of:
receiving an indication from said user to change said displayed relationship or hierarchy of said plurality of associated SSLs to provide a different IN service;
making changes to said retrieved subscription data to effectuate such changes to said displayed relationship or hierarchy of SSLs; and
communicating said changed subscription data to said plurality of SSLs for effectuating the provision of said different IN service.
16. The method of claim 15 wherein said subscription data are retrieved from a Service Management Application System (SMAS) associated with a Service Control Point (SOP) effectuating said subscriber service.
17. The method of claim 16 wherein said step of communicating said changed subscription data to said plurality of SSLs further comprises the step of communicating said changed subscription data to said SMAS.
18. The method of claim 17 wherein said step of communicating said changed subscription data to said plurality of SSLs further comprises the step of down-loading said communicated subscription data from said SMAS to said SCP.
19. The method of claim 14 wherein said step of determining said execution sequence further comprises the step of interpreting first of said retrieved subscription data wherein said step of interpreting includes the step of identifying a first SSL associated with said first of said retrieved subscription data and simulating the actions performed by an SSL associated with said first subscription data to determine the identity of the next SSL to be invoked.
20. The method of claim 19 wherein said step of interpreting is recursively performed for all of said retrieved subscription data to determine the identities of said plurality of SSLs associated with said IN service.
US08/785,853 1997-01-21 1997-01-21 Graphical intelligent network (IN) subscription manager Expired - Lifetime US5881144A (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US08/785,853 US5881144A (en) 1997-01-21 1997-01-21 Graphical intelligent network (IN) subscription manager
PCT/US1998/000888 WO1998032292A1 (en) 1997-01-21 1998-01-20 Graphical subscription manager intelligent network
EP98903534A EP0954932B1 (en) 1997-01-21 1998-01-20 Graphical subscription manager intelligent network
DE69816421T DE69816421D1 (en) 1997-01-21 1998-01-20 GRAPHIC SUBSCRIBER DATA MANAGER IN AN INTELLIGENT NETWORK
AU60283/98A AU744645B2 (en) 1997-01-21 1998-01-20 Graphical subscription manager intelligent network
NO993504A NO993504L (en) 1997-01-21 1999-07-16 System for creating services in communication networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US08/785,853 US5881144A (en) 1997-01-21 1997-01-21 Graphical intelligent network (IN) subscription manager

Publications (1)

Publication Number Publication Date
US5881144A true US5881144A (en) 1999-03-09

Family

ID=25136830

Family Applications (1)

Application Number Title Priority Date Filing Date
US08/785,853 Expired - Lifetime US5881144A (en) 1997-01-21 1997-01-21 Graphical intelligent network (IN) subscription manager

Country Status (6)

Country Link
US (1) US5881144A (en)
EP (1) EP0954932B1 (en)
AU (1) AU744645B2 (en)
DE (1) DE69816421D1 (en)
NO (1) NO993504L (en)
WO (1) WO1998032292A1 (en)

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6347311B1 (en) * 1997-05-16 2002-02-12 Nokia Networks Oy Implementation of service independent building blocks
US20020168055A1 (en) * 2000-11-21 2002-11-14 Crockett Susanne Marie Voice enhancing for advance intelligent network services
US20030063720A1 (en) * 2001-07-13 2003-04-03 Walter Malinowski Platform for rapid development of telecommunications services
US20030079028A1 (en) * 2001-10-24 2003-04-24 Sbc Technology Resources, Inc. Unified interface for managing DSL services
US6631186B1 (en) 1999-04-09 2003-10-07 Sbc Technology Resources, Inc. System and method for implementing and accessing call forwarding services
US20030191747A1 (en) * 2002-04-04 2003-10-09 Mayel Espino Method, device and computer program product including a lightweight directory access protocal client
US20030228011A1 (en) * 2002-06-07 2003-12-11 Gibson Elizabeth Goldwyn System and method for implementing and accessing call forwarding services
US20040022379A1 (en) * 1997-04-03 2004-02-05 Southwestern Bell Telephone Company Apparatus and method for facilitating service management of communications services in a communications network
US6754332B1 (en) * 1998-11-02 2004-06-22 Concerto Software, Inc. Object oriented system and method for directing incoming telephone calls
US20040136517A1 (en) * 1998-05-07 2004-07-15 Worldcom, Inc. System for executing advanced interactive voice response services using service-independent building blocks
US20040151294A1 (en) * 1997-04-03 2004-08-05 Sbc Technology Resources, Inc. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US20040209640A1 (en) * 2003-04-18 2004-10-21 Urban Blake R. Private Caller ID messaging
US6891940B1 (en) 2000-07-19 2005-05-10 Sbc Technology Resources, Inc. System and method for providing remote access to telecommunications services
US7155001B2 (en) 2001-10-24 2006-12-26 Sbc Properties, L.P. System and method for restricting and monitoring telephone calls
US20070033231A1 (en) * 2001-01-19 2007-02-08 Esoft, Incorporated Managed Services Platform
US7206398B2 (en) 1998-07-09 2007-04-17 Sbc Technology Resources, Inc. System and method for forwarding call from disconnected telephone number to new telephone number
US20070244820A1 (en) * 2005-03-29 2007-10-18 Microsoft Corporation Securely Providing Advertising Subsidized Computer Usage
US20080089503A1 (en) * 2002-04-30 2008-04-17 At&T Knowledge Ventures, L.P. Voice enhancing for advance intelligent network services
US20080103529A1 (en) * 2006-10-26 2008-05-01 Old Dominion University Apparatus and methods for performing cellular electro-manipulations
US7502457B2 (en) 2002-02-28 2009-03-10 At&T Intellectual Property I, L.P. Outbound call rules routing
US20140130010A1 (en) * 2000-02-28 2014-05-08 At&T Intellectual Property Ii, L.P. Paradigm in Multimedia Services Creation Methodology, and New Service Creation and Service Execution Environments
US9224168B2 (en) 2004-11-15 2015-12-29 Microsoft Technology Licensing, Llc Tuning product policy using observed evidence of customer behavior
US9336359B2 (en) 2004-10-18 2016-05-10 Microsoft Technology Licensing, Llc Device certificate individualization

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995029564A1 (en) * 1994-04-21 1995-11-02 British Telecommunications Public Limited Company Service creation apparatus for a communications network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995029564A1 (en) * 1994-04-21 1995-11-02 British Telecommunications Public Limited Company Service creation apparatus for a communications network

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
Abramowski S., et al.: "Concepts For Service Management By End Users" Nov. 29, 1993, pp. 867-871.
Abramowski S., et al.: Concepts For Service Management By End Users Nov. 29, 1993, pp. 867 871. *
Genette, M., et al.: "Intelligen Network: The Service Creation Environment" Jan. 1, 1995, pp. 13-20.
Genette, M., et al.: Intelligen Network: The Service Creation Environment Jan. 1, 1995, pp. 13 20. *
Ku, B.S.: "A Reuse-Driven Service Creation Environment For The Advanced Intelligent Network" May 1, 1994, pp. 263-267.
Ku, B.S.: A Reuse Driven Service Creation Environment For The Advanced Intelligent Network May 1, 1994, pp. 263 267. *
Uchida, Naoki, et al.: Customer Defined Service Model And Definition Method For Intelligent Networks Jun. 23, 1991, pp. 954 958. *
Uchida, Naoki, et al.: Customer-Defined Service Model And Definition Method For Intelligent Networks Jun. 23, 1991, pp. 954-958.

Cited By (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070047714A1 (en) * 1997-04-03 2007-03-01 Sbc Technology Resources, Inc. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US20040022379A1 (en) * 1997-04-03 2004-02-05 Southwestern Bell Telephone Company Apparatus and method for facilitating service management of communications services in a communications network
US7907714B2 (en) 1997-04-03 2011-03-15 At&T Labs, Inc. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US7103165B2 (en) 1997-04-03 2006-09-05 Sbc Technology Resources, Inc. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US8494138B2 (en) 1997-04-03 2013-07-23 At&T Intellectual Property I, L.P. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US8705718B2 (en) 1997-04-03 2014-04-22 At&T Intellectual Property I, L.P. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US20110142213A1 (en) * 1997-04-03 2011-06-16 At&T Labs, Inc. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US8139742B2 (en) 1997-04-03 2012-03-20 At&T Intellectual Property I, L.P. Apparatus and method for facilitating service management of communications services in a communications network
US20070121850A1 (en) * 1997-04-03 2007-05-31 Southwestern Bell Telephone Company Apparatus and method for facilitating service management of communications services in a communications network
US9369574B2 (en) 1997-04-03 2016-06-14 At&T Intellectual Property I, L.P. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US7167550B2 (en) 1997-04-03 2007-01-23 Southwestern Bell Telephone Company Apparatus and method for facilitating service management of communications services in a communications network
US20040151294A1 (en) * 1997-04-03 2004-08-05 Sbc Technology Resources, Inc. Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services
US6347311B1 (en) * 1997-05-16 2002-02-12 Nokia Networks Oy Implementation of service independent building blocks
US20040136517A1 (en) * 1998-05-07 2004-07-15 Worldcom, Inc. System for executing advanced interactive voice response services using service-independent building blocks
US7623644B2 (en) * 1998-05-07 2009-11-24 Mci Communications Corporation System for executing advanced interactive voice response services using service-independent building blocks
US7206398B2 (en) 1998-07-09 2007-04-17 Sbc Technology Resources, Inc. System and method for forwarding call from disconnected telephone number to new telephone number
US6754332B1 (en) * 1998-11-02 2004-06-22 Concerto Software, Inc. Object oriented system and method for directing incoming telephone calls
US6631186B1 (en) 1999-04-09 2003-10-07 Sbc Technology Resources, Inc. System and method for implementing and accessing call forwarding services
US20070217584A1 (en) * 1999-04-09 2007-09-20 At&T Labs, Inc. System and method for implementing and accessing call forwarding services
US7242754B2 (en) 1999-04-09 2007-07-10 At&T Labs, Inc. System and method for implementing and accessing call forwarding services
US20040005045A1 (en) * 1999-04-09 2004-01-08 Sbc Technology Resources, Inc., Austin, Texas System and method for implementing and accessing call forwarding services
US10127020B2 (en) * 2000-02-28 2018-11-13 At&T Intellectual Property Ii, L.P. Paradigm in multimedia services creation methodology, and new service creation and service execution environments
US9501266B2 (en) * 2000-02-28 2016-11-22 At&T Intellectual Property Ii, L.P. Paradigm in multimedia services creation methodology, and new service creation and service execution enviroments
US20170024189A1 (en) * 2000-02-28 2017-01-26 At&T Intellectual Property Ii, L.P. Paradigm in Multimedia Services Creation Methodology, and New Service Creation and Service Execution Environments
US20140130010A1 (en) * 2000-02-28 2014-05-08 At&T Intellectual Property Ii, L.P. Paradigm in Multimedia Services Creation Methodology, and New Service Creation and Service Execution Environments
US7593396B2 (en) 2000-07-19 2009-09-22 At&T Labs, Inc. System and method for providing remote access to telecommunications services
US6891940B1 (en) 2000-07-19 2005-05-10 Sbc Technology Resources, Inc. System and method for providing remote access to telecommunications services
US7317787B2 (en) 2000-11-21 2008-01-08 At&T Knowledge Ventures, L.P. Voice enhancing for advance intelligent network services
US20020168055A1 (en) * 2000-11-21 2002-11-14 Crockett Susanne Marie Voice enhancing for advance intelligent network services
US20080028061A1 (en) * 2001-01-19 2008-01-31 Esoft, Incorporated Managed Services Platform
US8180909B2 (en) 2001-01-19 2012-05-15 Zvelo, Inc. Managed services platform
US8977762B2 (en) 2001-01-19 2015-03-10 Zvelo, Inc. Managed services platform
US8572267B2 (en) 2001-01-19 2013-10-29 Zvelo, Inc. Managed services platform
US20070033231A1 (en) * 2001-01-19 2007-02-08 Esoft, Incorporated Managed Services Platform
US8266304B2 (en) 2001-01-19 2012-09-11 Zvelo, Inc. Managed services platform
US20070036315A1 (en) * 2001-07-13 2007-02-15 Sbc Properties, L.P. Platform for rapid development of telecommunication services
US7142655B2 (en) 2001-07-13 2006-11-28 Sbc Properties, L.P. Platform for rapid development of telecommunications services
US20030063720A1 (en) * 2001-07-13 2003-04-03 Walter Malinowski Platform for rapid development of telecommunications services
US7418089B2 (en) 2001-10-24 2008-08-26 At&T Intellectual Property I, L.P. System and method for restricting and monitoring telephone calls
US20080279359A1 (en) * 2001-10-24 2008-11-13 At&T Intellectual Property I,L.P. System and method for restricting and monitoring telephone calls
US7155001B2 (en) 2001-10-24 2006-12-26 Sbc Properties, L.P. System and method for restricting and monitoring telephone calls
US20030079028A1 (en) * 2001-10-24 2003-04-24 Sbc Technology Resources, Inc. Unified interface for managing DSL services
US7337220B2 (en) 2001-10-24 2008-02-26 At&T Labs, Inc. Unified interface for managing DSL services
US8155293B2 (en) 2001-10-24 2012-04-10 At&T Intellectual Property I, L.P. System and method for restricting and monitoring telephone calls
US7502457B2 (en) 2002-02-28 2009-03-10 At&T Intellectual Property I, L.P. Outbound call rules routing
US20030191747A1 (en) * 2002-04-04 2003-10-09 Mayel Espino Method, device and computer program product including a lightweight directory access protocal client
US7783593B2 (en) * 2002-04-04 2010-08-24 Verizon Business Global Llc Method, device and computer program product including a lightweight directory access protocol client
US20080089503A1 (en) * 2002-04-30 2008-04-17 At&T Knowledge Ventures, L.P. Voice enhancing for advance intelligent network services
US7957509B2 (en) 2002-04-30 2011-06-07 At&T Intellectual Property I, L.P. Voice enhancing for advance intelligent network services
US7076045B2 (en) 2002-06-07 2006-07-11 Sbc Properties, L.P. System and method for implementing and accessing call forward services
US20070286391A1 (en) * 2002-06-07 2007-12-13 At&T Knowledge Ventures, L.P. System and method for implementing and accessing call forwarding services
US8059808B2 (en) 2002-06-07 2011-11-15 At&T Intellectual Property I, L.P. System and method for implementing and accessing call forwarding services
US7778403B2 (en) 2002-06-07 2010-08-17 At&T Intellectual Property I, L.P. System and method for implementing and accessing call forwarding services
US20080170680A1 (en) * 2002-06-07 2008-07-17 At & T Knowledge Ventures, L.P. System and method for implementing and accessing call forwarding services
US20030228011A1 (en) * 2002-06-07 2003-12-11 Gibson Elizabeth Goldwyn System and method for implementing and accessing call forwarding services
US7346155B2 (en) 2002-06-07 2008-03-18 At&T Knowledge Ventures, L.P. System and method for implementing and accessing call forwarding services
US6954524B2 (en) 2002-06-07 2005-10-11 Sbc Properties, L.P. System and method for implementing and accessing call forwarding services
US20060203986A1 (en) * 2002-06-07 2006-09-14 Sbc Properties L.P. System and method for implementing and accessing call forwarding services
US7227940B2 (en) 2002-06-07 2007-06-05 At&T Knowledge Ventures, B.P. System and method for implementing and accessing call forwarding services
US20040209640A1 (en) * 2003-04-18 2004-10-21 Urban Blake R. Private Caller ID messaging
US9336359B2 (en) 2004-10-18 2016-05-10 Microsoft Technology Licensing, Llc Device certificate individualization
US9224168B2 (en) 2004-11-15 2015-12-29 Microsoft Technology Licensing, Llc Tuning product policy using observed evidence of customer behavior
US20070244820A1 (en) * 2005-03-29 2007-10-18 Microsoft Corporation Securely Providing Advertising Subsidized Computer Usage
US8099324B2 (en) * 2005-03-29 2012-01-17 Microsoft Corporation Securely providing advertising subsidized computer usage
US20080103529A1 (en) * 2006-10-26 2008-05-01 Old Dominion University Apparatus and methods for performing cellular electro-manipulations

Also Published As

Publication number Publication date
DE69816421D1 (en) 2003-08-21
NO993504D0 (en) 1999-07-16
AU744645B2 (en) 2002-02-28
WO1998032292A1 (en) 1998-07-23
EP0954932A1 (en) 1999-11-10
AU6028398A (en) 1998-08-07
EP0954932B1 (en) 2003-07-16
NO993504L (en) 1999-09-21

Similar Documents

Publication Publication Date Title
US5881144A (en) Graphical intelligent network (IN) subscription manager
US5771279A (en) Advanced intelligent network interacting with customer premises equipment
US6094479A (en) Computer telephony integration gateway
CA2167235C (en) Intelligent network internetworking access arrangement
US5732130A (en) System and method of providing enhanced subscriber services in a multi-node telecommunications network
EP0974234B1 (en) Mediation service control point within an intelligent network
HU221399B1 (en) Method for processing calls, telecommunication system, telecommunication computer system and processor
US5974252A (en) System and method for implementing programmable transaction capabilities application part communication protocol
EP0963663B1 (en) Dynamically associating service script logics to provide a subscriber feature within an advanced intelligent network
EP1121814B1 (en) Message monitoring in a network element
WO1999009659A2 (en) Method for communicating transaction capabilities application part (tcap) information
JPH10304075A (en) Method and system for realizing intelligent telecommunication service utilizing failure resistant object-oriented architecture having self-persistence
EP0813715A1 (en) Service management operation and support system and method
US6661887B1 (en) Service interaction in an intelligent network
US5894574A (en) Apparatus and method for SIB-based global title translation services
Sharp et al. Advanced intelligent networks: now a reality
US6370136B1 (en) Dialing plan arrangement for expandable telecommunications system
Martikainen et al. Tutorial on intelligent networks
EP1095525A1 (en) Hypertext transport protocol interface in an intelligent network node
EP0961507A2 (en) Extension of an AIN/IN SSP
Esaki et al. Service Logic Execution of IN in Multi-vendor Environment-Introduction of SLP Execution Processor
MXPA97003045A (en) System and method for providing improved subscriber services in a multine telecommunication network
SE518123C2 (en) Enhanced subscriber services in multi-node telecommunications network

Legal Events

Date Code Title Description
AS Assignment

Owner name: ERICSSON, INC., NORTH CAROLINA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HAVENS, ERIC;REEL/FRAME:008403/0883

Effective date: 19970121

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

REMI Maintenance fee reminder mailed
FPAY Fee payment

Year of fee payment: 8

FPAY Fee payment

Year of fee payment: 12