FI111879B - Käyttäjäprofiilin hallinta tietoliikenneverkossa - Google Patents

Description

, 111879 Käyttäjäprofiilin hallinta tietoliikenneverkossa Keksinnön ala

Keksintö liittyy yleisesti palvelujen tarjoamiseen tietoliikennever-5 kossa. Tarkemmin sanottuna keksintö koskee järjestelmää, joka antaa käyttäjäkohtaista tietoa verkossa, jossa tarjotaan yksilöllistettyjä palveluja.

Tekniikan tausta

Internetin käyttäjien ja sen kautta tarjottavien palvelujen valtava 10 kasvu on ollut yksi huomattavimmista ilmiöistä tietoliikenteessä viime vuosi na. Internetin suosio osoittaa sen, että ihmiset ovat innokkaita soveltamaan tekniikkaa elämässään. Kuitenkin sitä mukaa kun verkossa tarjolla olevat palvelut laajenevat ja monimutkaistuvat, muuttuu myös maksimaalisen hyödyn saavuttaminen palveluista paljon vaikeammaksi. Esimerkiksi jos käytet-15 tävissä olevalle hakukoneelle esittää yksinkertaisen kyselyn, saa tavallisesti tulokseksi tuhansia sivuja asiaankuulumatonta tietoa, joka täytyy käydä lävitse manuaalisesti. Toinen esimerkki voidaan ottaa tietoliikenteen maailmasta. Orastavilla avoimilla tietoliikennemarkkinoilla asiakkailla tulee olemaan mahdollisuus ostaa juuri heidän tarpeilleen ja makuunsa sopivia edullisia palvelu-20 ja. Tähän saattaa liittyä hankalia päätöksiä, jotka liittyvät räätälöityjen palve-lujen laatuun ja palvelun tarjoajan valintaan, erityisesti silloin, kun asiakas on • '·· kotiverkkonsa ulkopuolella. Jotta maksimaalinen hyöty saataisiin käyttöön, käyttäjien on tunnettava monia palveluntarjoajia ja käytävä neuvotteluja hei-·:··· dän kanssaan. Tämä vaatii liian usein valtavia ponnisteluja; tarjolla on käyttä- 25 jien kannalta liian monta vaihtoehtoa ja liian paljon tietoa. Tämä kasvava .···. kompleksisuus johtuu osaksi siitä, että perinteiset hakukoneet muutetaan webbiportaaleiksi, jotka tarjoavat monen eri alan palveluja.

Molemmissa yllämainituissa esimerkeissä melko älykästä tekniikkaa voidaan hyödyntää valintaprosessin automatisoimisessa. On kuitenkin ·;·' 30 saatava jotain tietoa käyttäjästä, jotta halutut tavoitteet saavutettaisiin. Tä- :Y: män tiedon tarjoaa käyttäjäprofiili. Se mitä profiili sisältää riippuu palvelusta, • · mutta ratkaisevana tavoitteena voisi pitää käyttäjän korkeatasoisen kuvauk- •« · sen muodostamista. Palveluntarjoajat voivat siten hyödyntää tätä kuvausta • · · '"l voidakseen tarjota kullekin käyttäjälle räätälöityjä palvelujaan. Toisin sanoen '···* 35 näiden profiilien avulla palveluntarjoajat voivat sovittaa sovelluksen toiminnan 2 111879 käyttäjille sopivaksi. Tätä käyttäjäprofiilien luomisprosessia, tai käyttäjiin tutustumista, kutsutaan profiloinniksi.

Profiloinnista on tullut tärkeä seikka ratkaistaessa yllämainittuja ongelmia, jotka liittyvät palvelujen monimutkaistumiseen ja valtavaan infor-5 maatiovyöryyn. Tämä johtuu siitä, että profilointi mahdollistaa palvelujen yksilöllistämisen, joka puolestaan tarjoaa räätälöityä apua käyttäjille yllämainituista ongelmista selviytymiseen. Yksilöllistäminen on prosessi, jossa sovelletaan käyttäjäprofiilin tietoja, jotta saataisiin tuloksia, jotka sopivat yksittäisen käyttäjän tarpeisiin. Nykyään monet webbiportaalit ovat menossa tähän 10 suuntaan tarjoamalla keinoja informaatiosisällön suodattamiseen käyttäjän intressien perusteella.

Vaikkakin yksilöllistäminen on nähty keinona ratkaista edellä mainitut ongelmat, nykyinen teknologia ei siihen vielä kykene, ja jo olemassa oleviin järjestelmiin liittyy monenlaisia ongelmia. Näitä esitellään seuraavassa 15 lyhyesti.

Tällä hetkellä käyttäjien on annettava profiilitietonsa kullekin yksittäiselle palveluntarjoajalle. Tämän vuoksi tarkkojen profiilien luomiseen tarvitaan paljon sekä palveluntarjoajien että käyttäjien resursseja. Jo siitä hetkestä lähtien, jolloin käyttäjät rekisteröityvät palveluun, heidän täytyy täyttää lu-20 kemattomia lomakkeita, jotka koskevat henkilökohtaisia ominaisuuksia ja li-sääntyvässä määrin myös mieltymyksiä. Palvelut muodostavat käyttäjien pro-: *·· fiilit alkuperäisistä tiedoista ja niistä havainnoista, jotka ne ovat saaneet ol- lessaan vuorovaikutuksessa käyttäjien kanssa. Jokaisen uuden palveluntar-:··: joajan opettaminen nollatilanteesta vie aikaa ja on käyttäjien kannalta tur- ;···. 25 hauttavaa työtä. Koska käyttäjän on syötettävä profiilitiedot jokaiselle palve- .··. luntarjoajalle, yksittäisen käyttäjän tiedot hajaantuvat ympäri verkkoa, ja eri • · palveluntarjoajilla on erilaiset tiedot käyttäjästä. Haittapuolena tässä on se, että palveluntarjoaja ei voi ainakaan suoraan hyödyntää toisen palveluntarjoajan profiilia. Profiilien hallinta voi myös aiheuttaa ongelmia. Esimerkiksi ”·’ 30 sähköpostiosoitteen päivitys jokaiselle palvelulle voi helposti muodostua ylit- : V: sepääsemättömäksi tehtäväksi. Vaikka palvelut tarjoaisivatkin välineistön päi- vitykseen, kaikkien kyseessä olevien palvelujen tiedottaminen asiasta on vaikeaa. Siksi käyttäjän mahdollisuudet ja motivaatio profiilien ylläpitämiseen :. #; ’ ovat heikot, ja profiilien tarkkuus heikkenee.

‘ · · · * 35 Eräs ongelma, joka liittyy jokaisen palvelun omien käyttäjäprofiilien ylläpitoon on lisäksi se, että yksittäisen palvelun näkymä käyttäjistä on hyvin 3 111879 rajallinen. Tämän vuoksi käyttäjä ei pysty hyödyntämään palvelua mahdollisimman tehokkaalla tavalla.

Vielä eräs tärkeä ongelma, joka liittyy nykyiseen tilanteeseen, on käyttäjien yksityisyys. On selvää, että sellaisten henkilökohtaisten tietojen, 5 kuten käyttäjäprofiilien, tallentaminen internetin kaltaiseen avoimeen ja jaettuun järjestelmään vaatii huolellista käyttäjän yksityisyyden huomioimista. Koska käyttäjät eivät voi nykytilanteessa kontrolloida kattavasti profiiliensa sisältöä ja käyttöä, käyttäjien yksityisyys on helposti murrettavissa. Käyttäjällä ei ole esimerkiksi mitään keinoja estää pahantahtoisen osapuolen pääsyä 10 yksittäisen palvelun profiilitietoihin tai eri palvelimilla olevien tietojensa yhdistämistä.

Jotkut äskettäin toteutetut järjestelmät jotka käyttävät käyttäjämal-lia toimivat paikallisesti käyttäjän päätteessä (esim. henkilökohtainen tietokone). Erästä tällaista kuvataan esim. US-patentissa 5,913,030, jossa kuvataan 15 asiakkaan työaseman ja siihen liitetyn palvelimen välillä olevaa tietoliikennejärjestelmää. Käyttäjän tiedot on tallennettu asiakasjärjestelmään (eli asiakkaan päätteeseen). Käyttäjän tiedot käsittävät monta attribuuttia, joista jokainen sisältää käyttäjään liittyvää tietoa ja suostuvaisuusindikaattorin, joka osoittaa käyttäjän halukkuuden paljastaa kyseiseen attribuuttiin liittyvää tie-20 toa. Pääte voi käsittää myös useita henkilömoduuleita, joista jokainen sisäl-tää tietoja, jotka määrittelevät käyttäjän tietyn persoonan. Käyttäjän yksityi-: *·· syyttä voidaan suojella myös siten, että tietoa käyttäjästä lähetetään luotetta- valle kolmannelle osapuolelle, joka paljastaa palveluja tarjoavalle palvelimelle ·:··: vain yleisiä demografisia tietoja kaikista käyttäjistä. Henkilömoduuli voidaan 25 varustaa myös naamioivalla toiminnolla, joka generoi väärää tietoa käyttäjäs-tä.

Sellaisten järjestelmien, joissa käyttäjäprofiilit ovat työasemassa, suurimpia haittapuolia on se, että käyttäjämallien hyödyntäminen on rajattu vain kyseiseen päätteeseen, esim. tavallisesti kiinteään paikkaan, ja käyttä-30 jämallien sisältämien tietojen levittäminen on rajoittunutta.

:Y: Nykyään on olemassa myös palvelimeen perustuvia järjestelmiä, jotka mahdollistavat käyttäjälle yksilölliset webbipalvelut, jotka tarjoavat tieto- • · · suojan. Eräs tällainen palvelu on ProxyMate (aik. Lucent Personalized Web • « · : Assistant, osoitteessa www.proxymate.com). ProxyMate on keskittynyt tar- ·...· 35 joamaan käyttäjille keinoja olla yhteydessä useaan palvelimeen siten, että yksittäinen palvelin, joka tarjoaa tiettyä palvelua ei voi selvittää käyttäjän 4 111879 identiteettiä, vaikka samanaikaisesti käyttäjä voidaan tunnistaa ja autenti-koida hänen käydessä toistuvasti palvelimella. Tämä on mahdollista siksi, että webbikäyttäjille on luotu turvallisia ja varmoja salanimiä ja siksi, että webbipalvelimille tuleva liikenne on anonymisoitu. ProxyMatea voidaan käyt-5 tää myös sähköpostien välittämiseen. Yksi tärkeimmistä ProxyMaten suunnittelukriteereistä on ollut se, että se toimii tilattomasti. Se ei ylläpidä minkäänlaisia pitkäikäisiä tiloja, esim. käyttäjien ja salanimien välisiä määrittelyjä. Päinvastoin, kaikki salanimet generoidaan pyydettäessä yksisuuntaisella funktiolla. ProxyMate toimii webbiliikenteen proxyna. Tämän vuoksi se voi 10 sijaita ja sitä voidaan käyttää missä tahansa verkossa. Palvelimeen perustuvat järjestelmät edellyttävät, että käyttäjä luottaa niihin. Vaikka niiden rakenne on teoriassa sellainen, että niiden ei tarvitse ylläpitää tilaa palvelu-istunnon ulkopuolella, voi toteutus esim. kerätä lokia käyttäjän toimenpiteistä. Toinen haittapuoli tällaisissa palvelimeen perustuvassa järjestelmissä on se, 15 että käyttäjän yhteys palveluja tarjoavaan palvelimeen menee aina näiden proxy-palvelimien kautta. Tämä rajoittaa niitä tapoja, joilla voidaan päästä haluttuihin tietoihin. Lisäksi alituinen reititys tiettyjen proxyjen lävitse johtaa verkon tiedonsiirtoresurssien tehottomaan käyttöön, ja näistä proxy-palveli-mista voi tulla pullonkauloja, joilla on haitallinen vaikutus palvelujen vaste-20 aikoihin.

Eräitä agenttijärjestelmiä on kuvattu lisäksi julkaisuissa GB-2335761-A, GB-2328110-A ja WO-96/23265. Eräs järjestelmä profiilitietojen ’. -. t hallintaan on esitetty vielä julkaisussa EP-0944002-A1.

‘Esillä olevan keksinnön tarkoituksena on saavuttaa ratkaisu, jonka 25 avulla on mahdollista lieventää tai poistaa ylläkuvattuja haittoja, ja saada aikaan järjestelmä, jonka avulla verkonkäyttäjät voivat kontrolloida kattavasti • profiilejaan.

Keksinnön lyhyt yhteenveto 30 Tämä ja keksinnön muut päämäärät saavutetaan esillä olevan keksinnön periaatteiden mukaisesti luomalla järjestelmä, jossa yksittäisen I · :;! käyttäjän profiilitiedot sijoitetaan profiiliagenttiin, joka on varattu vain kyseisen :·’ käyttäjän käyttöön. Täten jokaiselle käyttäjälle annetaan profiiliagentti, jonka ; *,*. avulla käyttäjä pystyy kontrolloimaan digitaalisia identiteettejään, toisin sano- 35 en identiteettejä, jotka palvelusovellukset näkevät käyttäjinä. Tällä tavalla on mahdollista tarjota yksittäisen profiiliagentin avulla sovellettavissa olevia 5 111879 profiilitietoja huomattavalle määrälle palveluja, jotka tarvitsevat erityyppisiä profiilitietoja.

Jokaisella käyttäjäkohtaisella profiiliagentilla on monikerroksinen rakenne siten, että käyttäjän profiilitietoihin pääsee vain ylimmän kerroksen 5 kautta, joka käsittää sopimuksia, jotka muodostavat rajapintoja käyttäjäkohtaisen tiedon ja verkon välillä. Käyttäjäkohtaiset profiiliagentit sijaitsevat erityisissä palvelimissa, joita kutsutaan tässä yhteydessä hostelleiksi, ja verkko käsittää lisäksi hakujärjestelmän, jonka avulla voidaan kysellä tietyn sopimuksen paikkaa. Palvelusovellukset pääsevät käyttäjäkohtaisiin tietoihin 10 ainoastaan tätä tarkoitusta varten tehdyn sopimuksen välityksellä. Sopimus määrittelee ne informaationimikkeet, jotka palvelusovellus näkee käyttäjäkohtaisesta datasta ja myös sen millä tavalla palvelu voi prosessoida mainittuja nimikkeitä. Jokainen sopimus muodostaa käyttäjäkohtaisen datan rajapinnan palvelulle tai palveluryhmälle. Sopimukset liittävät täten tietyt 15 näkymät tai profiilit tiettyihin palveluihin. Yksi palvelu voi kuitenkin käyttää myös useampaa kuin yhtä sopimusta päästäkseen käyttäjäkohtaiseen dataan. Tässä tapauksessa palvelu ei voi tunnistaa sitä, että kaksi sopimusta liittyy samaan käyttäjään.

Keksinnön edullisessa toteutustavassa käyttäjän profiilitiedot 20 leviävät ainoastaan käyttäjän määrittelemien digitaalisten identiteettien väli-tyksellä. Nämä identiteetit muodostavat välikerroksen, joka on sopimusten, jotka muodostavat käyttäjäprofiiliagentin ulommaisen kerroksen, ja perus- * »· ' profiilidatan välillä, joka puolestaan muodostaa käyttäjäprofiiliagentin sisim mäisen kerroksen. Mikään palveluista ei pääse perusdataan. Identiteetit, joita * ' ‘ > · 25 kutsutaan tässä yhteydessä persooniksi edustavat käyttäjän perusprofiili- * · ‘ ··' dataan olevia pysyviä näkymiä. Palvelut näkevät ainoastaan nämä näkymät, :eivätkä ne erota sitä, kuuluuko kaksi erilaista näkymää samalle käyttäjälle vai ei.

; Käyttäjien yksityisyydellä on siis keskeinen rooli järjestelmässä, 30 koska käyttäjäprofiili on keskitetty agenttiin, jota käyttäjä tai käyttäjän t \ valtuuttama osapuoli pystyy valvomaan. Lisäksi kahden sopimuksen yhteen- kuuluvuutta on vaikea osoittaa, ja sopimusten takana olevaa agenttia on * · *:·’ vaikea paljastaa.

Lisäksi, koska profiiliagentit voivat olla liikkuvia, niitä ei ole sidottu 35 tiettyihin tarjoajiin, ja näin profiilin elinikä on rajoittamaton.

»· · 6 111879

Kuvioluettelo

Seuraavassa keksintöä ja sen edullisia toteutustapoja selostetaan yksityiskohtaisemmin viitaten kuvioiden 1-14 esimerkkeihin oheisissa piirustuksissa, joissa 5 kuvio 1 esittää esillä olevan keksinnön mukaisen järjestelmän arkkitehtuuria, kuvio 2 esittää yksittäisen käyttäjäkohtaisen profiiliagentin yleistä rakennetta, 10 kuvio 3 esittää palvelusovelluksen yhteistoimintaa profiiliagentin kanssa, kuvio 4a esittää käyttäjän profiiliagentin alimman kerroksen tyypillistä rakennetta ja informaatiosisältöä, kuvio 4b esittää käyttäjän profiiliagentin alimman kerroksen sisällä olevan yksittäisen nimikkeen tyypillistä rakennetta ja sisältöä, 15 kuvio 5 on esimerkki käyttäjän profiiliagentin alimmaisen kerroksen sisällöstä, kuviot 6 ja 7 ovat esimerkkejä käyttäjän profiiliagentin keskimmäisen kerroksen kahden eri persoonan sisällöstä, kuviot 8 ja 9 ovat esimerkkejä käyttäjän profiiliagentin ulommaisen kerroksen 20 kahden eri sopimuksen sisällöstä, kuvio 10 on esimerkki järjestelmän elementtien välisestä sanoman siirrosta, kun käyttäjä luo oman profiiliagentin itselleen, kuvio 11 on esimerkki järjestelmän elementtien välisestä sanoman siirrosta, • kun luodaan sopimus palvelusovellukselle, .···. 25 kuvio 12 on esimerkki järjestelmän elementtien välisestä sanoman siirrosta yleisen informaatiopyynnön yhteydessä, jonka käyttäjän profiili-agentti on vastaanottanut, kuvio 13 on esimerkki järjestelmän elementtien välisestä sanoman siirrosta, kun käyttäjän profiiliagentti liikkuu verkossa, ja 30 kuvio 14 esittää hakujäijestelmän rakennetta.

• » « .***. Keksinnön yksityiskohtainen selostus

Kuviossa 1 esitetään esillä olevan keksinnön mukaisen yleisen jär-: ·* jestelmän arkkitehtuuria. Järjestelmä käsittää useita palvelimia (S1 - S3), jot- ·...· 35 ka tarjoavat laajan valikoiman resursseja ja palveluja verkon käyttäjille. Tässä esimerkissä kaikki palvelimet ovat internetin tai intranetin solmuja (tai vastaa- 7 111879 via TCP/IP verkkoja). Tässä yhteydessä termi ’’palvelu” viittaa palvelimessa olevaan palvelusovellukseen.

Käyttäjien päätteiltä (UT1 ja UT2) on pääsy palveluja tarjoaviin palvelimiin sinänsä tunnetulla tavalla. Päätteet voivat olla kiinteitä päätteitä, 5 kuten päätteen UT1 yhteydessä on esitetty, tai liikkuvia päätteitä, joilla on langaton yhteys järjestelmään tai verkkoon, kuten päätteen UT2 yhteydessä on esitetty. Langaton liittymä voidaan toteuttaa usean liittymäpisteen (AP1) välityksellä tai vaihtoehtoisesti yhdyskäytävän (GW1) välityksellä, joka muuttaa pyynnöt yhdyskäytävän ja päätteen välillä käytetystä protokollapinosta, 10 kuten WAP protokollapinosta, protokollapinoon, jota käytetään yhdyskäytävän ja palvelimen välillä, eli WWW-protokollapinoon (HTTP ja TCP/IP).

Mitä tulee keksinnön mukaiseen ajatukseen, niin käyttäjien päätetyypit ja käyttäjien päätteiden ja palveluja tarjoavien palvelimien väliset yhteydet eivät ole merkityksellisiä. Tässä yhteydessä ainoa päätteiden olennai-15 nen piirre on se, että ne on varustettu selaimilla tai muilla tunnetuilla asiakasohjelmilla, joiden avulla ne voivat olla yhteydessä palveluja tarjoaviin palvelimiin. Tämä kommunikointi tapahtuu ensisijaisesti HTTP-protokollan mukaisesti, vaikka palvelimen ja asiakaspäätteen välillä voi olla muuntava yhdyskäytävä, kuten yllä on mainittu.

20 Järjestelmä käsittää edelleen käyttäjäkohtaiset profiiliagentit PA, joten jokaisella järjestelmän käyttäjällä on edullisesti yksi profiiliagentti vain \ ·. kyseistä käyttäjää varten. Profiiliagentilla tarkoitetaan tässä ohjelmaa, joka voi suorittaa tehtäviä käyttäjänsä puolesta ja joka tallentaa käyttäjän profiili-·:··; datan. Täten yksittäinen profiiliagentti on kiinteä kokonaisuus, jolle käyttäjä .···. 25 voi antaa tehtäväksi koordinoida profiilinsa. Yksittäisen profiiliagentin raken- .···. netta, joka käsittää koodia ja dataa, käsitellään tarkemmin tuonnempana ku vioiden 2 ja 3 yhteydessä. Agentit implementoidaan tunnettua teknologiaa . hyväksikäyttäen.

Profiiliagentit sijaitsevat erityisissä palvelimissa, joita kutsutaan • 30 tässä yhteydessä hostelleiksi. Hostelli on yksinkertaisesti järjestelmän alusta :Y: (esim. tietokoneohjelma), joka tarjoaa suoritusympäristön profiiliagenteille ja .*··. yhteyden verkkoon. Yksinkertaisuuden vuoksi kuviossa 1 esitetään vain yksi hostelli, vaikka tavallisesti niitä on verkossa monta.

• · · ’ : ·* Järjestelmä käsittää lisäksi agentinluomisyksiköitä AC, joiden avul- 35 la käyttäjät voivat luoda omat profiiliagenttinsa. Agentinluomisyksiköt voivat sijaita esimerkiksi käyttäjien päätteissä tai hostellien yhteydessä.

8 111879 Käyttäjäkohtaista profiiliagenttia hallitsee vain sen käyttäjä. Esillä olevan keksinnön mukaisessa järjestelmässä käyttäjäprofiili on siis keskitetty agenttiin, jota käyttäjä valvoo. Käyttäjäkohtainen profiiliagentti voi olla kiinteässä paikassa tai se voi olla liikkuva agentti, varsinkin jos käyttäjä on liikku-5 va. Liikkuva profiiliagentti liikkuu mieluiten siten, että se on aina hostellissa, joka on lähinnä käyttäjän kulloistakin sijaintia.

Edistääkseen profiiliagentin liikkuvuutta järjestelmä käsittää lisäksi hakujärjestemän LS, joka tallentaa jokaisen yksittäisen profiiliagentin kulloisenkin sijainnin ja josta profiiliagenttien sijainteja voidaan tiedustella. 10 Hakujärjestelmän rakenteen yksityiskohtia kuvataan enemmän tuonnempana, jossa kuvataan sitä, kuinka jokaisen profiiliagentin sijainti on tallennettu monena sijaintina, joista jokainen osoittaa kulloisenkin osoitteen yksittäiselle sopimukselle, joka on osa profiiliagenttia.

Kuvio 2 esittää yksittäisen profiiliagentin rakenteen sen asiakkai-15 den näkökulmasta. Agentilla on edullisesti kolmikerroksinen rakenne, josta käyttäjän perusprofiili muodostaa alimman kerroksen. Perusprofiili käsittää tavallisesti kaiken datan käyttäjästä, jonka datan käyttäjä tai asiakkaat syöttävät. Keskimmäinen kerros käsittää käyttäjän eri digitaaliset persoonat. Jokainen persoona on muodostettu perusprofiilissa olevasta datasta ja se on 20 tietty käyttäjän määrittelemä näkymä perusprofiiliin. Yksittäinen persoona tai näkymä voidaan muodostaa passiivisesti, toisin sanoen se voi sisältää data-j ·.. yksiköitä, jotka muodostavat ydinprofiilissa olevien datayksiköiden alijoukon, tai aktiivisesti, jolloin halutut perusprofiilin datayksiköt ovat prosessoitavissa, • jotta saataisiin persoonan muodostavat datayksiköt.

.···. 25 Profiiliagentin päällimmäisin kerros koostuu rajapinnoista, joita .···. kutsutaan tässä sopimuksiksi. Sopimukset ovat rajapintoja, joiden kautta käyttäjä ja palvelut voivat päästä profiiliagenttiin. Käyttäjä pääsee aina profii-liagenttiin erityisellä sopimuksella, jota kutsutaan isäntäsopimukseksi, joka on tarkoitettu vain käyttäjän käyttöön. Palvelusovellukset pääsevät digitaalisiin 30 persooniin palvelusopimusten kautta, toisin sanoen palvelut voivat viitata vain :V: sopimuksiin, eivät sopimusten takana oleviin persooniin. Jotta pääsy profiili- .···. dataan olisi mahdollinen, jokaisen palvelun on ensin tehtävä sopimus profiili- agentin kanssa. Kun sopimus on tehty, voi palvelu hyödyntää profiiliagenttia :t ·* mainitun sopimuksen avulla (rajapinta). Jokainen agentti käsittää tyypillisesti 35 yhden sopimuksen palveluntarjoajaa tai palvelusovellusta kohden, vaikka on mahdollista, että yksi sopimus on yhtä palvelusovel- 9 111879 lus/palveluntaijoajaryhmää kohti ja yksi palvelusovellus/palveluntarjoaja voi hyödyntää myös useaa sopimusta.

Sopimukset valvovat siis käyttäjän henkilöllisyyttä. Vaikka arkkitehtuurin näkökulmasta katsottuna sopimukset edustavat pääosin 5 pseudonyymejä kosketuspisteitä profiilidataan, niiden tärkein tehtävä käyttäjien kannalta on rajoittaa asiakkaiden (eli palveluiden) saatavissa olevaa tietoa. Profiiliagentin on sallittava perusprofiilin nimikkeiden muuntaminen näkymistä perusprofiileiksi, ja päinvastoin. Tarvittavat muunnokset ovat tavallisesti hyvin yksinkertaisia, kuten nimen korvaaminen 10 salanimellä ja käyttäjän erilaisten mielenkiinnon kohteiden korostaminen. Perusprofiilin muunnos tehdään tiettyä asiayhteyttä varten. Tavallisesti muunnos tehdään kaikissa tarkastelu-ulottuvuuksissa - kuka, missä, milloin ja mitä. Nämä ulottuvuudet voitaisiin mallintaa itsenäisinä siten, että muunnos voisi olla kaikkien ulottuvuuksien muunnosten summa. Itse asiassa 15 käyttäjää voisi esittää perusprofiili ja lisäksi joukko muunnoksia jokaista ulottuvuutta kohti. Valitsemalla sopiva joukko jokaiselle ulottuvuudelle ja kerrostamalla nämä perusprofiilin päälle saadaan kontekstistä paljon enemmän Häiivio 3 esittää profiiliagentin ja palvelusovelluksen yhteistyötä. Ylimmäisen kerroksen jokainen sopimus CT käsittelee pääsyoikeuksia val-20 vomalla sekä profiiliagenttiin pääseviä olioita että sitä mitä näiden olioiden ;.'S annetaan tehdä, jos pääsy on sallittu. Käyttäjän persoonat puolestaan vas- taavat palvelusovellusten käytettävissä olevaa käyttäjän näkymää. Näky-mät on muodostettu käyttäjän perusprofiilista joko suoraan tai muunnosten välityksellä.

.··. 25 Käyttäjän kapasiteetti ei riitä laajan muunnosjoukon ylläpitämi- seen. Toinen äärimmäisyys eli täydellinen muunnosten puuttuminen ei ole myöskään tavoiteltavaa. Tämän vuoksi käyttäjän profiiliagentti perustuu ensisijassa näiden kahden kompromissiin, eli käyttäjä kohdistaa muunnokset johonkin asiayhteyteen. Itse asiassa muunnos määrittää käyttäjän persoonan, 30 esim. koti- tai työpersoonan. Lisäksi persoonat erotellaan omiin kerroksiinsa, niin että niitä voidaan käyttää monissa sopimuksissa ja että yksi sopimus voi .···. sallia useiden persoonien käytön.

Perusprofiili käsittää käyttäjän koko profiilin, joka on järjestetty hie-: ·' rarkkisesti. Kuvio 4a esittää esimerkin perusprofiilista, joka on järjestetty eri 35 kategorioihin profiilin sisällön mukaisesti. Tässä esimerkissä ensimmäinen kategoria käsittää käyttäjän uniikit tunnisteet, toinen kategoria biografiset ja 10 111879 demografiset käyttäjätiedot, kolmas kategoria käyttäjän osoitteet, neljäs kategoria käyttäjän mielenkiinnon kohteet, asenteet jne. ja viimeinen kategoria tiedot käyttäjän nykyisestä sijainnista ja aktiivisuudesta.

Perusprofiilin jokainen kategoria käsittää monia nimikkeitä (items).

5 Kuvio 4b esittää esimerkin yksittäisen nimikkeen rakenteesta. Nimikkeen sisältö on jaettu nimikettä kuvaileviin datayksiköihin. Kuvion 4b esimerkissä ensimmäinen datayksikkö edustaa nimikkeen nimeä, toinen kuvaa nimikettä, kolmas osoittaa nimikkeen tyyppiä, neljäs sitä kuinka nimike muutetaan käyttäjän persoonaksi ja viimeinen käsittää nimikkeen arvon. Tekemällä nimik-10 keet erikseen osoitettaviksi käyttäjä voi kontrolloida pääsyä yksittäisiin nimikkeisiin. Kuten on ilmeistä, yksittäisten kategorioiden nimikkeiden lukumäärä ja tyyppi voi vaihdella, riippuen esim. kategoriasta ja käyttäjästä. Perusprofiilin hierarkiatasojen lukumäärä voi myös vaihdella.

Kuvio 5 esittää esimerkin yhden perusprofiiliin sisällöstä, joka 15 muodostaa agentin alimman kerroksen. Kuviossa ne kategoriat tai nimikkeet, jotka ovat samalla hierarkkisella kerroksella on merkitty laatikoilla, jotka ovat valkoisia joka toisella kerroksella ja mustia joka toisella kerroksella. Tässä esimerkissä käyttäjä on Joe Doe, jonka lempinimi on ’’Foobaf’. Perusprofiilin ’’muunnoskenttä” esittää kaikkia niitä muunnoksia, jotka ovat mahdollisia ky-20 seiselle nimikkeelle. Esimerkiksi käyttäjän sukupuolta voidaan vaihdella mie-hestä (M) naiseen (F) ja sukupuolettomaan (N). Malli/preferenssikategoriassa eri palveluntarjoajat voivat kerätä tietoa käyttäjän preferensseistä. Tässä esi-merkissä ko. kategoria sisältää suhteelliset arvot, jotka osoittavat kuinka usein käyttäjä käyttää urheilu-, talous- ja sääpalveluja, joita tarjotaan palvelu-.···. 25 portaalissa www.company1.com. Jos käyttäjän preferensseihin käytetään jo- *** tain tiettyä sovittua ontologiaa, kaikki palveluntarjoajat voivat hyödyntää tätä tietoa omiin tarkoituksiinsa.

Käytännössä perusprofiili käsittää tavallisesti paljon enemmän tietoa kuin on esitetty kuvion 5 mukaisessa esimerkissä, joka kuvailee ainoas-30 taan sitä, mitä tietoa perusprofiili voi sisältää.

:y. Kuvioissa 6 ja 7 esitetään kaksi esimerkkiä käyttäjän persoonasta, .···. jonka käyttäjän perusprofiili on esitetty kuviossa 5. Kuvio 6 esittää työpersoo- *·' naa, jota voidaan käyttää esim. työaikana. Tässä persoonassa yllämainittu : www.companyl .com-sivujen talouskanava saa enemmän painoa kuin muut • · * 35 palvelut, toisin sanoen tätä persoonaa kiinnostaa talouspalvelut enemmän kuin muut palvelut. Lisäksi käyttäjän lempinimi on peitetty palveluilta, eli pal- ,, 111879 11 velut eivät näe käyttäjän lempinimeä. Kuviossa 7 esitetään henkilön toinen persoona, jota kutsutaan tässä online-persoonaksi, jota voidaan käyttää esim. kotoa suoritettavissa istunnoissa. Tässä persoonassa käyttäjän sukupuoli on muutettu sukupuolettomaksi, tulot pyöristetty lähimpään 10 000:een, 5 ja nimikategorian kaikki nimikkeet, lukuun ottamatta lempinimeä, ja myös kaikki kotiosoitteen alla olevat nimikkeet on piilotettu.

Kuviot 8 ja 9 esittävät käyttäjän profiiliagentin uloimman kerroksen sopimusten sisältöä. Kuvio 8 esittää vain käyttäjän käytössä olevaa isäntä-sopimusta. Varmistaakseen turvallisen yhteyden käyttäjän kanssa isäntäso-10 pimus tallentaa asiakkaan julkisen avaimen (PKU01) ja omat julkiset ja salaiset avaimensa (PKM01 ja SKM01). Isäntäsopimuksen asiakas on aina se käyttäjä, jonka isäntäsopimus on kyseessä. Kuvio 9 esittää esimerkin yleisestä palvelusopimuksesta, joka on merkitty kuviossa ”palvelu01”. Tämän sopimuksen välityksellä kaksi palvelua pääsee käyttäjän profiilitietoihin, eli ne 15 palvelut, joilla on julkiset avaimet PKS01 ja PKS02. Sopimus voi määrittää ne perusprofiilin nimikkeet, joihin päästään sopimuksen avulla (vrt. pääsyoikeu-det/tyyppi=pääsy). Tässä esimerkissä malli/preferenssikategorian nimikkeitä voidaan lukea ja kirjoittaa, kun taas tunnistekategorian ja ominaisuudet/tulot alla olevat nimikkeet voidaan vain lukea. Sopimus voi myös määritellä ne pe-20 rusprofiilin kohdat, joihin ei ole pääsyä sopimuksen välityksellä. Tässä esi-merkissä postiosoitekategorioihin ei ole pääsyä lainkaan (pääsyoikeu-!**.. det/tyyppi=kiellä).

Sopimus voi edelleen määritellä persoonat (näkymät), jotka voi- • · * daan nähdä sopimuksen kautta. Tässä esimerkissä vain online-persoona .···. 25 voidaan nähdä sopimuksen kautta. Täten, vaikka käyttäjä käyttää parhaillaan työpersoonaa, palveluOI näkee online-persoonan. Sopimus voi myös määritellä erilaisille palveluille eri toimintatavat. Kuvion 9 mukainen sopimus käsittää yhden toimintatavan: jos vastaanottaja, eli palveluntarjoaja, on ”yhtiö01 ”, " ’ mikä osoittaa, että nimikkeet ovat vain sen käyttöön, niin kaikkiin muihinkin 30 maskaamattomiin tai ei-piilotettuihin nimikkeisiin on pääsy. Alla on tarkemmin :Y: selvitetty sitä, kuinka käyttäjä valvoo niitä nimikkeitä, jotka voidaan nähdä • * .*··. sopimuksen avulla ja sitä missä muodossa ne voidaan nähdä. Sopimuksissa voidaan käyttää P3P-järjestelmän (Platform for Privacy Preferences Projects) * · · • ·’ mukaista standardiformaattia informoimaan palveluntarjoajaa profiiliagentin • ·» 35 (eli käyttäjän) omaksumista yksityisyyskäytännöistä.

12 111879 Tällä tavalla sopimus määrittelee lisäksi agentin keskimmäisen kerroksen näkymiä. Agentti voi käsittää myös useita keskimmäisiä kerroksia, joista jokainen manipuloi edellisen kerroksen näkymiä. Asiakkaan saatavilla olevan datan määritys toteutetaan edullisesti siten, että asiakkaan saatavissa 5 olevan datajoukon määritys on täsmällisempi ja yksityiskohtaisempi siirryttäessä perusprofiilista agentin uloimpia kerroksia kohti.

Jokainen käyttäjäprofiiliagentti on ensisijaisesti kyseisen käyttäjän luoma. Kuviossa 10 on esimerkki järjestelmän elementtien välisestä sano-manvaihdosta silloin, kun käyttäjä luo profiiliagentin itselleen. Esillä olevan 10 keksinnön mukainen järjestelmä käsittää agentin luomiseksi yllämainitut agentinluomisyksiköt. Jokainen agentinluomisyksikkö on pala ohjelmistoa, joka antaa käyttäjän luoda käyttäjäprofiiliagentin. Agentinluomisyksiköt voivat sijata käyttäjäpäätteissä, hostellien yhteydessä tai erillisillä, käyttäjille näitä palveluja tarjoavilla verkkosivuilla. Vaihdettavat viestit salataan salausavai-15 mella edullisesti aina silloin, kun vastakkaisen osapuolen julkinen avain on käytettävissä.

Aluksi käyttäjän työasema lähettää agentinluomisyksikölle viestin, jossa pyydetään kyseistä yksikköä aloittamaan käyttäjän profiiliagentin luominen (vaihe 1001). Tämä viesti käsittää käyttäjän julkisen avaimen 20 (P_KEY_U). Vastineena tähän viestiin agentinluomisyksikkö luo käyttäjälle ; tyhjän profiiliagentin. Kun tämä on suoritettu, agentinluomisyksikkö pyytää profiiliagenttia luomaan isäntäsopimuksen, jotta käyttäjä voisi muokata agent- .*··. tia mainitun sopimuksen kautta (vaihe 1003). Tämä pyyntö sisältää myös • · · käyttäjän julkisen avaimen. Käyttäjän profiiliagentti luo sitten tunnisteen (CID) 25 isäntäsopimukselle (vaihe 1004) ja avainparin isäntäsopimusta varten. Isän- • · täsopimuksella on nyt avaimet käyttäjän kanssa käytävään salattuun viesti-’*··* miseen, kuten kuviossa 8 on näytetty. Käyttäjän profiiliagentti informoi sen jälkeen agentinluomisyksikköä uudesta sopimuksesta lähettämällä luomisyk-: sikölle export-viestin, joka sisältää tunnisteen ja juuri luodun sopimuksen jul- 30 kisen avaimen (P_KEY_MC) (vaihe 1006). Vasteena tähän viestiin agentin-luomisyksikkö lähettää hakujärjestelmälle rekisteröintipyynnön (vaihe 1007). .···. Tämä pyyntö sisältää isäntäsopimuksen tunnisteen ja julkisen avaimen sekä reititystiedon, joka osoittaa profiiliagentin sijaintipaikkaan. Reititystieto on kui-: V tenkin tässä esimerkissä nolla (tyhjä), koska käyttäjän profiiliagenttia ei ole 35 siirretty vielä oikealle paikalleen verkossa. Saatuaan tämän viestin hakujärjestelmä tarkistaa, ettei mikään olemassa oleva sopimus käytä tunnistetta.

13 111879

Jos tunniste ei ole käytössä, hakujärjestelmä rekisteröi sopimuksen ja lähettää siitä kuittauksen agentinluomisyksikölle (vaihe 1008).

Tämän jälkeen käyttäjän profiiliagentti siirretään oikealle paikalleen, ts. hostelliin (vaihe 1009). Jos agentinluomisyksikkö ja profiiliagentti 5 ovat jo hostellissa, tämä vaihe luonnollisesti ohitetaan. Agentin siirtyminen sisältää tyypillisesti useita viestejä, vaikka kuviossa näytetään vain yksi.

Siirtymisen jälkeen sopimuksen tunniste viedään uudelleen hakujärjestelmään kunnollisella reititystiedolla varustettuna, joka osoittaa hostelliin (vaihe 1010). Tämä toteutetaan siten, että hostelli aktivoi ensin agentin. Tä- 10 män tuloksena agentti pyytää hostellia suorittamaan uudelleenviemisen, ja hostelli lähettää viestin hakujärjestelmään. Agentinluomisyksikkö kuittaa sitten käyttäjälle isäntäsopimuksen luomisen vaiheessa 1011. Tämä kuittaus-viesti käsittää isäntäsopimuksen tunnisteen ja julkisen avaimen. Käyttäjän profiiliagentti on nyt täysin käytettävissä, vaikka se on yhä tyhjä.

15 Käyttäjän on tämän jälkeen syötettävä dataa profiiliagentille. Tätä tarkoitusta varten käyttäjän työasema pyytää ensin profiiliagentin reititystietoja hakujärjestelmältä lähettämällä pyynnön, joka käsittää isäntäsopimuksen tunnisteen (vaihe 1012). Saatuaan reititystiedon, joka osoittaa siihen hostelliin, jossa käyttäjän profiiliagentti sijaitsee, päivitysviesti lähetetään hostellille 20 vaiheessa 1014. Tämä viesti sisältää isäntäsopimuksen tunnisteen, suoritet-tavat operaatiot ja niissä käytettävän datan. Hostelli välittää viestin profiili-!*·.. agentille. Esim. jos käyttäjä on luonut kuvion 5 mukaisen perusprofiilin, viesti voi sisältää seuraavat kirjoitusoperaatiot ja datan: t · · päivitä(”tunnisteet/nimi/etunimi”, ’’John”) .···, 25 päivitä(”tunnisteet/nimi/keskimmäinen nimi”, ’’Bar”) • · .‘l.’ päivitä(”tunnisteet/nimi/sukunimi”, ”Doe”) ’···' päivitä(”tunnisteet/nimi/lempinimi”, ’’Foobar”), jne.

Käyttäjä asettaa siis toivotun datan profiiliagenttiin isäntäsopimuk- ’ : sen välityksellä. Isäntäsopimuksen osoite haetaan ensin hakujärjestelmästä.

* · · 30 Tämä voi vaatia usean päivitysviestin lähettämistä hostellille.

Sen jälkeen kun profiiliagentti on suorittanut halutut toimenpiteet, .*··. se kuittaa ne (vaihe 1017) hostellille, joka lähettää kuittauksen edelleen käyt- • · täjän päätteeseen (vaihe 1018).

: V Käyttäjän profiiliagentti on nyt valmis palvelusovelluksille. Jos käyt- • * · 35 täjä haluaa myöhemmin päivittää omaa olemassa olevaa profiiliagenttiaan, päivitys tapahtuu kuten kuviossa 10, vaiheissa 1012 - 1018 on esitetty, ts.

14 111879 oikeaan hostelliin osoittavat reititystiedot pyydetään hakujärjestelmältä, ja sitten lähetetään yksi tai useampi päivitysviesti hostellille, jossa profiiliagentti sijaitsee.

Kun käyttäjä ottaa yhteyden palveluun, joka haluaa hyödyntää pro-5 fiilidataa, palvelua varten on ensin tehtävä sopimus. Kuviossa 11 näytetään esimerkki järjestelmän elementtien välisestä sanomanvaihdosta, kun profiili-agentin ja asiakkaan (ts. palveluntarjoajan/palvelusovelluksen) välille luodaan uusi sopimus. Ensin käyttäjä lähettää tavallisen palvelupyynnön palveluja tarjoavalle webbipalvelimelle (vaihe 1101). Vastauksena pyyntöön käyttäjä saa 10 yleensä palvelimelta rekisteröintilomakkeen (vaihe 1102). Tämän jälkeen käyttäjän on käytävä omalla profiiliagentillaan. Tätä tarkoitusta varten käyttäjä lähettää hakujärjestelmälle import-viestin, jossa pyydetään hakujärjestelmältä isäntäsopimuksen osoitetta (vaihe 1103). Vastauksena tähän viestiin hakujärjestelmä palauttaa reititystiedot käyttäjälle. Reititystiedot osoittavat 15 isäntäsopimuksen senhetkisen paikan. Tässä esimerkissä oletetaan, että käyttäjän profiiliagentti on sillä hetkellä hostellissa A.

Käyttäjä lähettää sitten viestin hostellille A (vaihe 1105) ja pyytää palvelusopimuksen luomista. Tämä viesti sisältää ainakin isäntäsopimuksen tunnisteen sekä palvelun julkisen avaimen (P_KEY_S), joka on saatu aikai-20 semmin rekisteröintisivun yhteydessä. Hostelli etsii käyttäjän profiiliagentin, joka vastaa vastaanotettua isäntäsopimustunnistetta ja toimittaa viestin •«· · :·. eteenpäin mainitulle käyttäjäprofiiliagentille vaiheessa 1106. Vastauksena ♦ * ,’···, tähän viestiin käyttäjän profiiliagentti luo palvelua varten sopimus-ID.n ja « » *]*. avainparin (vaihe 1107) ja agentti vie luodun sopimus-ID:n (CID) ja sen julki- 25 sen avaimen (P_KEY_C) hostellille (vaihe 1108). Hostelli tietää mikä hakujär-jestelmän solmu on käytettävissä ja lähettää pyynnön tälle solmulle vaihees-sa 1109. Tämä pyyntö pyytää hakujärjestelmää rekisteröimään uuden sopimuksen. Sanoma käsittää sopimus-ID:n, julkisen avaimen ja hostelliin A *": osoittavat reititystiedot. Tässä sanomassa annetut reititystiedot antavat eri 30 reitin hostelliin A kuin vaiheessa 1104, jotta isäntäsopimusta ja palvelusopi-musta ei voisi linkittää yhteen sijaintinsa välityksellä.

Jos uuden sopimuksen rekisteröinti on onnistunut, hakujäijestelmä I · kuittaa operaation hostellille (vaihe 1110), joka kuittaa sen edelleen käyttäjän profiiliagentille (vaihe 1111).

35 Tämän jälkeen käyttäjää informoidaan juuri luodun sopimuksen ID:stä. Käyttäjän profiiliagentti lähettää ensin sopimus-ID:n ja julkisen avai- is 111879 men hostellille, joka välittää viestin eteenpäin käyttäjän päätteeseen (vaiheet 1112 ja 1113).

Saatuaan tämän tiedon käyttäjän työasema päivittää sopimuksen preferenssiensä mukaisesti vaiheessa 1114. Toisin sanoen tässä vaiheessa 5 käyttäjä päättää niistä näkymistä, jotka ovat nähtävissä tämän sopimuksen lävitse määrittämällä ainakin profiiliagentin uloimman kerroksen. Tässä vaiheessa määritellään ne nimikkeet, jotka palveluntarjoaja/palvelusovellus voi nähdä, missä muodossa ne ovat nähtävissä, ja mitä palveluntarjoaja saa tehdä sopimuksella.

10 Tämän jälkeen käyttäjän työasema lähettää palveluntarjoavalle palvelimelle vastauksen vaiheessa 1102 vastaanotettuun rekisteröintisivuun. Tämä vaiheen 1115 sanoma voi olla tavallinen HTTP-POST -viesti, joka käsittää sopimuksen ID:n ja julkisen avaimen.

Kuten yllä on kuvattu, tässä perustoimintamallissa käyttäjä panee 15 alulle palvelun ja käyttäjän profiiliagentin välisen suhteen lähettämällä uuden sopimuksen tunnisteen palveluja tarjoavalle palvelimelle. Vastauksena tähän sanomaan palvelin pyytää reititystietoja agentin hostelliin hakujärjestelmältä (vaihe 1116). Kun palvelin saa tämän tiedon vaiheessa 1117, se tietää, että sopimus on olemassa eli että käyttäjä ei yritä petkuttaa. Palvelin pyytää sitten 20 tietoja käyttäjän profiiliagentista lähettämällä informaatiopyynnön hostelliin, joka lähettää pyynnön eteenpäin profiiliagentille (vaiheet 1118 ja 1119). J·*/ Pyyntö käsittää sopimuksen ID:n, operaatiot ja operaatioihin liittyvät paramet- rit. Esim. jos palvelin pyytää dataa, joka on käyttäjän profiilissa alikategorias-sa ’’nimi”, operaatio on ’’luku” ja parametrit käsittävät ’’tunnisteet/nimen”.

25 Käyttäjän profiiliagentti autentikoi ensin pyynnön ja prosessoi sen vasta tämän jälkeen. Vasteena palautetaan pyydetty tieto palvelimelle (vai- < «· heet 1121 ja 1122). Jos kuvion 9 mukainen sopimus on luotu aikaisemmin, käyttäjän profiiliagentti huomaa vaiheessa 1120, että on käytettävä online-·:··: persoonaa. Koska online-persoona on sellainen, että alikategoriassa ’’tunnis- ·*”: 30 teet/nimi” voidaan näyttää vain lempinimi, käyttäjän profiiliagentti palauttaa vain lempinimen (Foobar) vaiheessa 1121. Kun palvelin saa tämän viestin, se voi jatkaa tavallista operointiaan toivottamalla käyttäjän tervetulleeksi

I I

webbisivuille (vaihe 1123). Tämä HTTP-vastaus sisältää käyttäjän lempini-men sanoman rungossa. Tämän jälkeen käyttäjä voi käyttää palvelua.

·“*: 35 Jos palvelu haluaa lisätietoa käyttäjästä myöhemmin saman tai seuraavan palveluistunnon yhteydessä, palvelu lähettää informaatiopyynnön ie 111879 käyttäjän profiiliagentille. Kuvio 12 näyttää esimerkin järjestelmän elementtien välisestä sanomanvaihdosta tällaisen yleisen informaatiopyynnön yhteydessä, joka tulee palveluja tarjoavalta palvelimelta. Palvelin pyytää jälleen ensin reititystietoja profiiliagentin hostelliin hakujärjestelmältä ja saatuaan ne 5 lähettää informaatiopyynnön hostellille (vaiheet 1201 - 1203), joka välittää pyynnön eteenpäin käyttäjän profiiliagentille (vaihe 1204). Tässä yhteydessä on mahdollista määritellä se, että jos palvelun pyytämä operaatio ei ole sallittu, lupaa pyydetään käyttäjän työasemalta. Käyttäjän profiiliagentti kysyy sitten lupaa käyttäjän työasemalta lähettämällä vahvistuspyynnön käyttäjän 10 työasemalle hostellin välityksellä (vaihe 1205). Jos käyttäjä sallii operaation, se palauttaa hyväksynnän (vaihe 1206). Kun käyttäjän profiiliagentti saa tämän sanoman, se aloittaa pyynnön prosessoinnin ja lähettää sitten halutun tiedon palvelulle (vaiheet 1207 ja 1208). Esimerkiksi jos pyydetty operaatio oli ’’kirjoita”, niin käyttäjän profiiliagentti palauttaa pyynnön tilan (ts. pyyntö 15 suoritettu). Jos käyttäjän työasema kieltää palvelun tarvitseman operaation, palvelua informoidaan siitä, että pyydetty operaatio ei ole sallittu. Toisaalta, jos operaation vahvistusta ei tarvita, käyttäjän profiiliagentti vastaa palvelulle välittömästi pyynnön jälkeen.

Kuten edellä mainittiin, käyttäjän profiiliagentti voi myös liikkua 20 verkossa. Esimerkiksi, jos käyttäjän senhetkinen paikka on päivitetty jollakin tavalla, kuten GPS-vastaanottimella, käyttäjän profiiliagentti voi huomata, että i · jl" se on liian kaukana käyttäjän senhetkisestä paikasta. Käyttäjän profiiliagentti * · aloittaa silloin sijainninpäivityksen lähettämällä senhetkiselle hostellille siirty-mispyynnön, katso kuvio 13, vaihe 1301. Tämä viesti voi sisältää käyttäjän | * 25 työaseman senhetkisen paikan lähellä olevan uuden hostellin osoitteen, tai :: jos käyttäjän profiiliagentti ei tiedä missä lähin hostelli on, viesti sisältää käyt-

t « I

täjän senhetkisen paikan ja pyynnön siirtää agentti mainittua paikkaa lähinnä olevalle hostellille. Tämän tuloksena uudelle hostellille (hostelli B) lähetetään :··! pyyntö hyväksyä käyttäjän profiiliagentti (vaihe 1302). Jos uusi hostelli hy- • 30 väksyy profiiliagentin, se lähettää kuittauksen senhetkiselle hostellille (vaihe 1303). Vastaanotettuaan tämän sanoman senhetkinen hostelli pyytää käyttä- I | f jän profiiliagenttia sanallistamaan itsensä (vaihe 1304). Vastauksena tähän • agentti siirretään sanallistettuna uudelle hostellille (vaiheet 1305 ja 1306).

:*·*: Tämä uusi hostelli aktivoi käyttäjän profiiliagentin vaiheessa 1307. Vasteena 35 aktivoinnille käyttäjän profiiliagentti lähettää uudelle hostellille pyynnön päivittää jokaisen sopimuksen sijainti, yksi sopimus kerrallaan. Kuviossa 13 esite- 17 111879 tään kahden sopimuksen sijainnin päivitys (CID1 ja CID2, vastaavat vaiheet 1308 ja 1312). Käyttäjän profiiliagentin lähettämät sanomat sisältävät sopimuksen tunnisteen ja julkisen avaimen. Vasteena jokaiseen käyttäjän profiili-agentin pyyntöön uusi hostelli lähettää hakujärjestelmälle päivityspyynnön 5 iisäämällä viestiin reititysinformaation (vastaavat vaiheet 1309 ja 1313 ensimmäiselle ja toiselle sopimukselle). Hakujärjestelmä päivittää pyynnön osoittaman sopimuksen sijainnin ja lähettää kuittauksen takaisin hostellille (vaiheet 1310 ja 1314), joka välittää kuittauksen eteenpäin käyttäjän profiili-agentille (vaiheet 1311 ja 1315). Kun käyttäjän profiiliagentti on vastaanotta-10 nut kuittauksen jokaisesta päivitysprosessista, se lähettää uudelle hostellille kuittauspyynnön (vaihe 1316). Vasteena tähän pyyntöön uusi hostelli kuittaa alkuperäiselle hostellille agentin siirron (vaihe 1317).

Näin uusi hostelli päivittää käyttäjän profiiliagentin sijainnin sopimus sopimukselta. Sijainnit päivitetään sopimus kerrallaan, jotta estetään 15 hakujärjestelmää huomaamasta sopimusten kuuluvan samalle käyttäjän pro-fiiliagentille.

Hakujärjestelmä toimii kuten musta laatikko palvellessaan järjestelmän muuta osaa. Kontaktipisteet (ts. sopimukset) rekisteröidään siellä si-jainninpäivitysoperaation avulla ja niitä pyydetään sieltä hakuoperaatiolla. 20 Hakujärjestelmältä vaaditaan lisäksi, että sen pitää olla tehokas ja skaalautu- . :· va. Täten hakujärjestelmän resurssien ei pitäisi estää käyttäjän profiiliagent- ♦ · · · tien liikkuvuutta. Hakujärjestelmän toteuttamisen eri vaihtoehdoista kerrotaan • . · · ·. seuraavassa lyhyesti.

Koska profiiliagentti tuntee asiakkaansa, yksinkertaisin vaihtoehto • · 25 profiiliagentille olisi, että se pitäisi asiakkaat tietoisina sijainnistaan. Kuitenkin yhteistyön avulla asiakkaat voisivat tarkkailla, milloin kukin pseudonyymi '···' (persoona) vaihtaa sijaintiaan ja täten ne voisivat korreloida, mitkä pseudo nyymit todennäköisemmin liittyvät samaan henkilöön. Erityisesti tämä estäisi käyttäjiä käyttämästä kahta sopimusta asiakkaan kanssa.

·*[’: 30 Edelleenlähetysketjujen hyödyntäminen on toinen vaihtoehto hakujärjestelmän toteuttamiseksi. Tällaisessa ratkaisussa agentti jättää lähe-!.! tysosoitteen aikaisempaan hostelliinsa siirtyessään itse uuteen hostelliin.

T* Seuraamalla lähetysosoitteista muodostuvaa ketjua asiakas löytää agentin.

• V Tällaisen ratkaisumallin haittapuoli on se, että se toimii huonosti silloin kun 35 agentit liikkuvat vilkkaasti - ketjun pituus kasvaa ja hakupolku saattaa poukkoilla maapallon toiselta puolelta toiselle.

is 111879

Kotipohjainen ratkaisumalli eliminoi ketjumallin arvaamattomat hakupolut. Kotipohjaisessa ratkaisumallissa jokaisella käyttäjän profiiliagentilla olisi määritelty palvelin, koti, joka seuraa sen sijaintia. Tämä ratkaisumalli rajoittaa kuitenkin liikkuvuutta sitoen käyttäjän kotipalveluntarjoajaan.

5 Nimipalvelin ratkaisumallina on perinteinen tapa linkittää tunnisteet sijainteihinsä. Sitä käytetään esim. internetin aluenimijärjestelmässä. Nimi-palvelinjärjestelmät ovat erittäin skaalautuvia, koska osia tunnisteavaruudes-ta jaetaan hierarkkisesti eri palvelimille. Valitettavasti tällaisessa hierarkkisessa osoitteenmuodostuksessa oletetaan, että osoitteen sitovuus on melko 10 pysyvää.

Henkilökohtaisen liikkuvuuden maksimoimiseksi osoitteistuksen on oltava hierarkkisesti matala, eikä nimipalvelin ratkaisumallina ole mahdollinen. Sijaintipalvelua, joka perustuu hierarkkisesti matalaan osoiteavaruuteen (flat address space), kuvataan artikkelissa Ballintijn, van Steen ja Tanen-15 baum, Exploiting Location Awareness for Scalable Location-Independent Object Ids, Proceedings of Fifth Annual ASCI Conference, Heijen, Netherlands, June, 1999, pp. 321-332 (saatavissa myös sivuilla http://www.cs.vu.nl/pub/papers/globe/IR-459.99.pdf, käyty 4/2000). Esillä olevan keksinnön mukainen hakujärjestelmä on edullisesti tässä artikkelissa 20 esitetyn järjestelmän kaltainen. Keskeinen idea tässä paikannuspalvelussa on paikallisuuden hyödyntäminen, mikä tarkoittaa sitä, että haun kustannuk-set kasvavat välimatkan kasvaessa ko. osoitteeseen, jolloin on halvempaa ’ .' etsiä paikallisia kohteita.

\ Tällaisen hakujärjestelmän rakennetta kuvataan kuviossa 14. Pe-

* * t I

25 rusarkkitehtuuri on hierarkkinen, joten järjestelmän solmut jakavat verkon v.: maantieteellisten alueiden hierarkiaan. Hierarkian pohjalla ovat lehtisolmut, t | joista jokainen peittää lehtialueen, joka voi käytännössä olla muutamien lähiverkkojen kattama alue. Seuraava ylemmällä tasolla oleva alue voi sitten edustaa esimerkiksi sitä kaupunkia, jossa lähiverkot sijaitsevat. Jokaiseen 30 alueeseen liittyy hakemistosolmu, joka tallettaa sijaintitietoa alueellaan ole- * « « vista sopimuksista (ts. alueella, jonka sen alapuoliset solmut kattavat). Hie-rarkian huipulla oleva juurisolmu peittää koko verkon ja käsittää kullekin tun- • · ’·;· nisteelle osoittimien seuraavan kerroksen solmuun, jne. Lehtisolmut tallenta- :T: vat sopimusten osoitteet. Täten vain yksi lehtisolmu tietää, missä hostellissa 35 sopimus sijaitsee. Kun haku suoritetaan, hakuoperaatio alkaa siitä lehtisol-musta, joka vastaa sitä aluetta, jolla asiakas sijaitsee. Jos lehtisolmulla on 19 111879 osoite, asiakas saa osoitteen välittömästi. Muutoin pyyntö etenee ylöspäin kunnes se saavuttaa hakemistosolmun, joka käsittää etsityn tunnisteen tietueen, josta se laskee alaspäin siihen lehtisolmuun, jossa osoite sijaitsee.

Koska hakujärjestelmän rakenne ja toiminta on sinänsä tunnettua, 5 sen yksityiskohtia ei käsitellä tässä sen enempää. Lisätietoa saa yllämainitusta artikkelista tai artikkelista M. van Steen and F. Hauck: Algorithmic Design of the Globe Wide-Area Location Service, The Computer Journal, 1998, Voi. 41, No. 5, pp. 297-310 (saatavissa myös osoitteesta http://www.cs.vu.nl/pub/papers/globe/IR-440.97.ext.pdf).

10 Vaikka keksintöä selostettiinkin yllä liitteenä olevien kuvien esi merkkien avulla, on selvää, että keksintö ei rajoitu vain niihin, vaan ammattimies voi soveltaa keksintöä poikkeamatta keksinnön suoja-alasta ja hengestä. Seuraavassa esitellään lyhyesti joitakin todennäköisiä variaatioita.

Järjestelmä voi tukea profiiliagenttien kolmea erilaista kommunikaa-15 tiomoodia: tilatonta, istuntopohjaista ja tapahtumapohjaista moodia.

Edellä kuvatussa tilattomassa kommunikaatiomoodissa hakujärjestelmän ulkopuolella ei ylläpidetä mitään pitkäaikaista tietoa profiiliagentin sijainnista. Tämä tila sallii yksinkertaisen pyyntö-vastaus-sanomanvaihdon. Koska muissa moodeissa on turvallisuusriskinsä, tilaton kommunikaatio on 20 ensisijainen kommunikaatiotapa suurimmalle osalle asiakkaita. Jokaista sa-. ··· nomanvaihtoa varten asiakkaat hakevat ensin profiiliagentin sijainnin ja suo- rittavat sitten sanomanvaihdon, mukaan lukien autentikoinnin.

.···. Istuntopohjaisessa kommunikaatiomoodissa asiakas voi aloittaa pitkäaikaisen suhteen profiiliagentin kanssa. Jos profiiliagentti siirtyy tämän 25 ajanjakson aikana, istunto siirtyy myös. Lisäksi autentikointi ja ilmoitus me-nettelytavasta (policy) suoritetaan vain kerran. Kun profiiliagentti lähettää il-*···' moituksen uudesta osoitteesta asiakkaille, ne voivat kuitenkin ryhtyä korre- laatiohyökkäykseen perustuen päivitysten saapumisajankohtiin. Täten istun-topohjaisen kommunikaation käyttö tulisi rajoittaa vain asiakkaisiin, joihin luo-30 tetaan.

Tapahtumapohjaista kommunikaatiota voidaan käyttää profiilin muutosten jakamiseen. Tässä moodissa asiakkaat tilaavat tiettyjen ilmoitus-’·:** ten vastaanottamisen. Kun profiiliagentti on vastaanottanut jonkin päivityk- :·: sen, se lähettää ilmoituksen siitä kaikille tilanneille asiakkaille.

35 Myös tapahtumia voidaan hyödyntää korrelaatiohyökkäyksissä.

«♦ ·

Mahdollisia hyökkäyksiä voidaan vähentää tekemällä niiden toimitus asynk- 20 Ί11879 ronisemmaksi, ts. lisäämällä vaihtelevia viiveitä jokaisen lähetettävän ilmoituksen väliin.

Käyttäjän profiiliagentti voi olla myös hajautettu olio, joka käsittää äitiagentin ja useita lapsiagentteja. Näin eri sopimukset voivat sijaita eri hos-5 telleissa. Tällaisen toteutuksen etuna on se, että käyttäjän ei enää tarvitse luottaa kaikessa informaatiossa yhteen hostelliin, poikkeuksena äitiagentin hostelli, joka voi yhä päästä kaikkiin profiilin osiin, mutta joka ei enää tiedä kaikkia niitä asiakkaita, joiden kanssa profiiliagentti on suhteessa.

Profiiliagentit ovat toteutettavissa myös ilman, että tallennetaan nä-10 kymiä seuraavia informaatiopyyntöjä varten. Tällaisessa tapauksessa profiili-agentti muodostaa näkymän joka kerta, kun profiili-informaatiota pyydetään, käyttämällä yhtä tai useampaa näkymän määrittävää toimintoa. Tällaisessa tapauksessa mainitut yksi tai useampi toiminto muodostavat agentin keskimmäisen kerroksen, joka sijaitsee ytimen ja sopimuksien välissä. Sopimus 15 voi täten sisältää yksinkertaisimmassa muodossaan vain oman tunnisteensa.

Yllä mainitun vaihtoehdon käyttö on kuitenkin suositeltavaa, sillä on paljon yksinkertaisempaa määrittää ja hyödyntää valmiita näkymiä kuin luoda niitä reaaliajassa. Lisäksi palvelun tasoa voidaan helposti parantaa hyödyntämällä valmiita näkymiä. Järjestelmä voi esimerkiksi hyödyntää valmiita nä-20 kymiä, jotka otetaan käyttöön tiettynä vuorokauden aikana tai käyttäjän si- . ·:· jainnin mukaan.

:\it Jotta sopimusten lukumäärä pysyisi aisoissa, sopimus voidaan .···, poistaa, kun sitä ei ole käytetty tietyn ajanjakson kuluessa.

Järjestelmästä on mahdollista käyttää myös ’’riisuttua” versiota, si-25 ten että käyttäjän isäntäsopimuksen kautta syöttämä profiilitieto on kaikkien niiden asiakkaiden saatavissa, jotka pääsevät sopimuksen avulla profiilitie-'··’ töihin.

Anonyymiä reititystä voidaan myös hyödyntää estämään pahantah-toisia osapuolia paljastamasta käyttäjän agenttia sopimuksia korreloimalla. 30 Tällaisessa toteutustavassa käyttäjän agentin jokaiseen sopimukseen liite-tään eri osoite anonymisoivan verkon välityksellä, johon hostellit ovat yhtey-!.! dessä. Koska anonyymi reititys on sinänsä tunnettua, sitä ei esitellä tässä sen enempää.

i V Vaikka keksintöä kuvattiin yllä oheisten kuvioiden esimerkkien va- 35 lossa, on selvää, että keksintö ei rajoitu vain näihin esimerkkeihin, vaan alan ammattimies voi modifioida sitä poikkeamatta keksinnön piiristä ja hengestä.

Claims (19)

21 111879

1. Menetelmä käyttäjäkohtaisen informaation tarjoamiseksi palvelusovellusten käyttöön tietoliikenneverkossa, tunnettu siitä, että menetelmässä: 5. talletetaan käyttäjän profiilitietoa käyttäjäkohtaisiin ohjelmisto- agentteihin, joista kukin käsittää ainakin sisemmän kerroksen käyttäjän profiilitietojen tallentamiseen ja ulomman kerroksen sopimusten tallentamiseen, jotka sopimukset muodostavat rajapintoja, joiden avulla kontrolloidaan profiilitietojen verkosta päin tapahtuvaa käyttöä, 10. talletetaan mainitut agentit verkkoon, - tehdään sopimukset asiakkaiden käyttöön ja talletetaan sopimukset ulompaan kerrokseen, jolloin kukin asiakas on osapuoli, joka käyttää hyväkseen verkossa olevia profiilitietoja, ylläpidetään sopimusten kulloisiakin sijainteja sijainti-15 informaatiojärjestelmässä, - pyydetään halutun sopimuksen olinpaikkaa mainitulta järjestelmältä ja - siirretään käyttäjäkohtaista informaatiota asiakkaan ja agentin välillä mainitun sopimuksen välityksellä.

2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että se käsittää edelleen vaiheen profiilitietoihin olevien näkymien määrittä- • · : '·· miseksi ja jokaisen näkymän yhdistämiseksi ainakin yhteen sopimukseen, jolloin näkymä määrittää sen käyttäjäkohtaisen informaation muodon ja sisäl-:··: lön, joka on asiakkaan saatavissa näkymään yhdistetyn sopimuksen välityk- 25 sellä.

.··. 3. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että sopimusten tekeminen käsittää erillisen isäntäsopimuksen tekemisen ai-. noastaan käyttäjän käyttöön ja vähintään yhden palvelusopimuksen tekemi- !..* sen verkossa olevan palvelusovelluksen käyttöön. ·;·’ 30

4. Patenttivaatimuksen 2 mukainen menetelmä, t u n n e 11 u siitä, :V: että siirtäminen sisältää käyttäjäkohtaisen informaation siirtämisen mainitusta olinpaikasta asiakkaalle, jolloin mainittu informaatio on mainittuun sopimukseen yhdistetyn näkymän mukaista.

5. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, *···' 35 että mainittu siirtäminen sisältää käyttäjäkohtaisen informaation siirtämisen käyttäjältä mainittuun olinpaikkaan. 22 1 1 18 7 9

6. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että käyttäjä syöttää käyttäjäkohtaista informaatiota sisempään kerrokseen isäntäsopimuksen välityksellä.

7. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, 5 että käyttäjä aloittaa palvelusopimuksen tekemisen.

8. Patenttivaatimuksen 4 mukainen menetelmä, tunnettu siitä, että se sisältää lisäksi profiilitietoihin olevien näkymien tallentamisen agenttiin.

9. Patenttivaatimuksen 8 mukainen menetelmä, tunnettu siitä, 10 että käyttäjäkohtaisen informaation siirtäminen sisältää agenttiin aiemmin tallennetun näkymän käytön.

10. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että se käsittää lisäksi agenttien siirtämisen verkossa vasteena käyttäjän sijainnin muuttumiselle.

11. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu sii tä, että käyttäjäkohtaisen informaation siirtäminen käsittää tiedon salauksen.

12. Patenttivaatimuksen 3 mukainen menetelmä, tunnettu siitä, että sijainnin pyytäminen suoritetaan ainakin kerran jokaiselle käyttäjän ja asiakkaan väliselle palveluistunnolle.

13. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu sii- tä, että asiakas on palvelusovellus.

• '·· 14. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu sii- : ’ ’ ’: tä, että asiakas on käyttäjä.

·:··· 15. Järjestelmä käyttäjäkohtaisen informaation tarjoamiseksi pal- ;···. 25 velusovellusten käyttöön tietoliikenneverkossa, tunnettu siitä, että järjes- .···. telmä käsittää - käyttäjän profiilitietojen tallentamiseksi käyttäjäkohtaisia ohjelmis-. toagentteja, joista kukin käsittää vähintään sisemmän kerroksen mainittujen profiilitietojen tallentamiseksi ja ulomman kerroksen sellaisten sopimusten • · ·;·' 30 tallentamiseksi, joiden välityksellä asiakkaat pääsevät profiilitietoihin, jolloin kukin sopimus muodostaa rajapinnan, jonka avulla kontrolloidaan käyttäjän profiilitietojen verkosta päin tapahtuvaa käyttöä ja kukin asiakas on osapuoli, joka käyttää verkossa olevia käyttäjän profiilitietoja, • · » : >‘ - tallennusvälineet mainittujen agenttien tallentamiseksi verkkoon, ’··· 35 - sijainninhallintavälineet sopimusten kulloistenkin sijaintien hallitsemiseksi ja 23 1 11879 - välineet käyttäjäkohtaisen informaation siirtämiseksi mainitun sopimuksen välityksellä halutun sopimuksen senhetkisen sijainnin ja asiakkaan välillä.

16. Vaatimuksen 15 mukainen järjestelmä, tunnettu siitä, että 5 se käsittää lisäksi välineet profiilitietoihin olevien näkymien määrittämiseksi ja kunkin näkymän yhdistämiseksi ainakin yhteen sopimukseen, jolloin kukin näkymä määrittää sen käyttäjäkohtaisen informaation muodon ja sisällön, joka on saatavissa näkymään yhdistetyn sopimuksen välityksellä.

17. Vaatimuksen 16 mukainen järjestelmä, tunnettu siitä, että 10 käyttäjäkohtaiset ohjelmistoagentit käsittävät lisäksi näkymiä tallentavan kes kikerroksen, joka sijaitsee ulomman ja sisemmän kerroksen välissä.

18. Vaatimuksen 15 mukainen järjestelmä, tunnettu siitä, että käyttäjäkohtaiset ohjelmistoagentit ovat liikkuvia agentteja.

19. Vaatimuksen 15 mukainen järjestelmä, tunnettu siitä, että 15 se käsittää lisäksi agentinluomisvälineet käyttäjän profiiliagentin luomiseksi. • · • · »M • · · • · 1 · · • · 111879