CA2190457A1 - Customized telecommunication service - Google Patents

Abstract

A customized telecommunication service comprising a service related component, referred to as a service shell, and a number of customization parts open to customization by a service provider. The service shell is designed by a system vendor with due consideration taken to the fact that the service must not interfere in a non desired way with other existing services. The services shell comprises customization points to which the customization parts are added. Each customization point comprises an individual customization interface defining the scope of actions open to customization in the service shell. The service provider selects, among said actions, those which will build the desired function of the customization part.

Description

21 ~0457 WO 9~ 4980 P~_l/DI ~ 14 -- CU~ .. lLtU TELECOMMUNICATION SERVICE
~r~r.R~TI~D OF THE INVENTION
The present invention relates generally to services in a tele-communication system, and more specifically to the provision of CU~ t ; zt-fl telephone services .
.
5 A modern telt~t ~n~cation system provides a number of subscriber services, automatically invoked in specific situations. Typical examples are difierent types of rerQuting services. Different subscribers have different needs which implies variants of the service. Thus, there may be conditional rerouting service like lO "Call forward on busy'', "Call forward on no answer" as well as unconditional rerouting used to reroute incoming calls to a set of answer locations. Those services in their turn may exist in variants, where the calling subscriber is forwarded to different numbers based on his country code or directory number, date or 15 time of day, or on a code entered by the called subscriber etc.
The result is a greater variety of similar but different services .
The service provider wants to offer services that are tailored after the needs and wishes of his ~;u~t :., the subscribers. He 20 also wants to provide new and modified services with short deliv-ery times. This is most easily obtained when the services are CU~ t ~ 7e~1 as close as Foeei hl~ to the end customer.
PRIOR ART ~
WO 92/11724 describes how a new service can be implemented on a 25 network wide basis without modifying the tt-lt~rht nt~ network switching system software. Service primitives are ass ' let~ into telephone services using the graphic t-~r;~hi 1 ities of a computer work station . A complete tt~l t~rht~nt~ service is represented by a graph consisting of nodes and edges, the nodes representing ser-30 vice primitives executable by service implementing ~ ~ ents andthe edges representing the order of execution of said primitives.
With this lc~plese~ tion the new ttt~lPrht nt~ service is displayed as a "tree" of nodes. The tree display can be manipulated graph-ically to create and alter the logic of the service.

2 1 9Q457 WO 95/34980 ~ ~ l /4 A node library comprises all previously specified nodes (primi-tives ) . A service creator selects from said library a subset of nodes ( primitives ) that are interconnected to form a complete service logic. The service 1ogic thus created can by used as a S service template. The service creator will use the service tem-.
plate to indiv; A~l~l i 7e ths service to a particular user by en-tering individual subscriber A~r~nA~nt data.
There is no requirement that a customer created serYice must not interact or interfere with other existing services. The lack of 10 such reSIuirement may imply that a customer created service inter-acts in a non desired manner with other services causing unpre-dictable behavior of the telephone system.
W0 92~11603 describes a method and apparatus for creating custom-ized call processing information (CCPI) records providing custom-15 ized t~l ~phnn~ services for individual subscribers to a network .A graphical method is used to design the cus L i 7ed service. A
cu~ A services application is used to create each customer's service or service program . Each customer ' s se~vice or service program is stored as a record or as a series of records in a data 20 base Each such record comprises customized call processing in-formation (CCPI). The CU~t i7c-fl services application 1nrllldec a ~luyl ; ns interface which permits an operator to use the cus-tomized services application to create various user lnterfaces to obtain information in a manner which is relatively easy to use.
25 The customer or operator inserts only a small amount of informa-tion thus avoiding the need of a ~_ , uLt:l plOyl, ~n~ to write program sequences to define the service or to make changes to the program sequences tD modify the service.
The known graphical methods are used in order to create a com-30 plete service. It is fllff;r~llt for-the service software ~ecl~n~r to foresee all the ~:u~t i7~tion needs that a future service pro-vider may have, i.e., which type of p~i, Lt!15 are needed for ~,u~ i7ation of the service. When new yal L~::rs are needed the service software has to be r~APRi ~n~d since the pal Lt~ are 35 tightly coupled to the ~o~Lwc,l~. The redesign has to be ordered , . .. . , . .. . ~

V~/O 95/34980 . F~ ~4 from the service software vendor thus delaying the interval be-tween service redesign and service offering.
The ranges of the available parameters are limited to values de-fined in the service software. For example a rerouting service 5 may include a set of 10 answer locations as pal - L~ . Introduc-tion of an 11th answer location implies a redesign of the service sof tware .
It is tl~ffirlllt ior the service software designer to describe howto modify a service that has a number of parameters with complex 10 interdependencies. Consequently, it is also difficult to foresee the result of a new combination of parameter values for the ser-vices provider when modifying a servlce.
A service is implemented as a sof tware module. For each custom-ized variant of the service there is also a variant of the soft-15 ware modulè. To facilitate the introduction of only slightlydifferent variants of a service, the software modules include data or parameters that control the behavior of the service. A
few examples of such parameters are a set of answer locations, a set of times per day when answer locations are to be switched, a 20 set of originating area codes to be used when A~c1~lin~ the answer location for the call. The parameters may be available for change by the serYice provider. In this way the service provider gets a means to adapt services to indlYidual wishes to a certain extent.
U.S. Patent No. 4,747,127 relates to a customer proyl hle 25 real-time system allowing the customer to design a new service and to modify existing ones from his customer unit. The customer unit comprises a computer, a t~ rhnnP set and a t~rm; nAl, The logic that ; ,1 ~ ts the customer created service will execute in the customer's computer. Further, the ~:u:,i created 30 service is confined to the customer unit and cannot be used by other parties.
There is no reSluirement that a customer created service must not interact or in~elrelt: with other exlsting services. The lack of .

2t ~Q~5~
Woss/34980 r~l /4 such requirement may imply that a customer created service inter-~cts in a non ciesire~ manner with other services causin~ unpre-dictable behavior of the tr-l r~rhr nr~ system.
In this U.S. patent 4, 7~7,127 the customer needs to be aware of 5 the state diagrsm of a call in which the new service is invoked and of the system signals by which the new service is invoked.
This is a drawback since such state diagrams tend to be highly complicated requiring a high degree of expertise knoToledge of the customer. Further, the customer must have thorough knowledge of lO the system signal àlso re~uiring a high degree of expertise knowledge of the customer. Should the customer not have the re~uired knowledge there is a rJreat risk that the services he designs causes malfunction of his customer unit and of the complete tr~l r c nications system.
DISCLOSURE (~F THE INVENTION
It is therefore an ob~ect to provide a service that comprises a service related part, referred to as a service shell, and a num-ber of service customization parts open to ~,u:, L ; 7Ation by a service provider . The service shell is ~r~cl ~nr cl by a system 20 vendor, an organization that has all the knowledge and competence re~uired to design a servlce so it does not interfere with the proper operation of the tP1~ ;r~tion system within which the service is used. Preferably the system vendor designs the service shell so it will not give rise to unwanted service interaction.
25 In particular the service shell comprises customization points to which the customization parts are added. In accordance with the invention the system vendor provides each customization point with an individual customization interface 9rfin;nJ the scope of actions open to customization in the service shell.= The scope of 30 actions open to customization is so def ined by the system vendor that irrespective of how the individual actions are r inrrl, the resulting customization part cannot interfere with the proper operation of the trlr._ n;r~Ation system wherein the service is used. The service provider selects, among said actions, those 35 which will build the desired function of the customization part.
.. ..... . .. .. , _ , , _, , , 2 ~ ~0~57 Wo 95134980 P~ ~ /4 In accordance with the present invention a complete cu~t i7e~1 service is divided into two parts, a semi-manufactured basic part ~nd a customer logic part The semi-manufactured basic part is a services related component which in the following will be refer-5 red to as a service shell. The customer logic part comprisescustomer logic that is t~l ~1 Ore~ to the individual need of the customer and that comprises a subset of a predet~rm1 nfml set of service independent functions referred to as primitives in the f ollowing .
10 An important aspect o~ the present invention is that the service shell comprises basic service logic and one or more customization interf aces which are used to def ine the customer logic part . The customization interfaces are well defined by the system vendor or the organization providing the service shell so as not to cause 15 non-desired interdependencles, also referred to as interaction or interference, between different services which are active at the same time. The customization interfaces are in this sense "nar-row" since the parameters open to customization are selected by the system vendor ~ Ul ~ - which have an overall view of the 20 telecom services and their behaviors - for presentation to the service provider. Once selected by the service provider they cannot be altered by the customers. The system vendor, however, may later on add new or remove old customization points. A cus-tomization point resides in the service shell. From a customizat-25 ion point the ~:u, L 1 7~tion logic is called for execution. Thecustomization interfaces differ from ~;u~ '7ation point to customization point as a general rule. In the preferred embodi-ment of the invention the customization interfaces are presented to the service provider by a graphic editor used by the service 30 provider as a tool for generating the code of the customer logic.
Accordingly, the customization ~r~h; 1 i ties are entirely controlled by the customization interfaces.
DESCRIPTION OF THE DRAWINGS
.

21 9~1~57 WO 95/34980 r~ /4 6 `
Figure 1 is partly a block diagram partly a f low diagram showing the execution of a ~:4~ 7efl service in Rrrrrtl~nrf~ with the present invention, Figure 2 is 8 diagram showing the .:u:, l 1 7erl service of Figure 1, Figure 3 is a diagram $howing the service customization environment and the actors involved in service customization, Figure 4 is a diagram illustrating the service shell in Figure 1, Figure 5 is a diagram showing a functional view of a generic customization interface, Figure 6 is a diagram similar to Figure 4 showing an example of a customization interface description, Figure 7 is a diagram showing the ~Llu~,LuL~ of a primitive le~Le:s~-~tative for the primitives used in the set of primitives rlPf~n;n~ the customization interfaces in ~rrnrtl~nrP with the invention, Figure 8 is a diagram showing a primitive called "check-list", Figure 9 is plane view of a screen as shown on a monitor that forms part of a graphic editor used by a customer for ~9P.s{ gni n~ the customer logic, in accordance with the invention, Figure 10 is a diagram illustrating how primitives, shown on the graphic editor, are bound to a .;u:, t in-terf ace so as to f orm nodes that interact with the service shell, 2 1 9 fJ457 W0 95l34980 p~ 4 Figure ll illustrates each of the nodes of ~igure 9, in particular its respective primitive, igure 12 is a diagram showing the service shell, customer logic and the two kinds of interfaces therebetween, Figure 13 is partly a block diagram partly a flow diagram showing the execution o a service shell in runti-me, igure 14 is a block diagram showing an ~-nrl ~ - tatlon of a customization interface as a managed object in a tele i cation operation and support system.
~ESCRIPTION OF PREFERRED EMBODIMENTS ~ ~
In Figure 1 there is shown a service shell l comprising a number of procQsses l, 3, 4, 5 that are running one after the other in the order indicated by a time axis 6. Processes may also be run-15 ning concurrently but for the sake of clarity this has not beenillustrated. The service shell l comprises customization points 7, 8 that are encountered during execution of the service shell.
Cu:. t 1 7~tion points provide customization ''Ar~h; 1 i ties of the service shell and are sper;f;r~lly ~9~Ci3ne~ to support customiza-20 tion. In the example shown the service shell comprises two cus-tomization points but service shells having more or even less are within the scope of the present invention. A service shell must at least have one customization point. Each customization point comprises two types of interfaces: (1 ) Cu~i ~7~tlon interface 25 and ( 2 ) runtime interface. These interfaces are completely de-fined when the service shell is defined. When the service shell is executed and a customization point is reached thè ~iu:,L 7~t-ion point calls a customer logic interpreter 9 that controls the execution of customer logic lO sp~--;fi-~lly ~Si~n~i, by the 30 ~:u~ r, for customization point 7. After execution of the customer logic lO a result p~ l value is achieved, this result value being returned, by the .u:,~ r logic intt~ 9, to the service shell toyc:tllel with execution control. Execution proceeds of the service shell and when customization point 8 is _ _ _ . , _ _ _ _ _ _ _ _ _ _ _ _ _ . _ . . ..

WO95/34980 1 ~ 7~ l4 reached the same procedure is repeated at the customer logic in~el~!l~t~r 9, but now with a different customer logic 11.
Customer logic 11 is generally different from customer logic 10 but may also be the same.
A customization point presents a functional and user friendly customization view of the service shell and def ines in detail parameters and variables in ~he service shell 1 that are avail-able for customer logic. Available parameters and variables are specified with their types and allowed operations such as re2d, write as will be P--r`l ~i n~fl below .
In Figure 2 a customized service 12 is shown to comprise the service shell 1, the customer logic 10, 11 as well as other service implementation parts 13.
The service shell 1 is a semi-manufactured service to which customer logic is added. Variants of the service are created by adding and ~ ' ~nln~ different customer logic to one and the same service shell. A customer A may for example have customer logic 10 at customization point 7 while another customer E may have a dif~erent customer logic at customization point 7. Customer A
will accordingly have one CIIH ~ i 7e~ service 12 while customer B
will have a different customized service.
Figure 3 is showing the actors involved in the service customiza-tion process to be described below. There is a system vendor 14, a service provider 15, a network operator 16 and a service sub-scribers 17, 18. The system vendor 14 is the organization that develops the two components of the service cu7L ~7~tjon concept in accordance with the invention, i . e. the service shells and the primitives referred to in the introductory portion of the spe-cific2tion. The system vendor 14 also develops the network infra~Lu.:Lul~ to execute these ~ , ^ntS and the environment for service customization, i.e. a graphical editor in the pre-ferred embodiment of the invention. The network u~ LoL 16 is the organization responsible for operating the network, for example a GSM network operator. The network operator 16 has the ultimate rPcpnnc~ hi 1 1 ty that the telecom network, rep-esented by 2 1 9~457 ~IVO 95134980 r~ L ~ 4 reQrence numeral 19 in Figure 3, operates correctly. The network operator 16 must be sure that none of the customized services causes malfunction in the network. The service provider 15 is the organization that is r~cp~n~1 hl f' for the providing services to 5 the service subscribers 17, 18. One important role for the service provider is to customize services to the subscribers.
That is, the serviCQ provider 15 must have a service customiza-tion environment, such as a tool for generating customer losic, requisite service shells and primitives. However, the service 10 provider lS may have limited knowledge of the telecom network 19.
The service provider 15 may also be the network operator 16 or may be a third party. A possible scQnario is to have several ~ nf~r~n~nt service providers that provide cu,, i i 7~ services running in one the same network. Each of the service subscribers 17, 18 is an entity that subscribes to the cu~,i i7C.t1 service. A
service subscriber may be a company or an individual end user. A
service subscriber may need to f ine tune the customization to adj ust the service to his own particular needs . He does so by instructing the service provider to compose customer logic that 20 fulfill his needs. Provided that the service is rlpR~nf~d for customer fine tuning the subscriber can fine tune the customer logic .
In Figure 4 the general design of a service shell is shown. By way of example a service shell may relate to black-list-service, 25 call-back-service, conference-~ervice, diversion-service, hot-number-service, free-on-second-line-service, intrusion-service, parking-service, pick-up-service and many other ~ . The service shell comprises basic logic, 21, 22, 23 for the service and the reSIuisite ~us~ ~7Ation points 24, 25. A service shell 30 provides a robust platform for customization and does also take care of any undesirable interaction with other services in the network. The service provider creates a complete service by adding the nF.~-~CSA~y customer logic to the customization points of the service shell. The service shell is developed by a system 35 vendor using his regular development process and dev~ t tools. The service shell is delivered to the network o~eLel~ol and is loaded into the network. Each customization point is refer-enced, for example by a name such as CU-INTERFACE_NAME. Other . . . ~

21 90~7 W0 95/34980 Y~ 4 references than names may be used but it is preferred to use a name that descrlbes the action to be taken at the customizution point. In Figure 2 two customization points are shown but of course more than two can be present. The service shall must have 5 at least one customization point . In Figure 4 the servi ~-P chPl 1 20 comprises three blocks 21, 22, 23 of basic logic but this number is of course different for different services. It is the customization points that are specifically ~9efi;~n~ to support customization of the service.
10 In Figure 5 the general structure of a customization point is shown, for example customization point 24 of Figure 4. A custom-ization polnt has two types of interfaces: ~1) Customization in-terface and (2) runtime interface. These interfaces are defined when the service shell is ~9Pc1~nPrl In Figure 5 the customization 15 point is shown from a functional view and in this view only the customization interface is shown. The customization interface provides the basis for the creation of customer logic. Each cus-tomization interface comprises an number of p~ 26, 27, 28. Each parameter is referenced by a name CVARL_NAME, CVAR2_NA-20 ME...CVARn_NAME. The paL L~::L~D of a customization interface areof two types, input pal - ~ers and result parameters. The input parameters are input to the customer logic. The input parameters are made visible to customization and can not be changed during customization. The result pal L~ls are the parameters that must 25 be defined by the customer logic.
The following information must be defined for each customization interface parameter:
Name Each input-result parameter has a name Data type There is a set of common data types and each parameter must have a data type that belongs to the data type set in question. This prP-iPf 1 nP~ set of data types provides a common basis that allows different primitives to operate on input/output p~ Integer ', ' string ', ' subscriber number' are, 1PR of common data types. Any restrictions, such as max value, min value, range, 2 1 90~57 W0 95~34980 r~ ,h 14 restricted value, to the parameter must also be defined. This information is used by the graphical editor to assure that there is a correct type matching when a primitive ~ s5~c a parameter.
Parameter ~:a~y~ly Some of the parameters in a customization point may only be read but may not be changed, i . e . a read-only parameter. Other paL t~L~ may have a valid value that may be changed, i . e . a read/write paramete~ . Other p~L t~l ~ may not have a valid value and a result value must be provided, i.e. a write-only parameter.
Relational rules Some of the parameters may be optimal, others are mandatory. There may be relationships between parameters that must be clearly def ined . As an example a parameter CVARl must be greater than a paL t~ :L CVAR2 .
Descriptions To each paL -teL- belongs a descrlption describing the parameter so as to support and facilitate the creation of customer logic.
All of the above information is visible to the service provider at the graphical editor to be described below. The visible lnfor-mation is indicated by solid line blocks . The .:u~ ~ ' 7Ation in-25 terface also comprises invisible information indicated by dashedline blocks. In particular the address of each pal ~r in the individual customization interface is hidden to the person c1sn1ng the customer logic. Said addresses refer to positions in the call record ( the record that comprises A-number, B-number, 30 category etc. ) of the individual call. The hidden addressing information as will be described later on and is used when the graphical editor generates the data that is loaded into the telecom network 19.

2 t ~
WO9~/34980 I~ 4 The system vendor wants to keep control over the use of different primitives for different ~:ustomization points. In doing so the system vendor protects the telecom system r~ h11 i ty. It shall not be possible for a customer 1ogic designer to use primitives 5 that may interfere with the proper operation of the telecom sys-tem. To this end each customization interface also comprises a visible primitive type indicator 29 that describes the type of primitives the system vendor allows for the customization point.
A primitive is a basic Dperation that is used to build the 10 ~ u~ logic. The use oi primitlve type indicators also makes it possible for the system vendor to add, later on, new primi-tlves wlthout redefining the customization.
In Figure 6 there is shown a service shell similar to that shown in Figure 1 comprising a number of processes 31-34 and a custom-15 ization point 35. The service shell reLates to the service "Callforwarding at no reply". The service shell comprises the con-ventional call forwarding proces-ses "no reply", process 31, "authorize call forward" process 32, "analyze", process 33 and "2uthorize call set up", process 34. The service shell also 20 comprises the customization point 35 'fetch C-number"_ This process 35 must define the actual directory number for the answering position, i.e. the C-number. The cc,LL~ ...ding cus-tomization interface "fetch C-number" deflnes the lnformatlon whlch ls vlslble for customization, i.e. the lnput parameters A-25 number, country code, area code and subscriber number. There isalso a parameter called "call prlorlty". The result parameter, C-number, will be returned from the customer logic il~Lt:L~L~:t~:L 9 to the service shell as is indicated by the arrow 36. Each of the lnput and result pal ~La are deflned by thelr name data type 30 and other variables. The customization interface "fetch C-number"
comprises input and result paL t.~ ,. The customization inter-face merely describes the input and result paL teL,i. The cus-tomization interface plays no role during execution.
Primltlves are generlc ~ ts that are used to ~:u:,L ~7e many 35 dlfferent service shells. One and the same primitive can there-fore be used by many service shells. Primitives as well as service shells reside in the telecom network. In Figure 7 the 2 1 9~457 Wo 95/34980 1 ~ll~ . /4 general layout of a primitive 37 is shown. Each primitive has a name and comprises a set of if~put data, a set o~ result data, branching values and one or more outlets to be used for bran-ching. The outlets are~ links which are used to connect one primitive to another in the customer logic. As appears ~rom Figure 7 each primitive comprises a number of paL -. t~Ls 38, 39, 40, each such parameter being referred to as a parameter variable having a name PVARl_name, PVAR2_name . . . PVARn_name ( P referring to Erimitive). Each such parameter variable indicates whether the parameter represents input data or result data. Further to the parameters a primitive comprises code, represented by block 41, said code comprislng the functions and operations performed by the primitive. The parameters represent variables used by the functions in the code block. The type of each parameter must be stated, i . e . whether it refers to an integer, a string or whatever kind of data or data structure the parameter takes.
For each primitive there is defined a primitive interface that comprises a set of input parameters and a set of result parame-ters as viewed from within the primltive. Each ,input and result pal t~l of a primitive comprises the following attributes:
identity, data type and input/result category.
Primitives are rl~c:qified into two classes tler~ntlins on the type of resources that they can operate on, namely 1 ) a self contained resource or 2 ) shared resourc~as. Primitives of the type that operate on self-contained resources are so ~ c~n~ that they can only modify their own L~soul-es and result pal - Lt:l:.. Primitives of the self contained type may be used in the customer logic connected to any customization point without any risk of unde-sirable interaction. Primitives of the type shared resources are so designed that they are allowed to operate on and modify the status of lt:SOUl~ S that are shared by many services, such as for example a switching center. A primitive of the shared resources type can only be used at a customization point that is specifi-cally ~ c~nF~fl for it. In other words the customization interfac-es of a ~:u,, L ' 7~tion point in which a primitive of the common Lt:SOUl~:~S type is used may~restrict the use of primitives that manipulate shared lt:suulces.

2 1 ~ 57 WO95/34980 r~ '.~/4 In Figure 8 an example of a primitive called "check list" is shown. The input parameter is of the "string" type and the primitive comprises in its code part 41 a list of strings. The function of the primitive is to compare the input string with the list of strings. If there is ~ match a branching vaLue "match" is selected. If there is no match between the input string and the strings in the list the branching value "no match" is selected.
The same primitive "check list" may be used in a customer logic comprising B-numbers and in other ~:u:,t -r logic with "names", provided both are defined as strings. I.e. one and the same primitive may have màny functional= roles provided the pr~ fin~l data types of the parameters are consistent with each other.
Figure 9 is a view of the screen of a ~raphical user interface forming part of a customer logic generating tool. This tool generates data that represents the customer logic. To the right of the screen there is shown a number of icons Pl-P8, each icon representing an individual primitive. The service provider wish-ing to create customer logic starts by sketching the desired customer logic with regard to the poscihi 1 itie$ of iered by the existing primitives Pl-P8~ The procedure to create the customer logic is rather straight forward At first the desired service shell is selected and its customization points are retrieved.
This selectiDn takes place by t`11 rki n~ on an icon, not shown, representing the customization interface. A window 41 will pop up showing the parameters CVAR1_, CVAR2_ ... CVAR3_ that are avail-able for customization. Next the prlmitive that fulfills the desired function is selected from the palette of icons Pl-P8. The operator selects the icon in question by t~l irkin~ on it with a pointer device such as a mouse, a pencil or the like. I~hen an icon has been selected a second window 42 pops up, said second window showing the parameters of the primitives. These parameters PVARl, PVAR2 ... PVARn are shown within the window 42 on the screen. Next the operator binds one of said ~a~ 8ers to a para-meter available in the customization interface. Such binding takes place by using conventional point-and-drag-procedure, i.e.
by pointing ~t a parameter ( for example PVARl_) with the pointing device and dragging the pointing device to the corrl~cp-~nrl~n~
CVARn_ parameter ( for example CVAR2 ) in the pop up window 41.
.. .. . . . .... . . _ _ _ _ _ _ _ _ _ _ _ _ _ _ W0 9~l34980 ~ 4 This pointing and dragging has been illustrated by arrow 43. If more parameters of the selected primitive are to be bound to the customization interface a similar point and drag procedure is repeated. In Figure 9 this is represented by arrow 44. Next the 5 two last steps are repeated for each new primitive selected among the icons Pl-P8 and by providing the n~ c.si~lry bindings between the PVAR and CVAR parameters.
The binding of a primitive parameter PVARn to customization interface parameter CVARn_ means that the CVARn_-value, entered 10 by the customer logic- designer in the pop up window 41, will be taken by the primitive. The primitive will later on, when the customization logic is executed, perform its operation using the entered CVARn_-value.
When the customer logic designer points on the border of any of the windows 41, 42 a third window 60 opens and displays informa-tion that describes ~he performance and meaning of the customiza-tion interface and its variables. In other words this provides on-line support information to the customer logic designer.
When a primitive is selected a node represented by a ring 45 will 20 appear on the screen. If the primitive for example was "check list" as shown in Figure 8 the node 45 shown on the screen will also have the three straight lines that represent an inlet and two outlets. The outlets are named "match" and "no match". Next the two last steps are repeated for each new primitive selected 25 among the icons Pl-P8 and by providing the n~ ssi~lry hin~lin~c between the PVAR and CVAR parameters. A new node 46, shown in dashed lines, appears on the screen. The customer logic designer links the appropriate outlet of node 45 to the inlet of node 46.
In this manner a logical tree is successively built, said logical 30 tree showing the customer logic in a user friendly and easy to conceive way.
In Figure 10 the logical tree of one example of a customer logic for the service "call forwarding at no reply" shown in Figure 6 is indicated. When the service shell reaches a customization 35 point it hands over further execution of the service to the ..... .. _ . _ _ _ _ _ _ _ _ _ . . . .

-2 1 ~0~57 WO95/34980 1 ~~ ~/4 customer logic that starts by testing the calling party ' s number against the node "calling number list". If the calling party has the service active, result parameter `'true" is qr~l ~rt~-l while in the opposite case value Cl of the result parameter Cl is returned 5 to the service shell. I~ext the customer logic tests the date and time of the call from the calling party and if it is business hours and correct date a diversion to a certain t~ rh- n~ number, represented by value C3 of result parameter C3, is sent to the 6ervice shell. If the calls fal 1 s outside the date an~ time 10 tested by the date and time node then the call is diverted to another number, reprèsented by parameter C2, different from that represented by parameter C3 In ~igure 10 the hi n~l~ n~q between the customization interface variables CVAR and the variables PVAR
of the different primitives are shown in solid black lines labels 15 A-number, Bl, C2 and C3.
Figure 11 is a view showing the same logical tree as that in Figure lO. This Figure has been included to show that behind each of the nodes there is a primitive. Different nodes may use the same primitives.
20 Figure 12 illustrates the relation between .:u~ l7~tion inter-faces, customer logic and primitive interfaces. The service shell l has a customization interface 47. This interface comprises the parameters discussed in Figure 6, that is the parameters and their data types, value range, categories and relational rules 25 and allowed primitive types. The ~:u- t logic ll comprises at each node thereof a primitive interface 48 that matches the applicable part of the ~,u:~ i7~tion interface 47. This concerns the primitive type and everything that the customization inter-face 47 states about the parameters -(data types etc. ) to which 30 the node is connected. Part 49 of customer logic 11 is not an in-terface but represents the fulfillment of the relational rules that the customization interface 47 states about mandatory result p2Y t~rs and result p~l ~ L~:, interd~r~ l es. This type of rules refer to the customer logic ll as a whole and not to indi-35 vidual nodes therein.

W095l34980 2 1 9 0 4 5 7 P~ ,; ,4 In the previous Figures the service 5hell and the customer logichave been shown from a functional point of view. In Figure 13 they are shown in a run time view. The service shell 1 is de-signed using a tool 50 for editing and generating the code of the 5 service shell. The service shell is then loaded into the network.
The service shell may either be executed in local exchanges dis-tributed in the t~ .n~cation network or in centrally located service central points ( SCP: s ) . Upon execution of the service shell it interacts with the customer logic interpreter 9. The 10 intelyL~Ler 9 comprises logic 51 that is general to all ~:u:jL
logic 10, 11. After execution of the processes 31, 32 in the service shell 1 the customization point 35 is reached. At the customization point a call is made to the customer logic. This call is represented by symbol 52 "fetch C_no". This call repre-15 sents a runtime interface to the customer loglc. In response tothe call customer logic data is passed to the customization logic interpreter 9_ The passing of this data is represented by arrow 53. As d~ qc~qqed above the data sent to the interpreter 9 does not contain any code. It comprises customization interface data 20 of the type shown in Figure 6 which, as describ,ed in connection with Figures 9-11, contains information sufficient for the cus-tomization logic intc:LyLt:t~l 9 to reconstruct therefrom the particular customer logic . The ~:u~ L ~ logic is executed in the interpreter 9 and the result parameter ls returned to the same 25 customization point 35 from where the call was made. The result data tr~n~miqqinn back to the service shell is represented by arrow 54. The result data is then used by the service shell. Upon reception of the result data the service shell will take over control of the execution and use this result data in the next 30 operation 33. The reception of the result data in the service shell is indicated at symbol 55. Symbol 55 therefore also repre-sents a runtime interface of the service shell. The result data comprises just data and no code. In the ~;u~t '7iltion logic interpreter 9 the code of the primitives Pl-Pn is stored. Each 35 primitive is stored on its own memory location and is accessed by a reference to the address in the memory where it is stored. It is these addresses that are passed in the data passing 53 as primitives to execute, i.e. not the code of the primitives are ,, , .. , ., .. .. _ ,, .. . ,, _ , , . . _ ... . .,,, .. , ., .. . . ,,,, . __ ~ I 'tU4~/
WO 95/34980 18 P~I,~l ~4 passed but pointers to addresses 1n the memory location where the primitive are stored In Figure 14 a pre~erred implementation of the environment in which the customized telecommunication service ln accordance with 5 the invention is used. A software tool 56 for composing customer logic, i.e. soft,ware used by the customer logic editor of Figure 9, as well as a telecom network management system 57 form part of an operation support system ( OSS~ 58 which manages telecom net-work elements 59 such as local exchanges, access 6witches, 10 wherein customer log`ic 11 is defined as a managed object MO in accordance with the TMN concept. In this way custo~ner logic defined as managed objects can be operated upon as any other managed object in the network using a standard Q3 interface. Also standard security management functions can be used to control the 15 customization process The network operator will therefore have complete control over the custQmization interfaces and primitives (defined as MO:s) that are ~rff~cR~hl~ by each individual service provider. A service provider 15 having the graphical editor and the software tools 56 wiL1 be able to load his customization 20 logic into the network element 59 ln the corrF~spnnfl;n~ MO. Since the customer logic only contains data it can be loaded in the telecom network and new customized servi~es c~n be introduced without upgrading the existing software . The cu~ L ~ 7ed service is provisioned to an subscriber like any other ~service using 25 standard service management functions. ~ "service ob~ect" for the subscriber is created and the requisite attributes are defined.
One attribute that must be defined is "customization logic"-attribute The corresponding customization logic is i:lRSi 3nf~d to the "service object".
30 A service subscriber may fine tune the cu t i 7C~r9 service to fulfill his/her own needs. FQr= example each subscriber that uses the cu~ i7e~1 serv1ce shown in E;igure 10 can define his/her own values in the "calling number list", "date and time" and actual answering numbers Cl, C2~ C3. This data i5 called subscriber 35 data.

W095~34980 9~ 5 7 P~"~ 4 The subscriber terminal may be either a PC based terminal or any other standard terminal If the subscriber has access to a PC
connected to the network, for example by using ISDN, terminal software provides the npcpqc~ry user interface such as menus, 5 graphs and, ~c~tion with the network. An application protocol between the network and the tPrm1n~1 is needed since the tPrmin~1 must fetch the data from the network, presented to the subscriber in an user friendly way, and send the modified data back to the network. This applicatLon protocol is specific to the 10 system vendor.
If the subscriber has assess to a standard ~Prmin~l, the network may provide a voice prompting menu to help the subscriber. The user communicates wlth the network by dialling the nP~-Pcc~ry procedures .
The information available in the MO:s is used to assure that customization logic fulfills the customization interface. I.e.
the software tools 56 provides an automatic check that the customization logic complies with the interfaceS involved. While 20 being edited the customization logic is keDt in the software tools 5 6 .

Claims (19)

1. Customized telecommunication service characterized in that the service (12) comprises a service related part, referred to as a service shell (1) which is supplied by a system vendor, and at least one service customization part (10, 11) that can be supplied by a service provider (15), said service shell comp-rising at least one customization point (7, 8) at which the customization part is added to the service shell (1), said customization point: (i) comprising an individual customization interface, exclusively defined by said system vendor, (ii) defining the scope of the actions possible for said customization part by means of a first set of call associated parameters and a second set of primitive functions (P1-P8), referred to as pri-mitives, said parameters and primitives being the only parameters and primitives available at said customization point, said service customization part (10, 11) comprising customer logic (i) generated from a subset of said first set of primitives comprised in said customization interface and (ii) acting on a subset of said second set of parameters defined by said customization interface, the customer logic being communicated in the form of data only to an execution environment in which the service shell (1) and its said at least one customization part is executed.

2. Customized telecommunication service in accordance with claim 1 characterized in that the primitives are generic to different telecommunications services.

3. Customized telecommunication service in accordance with claim 2 characterized in that the parameters comprise a set of input parameters and a set of result parameters as viewed from the customer logic.

4. Customized telecommunication service in accordance with claim 3 characterized in that each input and result parameter comprises the following attributes: identity, data type, input/output ca-tegory and, if applicable, relational rules.

5. Customized telecommunication service in accordance with claim 4 characterized in that each customization interface further comprises address information relating to each of the parameters (26, 27, 28), the address information being protected and not available for use by the customer logic designer.

6. Customized telecommunication service in accordance with claim 5 characterized in that said customization point further com-prises a run time interface (52, 55) connecting the customization logic to the service shell in run-time.

7. Customized telecommunication service in accordance with claim 6 characterized in that each customization point comprises a first part visible through a graphical user interface (Fig.9) of a tool (56) used for building the customer logic and a second part non-visible through the graphical user interface, the visi-ble part comprising the parameters and the invisible part comprising said address information.

8. Customized telecommunication service in accordance with claim 7 characterized in that the customization logic generated by said tool (56) comprises just data.

9. Customized telecommunication service in accordance with claim 8 characterized in that said data representing the customization logic are stored in the telecom network allowing for the intro-duction of new customized services without upgrading existing software residing in the network.

10. Customized telecommunication service in accordance with claim 9 characterized in that said data comprises address information relating to each primitive used by the customer logic, data to be used by said primitive, and, if applicable, links to other primitives.

11. Customized telecommunication service in accordance with claim 10 characterized in that for each primitive there is a primitive interface.

12. Customized telecommunication service in accordance with claim 11 characterized in that each primitive interface comprises a set of input parameters and a set of result parameters as viewed from within the primitive.

13. Customized telecommunication service in accordance with claim 12 characterized in that each input and result parameter of 2 primitive comprises the following attributes: identity, data type and input/result category.

14. Customized telecommunication service in accordance with claim 13 characterized in that a parameter (38, 39, 40) of a primitive interface is connected with a corresponding parameter; of the customization interface.

15. Customized telecommunication service in accordance with claim 14 characterized in that one customization interface parameter is connected to zero, one or more parameters in one or more pri-mitives (P1-P8).

16. Customized telecommunication service in accordance with claim 15 characterized in that the customization interfaces are defined as managed objects in an existing operation support system (58).

17. Customized telecommunication service in accordance with claim 16 characterized in that the set of input parameters and the set of result parameters are mapped on the managed object as attribu-tes thereof.

18. A method of designing a customized telecommunication service in accordance with claim 1 characterized by the following steps stating the behavior of the customization with regard to the possibilities given by the service shell, finding the customization points in said service shell, selecting, at each found customization point, the primitives that fulfills the desired behavior of the customization logic, crea-ting an instance of the selected primitive and binding the instance of the selected primitive to the parameters of said selected primitive.

19. A method in accordance with claim 18 characterized in that the customization points are found by their name.