SERVICE MANAGEMENT OPERATION AND SUPPORT SYSTEM AND METHOD________________________________________________________________________

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: SERVICE MANAGEMENT OPERATION AND SUPPORT SYSTEM AND METHOD CROSS REFERENCE TO RE ATED APPLICATIONS This application is related to U.S. Patent Application Serial No. 07/972,817, the contents of which are hereby incorporated by reference. BACKGROUND OF THE INVENTION The present invention relates generally to the Advanced Intelligent Telephone Network ("AIN") , and more specifically to a Service Management System ("SMS") for processing and implementing new telephone services or modifying old services. Implementing new telephone services or modifying old services efficiently and economically has long been a problem for telephone companies. Recent advances in the AIN have reduced the cost of creating new services by simplifying creation process, but have left some problems unsolved, particularly problems concerning gathering and manipulating data required to implement new services. The AIN aa described in the related applications referenced above, providea telephone service programs customized to the desires of individual customers. Aa uaed in this application, "customer" refers to the entity for which a service is provided, and "user" or "operator" refers to the person using the system to create, teat, or modify the service. The user and cuatomer may be the same, but they need not be. The AIN includes a customized services ("CS") application to create and, in certain circumstances, execute each customer's service procedure or program. The CS can include one or both of ' 1 * β AD ORIGINAL (jk the Service Processing And Creation Environment ("SPACE®") software application and the Multi-Services Application Platform MI MSAP®") software application. Both SPACE and MSAP are proprietary software applications owned by Bellcore, the assignee cf this application. Each customer's service program is stored in a database as a record or a series of records of customized call processing information called a call processing record ("C?R") . 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. Fig. 1 illustrates an exemplary AIN 100 comprising an SMS 110, 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 from 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 2 - 6AD ORIGINAL ?% 130, can ensure that telephone service continues without interruption. Associated with the SCP pair 120 and 130 is an SMS 110. The SMS 110 provides a support interface through which customer data and service logic can be added or managed. Each of the SMS 110 and the SCPs 120 and 130 can execute 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 of CPRs. Fig. 2A is a functional block diagram of SMS 110. 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. - 3 BAD ORIGINAL ^ The service creation portion 254 of SMS 110 comprises the SPACE software application. The call processing portion 256 in SMS 110 and SCPs 120 and 130 comprises the MSAP software application. The service creation portion 254 cf SPACE is dedicated 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 r - 4 - BAD ORIGINAL (A customer's CPR would therefore be identical except for graph entry points, nodes defining the carriers, and nodes defining the time of day that specified carriers will service the call. All other nodes n of the graph and the structure of the graph would be "generic" to the service. It is impractical and inefficient to require a user to build the same graph for every customer requesting the same service. Accordingly, SPACE and MSAP provide for service templates. Once created and enabled, a template serves as a "form" for creating 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 100 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 100. "Service request," as used in 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 100, the operator must typically collect data from the customer. For a call screening service, for example, the operator must collect at least the 5 - r BAD ORIGINAL 0, customer's telephone number and a list of numbers not to be screened. It is desirable, cf course, to collect this data and instantiate this information into the network as quickly and as efficiently as possible to reduce costs and provide speedy service. With the current AIN 100, however, it s necessary fcr a person skilled in the operation of the SPACE software to collect the data and manually enter that data into a template at the SMS 120. This has the disadvantage of taking up the valuable t me cf trained employees and possibly requiring 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 - 6 BAD ORIGINAL fl more of the problems due to limitations and disadvantages of the related art. This invention allows relatively unskilled operators to coordinate requests for services at a Service Negotiation System ("SNS") by collecting data and sending it to the SMS quickly and efficiently. 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 tc 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 BAD O R I GINAL collected data gets to the network element manager in the proper orm. In accordance with another feature cf the invention, the SMS can have multiple SMPs to receive data in multiple formats and convert the data into a single provisioning data format. This flexibility allows the AIN of this invention to communicate with a large variety of input devices and data input schemes. The SMS, if configured properly, can accept its data from multiple remote terminals operated at work sites of multiple sales representatives, allowing quicker, more efficient 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 BAD ORIGINAL J* 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 understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of the specification, 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 inven ion; r g . BAD ORIGINAL 4 Fig. 5C is 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 network in accordance with one embodiment of the present invention; Fig. 7A is a flow diagram showing generally the operation cf the SNS of Fig. 3 in accordance with one embodiment cf the present 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 NEM of Fig. 3 in accordance with one embodiment of the present 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; BAD ORIGINAL £ Fig. 11 is a flow chart of the operation of the SMS in processing 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 embodiment of the present invention; BEST MODE FOR CARRYING OUT THE INVENTION Reference will now be made in detail to the construction and operation 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 invention is only exemplary of the invention. The present invention is not limited to these implementations, but may be realized 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 BAD ORIGINAL rfl 345 is connected to two SCPs 120 and 130, although it is understood that the number of SCPs connected to the NEM 345 may vary. The SNS 305 preferably comprises one or more computers (not shown) connected to the SMS 310 via modem communication lines, but can include any means for providing data to the SMS 310. Fig. 4 illustrates the software used in a preferred embodiment of the AIN 300. The software includes a modified 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 - 12 BAD ORIGINAL $ 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," 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 13 - r BAD ORIGINAL A service. The operator also uses the CP application to create any tables, databases, or definitions required for the execution cf the SMPs. The SMPs and additional data are stored in a database 552. Individual SMPs are created for each service and indicate the data that will be collected by the SNS 305 and sent tc the 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 (not 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 application 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 received 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 r "~ - 14 - BAD ORIGINAL drive, although it may be on any kind of storage medium that will allow for easy access by the SMS 310. The subscriber database 315 preferably includes an entry for each customer containing at least the customer's name, telephone number, and list cf subscribed services and related information and data concerning the subscribed services. The subscriber database may also include 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 1AESS switch, cr the Northern 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 Specification, document reference BD-SOAC-SPEC-002, but can be any interface device that will receive information 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 center ("OSC") 602, a service assurance group 604, one or more remote users 606, one or more remote operation support systems ("OSS") - 15 - BAD ORIGINAL J> 608, a user administration group ("UAG") 610, and a maintenance and operations console '"MOC") 612. The OSC 602, UAG 610, and MCC 612 are connected directly to the SMS 310 via LAN 335 The remote -sers 606 and tne remote OSSs 608 can connect to tne LAN from a remote location preferably via the internet using a transmission control protocol/internet protocol ("TCP/IP") . TCP/IP is αescribed in a series of technical reports called Internet Requests For Comments, which are available from the Network Information 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 oetween 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 tne 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 16 - BAD ORIGINAL A 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, therefore, be used by the SNS 305 to retrieve information relating to the current status of customer subscriptions, and then send updated subscription data to the SMS 310 based on that data. Alternatively, the interface could be used by the SNS 305 to retrieve current views of subscriptions when customers request such information or report troubles. Access to the SMS 310 by multiple 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 from the service 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 S0L*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 - 17 - BAD ORIGINAL j according to Abstract Syntax Notation One ("ASN.l") . ASN.l 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 Bellcore. The SMS 310 receives instructions from the SCE 325 regarding the processing of data received from the SNS 305 for transmittal to the NEM 345 for activating subscriptions in the SCPs 120 and 130. These instructions preferably comprise SMPs created with the modified SPACE system. These SMPs created by the SCE 325 instruct the SMS 310 on how to take information in one form and convert it 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.l. 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 - 18 - r - • BAD ORIGINAL ά geographic area serviced 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 geographical area in which the customer lives. In a preferred embodiment, the SNS 305 is connected to the switch interface system 355 to provide trigger information to the SSPs 160 and 170. Just 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 exists 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 r - 19 BAD ORIGINAL ά 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. 73 shows generally the operation of the SMS 310. Fig. 7C shows generally the operation of the NEM 335. Fig. 7D shows generally the operation of the switch interface system 355. As seen in Fig. 7A, the SNS 305 initially receives a request 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) . f BAD ORIGINAL J0 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 SPACE software as well as those available only in the modified 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 of 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 21 - BAD ORIGΓNAL & proper format with acceptable data values (step 914, . If the data is verified and valid, the SMS 310 then translates the collected data from its initial data format to a provisioning data format 'step 916) and saves the provisioning data as subscription data under the status of a pending view (step 917) . If in step 914, the data is either not verified or not valid, the SMS enters an error state 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 is 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) . If the NEM 345 does detect an error in step 928, the NEM 345 enters 22 " BAD ORIGINAL * * * an error state and ceases processing the request (step 929) . Cnce the SMS 310 receives the acknowledge from the NEM 345, the SMS 31C responds to the SNS 305 with an acknowledge signal (step 932) . The SMS 310 then stores the provisioning data in its subscriber database 315 under the status "active" (step 934) . The SNS 305, upon receiving the acknowledge signal, sends to the switch interface system 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 accessing 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 170, 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 processing 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 r BAD ORIGINAL d from the SSPs 160 and 170 to the SNS 305 (step 948) . SNS 305 later sends a signal to SMS 310 acknowledging that the AIN 300 has completed processing the service request (step 950) . In alternate embodiments, step 936 could be carried out directly by the SMS 310, avoiding the need for step 950. In th 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 relating 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 subscription 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 r - 24 - BAD ORIGINAL & to provisioning data, has passed all validations, and is awaiting posting to the NEM 345. The sending view 1008 contains a status cf "sending" which indicates that provisioning data corresponding to the data collected by the SNS 305 is currently being posted to the NEM 345. This view preferably exists only from the time the SMS 310 begins the posting process until the posting is completed, or until an error is 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 encountered during the posting process (exception view 1010) . 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 historical 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 processing of the - 25 - BAD ORIGINAL 4 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 step 1104, the SMS 310 saves the current data as subscription data m a pended view (step 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 r BAD ~ ORIGINAL 0 A* the subscription data in the present master view as a subscription data in the historic view (step 1122) and then saves the current data as subscription data in the master view (step 1123) . SMS 310 provides flexibility to manage a wide variety cf services through the mechanism of SMPs. The SMPs are created via the same or a similar graphical user interface used to create CPRs for the SCP 120 and 130. Individual SMPs can be tailored by operating personnel to sequence and control the execution cf 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 27 - BAD ORIGINAL the U.S. patent applications which have been incorporated by reference above. With data collected from the customer via the SNS 305, and the provisioning data required by the NEM 345 for the creation cf a CPR for the new service, the developer can create the SMP needed to coordinate the creation of the new service. The creation of an SMP will be illustrated by describing the processing of a request 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 received 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 28 BAD ORIGINAL & SMP (step 1202) , the OCS SMP determines where the transaction request came from (step 1204) . If the transaction request came from 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 cf request that is being made, i.e., request for new service, update of old service, cancel service, etc., based on information in the collected data (step 1212) . Then, depending en 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 the 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 SMS 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 29 BAD ORIGINAL ^ 1210) . As with the internal branch, m this embodiment tr.ere s only one function in the NEM branch, so step 1216 must choose the response branch (step 1228) . The response branch nandies a response to the provisioning request from the NEM 345 by nandi g over control to an SMP for accepting the response. That SMP analyzes the response, updates the subscription data in the subscriber database 315 m SMS 310, and sends an appropriate response back to SNS 305. It is understood that all of these secondary SMPs used m 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 invention, 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 with 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. r BAD ORIGINAL g Each of the following types of nodes are available for creating SMPs through a graphical user interface: program initiation, decision making, management of table data, gathering administrative data, interfacing with external systems, testing applications, managing applications, adding new services, invoking an SMP, and accessing a database. A "program initiation" function starts the SMP flowing. In 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 initiation 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 to 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 31 - BAD ORIGINAL A choices, or other information which is required by the NEM 345 for creating a CPR for a given service. During provisioning transactions, between the SMS 310 and the NEM 345, these tacles are accessed as part of a process to validate an order. Tables may also be used to store results of processing, such as error orders or pended orders . "Gathering administrative 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/IP 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 BAD ORIGINAL & coordinate multiple SMPs, templates, and convert collected data into provisioning data. "Adding new service" functions allows an operator to add a new service within an SMP. SMPs for new services will generally be able to use the existing programming tools to add new data bases, change or add editing rules, support new AIN service features or provide service management reports. In SPACE, the 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 indicating the SMP should be invoked, 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 - 33 - BAD ORIGINAL J> 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 internal 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, - 34 BAD ORIGINAL 4 multiple views, improved transaction processing, area-of-service network functioning, open access, and protocol support. Provisioning interface transactions for the interface between the SMS 310 and the NEM 345 are generated by SMPs which provide for multiple views cf a given request for service. Presently, NEM functions do not keep multiple views of a given request for 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 include 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 35 BAD ORIGINAL Jfr operator to meet a customer's individual needs. For example, an AIN service that must provision a digitized recording for a customer may use a play application, "Download Speech, " to send instructions to an IP provisioning system to activate the customized announcement. Another example of the use of the play application primitive s for customer self-provisioning cf 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 tne cnange 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 distribution 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 36 - BAD ORIGINAL tf 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 from their service customers . The operators of the SMS 310 have the ability to prohibit third party viewing of screens used for the maintenance and 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 verification of 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 field 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. BAD ORIGINAL Third party providers may have access to standard reports which would list their customers and the services to which they subscribe. Ad hoc reporting may be available under the guidance cf the operator to help ensure proper processing and performance levels cf the SMS 310 are being maintained for ail users. Report routing strategies depend upon the needs of the operator and the tmrd 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 development 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 38 BAD ORIGINAL intelligent workstations equipped with 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 TCP/IP, Token-Ring LAN connections can access the SMS 310 system. These users may be local to the LAN connected to the SMS 310 or may be remotely located where connectivity to SMS 310 is accomplished v a network routers 614. 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 workstation users simultaneously connected to the SMS 310. The SMS 310 workstation provides a graphical user interface where system capabilities 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, permitting 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. BAD ORIGINAL SMS 310 provides a dialog box which exists across the cccccm cf the screen to provide textual feedback on actions, such as syntactical error notifications or the status of remote operations. The user has on-line documentation readily available 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 fcr an incomplete request for service. This capability enables the user to suspend the current entering cf the request for service until a later time. The request will 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 processing statistics. Operating statistics associated 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 of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made, and - 40 - BAD ORIGINAL Λ equivalents 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. The present invention, however, can be used for system management in other telecommunications networks such as cable television networks, computer networks, wireless networks, broadband networks, cr the like. In addition, many modifications may be made to adapt a particular element, technique or implementation to the teachings of the present invention without departing from the central scope of the invention. Therefore, it is intended that this invention not be limited to the particular embodiments and methods disclosed herein, but that the invention include all embodiments falling with the scope of the appended claims. BAD ORIGINAL d

Claims: CLAIMS 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, cf: receiving a service request from the customer, tne 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 switcn 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. BAD ORIGINAL ^ 5. A method according to claim 1, further comprising the step cf 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: BAD ORIGINAL 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. r BAD ORIGINAL to 14. An intelligent network according to claim 9, wherein the network element is a service control point for processing telecommunication calls through telecommunication switches. - 45 - BAD ORIGINAL A

Inventors: FURKA JAMES FRANCIS, FURKA, JAMES, FRANCIS
Applicants: BELL COMMUNICATIONS RES, BELL COMMUNICATIONS RESEARCH, INC.
Application year: 1996
Main classification: G06F13
IPC codes: G06F13, H04M3, H04Q3