FI107978B - Tallettaminen - Google Patents

Description

107978

Tallettaminen

Keksinnön tausta

Keksintö liittyy menetelmään ja laitteeseen etukäteen maksaneiden tilaajien käytettävissä olevan saatavan määrän päivittämiseksi.

5 Matkaviestinjärjestelmissä, kuten GSM, etukäteen maksettujen SIM-korttien (Subscriber Identity Module) käyttö lisääntyy. Etukäteen maksetut SIM-kortit vapauttavat verkko-operaattorit luottotappioilta. Ne mahdollistavat sen, että vanhemmat voivat asettaa etukäteen ylärajan puhelinlaskulle. Niiden kolmantena etuna vaeltavat (roaming) tilaajat voivat maksaa paikallispuhelut 10 paikallistariffeilla, kun taas kotioperaattorin SIM-kortin käyttö johtaa kansainvälisten tariffien maksamiseen kotiverkkoon ja takaisin.

Jotkut operaattorit antavat tilaajien soittaa vuorovaikutteiseen ääni-vastauspalveluun (IVR, Interactive Voice Response), jonka välityksellä tilaajat voivat tarkistaa tilinsä saldon ja lisätä lisää rahaa tililleen. Tilisaldoa kutsutaan 15 myös saatavaksi. Rahaa lisätään vouchereilla. Jotkut operaattorit myyvät erityyppisiä vouchereita, jotka eroavat toisistaan esimerkiksi ’’puheluyksikön” hinnalla.

Nykyisen IVR-ratkaisun ongelmana on, että se ei tue voucherin tyypin muuttamista. Kun tilaaja laittaa lisää rahaa tililleen, voucherin arvo lisätään *·:·: 20 nykyiseen saatavaan. Tämä ei ole ongelma, kun aikaisempi voucher ja uusi • « : '·· voucher ovat samaa tyyppiä. Jos voucherit ovat erityyppisiä, voucherin arvoa @i pitäisi lisätä nykyiseen saatavaan, koska puheluyksiköiden ominaisuudet ovat erilaiset. Siksi joka yö tähän työhön varatun henkilön täytyy käydä läpi tietokanta ja löytää kaikki tilaajat, jotka ovat muuttaneet voucherinsa tyyppiä, • · 25 ja päivittää näiden tilaajien saatavat. Tämän menetelmän ongelmana on, että se on hidas, virhealtis ja työläs. Lisäksi tilaaja, joka on muuttanut voucher-tyyppiään, voi saada väärän vastauksen kysyessään saataviaan ennen tätä • · ^# manuaalisesti tehtyä päivitystä.

• · ♦ :·. Keksinnön lyhyt selostus .···. 30 Keksinnön tavoitteena on ratkaista yllä mainitut ongelmat. Keksin nön tavoitteet saavutetaan menetelmällä, järjestelyllä ja verkkoelementillä, • · · :·' « joille on tunnusomaista se, mitä sanotaan itsenäisissä patenttivaatimuksissa.

:Λ: Keksinnön edulliset suoritusmuodot ovat epäitsenäisten patenttivaatimusten kohteena.

2 107978

Keksintö perustuu tiedon ylläpitämiseen vouchereiden tyypeistä, talletettavan voucherin tyypin vertaamiseen viimeksi käytetyn voucherin tyyppiin ja vertailun tuloksesta riippuvan talletustavan valitsemiseen.

Keksinnön etuna on, että saatava päivitetään aina automaattisesti 5 oikein eikä muutoksia tarvita jälkikäteen. Siten liittymän tyypin muuttaminen on hyvin helppoa etukäteen maksaneille tilaajille ja operaattoreille. Lisäksi tilaaja saa nykyisen saatavansa määrän sellaisena, kuin se todella on, heti tallettamisen jälkeen.

Keksinnön eräässä edullisessa suoritusmuodossa, kun voucherit 10 ovat eri tyyppiä, saatavaksi päivitetään vain uuden voucherin arvo. Tämän suoritusmuodon etuna on lisäksi, että se on yksinkertainen tapa päivittää saatavia, kun voucherin tyyppi muuttuu.

Vielä eräässä keksinnön suoritusmuodossa, kun voucherit ovat eri tyyppisiä, saatava päivitetään kertomalla nykyinen saatava kertoimella, jonka 15 arvo määritellään vouchereiden tyyppien perusteella, ja tallettamisen jälkeinen saatava on kertolaskun tuloksen ja uuden voucherin arvon summa. Tämän suoritusmuodon etuna on lisäksi, että operaattori voi tarjota joustavan tavan muuttaa voucherin tyyppiä siten, että nykyistä saatavaa ei tarvitse poistaa kokonaan, vaan se voidaan sovittaa uuden voucherin tyyppiin. v 20 Vielä eräässä keksinnön suoritusmuodossa järjestelmä kysyy tilaa- ’* jalta, hyväksyykö hän, että nykyinen saatava tai osa siitä menetetään vouche- • · : rin tyypin muutoksen yhteydessä. Tämän suoritusmuodon etuna on lisäksi, että voucherin tyyppiä muuttavan tilaajan ei tarvitse enää muistaa, että käyt- • · *·.*·: tämätön saatava menetetään, tai oliko hänen viimeinen voucherinsa samaa :X: 25 tyyppiä. Lisäksi hän voi kieltää voucherin tyypin muuttamisen, säästäen täten :T: vanhan saatavansa. Tämä suoritusmuoto itse asiassa suojelee tilaajaa.

. Kuvioiden lyhyt selostus • ·

Keksintöä selostetaan nyt lähemmin edullisten suoritusmuotojen *:** yhteydessä, viitaten oheisiin piirroksiin, joista: f*·· 30 Kuvio 1 on lohkokaavio esittäen joitakin olennaisia verkkoelement- tejä; . Kuvio 2 on vuokaavio esittäen ensimmäistä edullista suoritusmuo- « ! toa; • · · *· Kuvio 3 on vuokaavio esittäen toista edullista suoritusmuotoa; ja 35 Kuvio 4 on toiminnallinen malli havainnollistaen tiedon vaihtoa eri verkkoelementtien välillä.

3 107978

Keksinnön yksityiskohtainen selostus

Kuvio 1 on lohkokaavio tietoliikennejärjestelmästä, joka on varustettu keksinnön edullisen suoritusmuodon mukaisella järjestelyllä. Tietoliikennejärjestelmän oletetaan olevan yleinen matkapuhelinverkko PLMN (Public 5 Land Mobile Network) rajoittamatta keksintöä kuitenkaan tähän tiettyyn verkkoon. Keksintöä voidaan käyttää missä tahansa tietoliikennejärjestelmässä, jossa etukäteen maksaneet tilaajat voivat lisätä rahaa tililleen. Kuviossa 1 havainnollistetussa suoritusmuodossa hyödynnetään älyverkkoteknologiaa. Älyverkko (IN) pystyy tarjoamaan tietoliikennejärjestelmän, kuten lankaverkon tai 10 matkapuhelinverkon, tilaajille lukuisia erilaisia palveluita. Eräs esimerkki tällaisesta älyverkosta on kuvattu ITU-T:n suositusten Q-1200 sarjoissa, joista ΟΙ 210 - Q1219 määrittelevät joukon ominaisuuksia, jotka tunnetaan CS-1:nä (Capability Set 1), ja vastaavasti Q-1220 - Q-1229 määrittelevät ominaisuus-joukon CS-2. Keksintö ja sen tausta tullaan selostamaan käyttäen suosituksen 15 ETS 300 374-1 terminologiaa, mutta keksintöä voidaan soveltaa myös älyverkoissa, jotka on toteutettu jollain muulla älyverkon standardilla.

Kuvio 1 esittää joitakin älyverkon elementtejä, jotka ovat olennaisia keksinnön ymmärtämiseksi, kuten erikoistuneen resurssitoiminnon SRF, joka on rajapinta verkkomekanismille, joka liittyy vuorovaikutukseen tilaajan kans-\\ 20 sa. Se voi olla liittyneenä sellaisiin, jotka tunnetaan älykkäinä oheislaitteina IP

(intelligent pheripheral) ja käsittää esimerkiksi enemmän kehittyneitä puheen- • · · käsittelytoimintoja kuin keskukset yleensä. IVR-sovellus sijaitsee yleensä *”*! IP:ssä. IVR-sovellus, jota kutsutaan myös etukäteen maksetun SIM:in IVR- • · · ” sovellukseksi, on vuorovaikutteinen äänellä vastaava sovellus, joka antaa ti- v.; 25 laajan lisätä rahaa (tallettaa) etukäteen maksetuille SIM-tileille antamalla etu- : käteen maksetun voucherin numeron. IVR-sovellusta kutsutaan myöhemmin yksinkertaisesti IVR:ksi. IVR Voicetek Generation:ia voidaan käyttää IVR:n ·:··: suoritusympäristönä.

·“*: IP on yhdistetty SSP:hen käyttäen esimerkiksi ISUP (ISDN User • « · 30 Part) -signalointia ja yhtä tai useampaa äänen siirtoa. SSP (Service Switching • ·

Point) on verkkoelementti, joka suorittaa palvelun kytkentätoiminnon (SSF, ’···* service switching function). SSP voi olla matkapuhelinkeskus MSC, joka si- : sältää SSF:n. SSF on rajapinta perinteisen puhelunohjaustoiminnon CCF ja • · · · älyverkon palvelun ohjaustoiminnon SCF välillä. Verkkoelementtiä, joka suo-35 rittaa SCF.n, kutsutaan palvelun ohjauspisteeksi (SCP). Älyverkkopalvelu tuotetaan siten, että palvelun kytkentäpiste SSP pyytää ohjeita palvelun ohja- 4 107978 uspisteeltä SCP sanomilla, jotka siirretään SSP/SCP-rajapinnan läpi, kun palveluun liittyviä havaintopisteitä kohdataan. Älyverkkopalvelun yhteydessä palvelun ohjauspisteessä SCP käynnistetään palveluohjelma, jonka toiminta määrittelee sanomat, jotka SCP lähettää SSP:lle jokaisessa puhelun vaihees-5 sa. Yleensä SCP:tä ei kuitenkaan käytetä etukäteen maksetuissa SIM IVR-sovelluksissa, se on CCF reitittää puhelut IVR:lle palvelunumeron perusteella suoraan IVR:lle.

Kuviossa 1 esitetyssä esimerkissä etukäteen maksaneen tilaaja-kohtainen tieto ja voucher-tiedot ovat palvelun hallintapisteessä SMP sijaitse-10 vassa tietokannassa. Vaihtoehtoisesti tiedot voivat sijaita eri tietokannoissa ja/tai jossain muussa verkkoelementissä. Keksinnön mukainen tilaajakohtai-nen tieto käsittää ainakin nykyisen saatavan. Se voi käsittää myös tietoa, josta voidaan selvittää viimeksi käytetyn voucherin tyyppi. Tilaajakohtainen tieto voi käsittää myös tietoa liittyen aikaan, jolloin voucherin tyyppi edellisen kerran 15 vaihdettiin. Voucher-tiedot käsittävät validien vouchereiden numerot ja arvot. Voucher-tiedot voivat käsittää myös tietoa voucherin tyypeistä. Vaihtoehtoisesti tieto viimeiseksi käytetyn voucherin tyypistä voidaan tallentaa voucher-tietoon esimerkiksi merkitsemällä voucher käytetyksi lisäämällä tietoa tilaajasta voucher-kohtaiseen tietoon. SMP voi myös käsittää lokitiedoston, joka sisältää . ^ 20 poistetun saatavan määrän mukana riittävästi tietoa tilaajan identifioimiseksi ja • · · * edullisesti ajan, koska poistaminen tehtiin. Lokitiedosto voi olla myös ulkoinen • ·

• “ tietokanta. IVR liittyy SMP:n tietokantaan palvelun hallinnan rajapinnan SMI

• · · *·ί·| välityksellä. SMP ja IP voivat olla kytketyt esimerkiksi lähiverkolla (LAN), joka ·.*·: käyttääTCP/IP:tä (Transmission Control Protocol/lnternet Protocol). IP:n ja • · 25 SMP:n välinen yhteys on kuvattu katkoviivalla, joka esittää vain hallintayhte-:T: yttä ilman signalointiyhteyttä.

Esillä oleva keksintö voidaan toteuttaa olemassa olevissa verkko-solmuissa. Niissä kaikissa on prosessoreita ja muistia, joiden avulla myöhem-.···. min selitettävä keksinnöllinen toiminnallisuus voidaan toteuttaa. Myöhemmin 30 selitettävät toiminnot voivat sijaita yhdessä verkkoelementissä tai joku (jotkut) • · • ** niistä voivat olla yhdessä elementissä ja loput toisissa elementeissä riippu- • · · matta siitä, kuinka ne on sijoitettu keksintöä kuvaavissa esimerkeissä.

: Kuvio 2 on vuokaavio kuvaten IVR:n toiminnallisuutta keksinnön • · · • · · · .·. : ensimmäisessä edullisessa suoritusmuodossa. Tässä esimerkissä on oletettu • · · 35 selvyyden vuoksi, että uusi voucher on validi ja kaikki tarpeellinen tieto saadaan. Oletetaan myös, että liittymän muutoksen tapauksessa, esimerkiksi 5 107978 vouchereiden tyypit eivät ole samat, nykyinen saatava otetaan pois/poistetaan (asetetaan nollaksi). Keksinnön ensimmäisessä edullisessa suoritusmuodossa voucherin tunnistenumerolta käytetään voucherin tyypin tunnistamiseen siten, että kun käytetään esimerkiksi kahden tyyppisiä vouchereita, tunnistenumerot 5 listalla 1 ovat tyyppiä 1 ja puuttuvat numerot ovat tyyppiä 2. Joissain suoritusmuodoissa jokaisella tyypillä voi olla oma tyyppilista tai esimerkiksi tunniste-numeron kaksi ensimmäistä numeroa osoittavat voucherin tyypin. Vaikka onkin olennaista määritellä voucherin tyyppi, keksinnölle kuitenkin on irrelevanttia, kuinka voucherin tyyppi määritellään.

10 Viitaten kuvioon 2 tilaaja on ostanut voucherin kaupasta, soittanut IVR:ään ja valinnut voucherin tallettamisen. Tilaajan oletetaan olevan etukäteen maksanut tilaaja, muussa tapauksessa hän ei voi tallettaa. Oletetaan, että IVR tarkistaa puhelun alussa, onko soittaja etukäteen maksanut tilaaja, ja jos hän ei ole, puhelu katkaistaan tai yhdistetään asiakaspalveluun. Kuvio 2 15 alkaa kohdasta 201, jossa IVR johdattelee (prompt) tilaajaa voucherin tunnistetta ID varten. Voucherin tunnistenumero ID2 vastaanotetaan kohdassa 202. Voucherin validiteetti tarkistetaan (ei esitetty kuviossa 2) ja sen jälkeen kohdassa 203 IVR hakee voucherin arvon V. Sen jälkeen kohdassa 204 tarkistetaan, onko tämä tilaaja tallettanut aiemmin. Jos tilaaja on tallettanut aiemmin, . . 20 IVR hakee tilaajan nykyisen saatavan kohdassa 205. IVR hakee myös viimek- si käytetyn voucherin tunnistenumeron ID1 kohdassa 206 ja määrittelee koh- • · • " dassa 207 vouchereiden tyypit käyttäen tunnistenumerolta ja käymällä läpi *···] listan (listoja) selvittääkseen tyypit.

V·: Kun vouchereiden tyypit on määritelty, IVR tarkistaa kohdassa 208, :.v 25 ovatko voucherit samaa tyyppiä. Jos ne eivät ole, tilaaja on tekemässä liitty- :T: män muutosta, se on muuttamassa voucherin tyyppiä. Koska keksinnön en simmäisessä edullisessa suoritusmuodossa operaattori ei halua, että tilaaja vaihtaa voucherin tyyppiä useammin kuin kerran päivässä, IVR hakee koh-.···. dassa 209 seuraavaksi päiväyksen, jolloin voucherin tyyppi viimeksi muutettiin *·* 30 ja tarkistaa, onko päiväys tämän päivityspäivän päiväys. Jos se ei ole, on : *** muutos sallittava. Joissain muissa suoritusmuodoissa voi olla erilaisia sääntöjä m ··· tai sääntö, sen määrittelemiseksi, on muutos sallittava ja määritteleminen teh-: dään edellä sanotun mukaisesti sovittaen sen säännön (sääntöjen) vaatimuk- !\ · siin. Yksi esimerkki tällaisesta säännöstä on, että profiilin muuttaminen on sai- • ·♦ 35 littua vain niinä päivinä, kun tilaaja ei ole vielä tallettanut mitään. Toinen esimerkki on, että talletusta täytyy seurata laskutettava puhelu ennen kuin uusi 6 107978 tallennus voidaan tehdä. Tämä viimeinen sääntö voi koskea myös tavallisia tallennuksia ilman tyypin muutosta.

Jos muutos on sallittava (kohta 210), IVR johdattelee (prompts) kohdassa 211 lupaa tyypin muuttamiseen. Tämän johdattelun yhteydessä ti-5 laajalle kerrotaan hänen nykyinen saatavansa ja lisäksi muistutetaan, että hän on ostanut toisen tyyppisen voucherin ja siksi nykyinen saatava menetetään, jos hän haluaa jatkaa tallettamista. Viimeiseksi tilaajalta johdatellaan antamaan joko lupa jatkaa tai katkaise -merkki. Joissain muissa suoritusmuodoissa voidaan ennen kohdan 211 tekemistä tarkistaa, onko saatava nolla, ja jos 10 saatava on nolla, hypätä kohdan 211 yli.

Jos lupa vastaanotettiin kohdassa 212, lokitiedosto päivitetään kohdassa 213 lisäämällä tietoa poistetun saatavan määrästä, kenen saatava se oli, koska se poistettiin ja mikä oli tyyppi. Tässä esimerkissä nykyinen saatava poistetaan, kun tyyppiä muutetaan. Sen jälkeen IVR asettaa voucherin arvoksi 15 V nykyisen saatavan kohdassa 214 ja asettaa viimeisen muutoksen päiväykseksi tämän päivän kohdassa 215. Sen jälkeen IVR jatkaa tunnetun tekniikan mukaisesti merkitsemällä voucherin ID2 käytetyksi kohdassa 216, hakemalla saatavan kohdassa 217 ja antamalla vihjeen (prompt) saatavasta kohdassa 218. Voucher merkitään kohdassa 216 käytetyksi lisäämällä tilaajatietoa .... 20 voucherin tunnistenumeroon ja antamalla ’’käytetty päiväykselle” tallettamisen • · · .! * päivän ensimmäisessä edullisessa suoritusmuodossa.

* *’ Jos tilaaja ei tahdo menettää nykyistä saatavaa, lupaa ei vastaan- • · · \·:·* oteta kohdassa 212 ja IVR lopettaa tekemättä mitään päivityksiä ja antaa vih- jeen näkemiin kohdassa 219. Puhelu katkaistaan.

• · 25 Jos päiväys, jolloin voucherin tyyppi viimeksi muutettiin, on tämän ··· ·,· ' päivityspäivän päiväys (kohta 210), IVR antaa vihjeen, että päivittäminen ei ole sallittua tänään kohdassa 220 ja jatkaa kohdassa 219 antamalla vihjeen nä- ·:··; kerniin.

Jos voucherit ovat samaa tyyppiä (kohta 208), IVR asettaa kohdas-30 sa 221 saatavaksi nykyisen saatavan ja voucherin arvon V summan ja jatkaa • · ‘ ** sitten kohdassa 216 merkitsemällä voucherin käytetyksi edellä kuvatulla ta- valla.

j ;*; Jos tilaaja ei ole tallettanut aiemmin (kohta 204), hänen saatavansa • · · « : on nolla ja IVR menee suoraan kohtaan 214 asettamaan saatavaksi voucherin 35 arvon V kuten edellä on selitetty.

7 107978

Kuvio 3 on vuokaavio, joka esittää IVR-sovelluksen toimintoa keksinnön toisessa edullisessa suoritusmuodossa. Myös tässä esimerkissä oletetaan selvyyden vuoksi, että uusi voucher on validi, kaikki tarvittava tieto saadaan ja soittava tilaaja on etukäteen maksanut tilaaja. Keksinnön toisessa 5 edullisessa suoritusmuodossa voucherin tunnistenumeron ensimmäistä numeroa käytetään voucherin tyypin identifioimiseen.

Kuvio 3 alkaa samasta kohdasta kuin kuvio 2: tilaaja on ostanut kaupasta voucherin, soittanut IVR:ään ja valinnut voucherin tallettamisen ja kohdassa 301 IVR johdattelee tilaajalta voucherin tunnistetta ID. Voucherin 10 tunnistenumero ID2 vastaanotetaan kohdassa 302 ja voucherin tyyppi T2 määritellään ID2:n ensimmäisestä numerosta kohdassa 303. Voucherin validiteetti tarkistetaan (ei esitetty kuviossa 3) ja sen jälkeen kohdassa 304 IVR hakee voucherin arvon V kuten selitetty kuvion 2 yhteydessä. Sen jälkeen IVR hakee tilaajan nykyisen saatavan kohdassa 305 ja viimeksi käytetyn voucherin 15 tyypin T1 kohdassa 306. Tyyppien T1 ja T2 perusteella IVR valitsee kohdassa 307 päivitystavan. Jos tyyppiä T1 ei löytynyt kohdassa 306 ja nykyistä saatavaa ei löytynyt kohdassa 305, tilaaja ei ole tallettanut aiemmin, ja hänen saatavansa asetetaan voucherin arvoksi V kohdassa 308A. Jos voucherit ovat samaa tyyppiä (se on T1=T2), voucherin arvo V lisätään nykyiseen saatavaan v, 20 C ja tulos asetetaan saatavaksi kohdassa 308B. Jos voucherit ovat eri tyyppiä, • · · kertoimen F arvo määritellään kohdassa 308C1, nykyinen saatava C kerrotaan • kertoimella F, tulos lisätään voucherin arvoon V ja lopputulos asetetaan saata- • · · vaksi kohdassa 308C2. Kertoimen arvo voi aina olla nolla, tai jos tyypin T1 pu- :.’*i heluyksiköt ovat kalliimpia kuin tyypin T2 puheluyksiköt, kertoimen arvo voi olla • · V.: 25 yksi, tai jos tyypin T1 puheluyksiköiden hinta on puolet tyypin T2 puheluyksi- I·· v : köiden hinnasta, kertoimen arvo voi olla 0.5. Operaattorilla on vapaus määri tellä etukäteen kertoimen arvoja erilaisille T1:n ja T2:n yhdistelmille. Keksintö ·:··· ei rajoita tätä vapautta, kunhan vähintään yksi kertoimen arvo on määritelty .···. silloin, kun käytetään tätä kertomismenetelmää.

,*·* 30 Sen jälkeen, kun saatava on päivitetty yhdellä edellä kuvatuista ta- • " voista, IVR asettaa viimeksi käytetyn voucherin tyypiksi T2 kohdassa 309. Sen jälkeen IVR jatkaa tunnetun tekniikan mukaisesti merkitsemällä voucherin ID2 : käytetyksi kohdassa 310.

·«« ·

Kuvioissa 2 ja 3 esitetyt kohdat eivät ole absoluuttisessa aikajär-35 jestyksessä. Osa edellä selitetyistä kohdista voi tapahtua samanaikaisesti tai eri järjestyksessä tai jotkut kohdista voidaan hypätä yli, esimerkiksi kohta 210.

8 107978

On myöskin mahdollista lisätä uusia kohtia, joita ei ole näytetty kuviossa, esimerkiksi erilaisia vihjeen antoja voidaan lisätä kuvioon 3. On myös mahdollista yhdistää kuviosta 2 ja kuviosta 3 kohtia, kun tehdään uusia suoritusmuotoja. On myös mahdollista, että kun IVR saa tulevan (incoming) puhelun, se tarkis-5 taa, onko soittaja etukäteen maksanut tilaaja, hakee nykyisen saatavan ja antaa vihjeeksi sen, jos soittaja on etukäteen maksanut tilaaja, tai antaa vihjeeksi informatiivisen sanoman, jos soittaja ei ole tilaaja. Näissä suoritusmuodoissa kohtia 204 ja 233 tai 308A ei tarvita. Olennaista on, että voucherin tyypin muutos havaitaan esimerkiksi vertaamalla viimeksi käytetyn ja uuden vouche-10 rin tyyppiä ja valinta, kuinka saatava päivitetään, riippuu siitä, onko muutos havaittu (esimerkiksi perustuu vertailun tulokseen).

Kuvion 4 toiminnallinen malli on toinen tapa havainnollistaa tilaajan saatavan päivitystä keksinnön edullisessa suoritusmuodossa. Tämä kuvio ei havainnollista varsinaista signalointia, koska IP:ssä olevan IVR:n ja SMP.n vä-15 linen kommunikaatio on yleensä TCP/IP LAN SMI:n kautta. Lisäksi yleensä IP:n ja SMP:n välillä ei ole signalointiyhteyttä. Myös tilaajan matkaviestimen ja IP:ssä olevan IVR:n välinen kommunikaatio on DTMFillä tai äänellä. Tässä esimerkissä oletetaan, että saatavan päivittäminen tapahtuu IN:n ohjauksessa, mutta tämä ei ole tarpeellista keksinnölle. Toinen tässä tehty oletus on, että IN

·.*, 20 vastaa myös etukäteen maksetun SIM-kortin käytettävissä olevien saatavien • · · .1/ seuraamisesta. Vielä eräs tässä tehty oletus on, että SCP ei ohjaa puheluita * . IVR:lle, koska ne reititetään suoraan IP:hen palvelunumeron perusteella. Li- • · · säksi oletetaan, että tilaaja on etukäteen maksanut tilaaja, joka aikoo muuttaa • ♦ · *· / liittymää, se on muuttaa voucherin tyyppiä.

v.: 25 Kuviossa 4 esitetty skenaario alkaa, kun tilaaja on ostanut uuden • · · v : voucherin ja soittanut IVR:ään, ja lähettää tapahtuman 4-1 (tallenna) IVR:lle.

IVR kysyy voucherin tunnistenumeroa tapahtumassa 4-2 (hae voucher id). Ti- *:··: laaja antaa (DTMF-valinnoilla) voucherin tunnistenumeron IVR.IIe tapahtu- ·“*: massa 4-3 (hae voucher id kuittaus). Sitten IVR kysyy SMP:ltä voucherin ar- ··» 30 voa tapahtumassa 4-4 (hae voucherin arvo). SMP tarkistaa voucheriin liitty- • · vistä tiedoistaan voucherin arvon tapahtumasta 4-4 saamansa voucherin tun- • · *·*.* nistenumeron avulla ja palauttaa arvon IVR:lle tapahtumassa 4-5 (hae vouche- • :*; rin arvo kuittaus). Sitten IVR kysyy SMP:ltä, mikä oli viimeksi käytetyn vouche-*♦* · rin tunnistenumero tapahtumassa 4-6 (hae viimeksi käytetty voucher). Joissain • · 35 muussa suoritusmuodossa IVR voi kysyä viimeksi käytetyn voucherin tyyppiä. SMP tarkistaa tilaajaan liittyvistä tiedoistaan viimeksi käytetyn voucherin tun- 107978 g nistenumeron ja lähettää sen IVR:lle tapahtumassa 4-7 (hae viimeksi käytetty voucher kuittaus).

Sitten IVR määrittelee viimeksi käytetyn voucherin ja uuden vouche-rin tyypit tunnistenumeroista käymällä läpi listan tai listoja, joilla tyyppi voidaan 5 määritellä. Kuten edellä on todettu, se voi määrittää tyypin vaihtoehtoisesti esimerkiksi tunnistenumeron ensimmäisestä numerosta tai kahdesta ensimmäisestä numerosta. Kuviossa 4 havainnollistetussa esimerkissä IVR vertaa kohdassa 4-8 vouchereiden tyyppejä ja havaitsee, että vouchereiden tyypit eroavat toisistaan. Niinpä IVR antaa vihjeen tapahtumassa 4-9 (hyväksy 10 poisto) tilaajalle, että hänen profiilinsa muuttuu ja nykyinen saatava asetetaan nollaksi, jos tilaaja hyväksyy sen. Tässä esimerkissä tilaaja hyväksyy poiston ja lähettää tapahtuman 4-10 (poisto hyväksytty) IVR:lle. Vasteena hyväksyvälle tapahtumalle 4-10 IVR lähettää tapahtuman 4-11 (kirjaa profiilin muutos) SMP:lle. Tämä tapahtuma sisältää edullisesti parametrit, jotka osoittavat tilaa-15 jän, mikä on nykyinen saatava, mikä oli viimeksi käytetty voucherin tyyppi ja päiväyksen. Tapahtuma 4-11 voi myös sisältää parametrin, joka osoittaa uuden voucherin tyypin ja/tai sen arvon. SMP päivittää lokitiedostonsa tapahtumassa 4-11 saamillaan tiedoilla ja lähettää kuittauksen tapahtumassa 4-12 (kirjaa kuittaus).

·.·, 20 IVR päivittää saatavaksi voucherin arvon kohdassa 4-13 ja lähettää t i · arvon SMP:lle tapahtumassa 4-14 (aseta saatava). SMP asettaa nykyiseksi * saatavaksi arvon, jonka se sai tapahtumassa 4-14, tilaajaan liittyvään tietoon • « · ’·*··] ja lähettää kuittauksen tapahtumassa 4-15 (aseta saatava kuittaus). Sen jäl- V·: keen IVR lähettää SMP:Ile tapahtuman 4-16 (merkitse käytetyksi) kertoen sitä • · \v 25 merkitsemään uuden voucherin käytetyksi. SMP merkitsee voucherin käyte-v · tyksi voucheriin liittyvissä tiedoissaan ja lähettää kuittauksen tapahtumassa 4- 17 (merkitse käytetyksi kuittaus). Sitten IVR lähettää tapahtuman 4-18 *:·»: (katkaise) tilaajalle. Sen jälkeen puhelu katkaistaan ja SMI-yhteys SMPille .**·. suljetaan tunnettujen proseduurien mukaisesti. Joissain muussa suoritusmuo- 30 dossa IVR kysyy ensin saatavan SMP:ltä ja antaa sen vihjeeksi tilaajalle en- • · nen tapahtuman 4-18 (katkaise) lähettämistä.

Joissain muussa suortusmuodossa IVR voi kysyä uuden voucherin : tyyppiä SMP:ltä ja sen sijaan, että kysyy tapahtumassa 4-6 tunnistenumeroa, kysyy viimeksi käytetyn voucherin tyyppiä. SMP voisi tarkistaa listansa 35 voucherin tyyppien määrittelemiseksi tunnistenumeroiden pohjalta ja palauttaa 10 107978 tyypit IVR:lle. Voucherin tyypin selvittämiseksi voidaan käyttää myös jotain muuta menetelmää.

Jos tapahtuma 4-10 on "poistamista ei hyväksytä” -tapahtuma, sitten sen vastaanottamisen jälkeen IVR lähettää tapahtuman 4-18 (katkaise) ti-5 laajalle tapahtuman 4-11 asemesta. Silloin ei tehdä tallennusta, nykyistä saatavaa ennen päivitystä ei menetetä, eikä uutta voucheria merkitä käytetyksi. Tilanne jää sellaiseksi ikäänkuin puhelua ei olisi ollenkaan tehty.

Kuviossa 4 olevat tapahtumat ja kohdat eivät ole absoluuttisessa aikajärjestyksessä. Jotkut edellä selitetyistä kohdista ja tapahtumista voivat 10 tapahtua samanaikaisesti tai eri järjestyksessä, esimerkiksi tapahtumat 4-4 ja 4-6. Tapahtumat voivat sisältää enemmän tietoa kuin mitä edellä on sanottu. Tapahtumien nimet voivat poiketa edellä esitetyistä tai keksinnön mukaisesti tarvittava tieto voidaan lähettää muissa kuin edellä sanotuissa tapahtumissa. Myös muita tapahtumia, joita ei ole esitetty kuviossa 4, voidaan lähettää tai ne 15 voivat tapahtua edellä sanottujen tapahtumien välissä.

Vaikka keksintöä on edellä selostettu edullisilla suoritusmuodoilla, joissa on käytetty vain yhtä tilaajaa, on alan ammattilaiselle ilmeistä, että useita talletusproseduureja voi olla käynnissä rinnakkaisesti, kunhan niille osoitetaan uniikit kanavat siten, että tilaajat eivät sekoitu. Myös muita toimin-20 teitä kuin saatavan päivittäminen voidaan päivittää ja/tai ottaa huomioon, kun saatavaa päivitetään, vaikka niitä ei selitetä tässä yksityiskohtaisemmin. Eräs ** mahdollinen toiminne on voucherille annettu validiteettiaika.

• " Oheiset kuviot ja niihin liittyvä selitys on ainoastaan tarkoitettu ha- ·ί·: vainnollistamaan esillä olevaa keksintöä. Alan ammattilaiselle tulevat olemaan • · V·: 25 ilmeisiä erilaiset keksinnön variaatiot ja muunnelmat ilman että poiketaan • · oheisissa patenttivaatimuksissa esitetyn keksinnön suojapiiristä ja hengestä.

• · · • · · • · 1 • · i»· • · • · · • · • · • ·· • · · • · • · • · · · • · · • · · • · · · • « • · · • · · • ·

Claims (14)

107978

1. Menetelmä tilaajan tilin saatavan päivittämiseksi tietoliikennejärjestelmässä, jossa ainakin kahta erilaista vouchertyyppiä voidaan käyttää tallettamiseen tilille; 5 tunnettu siitä, että menetelmä käsittää askeleet; määritetään ainakin kaksi erilaista tapaa saatavan päivittämiseksi (212, 222, 308); ylläpidetään tietoa, joko osoittaa parhaillaan käytetyn ensimmäisen voucherin tyypin (206, 306); 10 vastaanotetaan talletus, joka identifioi toisen voucherin (202, 302); määritellään toisen voucherin tyyppi (207, 303); ja valitaan saatavan päivittämistapa ensimmäisen voucherin ja toisen voucherin tyyppien perusteella (307, 208).

2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, 15 että menetelmä käsittää lisäksi askeleet tarkistetaan, ovatko ensimmäinen voucher ja toinen voucher samaa tyyppiä (208); ja päivitetään saatava lisäämällä toisen voucherin arvo saatavaan (222), jos voucherit ovat samaa tyyppiä; tai . . 20 päivitetään saatava asettamalla saatavaksi toisen voucherin arvo • * *;*·* (214), jos voucherit ovat eri tyyppiä.

• · : ** 3. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että menetelmä käsittää lisäksi askeleet • * tarkistetaan, ovatko ensimmäinen voucher ja toinen voucher samaa :X: 25 tyyppiä (307); ja :T; päivitetään saatava lisäämällä toisen voucherin arvo saatavaan (308B), jos voucherit ovat samaa tyyppiä; tai määritellään kerroin (308C1), kerrotaan saatava kertoimella ja lisä-tään kertolaskun tulos toisen voucherin arvoon ja asetetaan saatavaksi lisää-30 misen tulos, jos voucherit ovat eri tyyppiä.

< · · : *** 4. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, • · · •mmm· että määritellään kerroin ensimmäisen ja toisen voucherin tyyppien perus- : !·. teella.

♦ · * .* 5. Jonkin edellä olevan vaatimuksen mukainen menetelmä, tun- ♦ · · • · · * * 35 n e 11 u siitä, että menetelmä käsittää lisäksi askeleet; 107978 kysytään tilaajalta lupa päivittää saatava, jos voucherit ovat eri tyyppiä (211); ja päivitetään saatava ainoastaan, jos lupa vastaanotetaan tilaajalta.

6. Jonkin edellä olevan vaatimuksen mukainen menetelmä, t u n -5 n e 11 u siitä, että määritellään vouchereiden tyypit niiden tunnistenumeroista.

7. Jonkin edellä olevan vaatimuksen mukainen menetelmä, tunnettu siitä, että tietoliikennejärjestelmä on matkaviestinjärjestelmä.

8. Järjestely (IP, SMP) tilaajan tilin saatavan päivittämiseksi tietoliikennejärjestelmässä, jossa tilaajat voivat etukäteen maksaa puheluistaan tallo lettamalla tileilleen ainakin kahdella erityyppisellä voucherilla ja jossa saatava päivitetään ensimmäisellä tavalla, tunnettu siitä, että järjestely on sovitettu: havaitsemaan voucherin tyypin muutos (4-8), kun saatava päivitetään; 15 vasteena havaitsemiselle päivittämään saatavan toisella tavalla (4- 13).

9. Patenttivaatimuksen 8 mukainen järjestely, tunnettu siitä, että järjestely on lisäksi vasteena havaitsemiselle sovitettu kysymään tilaajalta lupaa saatavan päivittämiseksi (4-9) ja päivittämään saatavan vain vasteena 20 luvalle (4-10).

·.·. 10. Patenttivaatimuksen 8 tai 9 mukainen järjestely, tunnettu • · · siitä, että järjestely on lisäksi sovitettu havaitsemaan voucherin tyypin muutos * ** (4-8) määrittelemällä viimeksi käytetyn voucherin tyyppi ja uuden voucherin • · · tyyppi ja vertaamalla näitä tyyppejä. • · · ’· *· 25

11. Patenttivaatimuksen 8, 9 tai 10 mukainen järjestely, tun- n e 11 u siitä, että järjestely käsittää älyverkon älykkään oheislaitteen (IP), joka • · · v ·' käsittää vuorovaikutteisen äänivastauspalvelun (IVR), jonka välityksellä saatavat päivitetään.

·:··· 12. Tietoliikennejärjestelmän verkkoelementti, jossa järjestelmän ti- .·**. 30 laajat voivat maksaa puhelunsa etukäteen tallettamalla tileilleen rahaa ainakin ..· kahdella erityyppisellä voucherilla, joka elementti sisältää tietokannan tai yhte- • · : y yden tietokantaan (SM), jossa tilien saatavia ylläpidetään, tu n nettu siitä, että • verkkoelementti (IP) on järjestetty määrittelemään tilaajan viimeksi ··· · : 35 käytetyn ja uuden voucherin, jolla tilaaja aikoo päivittää saatavaansa, tyypit ja • · 107978 valitsemaan saatavan päivitystäpä ainakin kahdesta eri päivitystavasta mainittujen vouchereiden tyyppien perusteella.

13. Patenttivaatimuksen 12 mukainen verkkoelementti, tunnettu siitä, että verkkoelementti (IP) on lisäksi järjestetty kysymään tilaajalta 5 lupaa päivittää saatava vasteena sille, että mainitut voucherit ovat eri tyyppiä, ja päivittämään saatava vain vasteena vastaanotetulle tilaajan luvalle.

14. Patenttivaatimuksen 12 tai 13 mukainen verkkoelementti, tunnettu siitä, että verkkoelementti (IP) on lisäksi järjestetty määrittelemään kerroin vasteena sille, että mainitut voucherit ovat eri tyyppiä, ja kerto- 10 maan tilaajan nykyinen saatava kertoimella, lisäämään kertolaskun tuloksen toisen voucherin arvoon ja asettamaan saatavaksi mainitun lisäämisen tuloksen. • · • · • · · « « • 1 • · • · · • · · • · · • · · • · • · · • · • · • · • « · • · · ♦ · ♦ ·· • · · • · · ♦ · • · · • · ·« · * ♦ » · • · ♦ · · « • ·· • · · · • ♦ · • · ♦ · · • · · ··· · · • · · • · · • · 107978