SE503376C2 - Kundprofilerad telekommunikationstjänst - Google Patents

Description

505 576 2 komponenter och bågarna representerar den ordningsföljd i vilken primitiverna exekverar. Med denna representation kan nya telefonitjänster visas grafiskt som ett "träd" av noder.

Trädlogiken kan manipuleras grafiskt för att skapa tjänstens logik eller för att ändra tjänstens logik.

WO 92/11603 beskriver ett förfarande och en apparat för fram- ställning av kundprofilerade samtalsposter med samtalshanterande information (CCPI), vilka samtalsposter tillhandahåller kundpro- filerade telefonitjänster för individuella abonnenter. Dessa samtalsposter finns pà nätnivà. En grafisk metod används för att skapa den kundprofilerade tjänsten. En kundprofilerande tjänste- applikation används för att skapa varje kunds tjänst eller tjänsteutbud. Varje kunds tjänst eller tjänsterutbud lagras i form av en post eller en serie av poster i en databas. Varje sådan post består av kundprofilerad samtalshanteringsinformation (CCPI). Den kundprofilerande tjänsteapplikationen innefattar ett programmeringsgränssnitt, vilka gör det möjligt för en operatör att använda den kundprofilerande tjänsteapplikationen till att skapa olika användargränssnitt som erbjuder information på ett sätt som är lätt att använda. Kunden eller operatören fyller bara i en liten mängd information och därmed undviks programmering för att skapa programföljder som definierar tjänsten eller för att göra ändringar i existerande programsekvenser i syfte att modifiera tjänsten, De kända grafiska metoderna används för att skapa en komplett tj änst. En programvarukonstruktör av tjänster har svårt att förutse alla de kundprofileringsbehov som en framtida tj änsteope- ratör kan ha, t.ex. vilken typ av parametrar som behövs för kundprofilering av tjänsten. När nya parametrar skall införas máste tjänstens programvara omkonstrueras, eftersom parametrarna är hàrt kopplade till programvaran. Omkonstruktionen måste beordras av leverantören av systemprogramvaran, vilket fördröjer intervallet frán tjänsteomkonstruktionen till dess tjänsten kan erbjudas i nätet. 503 376 3 De områden inom vilka de tillgängliga parametrarna kan variera är begränsade av värden, vilka finns definierade i tjänstepro- gramvaran. Exempelvis kaneuuomstyrningstjänst innehålla en grupp om 10 svarsställen såsom parametrar. Skall ett lltte svarsställe införas, medför detta att tjänsteprogramvaran måste omkonstrue- IBS .

Det är svårt för tjänsteprogramvarukonstruktören att beskriva modifiering av en tjänst som har ett antal parametrar med komplexa inbördes beroenden. Således är det även svårt för tjänsteoperatören att vid modifiering av en tjänst förutse resultatet av en ny kombination av parametervärden.

En tjänst implementeras såsom en mjukvarumodul. För varje kundprofilerad variant av tjänsten finns det alltså en mjukvaru- modulvariant. För att underlätta introduktionen av varianter, vilka endast i ringa grad skiljer sig från varandra, av en tjänst innehåller programmodulerna data eller parametrar som styr tjänstens beteende. Några få exempel på sådana parametrar är en grupp av svarsställen, en grupp av tider per dag när svarsställe- na skall bytas, en grupp av riktnummerområdeskoder, avseende uppringande abonnenter, vilka koder skall användas när beslut skall tas om svarstället för samtalet. Dessa parametrar kan göras tillgängliga så att de kan ändras av en tjänsteoperatör. På detta sätt erhåller tjänsteoperatören ett verktyg med vars hjälp tjänsterna till en 'viss utsträckning kan anpassas till in- dividuella önskemål.

BESKRIVNING AV UPPFINNINGEN I enlighet med föreliggande uppfinning uppdelas en helt kundpro- filerad tjänst i två delar, nämligen en grunddel i form av ett halvfabrikat och en kundlogikdel. Den i form av ett halvfabrikat förekommande grunddelen är en tjänsterelaterad komponent som i det följande kommer att benämnas typtjänst. Kundlogikdelen består av kundlogik som kundprofileras till kundens individuella behov och som består av en delmängd av en förutbestämd mängd av tjänsteoberoendefunktioner,vilkai.detföljandekallasprimitiver. 503 376 4 En viktig aspekt av föreliggande uppfinning är att typtjänsten består av grundläggande tjänstelogik och ett eller flera kundprofileringsgränssnitt, vilka används för att definiera kundlogikdelen. Kundprofileringsgränssnitten definieras noggrant av systemleverantören eller av den organisation som tillhandahål- ler typtjänsten så att de inte åstadkommer icke-önskvärda ömsesidiga beroenden, nedan benämnt interaktioner eller in- terferenser, mellan. olika tjänster som är aktiva vid samma tidpunkt. Kundprofileringsgränssnitten är i detta avseende "smala" eftersom de parametrar som är öppna för kundprofilering väljs av systemleverantörens programmerare - vilka har en övergripande blick över telekomtjänsterna och dessas beteenden - för presentation för tjänsteoperatören. I och med att de har valts av tjänsteoperatören kan de inte ändas av kunderna. Däremot kan systemleverantören lägga till nya eller ta bort gamla kundprofileringspunkter. En kundprofileringspunkt finns i typtjänsten. Från en kundprofileringspunkt kallas kundlogikdelen in för exekvering. Allmänt sett gäller att kundprofilerings- gränssnitten är olika i olika kundprofileringspunkter. I den föredragna utföringsformen av uppfinningen presenteras kundpro- fileringsgränssnitten för tjänsteoperatören i en grafisk editor som tjänsteoperatören använder som ett verktyg med vars hjälp koden för kundlogikdelen genereras.

Således styrs det som kan kundprofileras helt och hållet av kundprofileringsgränssnitten.

FIGURBESKRIVNING Fig. 1 är dels ett blockschema dels ett flödesschema som visar exekvering av en kundprofilerad tjänst i enlig- het med föreliggande uppfinning, fig. 2 är ett diagram som visar den kundprofilerade tjänsten i fig. 1, fig. fig. fig. fig. fig. fig. fig. fig. 11 503 376 5 är ett diagram som visar den miljö i vilken tjänster kundprofileras och de aktörer som förekommer vid kundprofilering av tjänster, är ett diagram som visar typtjänsten i fig. l, är ett diagram som visar en funktionsvy av ett gene- riskt kundprofileringsgränssnitt, är ett diagram liknande det i fig. 4 och figuren visar ett exempel pà en beskrivning av ett kundprofilerings- gränssnitt, är ett diagram som visar strukturen av en primitiv, vilken får tjäna som en representant för de primitiver vilka används i den grupp av primitiver som definierar kundprofileringsgränssnitten i. enlighet med uppfin- ningen, är ett diagram som visar en primitiv benämnd “check- lista", är en plan vy av en skärmbild pá en monitor, vilken skärmbild erhålls med en grafisk editor som används av en kund till att konstruera en sin kundlogik i enlig- het med föreliggande uppfinning, är ett diagram som visar hur primitiver, såsom dessa ser ut i den grafiska editorn, binds till ett kundpro- fileringsgränssnitt för att bilda noder, vilka växel- verkar med typtjänsten, illustrerar var och en av noderna i fig. 9, i synner- het de olika primitiverna i noderna, är ett diagram som visar en typtjänst, kundlogik och de tvá typerna av gränssnitt mellan dessa delar, 503 376 6 fig. 13 är dels ett blockschema, dels ett flödesschema, som visar exekveringen av en typtjänst i körtid och fig. 14 är ett blockschema som visar en implementering av ett kundprofileringsgränssnitt i form av ett hanterings- objekt i ett drift- och underhållssystem för ett telekomsystem.

BESKRIVNING AV FÖREDRAGNA UTFÖRINGSFORMER I fig. 1 visas en typtjänst 1 som består av ett antal processer 1, 3, 4, 5 vilka utförs i den ordningsföljd som anges av tidsaxeln 6. Processer kan även utföras samtidigt men av tydlighetsskäl visas inte detta. Typtjänsten l innefattar kundprofileringspunkter 7, 8 vilka påträffas under typtjänstens exekvering.Knndprofileringspunkternaerbjuderkundprofilerings- möjligheter i typtjänsten och är specialkonstruerade för att stöda kundprofilering. I det visade exemplet har typtjänsten två kundprofileringspunkter men en typtjänst kan bestå av en eller flera sådana kundprofileringspunkter i enlighet med föreliggande uppfinning. En typtjänst måste dock ha åtminstone en kundpro- fileringspunkt. Varje kundprofileringspunkt består av två typer av gränssnitt: (1) kundprofileringsgränssnitt och (2) körtid- gränssnitt. Dessa gränssnitt definieras fullständigt i samband med att typtjänsten definieras. När typtjänsten exekverar och en kundprofileringspunkt påträffas anropar kundprofileringspunkten en kundlogiktclk 9, vilken styr exekveringen av kundlogik 10 som av kunden konstruerats för denna kundprofileringspunkt 7. När kundlogiken 10 har exekverat erhålls ett värde före en resultat- parameter och detta värde returnerar kundlogiktolken 9 till typtjänsten tillsammans med kontrollen av exekveringen. Ex- ekveringen fortsätter i typtjänsten och när kundprofilerings- punkten 8 påträffas upprepas samma procedur i kundlogiktolken 9 men nu med en annan kundlogik 11. Kundlogiken ll skiljer sig vanligen från kundlogiken 10 men inget hindrar att de är lika.

En kundprofileringspunkt presenterar en funktionell och an- vändarvänlig kundprofileringsvy av typtjänsten samt definierar 503 376 7 i detalj de parametrar och variabler i typtjänsten 1 vilka finns tillgängliga för- kundlogikdelen. Tillgängliga parametrar och variabler specificeras med avseende på typer och tillåtna operationer såsom t.ex. läs, skriv. Detta kommer att beskrivas närmare nedan. I fig. 2 visas en kundprofilerad tjänst 12 innehålla typtjänsten 1, kundlogik 10, 11 samt andra tjänsteim- plementerande delar 13.

Typtjänsten 1 är en tjänst i form av ett halvfabrikat till vilken kundlogikdelar kan adderas. Varianter av tjänsten skapas genom att addera och kombinera olika kundlogikdelar till en och samma typtjänst. En kund A kan t.ex. ha en kundlogikdel 10 vid kundpro- fileringspunkten 7 medan en annan kund B kan ha en annan kundlogikdel i kundprofileringspunkten 7. Kunden A kommer således att ha den kundprofilerade tjänsten 12 medan kunden B kommer att ha en annan kundprofilerad tjänst.

Fig. 3 visar de aktörer som förekommer vid den kundprofilerings- process som skall beskrivas nedan. Närmare bestämt förekommer en systemleverantör 14, en tjänsteoperatör 15, en nätoperatör 16 och abonnenter 17, 18 till tjänsten. Systemleverantören 14 är den organisation som utvecklar de två komponenterna av den kundpro- filerade tjänsten enligt föreliggande uppfinning, dvs. typtjän- sterna och primitiverna omnämnda i beskrivningens inledning.

Systemleverantören 14 utvecklar även den nätinfrastruktur som skall exekvera dessa komponenter samt även den miljö i vilken - kundprofileringen sker; en grafisk editor i den föredragna utföringsformen av uppfinningen. Nätoperatören 16 är en den organisation som ansvarar för nätets drift, t.ex. en GSM- nätoperatör. Nätoperatören 16 har det yttersta ansvaret för att telekomnätet, visat vid hänvisningssiffran 19 i fig. 3, fungerar korrekt. Nätoperatören 16 måste vara fullkomligt säker på att ingen av den kundprofilerade tjänsterna åstadkommer några fel i nätet. Tjänsteoperatören 15 är den organisation som ansvarar för att förse tjänsteabonnenterna 17, 18 med tjänster. En viktig roll för tjänsteoperatören är att skräddarsy tjänster till kunderna.

Tjänsteoperatören 15 måste ha en kundprofileringsmiljö såsom 503 376 8 t.ex. ett verktyg för generering av kundlogik, erforderliga typtjänster och primitiver. Tjänsteoperatören 15 kan emellertid ha begränsad kunskap om telekomnätet 19. Tjänsteoperatören 15 kan även vara nätoperatör 16 eller kan vara en tredje part. Ett möjligt scenario är att det finns flera oberoende tjänsteopera- törer vilka tillhandahåller kundprofilerade tjänster som är i drift i ett och samma nät. Var och en av tjänsteabonnenterna 17, 18 är en entitet som abonnerar pá den kundprofilerade tjänsten.

En tjänsteabonnent kan vara ett företag eller en enskild slutan- vändare. En tjänsteabonnent kan behöva fininställa kundpro- fileringen för att anpassa tjänsten till de egna individuella behoven. Sådan fininställning sker genom att instruera tjänsteo- peratören att komponera kundlogik som uppfyller tjänsteabonnen- tens behov. Förutsatt att tjänsten konstruerats sà att en kund själv kan fininställa kundlogikdelen kan kunden själv fininställa sin kundlogik.

Fig. 4 visar den allmänna uppbyggnaden av en typtjänst. Exempel pà typtjänster är tjänsten svartlistning, (spärr mot uppringning fràn nummer angivna pà en lista), tjänsten ring uppsenare, tjänsten konferenssamtal, tjänsten omstyrning, tjänsten heta linjen, tjänsten ledig pà andra linjen, tjänsten inbrytning, tjänsten parkering, tjänsten hämta pà annan anknytning och många andra. Typtjänsten innefattar grundlogik 21, 22, 23 för tjänsten samt erforderliga kundprofileringspunkter 24, 25. En typtjänst erbjuder en robust plattform för kundprofilering samt tar även hand om eventuell ej önskvärd interaktion med andra tjänster i nätet. Tjänsteoperatören skapar en komplett tjänst genom att lägga till den nödvändiga kundlogikdelen till kundprofilerings- punkterna i typtjänsten. Typtjänsten utvecklas av systemleveran- tören som för detta ändamål använder en konventionell utveck- lingsprocess och konventionella utvecklingsverktyg. Typtjänsten levereras till nätoperatören. och laddas ner' i nätet. Varje kundprofileringspunkt ges en referens, t.ex. ett namn såsom KP~ GRÄNSSNITT_NAMN. Andra referenser än namn kan användas men man föredrar att använda ett namn som beskriver den aktivitet som skall äga rum i kundprofileringspunkten. I fig. 4 förekommer tvà S03 376 9 kundprofileringspunkter men givetvis kan flera sådana förekomma.

Typtjänsten måste ha åtminstone en kundprofileringspunkt. I fig. 4 innefattar typtjänsten 20 tre block 21, 22, 23 som bildar grundlogiken men givetvis kan detta antal block vara olika i olika tjänster. Kundprofileringspunkterna är specialkonstruerade för att stöda kundprofilering av tjänsten.

I fig. 5 visas den allmänna strukturen för en kundprofilerings- punkt, t.ex. kundprofileringspunkten 24 i fig. 4. En kundpro- fileringspunkt har två typer av gränssnitt. (1). Kundprofile- ringsgränssnitt och (2) körtidgränssnitt. Dessa gränssnitt definieras när typtjänsten konstrueras. I fig. 5 visas en funktionsvy av kundprofileringspunkten och i denna vy visas endast kundprofileringsgränssnittet. Kundprofileringsgränssnittet utgör basen för skapandet av kundlogiken. Varje kundprofilerings- gränssnitt består av ett antal parametrar 26, 27, 28. Varje parameter refereras med ett namn CVARl_NAMN, CVAR2_NAMN..... C- VARn_NAMN. Parametrarna i ett kundprofileringsgränssnitt är av två typer, ingångsparametrar och resultatparametrar. Ingångs- parametrar är det som kundlogiken mottar. Ingångsparametrarna synliggörs för kundprofilering och kan inte ändras under kundprofileringen. Resultatparametrar är de parametrar som kundlogiken måste definiera.

Följande information måste definieras för varje parameter i ett kundprofileringsgränssnitt: Namn Varje ingángs-/resultatparameter har ett namn.

Datatyp Det finns en mängd av gemensamma datatyper och varje parameter måste ha en datatyp som hör ihop med ifråga- varande datatypmängd. Denna på förhand definierade mängd av datatyper utgör en gemensam bas som tillåter olika primitiver att operera på ingångs/utgángspara- metrar. Exempel på gemensamma datatyper är "heltal", "sträng", “abonnentnummer". Eventuella restriktioner, såsom t.ex. maxvärde, minvärde, område, begränsat 503 376 10 värde, för en parameter måste också definieras. Denna information används av den grafiska editorn för att säkerställa att korrekt typmatchning föreligger när en primitiv går in i en parameter.

Parameter- kategori Vissa parametrar i en kundprofileringspunkt kan endast läsas och kan inte ändras. Sådana parametrar kallas läsparametrar. Andra parametrar kan ha ett giltigt värde som går att ändra. Sådana parametrar kallas läs/skrivparametrar. Andra parametrar kan sakna ett giltigt värde och ett resultatvärde måste anges.

Sådana parametrar kallas skrivparametrar.

Relations- regler Vissa parametrar kan vara valfria, andra kan vara obligatoriska. Relationer mellan parametrar kan förekomma och måste definieras tydligt. Såsom ett exempel på en relation kan vara en parameter CVAR1 måste vara större än en parameter CVAR2.

Beskriv- ningar Till varje parameter hör en hjälpbeskrivning som beskriver parametern pà ett sätt som stöder och underlättar skapandet av kundlogik.

De ovanstående informationselementen är synliga för tj änsteopera- tören i den nedan beskrivna grafiska editorn. Den synliga informationen visas i fig. 5 i de block som har heldragna linjer.

Kundprofileringsgränssnittet innehåller även osynliga informa- tionselement som i fig. 5 visas i de block som har streckade linjer. Närmare bestämt är adressen för varje parameter i kundprofileringsgränssnittet osynligt för den person som konstruerar kundlogiken. Dessa adresser refererar till positioner i samtalsposten (den post som innefattar A-numret, B-numret, abonnentkategorin. etc.) för' en individuell förbindelse. Den osynliga adresseringsinformationen kommer att beskrivas närmare “503 376 ll nedan och används när den grafiska editorn genererar data som skall laddas ner i telekomnätet 19.

Systemleverantören önskar ha kontroll över användningen av olika primitiver i kundprofileringspunkterna. Genom att hälla sådan kontroll skyddar systemleverantören telekomsystemets tillförlit- lighet. Det skall inte vara möjligt för en konstruktör av kundlogiken att använda primitiver som interfererar med tele- komsystemets drift. För detta ändamål har varje kundprofilerings- gränssnitt även en synlig primitivtypindikator 29 som beskriver den typ av primitiver systemleverantören tillåter att förekomma i kundprofileringspunkten. En.primitiv är en basoperation som kan användas för bygga kundlogik. Användningen av primitivtypindika- torer gör det möjligt för systemleverantören att vid en senare tidpunkt lägga till nya primitiver utan att behöva omdefiniera kundprofileringspunkten.

I fig. 6 visas en typtjänst som är likartad den i fig. 1 visade och som innehåller ett antal processer 31-34 samt en kundpro- fileringspunkt 35. Typtjänsten avser i detta fall tjänsten “vidarekoppling vid ej svar". Typtjänsten. består av de vid vidarekoppling konventionella processerna "inget svar", process 31, "godkänn vidarekoppling“, process 32, "analysera", process 33 samt "godkänn uppställning av förbindelse", process 34.

Typtjänsten innehåller även kundprofileringspunkten 35 som i detta fall benämns "hämta C-nummer". Denna process 35 näste definiera det verkliga katalognumret för svarsstället, dvs. C- numret. Motsvarande kundprofileringsgränssnitt "hämta C-nummer" definierar den information som är synlig för kundprofilering, dvs. ingångsparametrarna A-nummer, landnummer, riktnummer och abonnentnummer. Vidare finns en parameter benämnd "samtalets prioritet". Resultatparametern, C-numreti.detta fall, kommer att av kundlogiktolken 9 returneras till typtjänsten sàsom markeras vid pilen 36. Var och en av ingàngs- och resultatparametrarna definieras med sitt namn, sin datatyp och med andra variabler.

Kundprofileringsgränssnittet"hämtaC-nummer"innehàlleringàngs- och resultatparametrar. Kundprofileringsgränssnittet beskriver 503 376 12 endast ingàngs- och resultatparametrarna. Kundprofilerings- gränssnittet har inte någon funktion under exekveringen.

Primitiver är generiska komponenter som används för att profilera typtjänster av olika slag. En och samma primitiv kan därför användas av många typtjänster. Primitiver såväl som typtjänster finns i telekomnätet. I fig. 7 visas det allmänna utseendet av en primitiv 37. Varje primitiv har ett namn och består av en mängd av ingángsdata, en mängd av resultatdata, förgreningsvärden och en eller flera utgångar som kan användas för förgrening.

Utgångarna är länkar som används till att förbinda en primitiv med en annan i kundlogiken. Som framgår ur fig. 7 består varje primitiv av ett antal parametrar 38, 39, 40 varvid varje sådana parameter refereras med hjälp av en parametervariabel som har ett namn PVARl_NAMN, PVAR2_NAMN...PVARn_NAMN (där P betyder primi- tiv) . Varje sådan parametervariabel anger om parametern represen- terar ingångsdata eller resultatdata. Förutom parametrarna består en primitiv av kod som i fig. 7 representeras av blocket 41.

Denna kod innehåller de funktioner och operationer som primitiven utför. Parametrarna representerar variabler vilka används av funktionerna i kodblocket. Typen av varje parameter måste anges, dvs. huruvida parametern avser ett heltal, en sträng eller vad slags typ av' data eller' vad slags typ av' datastruktur som parametern tar.

För varje primitiv finns definierat ett primitivgränssnitt som består av en mängd av ingångsparametrar samt en mängd av resultatparametrar, sett ur primitivens synpunkt. Varje ingångs- och resultatparameter i en primitiv består av följande attribut: identitet, datatyp och ingångs-/resultatkategori.

Primitiver klassifiseras i två klasser beroende pà typen av resurs som primitiven kan operera pà, nämligen 1) en egen resurs eller 2) en gemensam resurs. Primitiver av den typ som opererar på egna resurser konstrueras så att de endast kan modifiera de egna resurserna och resultatparametrarna. Primitiver av den typ som opererar på gemensamma resurser kan användas i kundlogik i 503 376 13 kundprofileringspunkter utan risk för ej önskvärd interaktion.

Primitiver av den typ som opererar på gemensamma resurser konstrueras så att de tillåts operera på och modifiera statusen av resurser som delas av många tjänster, såsom t.ex. väljarfunk- tioner i ett telekomsystem. En primitiv av den typ som opererar pà en gemensam resurs kan endast användas i en kundprofile- ringspunkt som speciellt har konstruerats för denna resurs. Med andra ord kan kundprofileringsgränssnittet i en kundprofilerings- punkt i vilket det förekommer en primitiv av den typ som används för en gemensam resurs, begränsa användningen av primitiver som manipulerar den gemensamma resursen.

Fig. 8 är ett exempel på en primitiv kallad "checklista".

Ingàngsparametern är av typen "sträng" och primitiven innehåller i sin koddel 41 en lista av strängar. Primitivens funktion är att jämföra ingàngssträngen med listan av strängar. Om en matchande sträng finns väljs ett förgreningsvärde "överensstämmelse". Om inte någon överensstämmelse finns mellan ingàngssträngen och strängarna i listan väljs förgreningsvärdet "ingen överensstäm- melse". Samma primitiv "checklista" kan användas i en kundlogik som består av B-nummer och i aux annan kundlogik med "namn" förutsatt att båda dessa entiteter definieras såsom strängar.

Således kan en och samma primitiv ha många funktionella roller förutsatt att de på förhand definierade datatyperna av paramet- rarna är konsistenta med varandra.

Fig. 9 är en skärmvy av ett grafiskt användargränssnitt som förekommer i ett verktyg för generering av kundlogik. Detta verktyg genererar data som representerar kundlogiken. Till höger på skärmen visas ett antal ikoner Pl-P8, där varje ikon represen- terar en individuell primitiv. När tjänsteoperatören önskar skapa kundlogik börjar han med att skissera upp den önskade kundlogiken med hänsyn till de möjligheter som de existerande primitiverna P1-P8 erbjuder. Den procedur som tjänsteoperatören följer när han skapar kundlogiken är enkel och rakt på sak. Till att börja med väljs den önskade profiltj änsten och dess kundprofileringspunkter tas fram. Valet görs genom att klicka pà en, ej visad, ikon som 14 representerar kundprofileringsgränssnittet. Ett:fönster 41 kommer då att öppnas på skärmen och i. fönstret syns de parametrar CVARl_, CVAR2_ ... CVARn_ som finns tillgängliga för kundpro- filering. Därefter väljs, från paletten av ikoner Pl-P8, den primitiv som uppfyller den önskade funktionen. Operatören väljer den berörda ikonen genom att klicka på denna med en pekanordning, t.ex. en mus, en penna eller dylikt. När en ikon har valts kommer att andra fönster 42 att öppnas pà skärmen och i detta fönster visas den valda primitivens parametrar PVARI, PVAR2... PVARn.

Därefter binder operatören en av dessa parametrar till en parameter som finns tillgänglig i kundprofileringsgränssnittet.

Bindningen sker med användande av konventionell peka-och-drag- teknik, dvs. genom att peka pá en parameter (t.ex. PVARl_) med pekanordningen och dra pekanordningen till motsvarande CVARn_- parameter (t.ex. CVAR2_) i det visade fönstret 41. Denna pek- och drag-procedur illustreras med pilen 43. Om fler parametrar i den valda primitiven skall bindas till kundprofileringsgränssnittet upprepas pek- och drag-proceduren. I fig. 9 representeras detta med pilen 44. Därefter upprepas de tvà sistnämnda stegen för varje ny primitiv som väljs bland ikonerna Pl-P8 och de nöd- vändiga bindningarna företas mellan PVAR- och CVAR-parametrarna.

Bindning av en primitivparameter PVARn_ till en parameter CVARn_ i kundprofileringsgränssnittet betyder att det CVARn_-värde, som konstruktören av kundlogiken matar in i det visade fönstret 41, kommer att användas av primitiven. Primitiven kommer därefter, i samband med att kundprofileringslogiken exekveras, att utföra sin operation och då använda det inmatade CVARn_-värdet.

När konstruktören av kundlogiken pekar pà kanten av något av fönstren 41, 42 kommer ett tredje fönster 60 att öppnas och visa information som beskriver beteendet och betydelsen av kundpro- fileringsgränssnittet och dess variabler. Med andra ord erháller konstruktören av kundlogiken pà detta sätt omedelbar hjälpin- formation. 503 376 15 När en primitiv väljs kommer en nod, representerad av en ring 45, att visas på skärmen. Om primitiven t.ex. var "checklista“, visad i fig. 8, kommer noden 45 på skärmen även att vara försedd med de tre bågarna som representerar en ingång och två utgångar.

Utgångarna benämns "överensstämmelse" och "ingen överensstämmel- se". Därefter upprepas de två sista stegen för varje ny primitiv som väljs bland ikonerna P1-P8 och de nödvändiga bindningarna mellan PVAR- och CVAR-parametrarna. En ny nod 46, visad med streckade linjer, kommer att visas på skärmen. Konstruktören av kundlogiken länkar den berörda utgången från nod 45 med berörd ingång på nod 46. På detta sätt kommer ett logiskt träd att byggas successivt. Detta logiska träd visar kundlogiken på ett användarvänligt sätt och gör att kundlogiken blir lätt att förstå.

I fig. 10 visas det logiska trädet för ett exempel på en kundlogik avseende tjänsten "vidarekoppling vid ej svar", visad i fig. 6. När typtjänsten kommer fram till kundprofilerings- punkten lämnar den över den vidare exekveringen av tjänsten till kundlogiken vilken.börjar med att prova den anropande abonnentens nummer mot noden "nummerlista för anropat nummer". Om den uppringande användaren har tjänsten aktiverad väljs resultat- parametern "sann" medan i det motsatta fallet värdet Cl för resultatparametern Cl returneras till typtjänsten. Därefter provar kundlogiken datum och tid för den uppringande abonnentens samtal och om anropet görs under affärstid och datumet är korrekt skickas vidarekopplingsnumret, representerat av ett värde C3 för resultatparametern C3, till typtjänsten. Om telefonsamtalet görs på en dag och vid en tid som inte överensstämmer med nodens dag och tid kommer telefonsamtalet att omstyras till ett annat nummer, representerat av parametern C2, som är skilt från det nummer som parametern C3 representerar. I fig. 10 visas bind- ningarna mellan kundprofileringsgränssnittets variabler CVAR och variablerna PVAR för de olika primitiverna med tjocka heldragna linjer betecknade A-nummer, Cl, C2 och C3. 16 Fig. 11 är en vy som visar samma logiska träd som i fig. 10. Fig. ll har tagits med för att visa att det bakom varje nod finns en primitiv. Olika noder kan använda samma primitiv.

Fig. 12 illustrerar relationen mellan kundprofileringsgränssnitt, kundlogik och primitivgränssnitt. Typtjänsten 1 har ett kundpro- fileringsgränssnitt 47. Detta gränssnitt består av de parametrar som beskrivits i samband med fig. 5, dvs. parametrarna, paramet- rarnas datatyper, värdeområden, kategorier och relationsregler samt tillåtna primitivtyper. Kundlogiken 11 består vid varje nod av ett primitivgränssnitt 48 som passar i en motsvarande del av kundprofileringsgränssnittet 47. Detta gäller med avseende på primitivtyp och allting som kundprofileringsgränssnittet 47 anger om de parametrar (datatyper etc) till vilka noden är kopplad.

Delen 49 av kundlogiken ll är inte ett gränssnitt utan represen- terar att relationsreglerna som kundprofileringsgränssnittet 47 anger beträffande ovillkorliga resultatparametrar och de inbördes beroendena mellan resultatparametrarna är uppfyllda. Dessa rela- tionsregler avser såväl kundlogiken ll i sin helhet som in- dividuella noder i kundlogiken.

I de ovanstående figurerna har typtj änsten och kundlogiken visats ur funktionssynpunkt. I fig. 13 visas de sett i körtidsvy.

Typtjänsten 11 konstrueras med hjälp av ett verktyg 50 som editerar och genererar koden för typtjänsten. Typtjänsten laddas därefter ner i nätet och vid exekvering av typtjänsten växelver- kar typtjänsten med kundlogiktolken 9. Kundlogiktolken 9 innefattar logik 51 som är generell för all kundlogik 10, 11.

Sedan processerna 31, 32 i typtjänsten 1 har exekverat uppnås kundprofileringspunkten 35. I kundprofileringspunkten görs ett anrop till kundlogiken. Detta anrop representeras av symbolen 52 "hämta C_nr" . Detta anrop representerar ett körtid-gränssnitt mot kundlogiken. Som svar på anropet skickas kundlogikdata till kundlogiktolken 9. Denna skickning av data representeras av pil 53. Såsom nämnts ovan innehåller det data som skickas till tolken inte någon kod. Det som skickas är profileringsgränssnittsdata av den typ som visas i fig. 6 och som, vilket beskrivits 503 376 17 samband med fig. 9-11, innehåller information som är tillräcklig för att kundlogiktolken 9 ur detta data kan rekonstruera den in- dividuella kundlogiken. Kundlogiken exekveras i tolken 9 och resultatparametern returneras till samma kundprofileringspunkt 32 från vilken anropet gjordes. Tillbakaskickningen av resultat- datat till typtjänsten representeras av pilen 54. Resultatdatat används därefter av typtjänsten. Vid mottagning av resultatdatat kommer typtjänsten att överta kontrollen av exekveringen och använda resultatdatat i nästföljande operation 33. Mottagningen av resultatdatat i typtjänsten markeras vid symbolen 55. Symbolen 55 representerar därför även ett körtid-gränssnitt mot typtjän- sten. Resultatdatat består också enbart av data och inte av någon kod. I kundlogiktolken 9 lagras koden för primitiverna Pl-Pn.

Varje primitiv lagras på varsin minnesplats och accessas genom en referens till den adress i minnet på vilken primitiven finns lagrad. Det är dessa adresser som vid dataöverföringen 53 skickas såsom primitiver som skall exekveras. Det är således inte primitivernas kod som skickas utan vad som skickas är pekare till adresserna till de.minnesplatser där primitiverna finns lagrade.

Fig. 14 är en föredragen implementation av den miljö i vilken den kundprofilerade telekomtjänsten i enlighet med uppfinningen används. Ett mjukvaruverktyg 56 för konstruktion av kundlogiken, dvs. den mjukvara som kundlogiktolken 9 använder, samt ett telkomnäthanteringssystem 57 bildar en del av ett driftstödsystem (OSS) 58, vilket hanterar* telekomnätelement 59, såsom t.ex. lokala växelstationer, accessväljare, i vilka kundlogik 11 är definierade såsom hanteringsobjekt MO i enlighet med TMN- konceptet. På detta sätt definieras kundlogik såsom hanteringso- bjekt, vilka kan manövreras på samma sätt som alla andra hanteringsobjekt i nätet med användande av ett standard Q3- gränssnitt. Ãven standard hanteringsfunktioner för säkerhet kan användas för att styra kundprofileringprocessen_ Nätoperatören kommer därför att ha fullständig kontroll över de kundpro- fileringsgränssnitt och primitiver (definierade såsom hanterings- objekt) vilka finns tillgängliga för varje individuell tjänsteo- peratör. En tjänsteoperatör 15 som har den grafiska editorn och 503 376 18 mjukvaruverktyget 56 är i stånd att ladda ner sin kundlogik i nätelementet 59i.det:motsvarande hanteringsobjektet:MO. Eftersom kundlogiken endast innehåller data kan den laddas ner i telekom- nätet och nya kundprofilerade tjänster kan införas utan att existerande mjukvara behöver uppgraderas. Den kundprofilerade tjänsten tillhandahålls åt en abonnent på samma sätt som vilken annan tjänst som helst med användning av standard tjänstehante- ringsfunktioner. Ett "tjänsteobjekt" för abonnenten skapas och erforderliga attribut definieras. Ett attribut som måste definieras är "kundprofileringslogik"-attribut. Den motsvarande kundlogiken tilldelas "tjänsteobjeket".

En tjänsteabonnent kan fininställa den kundprofilerade tjänsten så att den uppfyller abonnentens egna behov. T.ex. kan varje abonnent som använder den kundprofilerade tjänsten i fig. 10 definiera sina egna värden i "lista för anropade nummer", "datum och tid" samt faktiska svarsnummer Cl, C2, C3. Sådana data kallas abonnentdata.

Abonnetterminalen kan antingen vara en PC-baserad terminal eller någon annan standardterminal. Om abonnenten har en persondator som är ansluten till nätet, t.ex. med användande av ISDN, erbjuder mjukvara i persondatorn det nödvändiga användargräns- snittet, såsom t.ex. menyer, grafer och kommunikation, med nätet.

Ett applikationsprotokoll mellan nätet och terminalen behövs eftersom terminalen.màste hämta data från nätet, presentera datat för abonnenten på ett användarvänligt sätt och skicka tillbaka modifierat data till nätet. Detta applikationsprotokoll är specifikt för systemleverantören.

Om abonnenten har access till en standardterminal kan nätet tillhandahålla en röststyrd meny som hjälper abonnenten.

Användaren kommunicerar med nätet genom att knappa in de nödvändiga procedurerna.

Den information som finns tillgänglig i hanteringsobjekten används för att säkerställa att kundlogiken uppfyller kundpro- 503 376 19 fileringsgränssnittet. Närmare bestämt skall mjukvaruverktyget 56 tillhandahålla en automatisk kontroll av att kundlogiken överensstämmer med de inblandade gränssnitten. Medan kundlogiken editeras finns den i mjukvaruverktyget 56.

Claims (19)

505 376 20 PATENTKRAV

1. Kundprofilerad telekomtjänst, k ä n n e t e c k n a d av att tjänsten (12) innefattar en tjänsterelaterad del benämnd typtjänst (1), som tillhandahålls av en systemeleverantör, och åtminstone en kundprofileringsdel (10, ll) som kan tillhandahål- las av' en tjänsteoperatör (15), vilken typtjänst innefattar åtminstone en kundprofileringspunkt (7, 8) vid vilken kundpro- fileringsdelen adderas till typtjänsten (1), vilken kundpro- fileringspunkt: a) innefattar'ett:individuellt:kundprofileringsgränssnitt, vilket endast systemleverantören tillåts definiera, b) definierar omfånget av de för kundprofilering möjliga operationerna med hjälp av eu; första mängd koppelrelaterade parametrar och en andra mängd primitiv-funktioner (P1-P8) nedan benämnda primitiver, vilka parametrar och primitiver är de enda parametrarna och primitiver som finns tillgängliga i kundpro- fileringspunkten, vilken kundprofileringsdel (10, 11) innefattar kundlogik som är genererad från en delmängd av den nämnda andra mängden av primitiver ingående i kundprofileringsgränssnittet och som verkar på en delmängd av den andra mängden parametrar som är definierade av kundprofileringsgränssnittet, varvid kundlogiken överförs enbart i form av data till en exekveringsmiljö i vilken typtjänsten (1) och nämnda kundprofileringsdel exekverar.

2. Kundprofilerad telekomtjänst i enlighet med krav 1, k ä n - n e t e c k n a d av att primitiverna är generiska för olika telekomtjänster.

3. Kundprofilerad telekomtjänst i enlighet med krav 2, k ä n - n e t e c k n a d av att parametrarna innefattar en upp- sättning ingångsparametrar och en uppsättning resultatparametrar, sett ur kundlogikens synpunkt.

4. Kundprofilerad telekomtjänst i enlighet med krav 3, k ä n - n e t e c k n a d av att varje ingángs- och resultatparameter 505 376 9.» innefattar följande attribut: identitet, datatyp, ingångs- /utgångskategori och, om tillämpligt, relationsregler.

5. Kundprofilerad telekomtjänst i enlighet krav 4, k ä n n e - t e c k n a d av att varje kundprofileringsgränssnitt därutöver innefattar adressinformation avseende var och en av parametrarna (26, 27, 28), vilken adressinformation är skyddad och ej är tillgänglig för användning av konstruktören av kundlogiken.

6. Kundprofilerad telekomtjänst i enlighet med krav 5, k ä n - n e t e c k n a d av att kundprofileringspunkten vidare innefattar ett körtid-gränssnitt (52, 55) som i körtid förbinder kundlogiken med typtjänsten.

7. Kundprofilerad telekomtjänst i enlighet med krav 6, k ä n - n e t e c k n a d av att varje kundprofileringspunkt in- nefattar en första del, som är synlig i ett första grafiskt användargränssnitt (fig. 9) av ett verktyg (56) som används för byggning av kundlogiken, samt en andra del som inte är synlig i det grafiska användargränssnittet, varvid den synliga delen innehåller parametrarna och den osynliga delen innehåller adressinformationen.

8. Kundprofilerad telekomtjänst i enlighet med krav 7, k ä n - n e t e c k n a d av att den av verktyget (56) genererade kundlogiken innefattar enbart data.

9. Kundprofilerad telekomtjänst i enlighet med krav 8, k ä n - n e t e c k n a d av att data som representerar kundlogiken finns lagrat i telekomnätet, varigenom introduktion av nya kundprofilerade tjänster kan ske utan att existerande mjukvara i nätet behöver uppgraderas.

10. Kundprofilerad telekomtjänst i enlighet med krav 9, k ä n - n e t e c k n a d av att nämnda data innefattar adressin- formation som är relaterad till varje primitiv som används i 505 376 22. kundlogiken, data som skall användas av primitiverna, och, om tillämpligt, länkar till andra primitiver.

11. Kundprofilerad telekomtjänst i enlighet med krav 1, k ä n - n e t e c k n a d av att kundprofileringsgränssnitten är definierade som hanteringsobjekt i ett existerande driftstödsys- tem (58).

12. Kundprofilerad telekomtjänstzi enlighet med krav 16, k ä n - n e t e c k n a d av att mängden ingàngsparametrar och mängden resultatparametrar är mappade på hanteringsobjektet såsom attribut till detta.

13. Kundprofilerad telekomtjänstzi enlighet:med krav 12, k ä n - n e t e c k n a d av att för varje primitiv finns ett primitivgränssnitt.

14. Kundprofilerad telekomtjänst i enlighet med krav 13, k ä n - n e t e c k n a d av att varje primitivgränssnitt uppvisar en mängd ingángsparametrar sett ur primitivens synpunkt.

15. Kundprofilerad telekomtjänstzi enlighet med krav 12, k ä n - n e t e c k n a d av att varje ingángs- och resultatparameter av en primitiv innehåller följande attribut: identitet, datatyp och ingångs-/resultatkategori.

16. Kundprofilerad telekomtjänst:i enlighet med krav 15, k ä n - n e t e c k n a d av att en parameter (38, 39, 40) i ett primitivgränssnitt är kopplat till en motsvarande parameter i kundnrofilerinqsdränssnittet.

17. Kundprofilerad telekomtjänstzi enlighet:med krav 14, k ä n - n e t e c k n a d av att en parameter i kundprofilerings- gränssnittet är kopplad till ingen, en eller flera parametrar i en eller flera primitiver (Pl-P8). 503 376 za

18. Sätt att konstruera en kundprofilerad telekomtjänst som innefattar en tjänsterelaterad del benämnd typtjänst (1) och åtminstone en kundprofileringsdel (10, 11), vilken typtjänst innefattar åtminstone en kundprofileringspunkt (7, 8) vid vilken kundprofileringsdelen adderas till typtjänsten (1), vilken kundprofileringsdel (10, ll), innefattar kundlogik som alstras ur en delmängd av en förutbestämd mängd av primitiva funktioner (Pl-P8), benämnda primitiver, k ä n n e t e c k n a t av följande steg: definiering av kundlogikens beteende med hänsyn till de möjligheter typtjänsten (1) ger, uppsökning av kundprofileringspunkterna (7, 8) i typtjänsten (l), val, vid varje påträffad kundprofileringspunkt, av de primitiver (P1-P8) som uppfyller det önskade beteendet av kundlogiken, alstring av en instans av den valda primitiven, och bindning av instansen av den valda primitiven till paramet- rar i kundprofileringsgränssnittet.

19. Sätt enligt krav 18, k ä n n e t e c k n a t av att kundprofileringspunkterna hittas med ledning av deras resp. namn.