CA2214725A1 - Service management operation and support system and method - Google Patents

Abstract

An SNS (305) processes requests for services from one or more customers (180) of a network by sending the service request to an SMS (310). The service request includes a service name and corresponding data collected from the customer. The SMS (310) selects a service management program from a plurality of storage areas based on the function name and executes the service management program to obtain provisioning data. The provisioning data corresponds to the information necessary for a network element (120, 130) to process the network service based on the data collected from the customer (180). Once the provisioning data is determined, the SMS (310) sends the provisioning data to the network element (120, 130). The network element (120, 130) instantiates the requested service based on the provisioning data sent by the SMS (310).

Description

WO 96/2783~ PCTIUS96102273 SERVIOE M~NAGEMENT OPERATION AND SU2PORT ~Y'i 1~ AND ME~OD

C~?.OSS }~F~FF~7FNC~ TO }?F'T.~TFn APPTICATIONS
This application is related to U.S. Patent Application Serial ~o. 07/972,817, the content~ of which are hereby incorporated by reference.
BACKGROUND OF 1~ INVENTION
The present invention relates generally to the Ad~anced Intelligent Telephone Networ~ ("AINn), and more specifically ~o a Ser~ice Management System ("sMS") for proce~ing and implemen~_ new telephone services or modifyin~ old services.
Implementing new telephone services or modifying o'd se~rices efficle~tly and economically has long been a problem for telephbr.e companie3. Recent advances in the AIN have reduced the cost of creating new services by simplifying creation proces~, but have left ~ome problems unsolved, particularly problems concerning gathering and manipulating data required to implement new services.
The AIN ~J de~cribed in the related applications referenced above, pro~ide~ telerh~n~ service ~y~am~ custo~ to the desires of indi~id~al cu~tomers. As used in thi~ application, "customer~ refer~ lo the entity for which a service is pro~ided, and "user~ or ~operator~ refers to the person using the system to create, te~, or modify the service. The usQr and customer may be the same, but they need not be.
The AIN includeJ a cu~t~m~ erYice~ (~CS~) application to create and, in certain ci~ anc~ e~ch cu~tomer'~
gervice ~0~4 1..~ ~ or ~vy~ . The CS can include one or both of SUBSTITUTE SHEET (RUEE 26) CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 the Service Processing And Creation Environment ("SPACE~"j software application and the Multi-Services Application ~latform ~"~SAP~") software appl cation. Both SPACE and MSAP are proprie~ary software applications owned by Bellcore, the assignee of ~his appllcation. Each customer~s service program is s~o-ed _n a database as a record or a series of records of customized call proaessing information called a call processing record ("CPR").
Individual CPRs are created for each customer indicating the telephone services to which they subscribe and the call processing steps necessary to provide those services. These CPRs dictate how the network will respond to calls to or from the customer's telephone number.
In the AIN, the CPRs corresponding to a service are created in a creation environment of the CS application and are executed during call processing in a call processing environment of the CS
application. As used herein, a switch, or service switching point ("SSP"), is a piece of telephone equipment which receives and routes telephone calls t Fig. 1 illustrates an exemplary AIN 100 comprising an SMS
llO, Service Control Points ("SCPs") 120 and 130, Signal Transfer Points ("STPs") 140 and 150, and SSPs 160 and 170. Each SSP
recognizes a variety of "triggers" within customer telephone call signals and generates queries to SCPs based on the triggers. The SSPs then process customer calls in response to commands received f-om the SCPs.
The SCPs are configured as a mutually mated pair in different locations. If an SCP, such as SCP 120, is disabled, its mate, SCP

CA 0221472~ 1997-09-0~
W096l27835 PCT~S96102273 130, can ensure that telephone service continues without interruption.
Associated with the SCP pair 120 and 130 is an SMS ' 0. The SMS 110 provides a support interface through which customer data and service logic can be added or managed.
~ ach of the SMS ilO and the SCPs 120 and 130 can execu~e the CS application. The CS application generally provides for both the creation of a CPR (service creation) through an operator interface, and for the execution of CPRs during call processing.
However, the CS application may, in certain circumstances, provide for only the creation or the execution o~ CPRs.
Fig. 2A is a functional block diagram of SMS llo. SMS 110 comprises CPU 240, database 242, operator interface 244, and CS
application 246. Operator interface 44 comprises display 48, keyboard 50 and mouse 52, each connected to CPU 240. CS
application 246 includes service creation portion 254 and call processing portion 256. A CPR can be created at SMS 110 via operator interface 244 and can also be used by SMS 110 to process calls input to CPU 240 via any number of sources such as a network switch simulator or a dedicated testing switch (not shown).
Fig. 2B is a functional block diagram of SCPs 120 and 130.
SCPs 120 and 130 each comprise CPU 258, database 260, and CS
application 246. In Fig. 2B, CS application 246 comprises only call processing portion 256. This is because SCPs 120 and 130 provide no operator interface 244 (Fig. 2A), therefore, in this embodiment, CPRs cannot be created at SCPs 120 and 130.

CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 The service creation portion 254 of SMS 110 comprises the SPACE software application. The call processlng portion 256 in SMS llO and SCPs 120 and 130 comprises Ihe MSAP software application. ~he service creation portion 254 of SPACE is dedlcated to the creation of CPRs, and a service management portion of SPACE (not shown) is dedicated to managing services, testing and validating procedures, and transferring CPRs, tables, and messages to the SCPs 120 and 130.
CPRs corresponding to new telecommunication services are created using SPACE by generating a high level, display representation (graph) of the desired service on a display of a user workstation (not shown). The graph is comprised of "nodes,"
"decision boxes," and "branches." Each node represents a high level instruction for the execution of the service. The displayed graph of a CPR is extremely useful in that it permits an operator to create and understand the telephone service being created. For use in an execution environment, however, the CPR graph is first translated into a lower level representation comprising data structures and pointers representing the CPR, and is then translated into a binary representation. The SCPs 120 and 130 use this binary representation to process calls in the execution environment. Using SPACE, new services are easily created and easily implemented.
Many customers may request the same telecommunication service for mass markets, however. For example, many customers may wish to designate a long distance carrier during certain times of the day (i.e., business hours). The graph corresponding to each CA 0221472~ 1997-os-o~
W096/27835 PCT~S9610~273 custome~'s CPR would therefore be identical except or graph entry points, nodes defining the carriers, and nodes defining the t me of day that speci led carriers will service the call. All s~her nodes n of the graph and the structure of the graph would be "gener -" to the service.
It is impractical and inefficient to require a user ~s build the same graph for every customer requesting the same service.
Accordingly, SPAC~ and MSAP provide for service templates. Once created and enabled, a template serves as a "form" for creatirg a customer specific version of a service. Customer specific versions of a service are established by making "customizable" one or more nodes within a template. In this manner, the template allows the same service to be provided to more than one customer without having to rebuild the entire graph or redefine generic call variables in the CPR establishing the service.
Using the CS application, and particularly templates, to create and process CPRs has dramatically reduced the costs of creating and instantiating new telephone services, but problems remain. For example, the AIN l00 cannot quickly and economically receive and implement service requests from customers since a skilled operator must coordinate the instantiation of each new service in the AIN l00. "Service request," as used ir. this application, refers to a request by a customer to receive a new telecommunications service or alter an existing service.
To implement a new service in the AIN l00, the operator must typically collect data from the customer. For a call screening service, for example, the operator must collect at least the CA 022l472~ l997-09-0~
W096/2783S PCT~S96/02273 customer's telephone number and a list of numbers not to be screened. It is desirable, of course, to collect this data and -.stantiate this information into the network as quickly and as e~ficiently as possible to reduce costs and provide speedy service. With the current AIN 100, however, i_ s necessary for a person skilled in the operation of the SPACE software to collec-the data and manually enter that data into a template at the SMS 120. This has the disadvantage of taking up the valuable time of trained employees and possibly requlring training of additional employees in the operation of the SPACE software of the SMS 110.
The current AIN 100 has the additional disadvantage of requiring that AIN workstations be used for the implementation of service requests. This disadvantage reduces the accessibility of these AIN terminals for operation and maintenance activities.
It is desirable, therefore, to have telephone service sales representatives or data entry personnel enter in the collected data to the AIN 100 without a large amount of training. It is also desirable to allow the sales representatives or data entry personnel to enter the required data into the AIN 100 from a remote location via a cheaper or more accessible interface than is presently available for instantiating new CPRs or modifying existing CPRs.

DESCRIPTION OF THE INVENTION
Accordingly, the present invention is directed to an SMS
operation and support system that substantially obviates one or =

CA 0221472~ 1997-09-0~
WO 96/2783~ PCTIUS961022'73 more of the problems due to limitations and disadvantages cf the related art.
This invention allows relativeiy unskilled operators ~5 coordinate requests for services at a Service Negotiation System ( "SNS" ) by collecting data and sending it to the SMS quickly ana ef r ciently. The SMS accepts collected data from the SNS, translates the collected data into provisioning data," and supplies the provisioning data to a Network Element Manager ( "NEM" ) . AS used in this application, a network element refers to a component that requires data updates to provide service, e.g., an intelligent peripheral, an SCP, a network database, or the like. As used in this application, "provisioning data" refers to the data required by the NEM to create a CPR for a requested service. After creating the CPR, the NEM transfers the CPR to a database in an SCP. By translating collected data into provisioning data and supplying the provisioning data to the NEM, the SMS eliminates the need for skilled operators to create the provisioning data.
In accordance with one feature of the invention, those skilled in the operation of SPACE need only create a single Service Management Program ("SMP") (similar to a CPR) for each service. The SMP instructs the SMS to accept the collected data in a particular manner for a given customer service, reconfigure the data into the provisioning data format required by the NEM, and send the provisioning data to the NEM. Once this SMP is created, an unskilled operator can collect the data required for each customer service request, and the SMS will insure that the CA 0221472~ 1997-09-0~
W O 96/27835 PCTrUS96/02273 collected data gets to the network element manager in the proper form.
In accordance with another feature of the invention, the SMS
can have multiple SMPs to receive data in multiple forma~s and convert the data into a single provisioning data format. This flexibllity allows the AIN of this invention to communicate wi~h a large variety of input devices and data input schemes. The SMS, -f configured properly, can accept its data from multiple remote terminals operated at work sites of multiple sales representatives, allowing quicker, more efflcient entry of customer service requests.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the invention. The objectives and other advantages of the invention will be realized and attained by means of the instrumentalities and combinations particularly pointed out in the written description and appended claims hereof as well as the appended drawings.
To achieve these and other advantages and in accordance with the purpose of the invention, as embodied and broadly described, the invention recites in a telecommunications network, a method for processing a request for services from a customer, the method comprising the steps, executed by a data processor, of: receiving a service request from the customer, the service request including a function name, corresponding to a network service, and corresponding data; generating provisioning data corresponding to CA 0221472~ 1997-09-0~
W096/27835 ~CT~S96S0~273 information necessary for a network element to process the network service based on the data received from the customer; and sending the provisioning data to the network element.
It is to be unders~ood that both the roregoing genera_ description and the following detailed description are exemDlary and explanatory and are intended to provide further explanation o-the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and constitute a part o~ the speci~ication, illustrate presently preferred implementations of the invention and, together with the general description given above and the detailed description of the preferred implementations given below, serve to explain the principles of the invention.
Fig. 1 is a block diagram of an existing AIN;
Fig. 2A is a block diagram of the SMS in Fig. 1;
Fig. 2B is a block diagram of the SCP in Fig. 1;;
Fig. 3 is a block diagram of an AIN using an SMS in accordance with one embodiment of the present invention;
Fig. 4 is a block diagram of the software of the AIN in Fig.
3 in accordance with one embodiment of the present invention;
Fig. 5A is a block diagram of the SCE in Fig. 3 in accordance with one embodiment of the present invention;
Fig. 5B is a block diagram of the NEM in Fig. 3 in accordance with one embodiment of the present invention;

CA 0221472~ 1997-09-o~
W096/278~5 PCT~S96/02273 Fig. 5C ls a block diagram of the SMS in Fig. 3 in accordance with one embodiment of the present invention.
Fig. 6 is a block diagram of a service local area ne~work -n accordance with one embodiment of the present invention;
Fig. 7A is a flow diagram showing generally the opera~ion c the SNS of Fig. 3 in accordance with one embodiment of the presen-invention;
Fig. 7B is a flow diagram showing generally the operation of the SMS of Fig. 3 in accordance with one embodiment of the present invention;
Fig. 7C is a flow diagram showing generally the operation of the NFM of Fig. 3 in accordance with one embodiment of the presenr invention;
Fig. 7D is a flow diagram showing generally the operation of the switch interface system of Fig. 3 in accordance with one embodiment of the present invention;
Fig. 8 is a flow diagram showing the creation of SMP~s and CPRs in accordance with one embodiment of the present invention;
Fig. 9 is a flow chart illustrating of the operation of the advanced intelligent network of Fig. 3 in processing a request for service in accordance with one embodiment of the present invention;
Fig. 10 is a flow diagram of the operation of an SMS showing the manipulation of saved files in accordance with one embodiment of the present invention;

CA 022l472~ lss7-os-o~
W096/27835 PCT~S96102273 Fig. 11 is a flow chart of the operation of the SMS in processlng requests from an SNS in accordance with one embodiment of the present invention;
Fig. 12 is a graphical process diagram of a service management program for a originating call screening service management program in accordance with one embodimen~ of the present invention;

Reference will now be made in detail to the construction and operatlon of preferred implementations of the present invention which are illustrated in the accompanying drawings. In those drawings, like elements and operations are designated with the same reference numbers.
The following description of the preferred implementations of the present inventlon is only exemplary of the invention. The present invention is not limited to these implementations, but may be reallzed by other implementations.
Fig. 3 illustrates a preferred embodiment of an AIN 300 in accordance with this invention. The AIN 300 includes a Service Negotiation System ("SNS") 305, an SMS 310, a subscriber database 315, a Service Creation Element ("SCE") 325, a service local area network ("LAN") 335, an NEM 345, a switch interface system 355, SCPs 120 and 130, STPs 140 and 150, and SSPs 160 and 170.
The SCPs 120 and 130 preferably include the MSAP software for executing CPRs necessary to process calls received by the SSPs 160 and 170 from telephones 180. In a preferred embodiment, the NEM

CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 345 is connected to two SCPs 120 and 130, although il is understood that the number of SCPs connected to the NEM 345 may vary.
mhe SNS 305 preferably comprises one or more computers (not shown) connec~ed to the SMS 310 via modem communication lines, bu;
can incluae any means for providing data to the SMS 310.
Fig. 4 illustrates the software used in a preferred embodimen~ of the AIN 300. The software includes a modif ed version of the SPACE software 410, a modified version of the MSAP
software 430, a plurality of SMPs 420, the SPACE software 440, the MSAP software 460, a plurality of CPRs 450, and a plurality of triggers 470. The SMPs 420 control the operation of the SMS 310 in translating data collected by the SNS 305 into the provisioning data required by the NEM 345 for instantiating new services. The SMPs 420 are created by the modified SPACE software 410, preferably contained in the SCE 325, and are executed by the modified MSAP software 430, preferably contained in the SMS 310.
The CPRs 450 control the operation of the SCPs 120 and 130 in processing calls received at the SSPs 160 and 170. The CPRs 450 are created by the SPACE software 440, preferably contained in the NEM 345, based on the provisioning data and are executed by the MSAP software 460, preferably contained in the SCPs 120 and 130.
The triggers 470 respond to calls to or from the SSPs 160 and 170 and request that the MSAP execute particular CPRs based on theses calls.
The modified SPACE software 410 includes additional nodes tailored for the SMP's data conversion functions as described CA 0221472~ 1997-os-o~
W096127835 PCT~S96102273 below. The modified MSAP software 430 is designed to process the additional nodes provided in the modified SPACE software 410.
Both the modified SPACE software 410 and the modified MSAP
software 430 are proprietary software applications owned by Bellcore, the assignee of this application.
In accordance with the present invention, the SMPs 420 are created using the modified SPACE software 410 in a manner similar to the creation of the CPRs 450. Individual SMPs can be tailored by operating personnel to sequence and control the execution of service management functions for each particular service and for each particular format of data collected by the SNS 305. The SMPs 420 correspond to high level, displayed representations (graphs) of the desired service management functions. As with CPRs, these graphs are comprised of "nodes," "decision boxes,1' and "branches,"
with each node representing a high level instruction for the execution of the service management function.
Fig. 5A is a functional block diagram of a preferred embodiment of an SCE 325. SCE 325 comprises CPU 558, database 552, operator interface 44, and customized processing ("CP") application 560. Operator interface 44 comprises display 48, keyboard 50 and mouse 52, each connected to CPU 558.
The CP application 560 includes creation portion 564 and execution portion 566. The creation portion 564 of SCE 325 preferably comprises the modified SPACE software. The execution portion 566 of SCE 325 preferably comprises the modified MSAP
software. Through the CP application, an operator creates and, in certain circumstances, executes the SMP associated with a given CA 022l472~ lss7-os-o~
W096/27835 PCT~S96/02273 service. The operator also uses the CP application to create any tables, databases, or definitions required for the executi_n of the SMPs. The SMPs and additlonal data are stored in a database 552. _ndividual SMPs are created for each service and i..c_cate ~he data chat will be collected by the SNS 305 and sent to ~he SMS
310, and the provisioning data required by the NEM for instantiating the service. These SMPs dictate how the SMS 310 will receive data collected by the SNS 305 and translate the collected data into the provisioning data required by the NEM 335 to instantiate a new service. SMPs may be executed in the SCE 325 through inputs received from a simulated SNS or testing SNS (no~
shown).
Fig. 5B is a functional block diagram of a preferred embodiment of the NEM 345. NEM 345 comprises CPU 568, database 562, and CS applicatlon 246. CS application preferably includes service creation portion 254. The service creation portion 254 preferably comprises the SPACE software.
The NEM 345 preferably implements template programs to take provisioning data recei~ed from the SMS 310 and create the CPRs necessary for the SCPs 120 and 130 to process telephone calls.
Fig. 5C is a functional block diagram of a preferred embodiment of an SMS 310. SMS 310 preferably comprises CPU 540, database 542, and CP application 560. CP application 560 includes execution portion 566. The execution portion 566 of SMS 310 preferably comprises the modified MSAP software.
Referring again to Fig. 3, the subscriber database 315 preferably comprises an Oracle~ database stored on a hard disk CA 022l472~ l997-09-0~
W096/278~5 ~CT~S96tO2273 drive, although it may be on any kind of s~orage medium that will allow for easy access by the SMS 310. The subscriber database 3 -preferably includes an entry for each customer containing at leas.
the customer's name, telephone number, and 'ist of subscribed services and related information and data concerning the subscribed services. The subscriber database may also nclude additional data such as the mailing address of the customer, billing information, or the like.
The SSPs 160 and 170 preferably comprise any commercially available telephone switch used for processing telephone calls, e.g., the AT&T 5ESS switch, the AT&T lAESS switch, or the Norther-Telecom DMS 100 switch.
The switch interface system 355 preferably comprises a standard MARCH interface device, as disclosed in the Bellcore document SOAC/MAS Interface S~ecification, document reference BD-SOAC-SPEC-002, but can be any interface device that will receive in~ormation from the SNS 305 required for processing telephone calls and send it to SSPs 160 and 170. This information includes, e.g., the trigger data indicating when and how the SSPs 160 and 170 must query the SCPs 120 and 130 during call processing. In an alternate embodiment, the switch interface system 355 can be connected via an interface to the SMS in addition to or instead of to the SNS 305.
Fig. 6 shows a preferred embodiment of the service LAN 335.
As shown, LAN 335 preferably includes an operations support cente-("OSC") 602, a service assurance group 604, one or more remote users 606, one or more remote operation support systems ("OSS") CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 608, a user administration group ("UAG") 610, and a maintenance and operations console ("MOC") 612. The OSC 602, UAG 610, and MOC
5-2 are connected directly to the SMS 310 via LAN 335. ~he remore users 606 and the remote OSSs 608 can connect to the L~N from a remote location preferably via the internet using a transmissior.
control pro~ocol/internet protocol ("TCP/IP"). TCP/IP is àescribed in a series of technical reports called Intern_t ~ecuests For Ccmments, which are available from the Network Tnformation Center. The operation of the service LAN 335 will be described in more detail below.
Referring again to Fig. 3, in accordance with the present invention, during operation of AIN 300, the SMS 310 receives data from the SNS 305 relating to the activation or alteration of the services subscribed to by a customer, for example, data concerning a new connection, a change of service, or a disconnection. The data may include various types of service order passes for communicating with other parts of the AIN 300, e.g., notification of completion, correction, or cancellation. The connection between the SNS 305 and the SMS 310 helps coordinate the AIN
provisioning flow and ensure that the subscriber database 315, the SCPs 120 and 130, and the SSPs 160 and 170 are all updated in the proper order. In implementing the flow of collected data from the SNS 305, the SMS 310 correlates data received from the SNS 305 with associated subscription data, if any, contained in the subscriber database 315. As used in this invention, "subscription data" refers to information relating to past, active, and pending data received by the SMS 310 from the SNS 305. The SNS 305 can CA 022l472~ lss7-os-o~
W096/27835 PCT~S96102273 also, as necessary, retrieve and update subscription data stored in the subscriber database 315. The connection between the SNS
305 and the SMS 310 can, thereIore, be used by the SNS 305 to retrieve information relating to the current status of customer subscriptions, and then send updated subscription data .o ~he SM5 310 based on that data. Alternatively, the interface could be used by the SNS 305 to retrieve current views of subscript~ons when customers request such information or -eport troubles.
Access to the SMS 310 by ~ultiple different inquiries from the SNS 305 is also within the scope of the invention.
The SMS 310 administers the subscriber database 315 by, for example, creating, deleting, updating, and retrieving subscription data in the subscriber database 315. The SMS 310, in addition to operating based on information from the SNS 305, also accesses and administers the subscriber database 315 in response to inquiries made ~rom the ser~ice LAN 335. The subscriber database 315 is preferably connected directly to the SMS 310, but can also be a remote database accessed by a remote interface, such as the SQL*Net interface. The SQL~Net interface is described in the SOL~Net TCP/IP User's Guide (version 1.2) available from Oracle, Inc.
Access to the SMS 310 by multiple inquiries from the SNS 305 is also within the scope of the invention. The SMS 310 and the SNS 305 are preferably connected using a TCP/IP interface, but can be implemented using any interface that will allow the data to be passed between the SNS 305 and the SMS 310. The messages passed between the SNS and the SMS preferably have the data coded CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 according to Abstract Syntax Notation One ("ASN.1~). ASN.1 is a language-independent, operating system-independent notation for defining abstract data types and is described in CCITT
Recommendations X.208 and X.409, both documents produced by ;3ellcore.
The SMS 310 receives instructions from the SCE 325 regard ng the processing of data received from the SNS 305 for transmit_al to the NEM 345 for activating subscriptions in the SCPs '20 and 130. These instructions preferably comprise SMPs created with the modified SPACE system. These SMPs created by the SCE 32S instruc~
the SMS 310 on how to take information in one form and convert i~
into a form acceptable for entry into a CPR template, i.e., provisioning data.
The interface between the SMS 310 and the SCE 325 may be a physical connection, such as an RS-232 interface, internet connection, modem connection, or the like, or the SCE 325 may be physically separate from the SMS 310 and the programs can be loaded onto floppy disks at the SCE 325 and hand carried from the SCE 325 to the SMS 310.
The interface between the SMS 310 and the NEM 345 is preferably a TCP/IP interface with the data encoded according to ASN.1. The SMS 310 controls message traffic to the NEM 345 and queues messages for later transmittal to the NEM 345 when the SMS
310 is temporarily out of contact with the NEM 345.
SMS 310 can interface with multiple NEMs 345 and can provision each with the appropriate provisioning data for a given customer based on the geographic address of the customer the CA 022l472~ lss7-os-o~
W096/2783S PCT~S96102273 geograpAic area servicéd by each NEM 345 and SCP pair 120 and 130.
This way the SMS 310 insures that it provisions a customer~s service for the SCPs 120 and 130 that service the seographical area in which the customer lives.
In a preferred embodiment, the SNS 305 is connected -_ ~he switch interface system 355 to provide trigger informatior. to the SSPs 160 and 170. ~ust as the SCPs 120 and 130 receive CPRs including the proper information to process calls and implement services in accordance with the invention, the SSPs receive trigger data to instruct them as to what CPRs to request activation of by the SCPs 120 and 130, and when to request the activation.
In an alternate embodiment, SMS 310 may be directly connected to the switch interface system 355 to send trigger data to SSPs 160 and 170, and the connection between the SNS 305 and the switch interface system 355 may be deleted. In this alternate embodiment the SMS 310 sends the necessary trigger data in the proper format to the switch interface device based on information received from the SNS 305.
In addition to the interface between the SMS 310 and the SCE
325, there also e~ists an interface between the SMS 310 and the service LAN 335. Via this interface, operators can view and update subscription data in the subscriber database 315. Updates to subscription data based on data entered by this method are treated just like updates based on data collected by the SNS 305.
In both cases, the SMS 310 will proceed to convert collected data CA 022l472~ l997-o9-o~
W096/2783~ PCT~S96/02273 to provisioning data and send the provisioning data to the NEM
345.
Figs. 7A-7D show generally the operation of the AIN 300 in accordance with a preferred embodiment of the present invention.
Fig. 7A shows generally the operation of the SNS 305. Fig. 7B
shows generally the operation of the SMS 310. Fig. 7C shows generally the operation of the NEM 335. Fig. 7D shows generaily the operation of the switch interface system 355.
As seen in Fig. 7A, the SNS 305 initially receives a requesc for new service from a customer (step 710). The SNS 305 then collects data from the customer (step 712) and sends the collected data to the SMS 310 (step 714). Finally, based on the collected data, the SNS 305 creates the trigger data necessary for the SSPs 160 and 170 to correctly process calls in accordance with the new service (step 716) and sends the trigger data to the switch interface system 355 (step 718).
As seen in Fig. 7B, the SMS 310 receives the collected data from the SNS 305 (step 720), converts the collected data into the provisioning data required by the NEM 335 to instantiate the new service (step 722), and sends the provisioning data to the NEM 335 (step 724).
As seen in Fig. 7C, the NEM receives the provisioning data from the SMS 310 (step 730), fills the necessary templates with the provisioning data (step 732), and instantiates the requested service via the filled template (step 734).

CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 As seen in Fig. 7D, the switch interface system receives the trigger data from the SNS 305 (step 740) and places the trigger data to the SSPs (step 742) .
Fig. 8 is a flow diagram showing the creation of SMPs and CPRs and illustrates this commonality of service creation in the present invention. The creation portion 564 of CP application 560 (Fig. 5A) includes all of the functions available in the S2ACE
software as well as those avallable only in the modi~ied SPACE
software. As a result, an operator 802 may use the SCE 325 to create CPRs 806 for execution by SCPs 120 and 130 and may also use the same SCE 325 to create SMPs 804 for execution by SMS 310.
A preferred method of operation o~ the AIN 300 including the SMS 310 in accordance with this invention will now be described with reference to Figs. 9A and 9B which show processing steps of the AIN 300 to process a request from a customer for the activation or alteration of a service.
The processing begins when a customer requests to add, change, or delete a service provided by the AIN 300, i . e., submits a "change service" order, and gives the request, to the SNS 305 (step 908). The SNS 305 then collects data from the customer required to add, change, or delete the service (step 910). Based on the information collected from the customer, the SNS 305 sends the data in an agreed upon format to the SMS 310 (step 912).
Using the data from the SNS 305, the SMS 310 determines the appropriate SMP to execute and based on that SMP, verifies that necessary data has been collected and received, and validates the data, i.e., determines if sufficient data has been submitted in a CA 0221472~ 1997-09-05 W 096/27835 PCTrUS96/02273 proper format with acceptable data values (step 914). If the data is verified and valid, the SMS 310 then translates the collected da~a from its initial data format to a provisioning data format !s~ep 9~6) and saves the provisioning data as subscription data ~nder .he status of a pending view (step 917). If ~n step 314, ~he data is either not verified or not valid, the SMS enters an error s~ate and ceases processing the request (step 915).
After the collected data is converted to provisioning data, the SMS checks the due date of the request (step 918). If SMS
determines that the due date requested by the SNS 305 ls immediate, the SMS 310 sends the provisioning data to the NEM 345 (step 922). If the due date is some time in the future, the SMS
310 exits the process (step 920) and continues with other operations until it determines that the requested due date has arrived, at which time it returns (step 921) and executes step 922.
Upon receiving the provisioning data, the NEM 345 populates the template associated with the service requested by the customer with the supplied provisioning data to complete the required CPR
for processing the customer's change service order (step 924).
Then the NEM 345 updates the databases associated with the SCPs 120 and 130 with the resulting CPR (step 926). Next, the NEM
determines if any errors have occurred during the creation or modification of the required CPR (step 928). If the NEM 345 detects no errors in step 928, the NEM 345 responds to the SMS 310 with a message acknowledging the successful update (step 930). I~
the NEM 345 does detect an error in step 928, the NEM 345 enters CA 022l472~ lss7-os-o~
W096/27835 PCT~S96102273 an error state and ceases processing the request (step 923). Cnce the SMS 310 receives the acknowledge from the NEM 345, the SMS 31 responds to the SNS 305 with an acknowledge signal (step 932).
The SMS 310 then stores ~he provisioning data in its subsc~iber database 315 under the status ~active~ (step 934).
The SNS 305, upon receiving the acknowledge signal, sends to the switch interface sys~em 355 a packet of information containing the trigger data (step 936). As used in this application, ~trigger data" is the data necessary for the switch interface system 355 to place the required triggers in the SSPs 160 and 170 for properly accesslng the SCPs 120 and 130 to process the new service. The switch interface system then checks the due date of the service request (step 938). If the switch interface system 355 determines that the due date for starting the service is immediate, the switch interface system 355 sends the AIN triggers to the SSPs 160 and 170 (step 942) . If the due date is some time in the future, the switch interface system 355 exits the process (step 940) and continues with other operations until it determines that the requested due date has arrived, at which time the switch interface system 355 returns (step 941) and executes step 942.
As the switch interface system sends the triggers to the SSPs 160 and 17Q, it determines if any errors occurred during transmission (step 946). If the switch interface system 355 detects any errors, it enters an error state and ceases processins the request (step 944). If the switch interface system 355 detects no errors in the sending of the triggers to the SSPs 160 and 170, the switch interface system 355 sends an acknowledgment CA 022l472~ l997-09-0~
W096t27835 PCT~S96/02273 from the SSPs 160 and 170 to the SNS 305 (step 948). SNS 305 later sends a signal to SMS 310 acknowledging that the AI~ 300 has completed processing the service request (step 950).
Tn al'ernate embodiments, step 936 could be carried out àirectly by the SMS 310, avoiding the need for step 950. _n ~h s alternate embodiment, the switch interface system 355 sends an acknowledgment directly to the SMS 310 as step 948.
The subscriber database 315 records the history of a customer's subscriptions from the time collected data is first sent to the SMS 310. SMS 310 maintains a set of subscription data re ating to a particular customers service subscription, including multiple "views" of that subscription from its initial request through any additional requests for modification or cancellation.
These different views reflect the history of that service for the customer. SMS 310 tracks the different views by assigning a "status" to each piece of data indicating what stage of implementation the request has reached. The views supported by the SMS 310 and subscrlption status indications are summarized as follows, with reference to Figs. 10 and 11.
As shown in Fig. 10, the SMS 310 saves the collected data as subscription data in a saved view 1002, exception views 1004 and 1010, a pended view 1006, a sending view 1008, a master view 1012, and a historical view 1014. The saved view 1002 contains a status of "saved" which indicates that the collected data has been received by the SMS 310, but has not been validated or translated.
The pended view 1006 contains a status of "pending" which indicates that the collected data has successfully been translated CA 022l472~ l997-09-0~
w096l27835 PCT~S96102273 to provisioning data, has passed all validations, and is awaitir.g posting to the NEM 345. The sending view 1008 contains a status of llsending" which indicates that provisioning data correspondi.,g to the data collected by the SNS 305 is currently being posted to the NEM 345. ~his view preferably exists only frcm the t-me the SMS 310 begins the posting process until the posting is czmpleted, or unt-l an error ~s encountered. The exception views 1004 and 1010 contain a status of "failed" which indicates that the collected data or provisioning data has either failed the validation (exception view 1004) or an error was encoun~ered during the posting process (exception view lO10). The master view 1012 contains a status of "active" which indicates that this is the data corresponding to the CPR currently contained in the database associated with the SCPs 120 and 130. The hlstorical view 1014 contains a copy of the most recent master view 1012 that was successfully posted to the NEM 345 prior to the present master view 1012.
Fig. 11 is a flow chart of the operation of the SMS 310 and the subscriber database 315 as they relate to Fig. 10. The SMS
310 initially receives collected data from the SNS 305, which reflects the customer's request for new or altered service and saves the data as subscription data in a saved view (step 1102).
The SMS 310 then determines whether this data requires any corrections or has resulted in any errors, i.e., validates the data (step 1104). If there are errors or required corrections, the SMS 310 saves the collected data as subscription data in an "exception" view (step 1106) and exits the processlng of the CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 request (step 1107). If the SMS 310 later receives data providing correction of the error, the SMS 310 returns (step 1114), makes the correction (step 1113), and proceeds to step 1108.
If no errors are detected in the initial request in s~ep llG4, the SMS 310 saves the current data as su~script on data -n a pended view tstep 1108). Next, the SMS determines when the request is due to be instantiated (step 1110). If the SMS 310 determines that the request is due to be instantiated immediately, the SMS 310 sends the request, in the form of provisioning data, to the SCPs 120 and 130 via the NEM 345 (step 1116). If the SMS
310 determines that the due date is some time in the future, the SMS 310 exits the process (step 1112) and continues with other operations until it determines that the requested due date has arrived, at which time it returns (step 1114) and executes step 1116~ Upon sending the provisioning data, the SMS 310 then determines whether the sending of provisioning data has resulted in any errors (step 1118).
As in step 1104, if there are any detected errors, the SMS
310 saves the current provisioning data as subscription data in an exception view (step 1120) and exists the process (step 1121). If the SMS 310 later receives data providing correction of the error, the SMS 310 returns to the process (step 1124), makes the correction (step 1125), resends the corrected provisioning data (step 1116), and rechecks whether its transmittal was successful (step 1118).
If the sending of provisioning data from the SMS 310 to the NEM 345 proceeds with no errors in step 1118, the SMS 310 saves CA 022l472~ lss7-os-o~
W096l27835 PCT~S96102273 the subscription data in the present master view as a subscription data in the historic view ( st2p 1122) and then saves the current data as subscription data in the master view (step il23).
SMS 310 provides flexibility to manage a wide variety cf services througn the mechanism of SMPs. The SMPs are crea~ed v~a the same or a similar graphical user interface used to create C~Rs for the SCP 120 and 130. Individual SMPs can be tailored by operating personnel to sequence and control the execution c~
service management functions for each particular service.
For a given service, an SMP and any associated data tables allow operators to specify the particular data items expected by the SMS 310, the source of each data item, and the processing steps necessary to convert the collected data into the provisioning data required by the NEM 345. The operators preferably specify this conversion by specifying which of a plurality of NEMs 345 to provision, which NEM template should be populated with the data, and the error handling for a variety of conditions, e.g., faulty or missing data, incorrect area of service, no response from the NEM system 345, or the like.
The creation of a new AIN service as it relates to the SMS
310 will be described below with reference to Fig. 12. As discussed, AIN service creation typically starts with an operator graphically creating and testing the logic for the new service.
Once this logic is tested in the call processing environment, the developer creates a CPR "template" for the service. This template represents the provisioning data needed for creation of a CPR for the new service. Service templates are described more fully in CA 022l472~ l997-09-0~
W096;~ 35 PCT~S96/02273 the U.S. patent applications which have been incorporated by reference above.
With data collected from ~he customer via the SNS 305, and the provisioning data required by the NEM 345 for the creaticn ~~
a CPR for ~he new service, the developer can create the SMP neede~
to coordinate the creation of the new service. The creation or an SMP will be illustrated by describing the processing of a requesc for a originating call screening ("OCS") service will be explained.
OCS is a mass market service that allows customers to "screen" incoming calls. Typical collected data includes the customer's telephone number, their list of numbers not to be screened, an override PIN used to bypass the screening, a screening list PIN (used by the customer to update the screening list telephone numbers), and a forwarding number (to which callers who have been screened are directed, e.g., the customer's voice mailbox).
Fig. 12 illustrates an OCS SMP in accordance with one embodiment of this invention. The OCS SMP controls the SMS 310 behavior during conversion of collected data received from the SNS
305 into provisioning data for filing a template in the NEM 345 to create the CPR for the OCS service.
When an OCS transaction request is recelved by SMS 310, the SMS 310 executes the OCS SMP. As used in this application, a "transaction request" for a given service refers to any piece of data received by the SMS 310 pertaining to the creation, deletion, or alteration of a CPR for that service. Upon entry into the OCS

CA 022l472~ lss7-os-o~
w096l2783~ PCT~S96102273 SMP (step 1202), the OCS SMP determines where the transac~ion request came from (step 1204). If the transaction request came rom the SNS 305, the processing of the SMP branches to an SNS
path (step 1206). In the SNS path, the SMS 310 determines the specific type c- request that is being made, i.e., reques. 'or new service, update of old service, cancel service, etc., based on information in the coliected data (step 1212). Then, depending cn the type of request made, the processing branches to the section of the SMP designed to handle that request type (steps 1218-1224).
While handling a particular request, the SMP may temporarily hand over processing control to a second SMP to perform one part of th.e request. The SMS 310 will execute this other SMP and then return processing control to the original SMP. These handover processes include processes for adding new OCS service (step 1230), cancelling a service (step 1232), etc.
If step 1204 determines that the request comes internally from the SMS 310, the processing of the SMP branches to an internal path (step 1208), immediately during processing or on the subscription due date and time, and the posting process begins (step 1216). The SM5 310 then hands over process control to an SMP for sending data (step 1234) which retrieves the provisioning data from the subscriber database 315 and then sends provisioning data to the NEM 345. In this embodiment, since there is only one function in the internal branch, step 1214 must choose the posting branch (step 1226).
If step 1204 determines that the request comes from the NEM
335, the processing of the SMP branches to an NEM path (step CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 1210). As with the internal branch, in this embodiment .here s only one function in the NEM branch, so step 1216 must choose the response branch (step 1228). The response branch handles a -esponse to the provisioning request Crom the NEM 345 by :-andi~.g over control to an SMP for accepting the response. ~hat SMP
analyzes the response, updates the subscription data in _he subscriber database 315 in SMS 310, and sends an appropr ate response back to SNS 305.
It is understood that all of these secondary SMPs used in the handover processes could be part of the OCS SMP. They are preferably saved as separate SMPs to reduce the complexity and creation cost of the individual SMPs. In this way a "basic" SMP
may be accessed essentially as a node by multiple other SMPs.
In accordance with the present lnvention, the creation portion 464 of the CP application 460 in the SCE 325 has been enhanced and extended to include new programming elements to support functions of the SMS 310 which are not performed by the SCPs 120 and 130. These new elements are in the form of additional nodes to use in the creation of the graphs used to make the SMPs. In addition, SMS-specific functions have been added to the execution portion of the CP application in the SMS 310 and the SCE 325.
The basic programmability features available wlth the MSAP
and SPACE software are outlined below, followed by the preferred enhancements and extensions of this invention. The functions listed below include basic nodes existing in the SPACE software as well as additional node types.

CA 022l472~ lss7-os-o~
W096/27835 PCT~S96/02273 Each of the following types of nodes are available _or creating SMPs through a graphical user interface: program nitiation, decision making, management of table data, gathering administrative data, interfacing with external systems, _es~ing applications, managing applications, adding new services, _~voki~_ an SMP, and accessing a database.
A "program initiation" function starts the SMP f owing. n the case of call processing, using CPRs, this function determines when a switch encounters a trigger while processing a call, e.g., the caller dials a specific number, receives a call, or goes off-hook. A program inltiation for an SMS 310 starts in response to an invoke SMP function. The SMS 310 invokes SMP function whenever the SMS 310 receives any data that it identifies as relating to a particular service associated with an SMP.
"Decision making" functions enable an SMP to make logical decisions which effect the processing flow of data through the SMS
310. For example, an SMP for processing collected data for an AIN
service may have an area-of-service decision to see if the customer's geographical area is served by particular switches.
Based upon the decision, the service request may continue or be handled by exception processing routines.
"Management of table data" functions allow the application t~
manipulate data tables. SPACE software includes the ability to create, populate, access, and update data in tables. Preferably these tables are stored internally by the SMS 310 or SCPs 120 and 130 as regular Oracle~ tables. Table data may contain provisioning data relating to area-of-service, service parameter CA 0221472~ 1997-09-0~
W O 96/2783S PCTrUS96/02273 choices, or other information which is required by the NEM 345 fo-creatlng a CPR for a given service. During provisioning t~ansactions, between the SMS 310 and the NEM 345, these ~ables are accessed as part of a process to validate an crder. Tables may also be used to store results of processing, such as e-ror orders or pended orders.
"Gathering administrat ve data" functions allow the SMP
designer to include data collection and reporting in an SMP. Data collection may be specified in the SMP for any network event or situation, such as creation of a new service subscription, cancellation of a service subscription etc. When this network event occurs, the collected data is then sent to a data and reports system ("DRS") for retention and reporting.
"Interfacing with external systems" functions allow SMP
designers to access data in external systems, such as other OSS
systems. In the SPACE system, GetData and SendData nodes or processing routines retrieve and update data in external systems.
The GetData and SendData nodes currently support systems on TCP/I~
networks, 3270 SNA networks, and SS7 network databases.
"Testing applications" functions allow the application to perform testing operations. SPACE software includes built-in testing tools which are used for initial testing and can also be invoked by the SMS 310 for diagnosis and trouble shooting.
"Managing application" functions make it possible for an operator to modify applications and activate them in the SMS 310.
Managing application functions include specific functions to CA 022l472~ l997-o9-o~
W~96/27835 PCT~S96102273 coordinate multlple SMPs, te~plates, and convert collected data into provisioning data.
Adding new service" functions allows an operator to add a ~ew service within an SMP. SMPs for new services will generally be able tO use the exist ng programming tools to add new data bases, change or add editing rules, support new AIN service _eatures or provide service management reports. In SPACE, Ihe GetData, SendData and Play Application generic contract nodes can be used to get data from different external OSSs or to invoke specially written new software for highly unusual processing or to access OSS data.
The ~'invoke SMP" function allows the application such as an SMP, to invoke another SMP. The current AIN allows for service initiation of CPRs through the AIN-defined triggers which are implemented in SSPs 160 and 170. These static AIN triggers are not adequate for SMP initiation and are replaced in the SMS 310 with the invoke SMP function. All SMPs are initiated by the invoke SMP function. An invoke SMP transaction occurs when data is received from a cooperating system indica~ing the SMP should be involced, e.g., the transmission of data. An example of this can be seen in the operation of the OCS SMP, with reference to Fig.
12. In Fig 12, the SMP can be initiated from the SNS 305 causing the SMP to branch to step 1206, the SMS 310, i.e., internally, causing the SMP to branch to step 1208, or the NEM 345 causing the ~ SMP to branch to step 1210.
A preferred embodiment of the invention includes a number of facilities in the AIN 300 which send invoke SMP transactions to CA 022l472~ lss7-os-o~
W096/27835 PCT~S96/02273 the execution environment in the SMS 310. The most often used are the connection between the SMS 310 and the SNS 305, which will package data as invoke SMP transactions, and the interface between the LAN 335 and the SMS 310 which will allow administrative and operator personnel to initiate SMPs.
The database access functions allow the SMP to access data from an external or an lnternal database. In the SPACE system, database access functions include generic Data Layer Building Block ("DLBB") primitives, Table Access Primitives, GetData Primitives, and SendData Primitives, which are extensively used for the SMS 310, especially for accessing the subscriber database 315.
In addition, a preferred embodiment of the CP application of the present invention enhances several functions of the standard SPACE software. For example, the SPACE software currently allows for the definition of tables which are used for AIN services.
According to a preferred embodiment of the present invention, these facilities are extended to allow SMP developers to define more complex databases which are required for the subscriber databases. These databases are directly available on the SMS 310 execution environment through existing primitives (Table Access, GetData and SendData). Preferably these databases are created as Oracle~ databases.
The SMS 310 also includes a number of additional functions which are not available in the current version of the SPACE
software. These functions relate to provisioning interfaces, CA 022l472~ l997-09-0~
W096/27835 PCT~S96102273 multiple views, improved transaction processing, area-of-service network functioning, open access, and protocol support.
~ Provisioning interface transactions for the ir.terface be~ween the SMS 3iO and the NEM 345 are generated by SMPs which provids for mult_ple views cc a given request for service. Preser.tly, ~M
functions do not keep multiple views of a given request fcr execution of a CPR. The SMS 310 provides for improved transaction processing by supporting database rollback facilities. The SMS
310 allows for subscriptions to be sent to a network system for any geographic area and does not limit transmission to a mated pair of SCPs. The SMS 310 will also accept requests for services obtained by GetData/SendData functions from other OSS systems, which provides for the open access envisioned by emerging service needs. The requests obtained by GetData/SendData functions preferably operate over a variety of network protocols and can be extended to lnclude protocol handlers for customer-specific situations.
A preferred embodiment of the SMS in the present invention also includes a generic process layer building block ("PLBB") called the play application primitive. The play application primitive is used for AIN services to initiate processes which operate on intelligent peripherals ("IPs") for specialized applications, such as accessing paging networks.
The play application primitive also provides the ability to - initiate external processes in a cooperating system. This allows the SMS to reuse certain processes, some of which can be provided for immediate use, and some of which may be developed by the CA 022l472~ l997-09-0~
W096l27835 PCT~S96/02273 operator to meet a customer's individual needs. For example, an AIN service that must provlsion a digitized recording for a customer may use a piay application, "Download Speech,~ to send instruc ions to an IP provisloning system to activate the customized announcement.
Another example of the use of the play application primitive is for cus~omer self-provisioning of services. A customer may for example, call a "service desk" application to modify characteristics of their service themselves. The AIN service desk application issues a play application to the SMS 310 to manage the change in the effected systems. This may be done, e.g., with the use of a touch tone telephone. In this example, the play application comes into the SMS 310 as an invoke SMP, and the invoked SMP handles validation and distributlon of the customers changes.
In a preferred embodiment of this invention, third party providers have the option of using their own system to communicate with SMS 310, using a standard OSS gateway. Alternatively, the providers have access to SMS 310 via supported application terminals. Since SMS 310 provides an open contract interface for transaction requests, third party providers can take advantage of these same communications protocols.
Third party providers using their own system to maintain their customers will use the OSS gateway for access into the AIN
system including the SMS of the present invention. With this approach, the interface is system-to-system and does not require any SMS 310 display "screens" for maintenance of data, although CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 third party providers may access the SMS 310 using screens for provisioning and maintaining their customers AIN service data.
These screens provide the necessary data element "templates"
required for gathering the necessary data rrom their serv_ce customers.
The operators o~ the SMS 310 have the ability to prohibit third party viewing of screens used for the main~enance ana operations of the SMS 310 system however. These screens are preferably available only to operating personnel responsible for such tasks.
In addition, the SMS 310 may provide security veri~ication O r messages through physical communication addresses, message type, request type, and a security field. All transaction requests from a third party provider are screened through security to help ensure that the service provider is authorized to access the SMS
310 and execute the requested transaction. There is always a security ~ield associated with any transactions with SMS 310 requesting a change in service. This security field contains data values which are stored along with subscription data when the data is added or changed. Third party providers are limited to viewing and maintaining only their own customer's subscriptions.
SMS 310 executes specific SMPs to process the transactions requested by third party service providers. It is within the scope of this invention to include processing logic in these SMPs to gather appropriate statistics as desired by the operator or the third party service providers.

- 37 _ CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 Third party providers may have access to standard reports which would list their customers and the services ~o which they subscr be. Ad hoc reporting may be available under the suidance ~f the operator to help ensure proper processing and perfsrmance :evels c the SMS 310 are being maintalned for all users. Repor--outing strategies depend upon the needs of the operator and the ~hird parties.
Errors in third party transaction requests are reported to an error file which can be viewed by the third party.
The preferred embodiment of the SMS 310 software developmen~
includes a tool kit based on the existing SPACE service creation environment. The SPACE system report and listing capabilities are available to list service creation components that have been created by the third party. For third party use of the SMS 310 process server, the operator can include SMP logic which will capture certain statistical information concerning subscriptions cf customers owned by the third party.
A preferred embodiment of the SMS 310 provides certain service management features and access flexibility to support the user interface and AIN user group requirements. For use with the preferred embodiment of SMS 310 and user workstations provides TCP/IP, Token-Ring, or Ethernet communications which allow various groups access to the SMS 310.
Fig. 6 illustrates how the support center users, mediated access users, service assurance users, and user administrators can either locally or remotely access the SMS 310. The terminal devices used in the configuration shown in Fig. 6 are preferably CA 022l472~ lss7-os-o~
W~96/27835 PCT~S96J02273 intelligent workstations equipped wi~h a TCP/IP, Token-Ring LAN
interface capability which will allow users of SMS 310 to access other systems used by the operator.
Authorized users who have workstations equipped with T~
Token-Ring hAN connections can access the SMS 310 system. ~hese users may be iocal to ~he LAN connected to the SMS 310 or may be remotely located where connectivity to SMS 310 is accompiisned v a network routers 514.
The maximum number of workstations that can be supported is largely driven by response time requirements. A preferred embodiment of the SMS system will allow for 30 workstatlon users simultaneously connected to the SMS 310.
The SMS 310 workstation provides a graphical user interface where system capabilitles and functions are presented using menu bars and pull downs. The user can navigate through the menu selections with point and click technology or may access functions via function key combinations.
The preferred embodiment of the graphical user interface is based on the X Window System with Motif Style guides. A color monitor attached to the workstation provides a high level of resolution, permi~ting an extensive amount of information to be displayed without loss of detail.
SMS 310 provides operators with on-line help for all functions and tasks they must perform. A complete set of on-line documentation can be accessed, with support for user specific notations and bookmarks for later retrieval.

CA 022l472~ l997-09-0~
W096/27835 PCT~S96/02273 SMS 310 provides a dialog box which exists across the bc~cm cr the screen to provide textual feedback on actions, such as syntactical error notifications or the s~atus of remote cperat ons. The user has on-line documentation readily ava ab 5 which will provide more information to help resolve any errors and provide more details on how to use the system.
The SMS 310 supports a "saved" view of a subscription which acts as a hold facility for an incomplete request ror service.
This capability enables the user to suspend the current entering of the request for service until a later time. The request wil' remain saved until the user completes the request information and submits it for validation processing.
A preferred embodiment of SMS 310 stores the subscription data elements in Oracle~ database tables. Standard Oracle~
reporting tools are preferably available for the user to create ad hoc reports. In addition, sampling and measurement nodes are available to the developer of the SMPs if the operator chooses to have SMS 310 communicate with a data and reports system. By leveraging the DRS system to support reporting capabilities on the SMS 310, the operator can collect data reflecting actual SMP
request proces~ing statistics. Operating statistics assoclated with system functions are provided to the user via the SMS 310 maintenance and operations console 612.
While there has been illustrated and described what are at present considered to be preferred embodiments and methods o~ the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and CA 0221472~ 1997-09-0~
w096/27835 PCT~S96/02273 equivaients may be substituted for elements thereof without departing from the true scope of the invention For example, the preferred embodiments of the invention have been described in the context of the AIN and telephone networks ~he preser.t _nven~cr, howeve~, can be used for system managemen~ in other telecommunications networks such as cable television netwcrks, computer networks, wireless networks, broadband networks, or the like In addition, many modi~ications may be made to adapt a particular element, technique or implementation to the teachings of the present invention without departing from the central scope of the invention. Therefore, it is intended that this invention not be limited to the particular embodiments and methods disclosed herein, but that ~he invention include all embodiments falling with the scope of the appended claims.

Claims (14)

1. In a telecommunications network, a method for processing a request for services from a customer, the method comprising the steps, executed by a data processor, of:
receiving a service request from the customer, the service request including a function name, corresponding to a network service, and corresponding data;
generating provisioning data corresponding to information necessary for a network element to process the network service based on the data received from the customer; and sending the provisioning data to the network element

2. A method according to claim 1, further comprising the step of retrieving additional data from an external system, and wherein the generating step generates provisioning data based on both the data received from the customer and the additional data retrieved from the external system.

3. A method according to claim 1, further comprising the steps of:
generating trigger data; and sending the trigger data to the telecommunications switch in the network, said trigger data being recognized by the switch to indicate that a service should be processed.

4. A method according to claim 1, wherein the network element is a service control point for processing telecommunication calls through telecommunication switches.

5. A method according to claim 1, further comprising the step of sending subscription data to an external system corresponding to the data received from the customer.

6. A service management system comprising:
a memory containing a plurality of service management programs;
means for receiving a service request from a customer, the service request including a function name, corresponding to a network service, and corresponding data;
means for selecting a service management program from a plurality of storage areas based on the function name;
a data processor for executing the service management program to obtain provisioning data corresponding to the information necessary for a network element to process the network service based on the data received from the customer; and means for sending the provisioning data to the network element.

7. A service management system according to claim 6, wherein the function name corresponds to a service name for a service available in a telecommunications system.

8. A service management system according to claim 7, wherein the data processor also generates trigger data and sends the trigger data to the telecommunications switch in the network, said trigger data being recognized by the switch to indicate that a service should be processed.

9. An intelligent network comprising:

a processor for transmitting a service request from a customer, the service request including a function name, corresponding to a network service, and corresponding data;
means for selecting a service management program from a plurality of storage areas based on the function name;
a data processor for executing the service management program to obtain provisioning data corresponding to the information necessary for a network element to process the network service based on the data received from the customer; and a network element for receiving the provisioning data.

10. An intelligent network according to claim 9, further comprising a service creation element for creating additional service management programs and other service creation data.

11 An intelligent network according to claim 9, further comprising an external data system operatively connected to the data processor for storing additional data relating to the requested service.

12. An intelligent network according to claim 9, wherein the function name corresponds to a service name for a service available in a telecommunications system.

13. A method according to claim 12, wherein the data processor also generates trigger data and sends the trigger data to the telecommunications switch in the network, said trigger data being recognized by the switch to indicate that a service should be processed.

14. An intelligent network according to claim 9, wherein the network element is a service control point for processing telecommunication calls through telecommunication switches.