Her følger en knippe eksempler på bruksmønstre som kan gi en ide om mulighetene som åpner seg. Noen av eksemplene vil kreve funksjonalitet i tillegg til grunnfunksjonaliteten, men hovedsakelig skal de gi et bilde av hva som er mulig når man har en distribuert plattform med autentisering, autorisering, anonymisering via koblede id’er og et personlig datalager som alltid er tilgjengelig.
Bruk mot retailer
Kunde går til en retailer’s website, landingssiden lastes og med den lastes en klient mot Haven (kalt Ward). Kunden autentiserer med Ward og en notifikasjon går til Retaileren med beskjed om at Ward er autentisert, men det eksisterer ingen kobling mellom kundens profil i Haven og Retaileren. Norwegian som nå har et kaldstart problem sender en forespørsel om å få samtykke til å koble kunden til Retaileren, enten ved å sende et kundenummer til Haven gate eller få en ID fra Gate som Retaileren selv lagrer med kundenummeret. I tillegg ber Retaileren om et knippe med samtykker for å gi kunden en best mulig opplevelse. Om kunden svarer ja til samtykkene slipper han å fylle ut noe som helst om seg selv. Her er det opp til Retaileren å la kunden forstå at de vil kundens beste. Samtykkene kan kunden trekke tilbake eller begrense via sin profil i Haven som inneholder alle samtykker kunden har inngått med tjenester som bruker Haven. Dette kan enten være å få tilgang til å se hvilke andre butikker kunden har data fra eller å spørre etter data fra en kjent tjeneste som normaliserer data fra forskjellige nettsteder. Et eksempel kan være fra Operaen som i tillegg til hvilke forestillinger kunden har vært på har utvidet profilen med data om hvorfor kunden går i operaen. Om kunden går i Operaen fordi kunden elsker opera eller om det er fordi det er viktig å bli oppfattet som intellektuell vil kunne være nyttig i forhold til hvilken opplevelse som tilbys fra Retaileren. Data fra en tjeneste som Spleis kan muligens brukes for å se om kunden er en type som f.eks er opptatt av å minske karbonfotavtrykk som også vil kunne ha noe å si for hvilke produkter som presenteres. Det kan være interessant å sjekke hvilke bøker kunden leser med data fra Ark eller en annen bokhandel. Man vil også kunne sjekke om kunden har noe interessante data fra Amazon, Facebook eller andre som kan ha data som vil kunne si noe om hvilke produkter kunden har, er interessert i eller hva slags motivasjon det er som driver kunden.
Bruk mot tredjeparts tjenester
Nå som det eksisterer en kobling til kunden kan Retaileren spørre kunden om denne går med på å lage koblinger til eksterne tjenester. La oss anta at Retaileren har en avtale med en forhandler av programmatisk markedsføring og en leverandør av produktanbefalinger. For lagring av data til produktanbefalinger trengs yttligere samtykker, men dette kan gjøres lettere for kunden å akseptere ved at hverken programmatisk- eller anbefalingsleverandøren har noen mulighet til å finne ut hvem kunden er og kunden har full mulighet til selv å slette koblingen uten å måtte stole på at leverandørene rydder selv. Dette gjøres ved at trackerne til leverandørene lastes inn med en id som er koblet til kundens profil men det er kun Haven som vet hvilken profil de er knyttet til. Når kunden er målet i en budrunde om annonse plass vunnet av Retaileren og annonsen lastes sender programmatiskleverandøren en forespørsel via Haven til anbefalingsleverandøren. Haven bytter id’en til den som representerer kunden i datasettet til programmatiskleverandøren med id’en som representerer kunden hos anbefalingsleverandøren som kan berike annonsen med anbefalinger basert på Retailerens interne data. Det er forøvrig verd å merke seg at noen programmatiskleverandører er veldig tilbakeholdne med å dytte en id igjennom nettverket sitt. Dette kan bero på at de er usikre på hvordan byråene vil stille seg til dette. Noen mindre aktører er positive og noen større har sendt litt blandete signaler. Dette er en mulighet til å kutte ut noen ledd i programmatisk markedsføringen og samtidig gjøre anbefalingene basert på interne data.
Bruk i akuttmedisin
En person får en skade som gjør at han må på sykehuset. Når personen ankommer sykehuset forsøker helsepersonell å få nok opplysninger til å rimelig sikkert kunne avgjøre hvem personen er. For eksempel muntlig navn eller telefonnummer, fysisk identifikasjon eller kanskje nfc eller liknende. Personell på sykehuset ønsker å administrere medikamenter men ønsker å sjekke om pasienten har en kondisjon eller bruker medikamenter som kryssreagerer. Basert på info om personalia gjøres en spørring mot profilen om medikamentene man ønsker å bruke er ok. Det er ikke nødvendig å få tilgang til all data om personen så lenge man er tilstrekkelig sikker på at svaret er riktig. Om pasienten benytter seg av naturmedisin kan også dette ligge i profilen. Dette gjør også at alle handlinger i forhold til pasienten automatisk legges til personens profil. Skjønt, om bestemmelsen av pasientens ID er for usikker, må dataene mellomlagres inntil pasientens ID er sikret. Alt som registreres digitalt i forhold til pasienten kan også lagres i en blockchain for å ha en sikker dokumentasjon på hva som er gjort.
Bruk hos fastlege
Pasienten kommer seg helt fint, men oppsøker fastlege for sykemelding og eventuell videre behandling. Fastlegen ønsker å se hva som har skjedd og sender en samtykkeførespørsel til pasienten – som pasienten svarer ja til. Fastlegen har ikke noe behov for hverken å kontakte sykehuset eller å lagre noen av pasientens data i egne systemer – utover hva som er påkrevd av dokumentasjon. Fastlegen rekvirerer en spesialist til oppfølging, skriver ut resepter og sender nødvendig data til nav. Fastlegen trenger ikke å samle inn data om arbeidplass, eller kontaktopplysninger det er kun nødvendig å få et samtykke fra pasienten til å sende ut forespørsler til de rette instanser. Forespørslene vil typisk inneholde hva som ønskes og en ny ID som er koblet til pasientens profil. Ønskes enda større sikkerhet kan forespørslene også sendes som temporære id’er som kun autoriserte instanser kan slå opp.
Bruk hos hotell
En person kommer inn i lobbyen og har åpenbart hatt en slitsom dag. Personen er på vei til et arrangement i en annen by, men har på grunn av forsinkelse mistet videre fly og blir nødt til å overnatte på et hotel. Flyselskapet som forsøker å hjelpe har funnet et hotel med ledig rom i nærheten og har spurt personen om tillatelse til å sende nok data til hotellet slik at de kan ta vel imot personen. Hotellet får ikke tak i noe relevant data om personen i sine systemer internt i tillegg til det som kom med forespørselen om ledig rom, så systemet bestemmer seg for å sjekke med brukerens HAVEN profil. Basert på dataene hotellet allerede har fått tillatelse til å bruke, gjøres en vurdering av hvilke andre data det vil være ønskelig å få tilgang til. Systemet bestemmer seg for å be om tilgang til enkelte nøkkeldata som det vil bruke mot en tredjepartstjeneste som genererer psykologiske profiler. Dette koster noe men om man kan få personen ikke bare til å bli godt ivaretatt men få en følelse av å bli likt er det en god sjanse for at personen vil bli en returnerende gjest. Personen som kjenner til HAVEN fra tidligere vet at ingen opplysninger vil komme på avveie og at ingen andre mennesker vil se bakgrunnen for valgene systemet gjør. Basert på tilgjengelige data legger systemet opp til en liten hvil før en sen middag – hvor det blir servert noe tilpasset, eksklusivt og overraskende – før det blir lagt opp til en mulighet til å treffe noen andre gjester som passer til både øyeblikk og person. Eventuelle behov for en forfriskende natts søvn blir arrangert og neste morgen forlater personen hotellet med følelsen av å ha blitt like godt ivaretatt som av sin egen mor men uten unødvendige formaninger.