NO325783B1 - Autentisert betaling - Google Patents

Description

Relatert søknad

Denne søknad krever prioritet fra US provisional patentsøknad nr. 60/198,110, med tittelen "Authenticated payment" av Greg Whitehead, Michael Graves og Thane Plambeck, levert 17. april 2000, hvis søknadsgjenstand er innlemmet heri ved referanse.

Oppfinnelsens område

Den foreliggende oppfinnelse vedrører å autentisere kjøpere ved onlinehandelstransaksjoner og, nærmere bestemt, å ha en separat autentiseringstjeneste for å autentisere kjøperen.

Oppfinnelsens bakgrunn

Som et resultat av økende popularitet og akseptanse av Internett og andre former for nettverkskommunikasjon, er onlinehandel blitt "big business". For eksempel er volumet av forbrukshandler "business-to-business"-handel og aksjehandling og andre former for investeringer som forekommer over Internett og/eller trådløse nett stadig økende, noe som også er tilfelle for onlinehandel. I tillegg blir det gjort store anstrengelser for å utvikle alternative forretningsmodeller (slik som auksjoner og gruppehandling) og alternative former for betaling (slik som e-kontanter og internettautoriserte kapitaloverføringer) i et forsøk på å dra fordeler av de unike karakteristika til onlinehandel.

En av ulempene med onlinehandel er imidlertid vanskeligheten med kjøperautentisering. Ta for eksempel et tilfelle hvor en forbruker ønsker å kjøpe en artikkel ved å benytte et kredittkort. Hvis kjøperen hadde gjort dette i den virkelige verden, ville kjøperen måtte være tilstede sammen med sitt fysiske kredittkort (eventuelt med et bilde på) og ville ha måttet signere kredittkortkvitteringen med en signatur som matcher den på kredittkortet. Disse handlinger oppnår to viktige mål. For det første etablerer de med en viss tiltro at kjøperen er autentisert til å benytte kredittkortet. For det andre genererer de et bevis som gjør det vanskelig for kjøperen å senere benekte at han har autorisert kjøpet. Begge disse faktorene reduserer risikoen for en svindlertransaksjon betydelig.

I onlineversjonen av denne transaksjonen, vil handlingene som tilsvarer det å fremvise et fysisk kredittkort og å signere kredittkortkvitteringen enten ikke eksistere, og hvis de eksisterer, er de ikke så effektive for å redusere risikoen. For eksempel må kjøperen i mange tilfeller kun taste inn sitt kredittkortnummer og deretter klikke på en utfør kjøp-knapp. Disse to handlingene er mer utsatt for svindel enn det som skjer i den virkelige verden fordi selgeren ikke vet om personen som utfører disse handlinger faktisk er autorisert til å benytte kredittkort. Med andre ord er det vanskelig for selgeren å autentisere kjøperen. Videre, selv om den faktiske kredittkorteier autoriserte transaksjonen, betyr den økte risikoen for svindel at den resulterende transaksjon ikke er så sterk siden kredittkorteieren kan hevde at en svindler autoriserte transaksjonen. Denne ekstra risikoen for svindel i "kort ikke tilstede"-situasjonen resulterer i høyere vekslingsgebyrer og gebyrer for transaksjoner som prosesseres over Internett og andre onlinehandelssystemer, og er kanskje den største enkeltbidragsyter til kostnadsgrunnlaget for internetthandel.

Tidligere er det kjent fra US5793028 ett sikkerhetssystem for elektronisk overføring hvor hver elektronisk overføring blir lagret og verifisert. Fra W09942961 er det kjent ett system som bruker et kort med en forhåndsgenerert kode for å verifisere at en person som gjør en betaling er autorisert for å utføre en transaksjon. Felles for disse to er at de ikke lagrer en datapost av betalingstransaksjonen, digitalt signert av kjøperen, i et transaksjonsarkiv.

En av grunnene for at internettsvindel og annen onlinesvindel har vokst er at personlig

betalingsinstrumentinformasjon slik som kredittkortnummer, kontonumre og relaterte data i stor grad har blitt "offentlig informasjon" i den betydning at disse dataene har blitt lett tilgjengelig. For eksempel oppgir en forbruker sitt kredittkortnummer, og utløpsdato etc. i et ubeskyttet format til hver onlinetilbyder i hver transaksjon. I tillegg er også informasjon slik som navn, adresse, personnummer, etc. tilgjengelig fra kilder utenom kortholderens. For eksempel kan søkbare, webtilgjengelige telefonkataloger og andre katalogtyper inneholde mye av denne type informasjon. Den repeterte, ubeskyttede avsløringen av betalingsinstrumentinformasjonen, sammen med det faktum at mye av denne informasjonen også er tilgjengelig fra andre kilder, øker risikoen for svindlerske transaksjoner. For eksempel trenger hackere ofte bare å hente kredittkortnummeret og tilknyttede navn og adresseinformasjon fra databaser for å gi seg ut for å være den faktiske korteier i mange

onlinetransaksj onsmilj øer.

Vanligvis har kjøpsautentiseringsproblemet blitt forsøkt løst gjennom bruken av passord, noe som er vanlig i internetthandelsmiljøer, hvor kjøperen autentiserer seg selv ved typisk å benytte et enkelt brukernavn og et passord. Som tidligere beskrevet, har passord iboende svakheter når de benyttes for dette formål og nåværende implementasjoner forverrer disse svakhetene ytterligere. For eksempel må forbrukere typisk foreta en individuell registrering hos hver tilbyder ved å benytte en onlineprosess. Som et resultat av dette, har tilbyderen en begrenset mulighet til å verifisere forbrukerens registrering, siden timingen av onlineregistreringen ofte ikke tillater tilstrekkelig verifisering, og selv om dette var tilfelle, ville kostnaden være hindrende siden hver tilbyder ville måtte bære kostnaden for sin egen verifikasjon. I tillegg vil forbrukerne ofte benytte samme brukernavn og passord for flere kontoer. Dette øker sjansen for at brukernavn og passord vil bli brakt i fare, og dette øker den potensielle skaderisikoen. Videre, siden brukernavn og passord typisk overføres til tilbyderen i ren tekstformat, kan skruppelløse tilbydere også benytte denne informasjonen til å kompromittere forbrukerens andre kontoer. Som et avsluttende eksempel, har mange autentiseringssystemer med kundens identitet (for eksempel anta at brukeren faktisk er John Doe), men å autentisere noens identitet er ikke nødvendig det samme som å verifisere at noen er autorisert til å benytte et bestemt betalingsinstrument.

Secure Electronic Transaction-protokollen (SET) var ett forsøk på å løse kjøperautentiseringsproblemet for å skaffe tilveie sikker betalingskorttransaksjoner over Internett. I SET ble digitale sertifikater benyttet for å opprette en tillitskjede gjennom transaksjonen. For eksempel ville forbrukeren ha et digitalt sertifikat som han presenterte til tilbyderen. Tilbyderen ville ha et digitalt sertifikat som han presenterte til forbrukeren. Hver ville verifisere den andres digitale sertifikat og den underliggende kjeden av digitale sertifikater for å etablere tillit. Denne tilnærmingen førte imidlertid til betydelig administrativ og operasjonell kompleksitet for kunder, tilbydere og tilhørende transaksjonsprosesseringsinfrastruktur. For eksempel krevdes det fra både kjøper og tilbyder spesialisert teknologi for å ta del i protokollen og det var nødvendig å oppgradere teknologien hver gang ny digital sertifikatteknologi ble benyttet. Som et resultat av dette, har ikke SET blitt særlig utbredt.

Det er derfor et behov for en solid kjøperautentisering i forbindelse med onlinehandelstransaksjoner. Det er videre et behov for tilnærming til kjøperautentisering som også er fleksibelt nok til lett å kunne tilpasse seg forskjellige sikkerhetsnivåer for forskjellige bruksområder og også å kunne tilpasse seg nye teknologier. Tilnærmingen bør fortrinnsvis heller ikke påføre særlige byrder på eller kreve omfattende modifikasjoner av eksisterende transaksj onsprosesseringsinfrastrukturer.

Kort oppsummering av oppfinnelsen

I henhold til den foreliggende oppfinnelse, slik den er beskrevet i søknadens selvstendige krav 1, 8 og 15 og deres tilhørende uselvstendige krav, omfatter et online handelstransaksjonssystem (100) en kjøper (110), en selger

(120) og en autentiseringstjeneste (130). Det er ønskelig å autentisere (204) til selgeren (120) at kjøperen (110) er autorisert til å benytte et betalingsinstrument som del av en onlinehandelstransaksjon med selgeren (120). For å gjøre dette utfører autentiseringstjenesten (130) de følgende trinn, hvorpå alle opptrer i sann tid som en del av onlinehandelstransaksjonen. Autentiseringstjenesten (130) mottar (230) forespørselen om å verifisere at kjøperen

(110) er autorisert til å benytte betalingsinstrumentet. Den bestemmer (246) hvorvidt kjøperen (110) har tilgang til en bestemt sikkerhetsinformasjon uten å avsløre sikkerhetsinformasjonen til selgeren (120) . Tilgangen til den sikre informasjonen vil verifisere autoriteten for å bruke betalingsinstrumentet. Som en respons til bestemmelsen av hvorvidt kjøperen (110) har tilgang til sikkerhetsinformasjonen, sender (250) autentiseringstjenesten (130) til selgeren (120) en respons som inneholder informasjon om hvorvidt kjøperen (110) er autorisert til å benytte betalingsinstrumentet. I et annet aspekt ved oppfinnelsen, gir (260) autentiseringstjenesten

(130) profilinformasjon om kjøperen (110) til onlinehandelstransaksjonen og/eller prosesserer (270) eller i det minste delvis prosesserer betalingstransaksjonen. Autentiseringstjenesten (130) kan også lagre (280) en datapost over bruken av betalingsinstrumentet og/eller transaksj onen.

I en foretrukken utførelse (300) opptrer

onlinehandelstransaksjonen på Internett. Kjøperen (110) aksesserer Internett via en webbrowser, selgeren (120) opererer på en internettbutikk på en webserver, og autentiseringstjenesten (130) er implementert på en webserver. Videre omfatter den hemmelige informasjonen en privat nøkkel. Med andre ord vil opprettelsen av digitale signaturer ved å benytte den private nøkkel være et bevis på at signereren er autorisert til å benytte det tilhørende betalingsinstrument. I denne utførelsen blir forespørselen

(330) for autentisering trigget av kjøperens utfylling av et skjema (400), som inkluderer en handlingsattributt som identifiserer autentiseringstjenesten (130). Forespørselen

(330) til autentiseringstjenesten (130) omfatter også selgerens adresse, slik at autentiseringstjenesten vet hvor den skal sende (250) resultatet av autentiseringsprosessen. For å autentisere selgeren (120), sender (340) autentiseringstjensten (130) en utfordringsforespørsel til selgeren (120) som spør kjøperen (110) om å benytte den private nøkkelen til digitalt å signere noe data. Autentiseringstjenesten (130) benytter kjøperens respons

(342) for å bestemme (346) hvorvidt kjøperen (110) har tilgang til den private nøkkelen og sender (350) så resultatene til selgeren (120). Autentiseringstjenesten

(130) kan videre forespørre om kjøperen (110) kan signere en datapost av en transaksjon digitalt, for dermed å opprette (380) en sterk transaksjonsdatapost.

Den foreliggende oppfinnelse er spesielt fordelaktig fordi en separat autentiseringstjeneste (130) i stedet for selgeren (120) benyttes for å autentisere kjøperen (110) . Som et resultat, får ikke selgeren (120) tilgang til sikkerhetsinformasjon tilknyttet kjøperens betalingsinstrument. Dette hindrer selgeren (120) fra senere gjenbruk av sikkerhetsinformasjon for å autorisere svindeltransaksj oner.

Videre resulterer konsentrasjonen av

autentiseringsfunksjonen i autentiseringstjensten (130), i betydelig fleksibilitet og salgsøkonomi. Mange typer sikkerhetsinformasjon kan benyttes, hvor hver enkelt krever forskjellig implementeringsteknologi. Ved å konsentrere autentiseringsfunksjonen i autentiseringstjenesten (130) kan kostnaden til den påkrevde teknologi deles blant mange selgere (120) . Videre, hvis typen sikkerhetsinformasjon til den aktuelle kjøperautentiseringsprosedyre endres, vil omfanget av endringene kun påvirke autentiseringstjenesten

(130), slik at ny autentiseringsteknologi lett kan impelementeres. Hvis autentiseringstjeneste (130) utfører andre funksjoner, slik som å legge til kjøperprofilinformasjonen til transaksjonen, prosessering av betalingsinstrumenter eller lage eller bevare transaksjonsdatapostene, kan ytterligere skaleringsøkonomier (econimies of scale) bli realisert, siden autentiseringstjenesten (130) er et naturlig sentralisert punkt for disse andre funksjoner.

Kort beskrivelse av tegningene

Disse og andre mer detaljerte og spesifikke formål og trekk ved den foreliggende oppfinnelse blir mer fullstendig angitt i den følgende spesifikasjon, med henvisning til de vedlagte tegninger, i hvilke: Figur 1 er et blokkdiagram over et system i henhold til den foreliggende oppfinnelse, Figur 2 er et hendelsesforløp som illustrerer en fremgangsmåte for å operere systemet i figur 1, Figur 3 er et hendelsesforløp som illustrerer en foretrukken fremgangsmåte for å operere en foretrukken utførelse av systemet i figur 1, og Figurene 4-7 er forskjellige skjermbilder og dialogbokser som illustrerer fremgangsmåten i figur 3.

Detaljert beskrivelse av foretrukne utførelser

Figur 1 er et blokkdiagram over et system 100 i henhold til den foreliggende oppfinnelse. Systemet 100 inkluderer en kjøper 110, en selger 120 og en autentiseringstjeneste 130 som kommuniserer med hverandre. Systemet 100 inneholder eventuelt også en katalog 140 i autentiseringstjenesten, som er tilgjengelig for kjøper 110, og en database 150 med kjøperprofiler og et transaksjonsarkiv 170, som begge er tilgjengelig for autentiseringstjenesten 130. Betalingsgatewayen er også tilgjengelig fra autentiseringstjenesten 130, selv om det i alternative utførelser kan være selgeren 120 eller både autentiseringstjenesten 130 og selgeren 120 som aksesserer betalingsgatewayen 160. Betalingsgatewayen 160 er rett og slett forbindelsen gjennom hvilken betalingstransaksjonene videresendes til de respektive finansielle institusjoner. Den foreliggende oppfinnelse kan benyttes sammen med mange forskjellige betalingsgatewayer 160 (eller til og med uten betalingsgateway) og er ikke ment å være begrenset til en bestemt type gatewayteknologi.

Kjøperen 110 ønsker å benytte et betalingsinstrument som en del av en onlinehandelstransaksjon med selgeren 120. For eksempel, i en applikasjon, er kjøperen 110 en forbruker, selgeren 120 er en tilbyder med en internettbutikk og forbrukeren ønsker å benytte sitt kredittkort for å kjøpe noen produkter, noe informasjon eller en tjeneste fra tilbyderen. Som et annet eksempel, er kjøperen 110 et individ som kobler seg til selgeren 120 via en trådløs telefon eller en håndholdt personlig digital assistent (PDA). Selgeren 120 er en fakturabetalingstjeneste og individet ønsker å skrive ut "internettsjekker" for å betale sine månedlige regninger. Som enda et annet eksempel, er kjøperen 110 et selskap eller et individ som agerer på vegne av et selskap som kjøper materialer eller tjenester fra selskapets leverandør 120. Andre eksempler på betalingsinstrumenter omfatter å sjekke kontonummeret, virtuelle penger eller elektroniske representasjoner av kontanter, forhåndsinnbetalte kontante verdier lagret i elektroniske lommebøker, kjøpekort og internettkreditter eller kuponger.

Det burde være klart fra disse eksemplene at mange andre applikasjoner er mulige og terminologiene "kjøper" og "selger" benyttes som passende merkelapper, men er ikke ment å begrense disse entiteter. "Kjøperen" 110 er ikke nødt til faktisk å kjøpe noe og "selgeren" 120 trenger ikke faktisk å selge noe. På samme måte er ikke

"onlinehandelstransaksjon" begrenset til

kjøp/selgetransaksjoner. Onlinehandelstransaksjonen kan være en hvilken som helst transaksjon hvor kjøperen 110 ønsker å bruke et betalingsinstrument som en del av transaksjonen, eller, mer generelt, en hvilken som helst transaksjon som kan dra fordel av autentiseringen av kjøperen 110. Som et eksempel av en applikasjon som ikke benytter et betalingsinstrument, er at "kjøperen" 110 kan være et individ, "selgeren" 120 kan være et forsikringsselskap med hvilket kjøperen holder en polise, og "transaksjonen" kan være at kjøperen ønsker å veksle sin beneficiarius. Selgeren ønsker å først autentisere kjøperens identitet før aksess til hans konto kan tillates.

Figur 2 er et hendelsesdiagram som illustrerer systemets 100 operasjon 200. Fremgangsmåten 200 kan brytes ned til tre hoveddeler: kjøperregistrering 202, kjøperautorisering 204 og transaksjonsregistrering 206. Ikke alle implementasjoner vil utnytte alle de tre trinnene 202-206 eller alle de individuelle trinnene vist i figur 2, men de er med i dette eksempel for å illustrere de forskjellige aspektene ved oppfinnelsen. I kjøperregistreringen 202 etableres hemmelig informasjon som vil bli benyttet i trinn 204 for å autentisere kjøperen og betalingsinstrumentet mellom kjøpere 110 og autentiseringstjenesten 130. Kjøperregistreringen 202 opptrer fortrinnsvis bare en gang per betalingsinstrument. Kjøperautorisering 204 opptrer i sann tid som en del av onlinehandelstransaksjonen. På dette trinnet demonstrerer kjøperen 110 aksess til den hemmelige informasjonen til autentiseringstjenesten 130. Hvis aksessen er vellykket, informerer autentiseringstjenesten 130 selgeren 120 om at kjøperen 110 er autorisert til å benytte betalingsinstrumentet. I

transaksjonsregistreringstrinnet 206 oppretter autentiseringstjenesten 130 en datapost for transaksjonen, og denne dataposten kan etterpå benyttes som bevis for hvorvidt en bestemt transaksjon har inntruffet.

Bruken av en separat autentiseringstjeneste 130 har mange fordeler. For eksempel, som vil bli klarere fra beskrivelsen nedenfor, vil størsteparten av kjøperautentiseringsprosessen 204 utføres av autentiseringstjenesten 130. Autentiseringstjenesten 130 bestemmer hvorvidt kjøperen 110 har demonstrert tilgang til den hemmelige informasjonen og derigjennom er autorisert til å benytte betalingsinstrumentet. Kjøperen 110 er bare minimalt involvert og selgeren 120 er i all hovedsak ikke involvert i det hele tatt. Konsentrasjonen av denne funksjonen i autentiseringstjenesten 130 resulterer i betydelig fleksibilitet og besparelser. For eksempel kan forskjellige typer hemmelig informasjon, alt fra enkle PIN-koder til sofistikerte digitale sertifikatprotokoller, benyttes for å oppnå forskjellige sikkerhetsnivåer for forskjellige betalingsinstrumenter. Forskjellige typer sikkerhetsinformasjon vil typisk kreve forskjellig infrastruktur for å utføre kjøperautentiseringstrinnet 204. Å konsentrere kjøperautentiseringstrinnet 204 i autentiseringstjenesten 130 gjør at kostnadene for denne infrastrukturen kan deles mellom mange selgere 120. Videre, hvis sikkerhetsinformasjonstypen eller den tilhørende kjøperautentiseringsprosedyren endres, vil endringene bare påvirke autentiseringstjenesten 130, slik at nye autentiseringsteknologier lett kan implementeres. Dette i motsetning til tidligere tilnærminger, slik som SET, som krever at hver selger 120 tilveiebringer mye av den nødvendige infrastruktur. Dette fører til høye kostnader, treg initiell tilpasning, og vanskeligheter med å gå over til nye teknologier, som til slutt fører til feil og ulemper i SET og lignende tilnærminger.

Denne tilnærming er også fordelaktig fordi selgeren 120 ikke får tilgang til kjøperens 110 sikkerhetsinformasjon siden selgeren ikke er involvert i kjøperens autentisering 204. Dette hindrer at selgeren 120 senere kan gjenbruke kjøperens 110 sikkerhetsinformasjon for å autorisere falske transaksjoner. For eksempel, anta at sikkerhetsinformasjonen er en PIN-kode. Hvis selgeren 120 var ansvarlig for kjøperautentiseringen 204, ville kjøperen 110 angi sin PIN-kode til selgeren 120, som ville være i stand å benytte den senere i svindlerske hensikter. I nåværende tilnærminger angir imidlertid selgeren 120 PIN-kode n bare til autentiseringstjenesten 130 og ikke til selgeren 120.

Videre, siden kjøperautentiseringstrinnet 204 er konsentrert i autentiseringstjenesten 130, kan ytterligere besparelser realiseres ved at autentiseringstjenesten 130 også utfører andre funksjoner, som vil bli nærmere diskutert nedenfor. For eksempel kan autentiseringstjenesten 130 legge til ytterligere informasjon til transaksjonen (for eksempel kjøperens adresse), prosess eller spesielt prosessere kjøperens betalingsinstrument og/eller lage og beholde dataposter for transaksjonene.

I figur 2 representerer hver av de stiplede bokser 110, 120 og 130 en av komponentene i system 100. Heltrukne bokser representerer forskjellige trinn i fremgangsmåten 200. Plasseringen av en heltrukken boks i en stiplet boks indikerer at trinnet generelt utføres av komponenten. For eksempel er trinnet 210 plassert innenfor den stiplede boks for autentiseringstjenesten 130. Dette indikerer at autentiseringstjenesten 130 generelt utfører trinn 210. Noen trinn har to bokser, noe som indikerer at trinnene opptrer over to komponenter. For eksempel kan en komponent sende en melding til en annen komponent. Trinnene implementeres fortrinnsvis av programvare som kjører på forskjellige komponenter i systemet 100, eventuelt assistert av maskinvaremoduler. De kan også bli implementert i maskinvare og/eller firmware.

Kjøperregistreringstrinnet 202 opptrer fortrinnsvis før den faktiske onlinehandelstransaksjon. I dette trinn 202 etableres sikkerhetsinformasjonen mellom kjøperen 110 og autentiseringstjenesten 130. Informasjonen er sikker i den forstand at det ideelt er kjent og/eller tilgjengelig bare av kjøperen (eller av kjøperen 110 og autentiseringstjenesten 130 i tilfelle med en hemmelig informasjon som deles av de to). Den er generelt ikke tilgjengelig for offentligheten eller for selgeren 120. Videre tilhører sikkerhetsinformasjonen et bestemt betalingsinstrument(er), og å tilveiebringe aksess til sikkerhetsinformasjonen vil bli forstått som en autorisering til å benytte betalingsinstrumentet.

Forskjellige typer sikkerhetsinformasjon kan benyttes avhengig av sikkerhetstypen som er nødvendig. Eksempler på sikkerhetsinformasjon kan være en PIN-kode eller passord, en nettverkslagret akkreditering (for eksempel for å støtte roaming), en digital "roame"-signaturkapabilitet, en programvareakkreditering slik som en privat nøkkel plassert i kjøperens maskin, en maskinvareakkreditering slik som et maskinvarekjennemerke, eller en privat nøkkel i et smartkort, en biometrisk akkreditering, og informasjon som benyttes i kryptografiske responsprotokoller.

I det bestemte eksemplet i figur 2 etableres sikkerhetsinformasjonen som følger: autentiseringstjenesten 130 mottar 210 bekreftelsesinformasjon som gjør autentiseringstjenesten i stand til senere å bestemme hvorvidt kjøperen 110 har aksess til sikkerhetsinformasjon. Autentiseringstjenesten 130 lagrer 212 da denne bekreftelsesinformasjonen tilknyttet betalingsinstrumentet, for eksempel som en del av kjøperprofildatabasen 150. I én utførelse som følger denne modellen er kjøperens sikkerhetsinformasjon en privat nøkkel og den tilhørende bekreftelsesinformasjon er den tilhørende offentlige nøkkel.

I alternative utførelser implementeres kjøperregistreringen 202 på andre måter. For eksempel kan

bekreftelsesinformasjonen være lagret utenfor autentiseringstjenesten 130. I stedet for kan den hentes av autentiseringstjenesten 130 når det er nødvendig. Alternativt, i stedet for å lagre bekreftelsesinformasjonen som er forskjellig fra sikkerhetsinformasjonen, kan autentiseringstjenesten 130 ganske enkelt lagre sikkerhetsinformasjonen selv (for eksempel lagre passord eller hasher med passord). Som et annet eksempel, kan kjøperregistrering 202 foregå offline. For eksempel kan kjøperen 110 fylle ut en søknad og sende den til en bank. Banken verifiserer informasjonen på søknaden, utsteder et kredittkort til kjøperen 110, og sender kontoinformasjon til autentiseringstjenesten 130. Autentiseringstjenesten 130 lager et smartkort med integrert sikkerhetsinformasjon og smartkortet sendes kjøperen 110, for eksempel gjennom vanlig postgang. Legg merke til at i dette siste eksempel drar kjøperregistrering 202 fordeler av

kredittkortutrullingsprosessen. Kjøperregistreringen kan også trekke fordeler av andre prosesser.

Sikkerhetsinformasjonen genereres fortrinnsvis av kjøperen 110 for å minimalisere avsløringene til andre parter. I alternative utførelser kan den imidlertid genereres og/eller deles med andre parter, for eksempel autentiseringstjenesten, spesielt når risikoen disse parter bidrar med antas å være lav.

I kjøperautentiseringstrinnet 204 ønsker kjøperen 110 å benytte betalingsinstrumentet som en del av en online handelstransaksjon med selgeren 120. Autentiseringstjenesten 130 bestemmer i sanntid som en del av transaksjonen hvorvidt kjøperen 110 er autorisert til å gjøre dette. I det bestemte eksempel i figur 2 foregår dette som følger. Kjøperen 110 tilbyr 220 bruk av betalingsinstrument. For eksempel kan kjøperen 110 tilby betaling for et kjøp ved å benytte et kredittkort.

Selgeren 120 vil gjerne vite hvorvidt kjøperen 110 er autorisert til å benytte betalingsinstrumentet, så han sender 230 en forespørsel til autentiseringstjenesten 130 om å verifisere kjøperens autoritet. Avhengig av betalingsinstrumentet, kan identiteten til autentiseringstjenesten 130 ikke nødvendigvis være umiddelbart åpenbar. Det kan være mer enn en autentiseringstjeneste, for eksempel kan hvert kredittkortselskap tilveiebringe sin egen

autentiseringstjeneste. En måte å løse dette problemet på er å ha en katalog 140 som tilknytter

autentiseringstjenester med betalingsinstrumenter. I dette tilfellet aksesserer selgeren 120 katalogen 140 for å bestemme hvilken autentiseringstjeneste som er den mest beleilige for betalingsinstrumentet som er presentert av kjøperen 110.

Autentiseringstjenesten 130 bestemmer hvorvidt kjøperen 110 har tilgang til sikkerhetsinformasjonen i trinnene 240 til 246. Autentiseringstjenesten 130 sender 240 en "utfordringsforespørsel" til kjøperen 110. Utfordringsforespørselen spør etter bevis på at kjøperen har tilgang til sikkerhetsinforasjon. For eksempel, hvis sikkerhetsinformasjonen er et passord, kan

utfordringsforespørselen spørre etter et passord. Hvis

sikkerhetsinformasjonen er en privat nøkkel, kan utfordringsforespørselen forespørre kjøperen 110 om digitalt å signere noe ved å benytte den private nøkkelen. I en utførelse inkluderer utfordringsforespørselen også en beskrivelse på en onlinehandelstransaksjon og gjør det mulig at kjøperen kan avslå transaksjonen, for eksempel hvis beskrivelsen ikke tilsvarer kjøperens forventning. På samme måte kan utfordringsforespørselen i stedet spørre etter kjøperens samtykke til transaksjonen. Hvis kjøperen 110 ønsker å fortsette, sender han 142

"utfordringsresponsen" tilbake til autentiseringstjenesten 130.

Autentiseringstjenesten 130 henter ut 244 den tidligere lagrede bekreftelsesinformasjonen for betalingsinstrumentet og benytter bekreftelsesinformasjonen og utfordringsresponsen for å bestemme hvorvidt kjøperen 110 har tilgang til sikkerhetsinformasjon. For eksempel, i en utførelse av passordeksemplet, hasher autentiseringstjenesten 130 det angivelige passord fra utfordringsresponsen og sammenligner dette med hashen som er lagret som bekreftelsesinformasjon. I en utførelse av privatnøkkeleksemplet, benytter autentiseringstjenesten 130 den offentlige nøkkel lagret som bekreftelsesinformasjon for å bestemme hvorvidt den digitalt signerte melding i utfordringsresponsen virkelig ble digitalt signert ved å benytte den tilhørende private nøkkel.

Autentiseringstjenesten 130 transmitterer 250 så til selgeren 120 en respons på selgerens opprinnelige forespørsel. Responsen inkluderer hvorvidt kjøperen 110 er autorisert til å benytte betalingsinstrumentet. Den kan også inkludere ytterligere informasjon, som vil bli beskrevet i forbindelse med trinnet 260 og 270. Legg merke til at i løpet av kjøperautentiseringen 204, avsløres ikke sikkerhetsinformasjonen for selgeren 120.

Før vi går videre til trinnene 260 og 270, bør det legges merke til at autentiseringstrinnene 240-250 illustrert i figur 2 bare er en måte å implementere kjøperautentiseringstrinnet 204. Andre implementasjoner vil være åpenbare. For eksempel kan autentiseringstjenesten 130 motta 230 forespørsel for autentisering fra kjøperen 110 i stedet for selgeren 120. Som et annet eksempel, kan autentiseringstjenesten 130 ikke benytte en utfordringsforespørsel 240 og tilhørende utfordringsrespons 242. Bevis på aksess til sikkerhetsinformasjonen kan være inkludert som en del av en initiell forespørsel 230 i stedet. I tillegg, som nevnt i kjøperregistreringsfasen 202, kan autentiseringstjenesten 130 benytte fremgangsmåter i tillegg til bekreftelsesinformasjon (trinnet 244 og 246) for å bestemme hvorvidt kjøperen har tilgang til sikkerhetsinformasj on.

I figur 2, i noen utførelser, kan autentiseringstjenesten 130 også benytte ytterligere kjøperprofilinformasjon for transaksjon. For eksempel kan selgeren 120 forespørre om at kjøperens adresse må legges til transaksjonen. Autentiseringstjenesten 130 vil hente ut denne informasjonen gjennom databasen 115 og legge den til den pågående transaksjon. Ytterligere informasjon kan legges til ved forskjellige tidspunkter i løpet av transaksjonen og kan eventuelt involvere kommunikasjoner med enten kjøperen 110 eller selgeren 120. I adresseeksmplet kan kjøperen 110 bli spurt om å verifisere adressen og/eller selgeren 120 kan benytte adressen for å beregne forsendelsesgebyrer, som i sin tur vil veksle transaksj onspengesummen.

På samme måte kan autentiseringstjenesten 130 også prosessere 270 betalingstransaksjon, for eksempel via betalingsgatewayen 160. Som en ekstremitet, kan autentiseringstjenesten 130 ganske enkelt gi beskjed 250 til selgeren 120 om at kjøperen 110 er autorisert til å benytte betalingsinstrumentet, men selgeren 120 foretar alle andre trinn som er nødvendig for å prosessere betalingsinstrumentet. Som en annen ytterlighet, kan det være autentiseringstjenesten 130 som foretar trinnene med å prosessere betalingstransaksjonene. I det mellomliggende tilfellet foretar autentiseringstjenesten 130 noen trinn og kjøperen ferdiggjør de andre.

Både kjøperprofilering 260 og betalingsprosessering 270 er attraktive fordi autentiseringstjenesten 130 er et naturlig sentralt punkt for disse aktiviteter. Som for de faktiske autentiseringstrinn 240-246, kan besparelsene realiseres ved å få autentiseringstjenesten 130 til å utføre disse funksjoner i stedet for å kreve at hver individuelle selger 120 skal gjøre dette.

I transaksjonsregistreringstrinnet 206 lagrer 280 autentiseringstjenesten 130 en datapost for transaksjonen i transaksjonsarkivet 170. Påliteligheten til dataposten vil være avhengig av den bestemte applikasjon. Som ett eksempel, kan autentiseringstjenesten 130 ganske enkelt lagre rene tekstbeskrivelser av transaksjonen. Som et annet eksempel, kan digitalt signerte og tidsstemplede dataposter være mer anvendelig. For å fortsette passordeksemplet ovenfor, kan en digitalt signert datapost opprettes ved å få autentiseringstjenesten til digitalt å signere dataposten ved å benytte sin egen privatnøkkel. I det private nøkkeleksempel oppretter kjøperen 110 selv en digital signert datapost for transaksjonen ved å benytte sin egen private nøkkel. I begge disse eksempler er resultatet en vedvarende, digitalt signert datapost for transaksjonen, som kan benyttes av kjøperen 110, selgeren 120 eller andre parter for å løse diskusjoner rundt transaksj onen.

Figurene 3-7 illustrerer en foretrukken utførelse av systemet 100 og fremgangsmåten 200. I internettutførelsen opptrer onlinehandelstransaksjonen over et http-basert system, spesielt Internett. Kjøperen 110 aksesserer

Internett ved å benytte en konvensjonell webbrowser. Selgeren 120 er en tilbyder som opererer i en websitebutikk på Internett, fiktive Pete's Soccer Emporium i dette tilfellet. Butikken befinner seg på en konvensjonell webserver. Autentiseringstjenesten 130 har også et grensesnitt mot Internett via en webserver. Kjøperen 110 ønsker å kjøpe Adidas Eqt. Predator Accelerator Cup fra Pete's Soccer Emporium ved å benytte sitt kredittkort som betalingsinstrument. Sikkerhetsinformasjonen som benyttes for å sikre transaksjonen er en privat nøkkel tilknyttet betalingsinstrumentet. Av bekvemmelighetshensyn refereres denne utførelse til som internettutførelsen, men dette er ikke ment å implisere at utførelsen er den eneste mulighet for Internett.

Figur 3 er et hendelsesforløp som illustrerer operasjonen for internettutførelsen. Som for fremgangsmåte 200, kan fremgangsmåte 300 grovt sett brytes ned i tre hoveddeler: kjøperregistrering 302, kjøperautentisering 304 og transaksjonsregistrering 306. Trinnet for

kjøperautorisering 304 og transaksjonsregistrering 306 er imidlertid blandet med hverandre.

I kjøperregistreringsfasen 302 setter kjøperen 110 opp sin "konto" med autentiseringstjenesten 130. I dette tilfellet betyr dette at en hvilken som helst offline undersøkelse kan benyttes. For eksempel motta informasjon fra kredittkortselskap om at kjøperen 110 er autorisert til å benytte kredittkortet. I tillegg genereres et privat/offentlig nøkkelpar for kontoen og den offentlige nøkkelen lagres 312 i autentiseringstjenestens database 150. I en foretrukken utførelse lagres den offentlige nøkkel i form av et digitalt sertifikat som representerer at den offentlige nøkkel er bundet til kjøperens konto.

I denne utførelse er kontoen og nøkkelparet bundet til et antall betalingsinstrumenter, inkludert det spesifikke kredittkortet som skal benyttes. Med andre ord, det digitale sertifikatet og nøkkelparet er for kjøperens "lommebok" som inneholder mange betalingsinstrumenter, i stedet for ett bestemt betalingsinstrument. Andre utførelser kan imidlertid benytte forskjellige regler, slik som å benytte en ny konto og et nytt nøkkelpar for hvert betalingsinstrument. I tillegg kan kjøperen 110 ha et antall kontoer og nøkkelpar. I denne utførelsen administreres kjøperens private nøkler og de tilknyttede offentlige nøkkelinfrastrukturtjenester (PKI - public infrastructure) for kjøperen 110 ved hjelp av en programvareagent, nærmere bestemt VeriSign Personal Trust Agent (PTA). PTA-en tilveiebringer generell nøkkel- og sertifikatadministrasjonsfunksjonalitet og er lagret for å lett kunne bli inkorporert i webapplikasjoner.

VeriSign PTA administrerer kjøperens PKI-akkreditering. For eksempel, hvis kjøperen 110 ikke har et digitalt sertifikat eller nøkkelpar, tar PTA-en kjøperen 110 til en sertifikatutrullingsside. Hvis kjøperens digitale sertifikat snart utgår, ber PTA-en kjøperen 110 om å fornye sertifikatet før han fortsetter og kan ta kjøperen 110 til sertifikatfornyingssiden. På samme måte, hvis kjøperens sertifikat allerede har utgått, tilbyr PTA-en muligheten til å gå til sertifikatfornyelsessiden for å fornye det utgåtte sertifikat. Alt dette implementeres ved hjelp av et sett med dialogbokser som er konsistente over forskjellige browsere. Videre, selv om denne bestemte utførelse benytter browsere, støtter PTA også andre innretninger, slik som trådløse telefoner og håndholdte PDA-er.

PTA-en og private nøkler kan være lokalisert på et antall steder. I dette eksempel holder en separat server (ikke vist) programvaren som implementerer PTA-en og lagrer tilhørende private nøkler. En fordel med denne tilnærming er at siden PTA-en og private nøkler er implementert som en nullklient, leid tjeneste, trenger ingen endringer å gjøres i kjøperens browser. En annen fordel er at siden kjøperens browser ikke trenger noen spesiell programvare, kan kjøperen 110 potensielt aksessere PTA-en og dens private nøkler fra en hvilken som helst standardbrowser. For et eksempel på hvordan dette kan være implementert, se US patentsøknad 09/574,687, "Server-Assisted Regeneration of a Strong Secret from a Weak Secret", av Warwick Ford, levert 17. mai 2000, hvis søknadsgjenstand er inkorporert heri ved referanse. Hvis servere som holder PTA-en er det samme som den som holder autentiseringstjenesten 130, kan de to funksjoner til en viss grad være integrert. En alternativ utførelse er PTA-en og/eller tilhørende private nøkler implementert på kjøperens klient. For eksempel kan PTA-en være implementert som en plugin (for eksempel aActiveX control) i kjøperens browser og de private nøkler lagret lokalt på kjøperens klient eller i dedikert maskinvare (for eksempel et maskinvaremerke - hardware token).

For å fortsette fotballeksemplet, etter registrering 302, handler kjøperen 110 hos Pete's og bestemmer seg for å kjøpe noen produkter. Figur 4 er et skjermbilde over kjøperens browser når han begynner utsjekkingsprosessen. Html-ordreskjema 400 inneholder et ordreområde 410 og også en knapp 420 for autentisert ekspressbetaling. Ordreområdet indikerer at det totale beløp pluss moms for denne ordre er $59.99. Kjøperen 110 kan sjekke ut på en uautorisert måte ved å benytte resten av skjemaet, fylle inn kredittkortinformasjon, faktureringsadresse etc. Kjøperen 110 ønsker likevel å benytte autentisert betaling og klikker i stedet på knappen 420 for "AuthPay" (dvs. autentisert betaling).

Som et resultat av å klikke på den autentiserte betalingsknapp 420, sendes en forespørsel for autentisering fra kjøperens browser til autentiseringstjenesten 130. Forespørselen inkluderer en beskrivelse av betalingstransaksjonen og identifiserer også selgeren 120. Autentiseringstjenesten 130 bestemmer hvorvidt kjøperen 110 har tilgang til sikkerhetsinformasjon (i dette tilfellet den private nøkkel for den valgte konto) i trinnet 340-346. Nærmere bestemt sender autentiseringstjenesten 130 en utfordringsforespørsel til kjøperen 110. Utfordringsforespørselen spør kjøperen 110 om han digitalt kan signere noe data ved å benytte den private nøkkel for den valgte konto. Kjøperen 110 sender 342 hans utfordringsrespons tilbake til autentiseringstjenesten 130. Autentiseringstjenesten 130 henter ut den tidligere lagrede offentlige nøkkel og benytter den for å bestemme 346 hvorvidt kjøperen 110 har tilgang til den tilhørende private nøkkel. Autentiseringsprosessen gjennomføres typisk mellom datamaskiner uten kjøperens 110 aktive manuelle deltakelse.

I denne utførelsen blir PTA-en også anropt for at kjøperen 110 skal kunne velge hvilke av hans kontoer han ønsker å benytte og senere for å velge det bestemte betalingsinstrument fra kontoen. Nærmere bestemt forårsaker det å klikke på knappen 420 at kjøperens webbrowser interagerer med PTA-en via dialogboksene i figurene 5A og 5B. I figur 5A spesifiserer kjøperen 110 hvilken konto han ønsker å benytte ved å fylle inn brukernavnfeltet 510 og deretter å autentisere seg selv for PTA-en ved å fylle inn riktig passord 520. PTA-en viser dialogboksen i figur 5B, som inkluderer en visuell representasjon 530 av kontoen som er valgt. Kjøperen 110 bekrefter at han ønsker å benytte denne kontoen ved å klikke på login-knappen 540. Den private nøkkel for kontoen er nå tilgjengelig for autentisering og digital signering.

Hvis kjøperen 110 mislykkes i autentiseringstrinnet, foretar autentiseringstjenesten 130 noen handlinger. For eksempel den kan gjøre selgeren 120 oppmerksom på at kjøperen ikke ble autentisert. Alternativt kan den avvise og prosessere transaksjonen videre og returnere kjøperen 110 til et tidligere skjermbilde (for eksempel utsjekkingsskjermbilde 400).

Hvis kjøperen 110 autentiseres, gir autentiseringstjenesten 130 ytterligere kjøperprofilinformasjon til transaksjonen. I dette tilfellet henter autentiseringstjenesten 130 kjøperprofilinformasjon og sender denne informasjonen til browseren som skjema vist i figur 6. Informasjonen inkluderer de forskjellige betalingsinstrumenter 610 i denne konto og også forskjellige adresser 620. Kjøperprofilinformasjon kan være av en sensitiv natur, slik at det er ønskelig at autentiseringstjenesten 130 autentiserer kjøperen 110 før informasjon sendes til ham. Skjema reitererer også informasjon 630 om transaksjonen. Kjøperen 110 velger betalingsinstrument 610 og faktureringsadresse 620 og leverer inn skjema ved å klikke på fortsett-knappen.

Kjøperen 110 og autentiseringstjenesten 130 oppretter 380 en digitalt signert datapost av transaksjonen ved å benytte skjemaet og dialogboksen vist i figur 7A og 7B. Som respons på innleveringen av skjema 600, returnerer autentiseringstjenesten 130 skjemaet i figur 7A som inneholder en oppsummering 710 av transaksjonen og forespør kjøperen 110 til å autentisere transaksjonen. Kjøperen 110 gjør dette ved å klikke autoriser transaksjons-knappen 720. Denne anroper PTA-dialogboksen i figur 7B. Ved å klikke signer-knappen 730, forårsaker kjøperen PTA-en til digitalt å signere sammendraget, for dermed å lage en digitalt signert post av transaksjonen. Autentiseringstjenesten 130 varsler 350 selgeren 120 at kjøperen er autorisert til å benytte betalingsinstrumentet, og gir fortrinnsvis kjøperen også beskjed om at transaksjonen ble godkjent.

I denne utførelsen prosesserer også autentiseringstjenesten 130 betalingsinstrumentet for selgeren 120 via betalingsgatewayen 160, slik som PayFlow-tjenesten som er tilgjengelig fra VeriSign.

Transmisjonen av informasjonen mellom kjøperen 110, selgeren 120 og autentiseringstjenesten 130 i fremgangsmåten 300 gjennomføres ved å benytte konvensjonelle webteknikker. Legg for eksempel merke til at skjema 400 blir betjent av selgeren 120 ved å klikke på den autentiserte betalings-knapp 420 uten at kjøperens browser blir involvert fra selgeren 120 til autentiseringstjenesten 130. På samme måte, idet autentiseringsprosessen er ferdig, returneres kjøperens browser fra autentiseringstjenesten 130 til selgeren 120.

Begge disse overføringene gjennomføres ved å benytte konvensjonelle teknikker, slik som GET, POST, og/eller rediriger. For eksempel kan overføringen gjennomføres ved hjelp av en http POST i et skjema som inneholder dataene som skal transporteres. Dette er robust, men resulterer noen ganger i uønskede mellomliggende websider. Et automatisk trigget klientskript kan imidlertid benyttes for å eliminere nødvendigheten av å klikke seg gjennom mellomliggende sider. En annen mulighet er http-viderekobling til en URL som inneholder dataene som skal transporteres. Dette kan eliminere mellomliggende sider, men er for tiden begrenset i forhold til datamengden som kan transporteres (siden bare http GET kan viderekobles). En annen mulighet er http-viderekobling til en URL med henvisninger til plasseringen av dataene som skal transporteres, men at dataene i virkeligheten overføres ved hjelp av en annen mekanisme. Dette er mer kompleks enn de andre to fremgangsmåter, men kan eliminere mellomliggende sider uten å begrense datamengden som skal transporteres. Dataene transmitteres ved hjelp av en annen mekanisme enn ved destinasjon, den tildeles en identifikator og lagres. Kjøperen 110 viderekobles med en URL som inneholder den tildelte identifikator.

Som et enkelt eksempel, anta at idet den autentiserte betalings-knapp 420 klikkes, sendes en forespørsel for autentisering til autentiseringstjenesten 130. I en utførelse oppnås dette ved å benytte et skjema 400 med følgende struktur: http:// authpay. verisign. com/ authenticate. dll er URL-et for autentiseringstjenesten 130. Return URL-feltet spesifiserer en lokasjon ved selgerens 120 website til hvilken kjøperen 110 returnerer etter at autentiseringen er ferdig. Msg-feltet bærer forespørselen for autentisering. Andre felt kan benyttes for å støtte ytterligere funksjonalitet, slik som å benytte profilinformasjon eller

betalingsprosessering.

Ved ferdigstillelse av betalingsautoriseringsprosessen, overlates kjøperen 110 fra autentiseringstjenesten 130 tilbake til selgeren 120 via en http POST til return URL spesifisert i forespørselen. HTML-skjemaet som postes tilbake til selgeren 120, har den følgende struktur:

transID-feltet inneholder en transaksjonsidentifikator som kan benyttes av enten kjøperen 110 eller selgeren, 120 for å henvise til transaksjonen i transaksjonsarkivet 170. msg-feltet bærer responsen fra autentiseringstjenesten 130 til selgeren 120.

Selv om oppfinnelsen er blitt beskrevet svært detaljert med henvisning til visse foretrukne utførelser, er også andre utførelser mulig. For eksempel i en trådløs, for eksempel WAP-basert, utførelse opptrer noe eller all kommunikasjon mellom kjøper 110 og selger 120 og autentiseringstjeneste 130 via trådløse forbindelser eller via gatewayer som kobler trådløs infrastruktur til kablet infrastruktur. For eksempel kan kjøperen 110 kommunisere fra en WAP-telefon. Derfor begrenses ikke rekkevidden av de vedlagte krav av beskrivelsen av de foretrukne utførelser som er beskrevet her.

Claims (21)

1. En fremgangsmåte for å autorisere en betalingstransaksjon over et nettverk, omfattende: å lagre en offentlig nøkkel assosiert med en offentlig nøkkelinfrastruktur, PKI, nøkkelpar i en profildatabase (150), i respons for å motta en autentiseringsforespørsel (230) fra en kjøper (110) over et nettverk, autentiseringsforespørselen inkluderer en beskrivelse av betalingstransaksjonen og en identitet av en selger, å sende en utfordringsforespørsel (240) til en kjøper over nettverket, idet utfordringsforespørselen inkluderer et sammendrag av betalingstransaksjonen som skal fremvises for kjøperen og så bli digitalt signert av brukeren ved bruk av en privat nøkkel assosiert med PKI-nøkkelparet, i respons på å motta en utfordringsrespons (242) fra kjøperen over nettverket vil utfordringsresponsen inkludere det digitalt signerte sammendraget for betalingstransaksjonen, bestemme hvorvidt kjøperen har tilgang til den private nøkkelen ved bruk av offentlig nøkkel for å dekryptere det digitalt signerte sammendraget for betalingstransaksjonen, om dette bestemmes, lagre en digitalt signert datapost for betalingstransaksjonen i et transaksjonsarkiv (280), og sende en autentisert respons (250) til selgeren over nettverket.

2. Fremgangsmåte i henhold til krav 1, karakterisert ved at videre å omfatte: å skape et PKI-nøkkelpar, og sende den private nøkkelen til kjøperen over nettverket.

3. Fremgangsmåte i henhold til krav 1, karakterisert ved at dataposten for betalingstransaksjonen er digitalt signert ved bruk av den private nøkkel.

4. Fremgangsmåte i henhold til krav 1, karakterisert ved at dataposten for online-transaksjonen blir digitalt signert ved bruk av lokal privatnøkkel.

5. Fremgangsmåte i henhold til krav 1, karakterisert ved at den offentlige nøkkel blir lagret i form av et digitalt sertifikat som anskueliggjør at den offentlige nøkkelen er knyttet til kjøperen.

6. Fremgangsmåte i henhold til krav 1, karakterisert ved videre å omfatte: å innehente en kjøperprofil fra databasen, idet kjøperprofilen inkluderer et flertall av betalingsinstrumenter og et flertall av leveringsadresser, å sende kjøperprofilen til kjøperen over nettverket, og motta et utvalg av et flertall av betalingsinstrumenter og én av et flertall av leveringsadresser fra kjøperen over nettverket.

7. Fremgangsmåte i henhold til krav 1, karakterisert ved videre å omfatte: å prosessere betalingstransaksjonen via en betalingsgateway.

8. Et datamaskinlesbart medium for lagring av instruksjoner tilpasset til å bli utført av en prosessor, der instruksjonen inkluderer en fremgangsmåte for å autentisere en betalingstransaksjon over et nettverk, idet fremgangsmåten videre omfatter: lagre en offentlig nøkkel assosiert med en offentlig nøkkelinfrastruktur (PKI) nøkkelpar i en profildatabase, i respons på å motta en autentiseringsforespørsel fra en kjøper over et nettverk, idet autentiseringsforespørselen inkluderer en beskrivelse av betalingstransaksjonen og en identitet for en selger, sende en utfordringsforespørsel til kjøperen over nettverket, utfordringsforespørselen inkluderer et sammendrag av betalingstransaksjonen som fremvises for kjøperen for så å bli digitalt signert av kjøperen ved bruk av en privat nøkkel assosiert med PKI-nøkkelparet, i respons på å motta en utfordringsrespons fra kjøperen over nettverket, idet utfordringsresponsen inkluderer det digitalt signerte sammendraget for betalingstransaksjonen, bestemme hvorvidt kjøperen har tilgang til den private nøkkelen ved bruk av den offentlige nøkkelen for å dekryptere det digitalt signerte sammendraget for betalingstransaksjonen, om så er tilfellet, lagre en digitalt signert datapost for betalingstransaksjonen i et transaksjonsarkiv, og sende en autentiseringsrespons til selgeren over nettverket.

9. Et datamaskinlesbart medium i henhold til krav 8, karakterisert ved at fremgangsmåten videre omfatter: å skape et PKI-nøkkelpar, og sende den private nøkkelen til kjøperen over nettverket.

10. Et datamaskinlesbart medium i henhold til krav 8, karakterisert ved at dataposten for betalingstransaksjonen blir digitalt signert ved bruk av lokal privatnøkkel.

11. Et datamaskinlesbart medium i henhold til krav 8, karakterisert ved at dataposten for online-transaksjonen blir digitalt signert ved bruk av lokal privatnøkkel.

12. Et datamaskinlesbart medium i henhold til krav 8, karakterisert ved at den offentlige nøkkel blir lagret i form av et digitalt sertifikat som anskueliggjør at den offentlige nøkkelen er knyttet til kjøperen.

13. Et datamaskinlesbart medium i henhold til krav 8, karakterisert ved at fremgangsmåten videre omfatter: å innehente en kjøperprofil fra databasen, idet kjøperprofilen inkluderer et flertall av betalingsinstrumenter og et flertall av leveringsadresser, å sende kjøperprofilen til kjøperen over nettverket, og motta et valg av et flertall av betalingsinstrumenter og én av et flertall av leveringsadresser fra kjøperen over nettverket.

14. Et datamaskinlesbart medium i henhold til krav 8, karakterisert ved at fremgangsmåten videre omfatter: å prosessere betalingstransaksjonen via en betalingsgateway.

15. Et system for å autentifisere en betalingstransaksjon over et nettverk, omfattende: en profildatabase, et transaksjonsarkiv, og en autentiseringstjenestewebserver koplet til profildatabasen, idet transaksjonsarkivet og nettverket, autentiseringstjenestewebserveren er adaptivt konfigurert for å lagre en offentlig nøkkel assosiert med en offentlig nøkkelinfrastruktur (PKI) nøkkelpar i en profildatabase, i respons for å motta en autentiseringsforespørsel fra en kjøper over et nettverk, idet autentiseringsforespørselen inkluderer en beskrivelse av betalingstransaksjonen og en identitet for en selger, sende en utfordringsforespørsel til kjøperen over nettverket, idet utfordringsforespørselen inkluderer et sammendrag for betalingstransaksjonen for å bli fremvist for kjøperen og deretter bli digitalt signert av kjøperen ved bruk av en privatnøkkel assosiert med PKI-nøkkelparet, i respons for å motta en utfordringsrespons fra kjøperen over nettverket, idet utfordringsresponsen inkluderer det digitalt signerte sammendraget for betalingstransaksjonen, bestemme hvorvidt kjøperen har tilgang til den private nøkkelen ved bruk av den offentlige nøkkelen for å dekryptere det digitalt signerte sammendraget for betalingstransaksjonen, om så blir bestemt, å lagre en digitalt signert datapost for betalingstransaksjonen i et transaksjonsarkiv, og sende en autentiseringsrespons til selgeren over nettverket.

16. Systemet i henhold til krav 15, karakterisert ved at autentiseringstjenestewebserveren videre er tilpasset for: å skape et PKI-nøkkelpar, og sende den private nøkkelen til kjøperen over nettverket.

17. System i henhold til krav 15, karakterisert ved at dataposten for betalingstransaksjonen er digitalt signert ved bruk av den private nøkkel.

18. System i henhold til krav 15 karakterisert ved at dataposten for online-transaksjonen blir digitalt signert ved bruk av lokal privatnøkkel.

19. System i henhold til krav 15, karakterisert ved at den offentlige nøkkel blir lagret i form av et digitalt sertifikat som anskueliggjør at den offentlige nøkkelen er knyttet til kjøperen.

20. Systemet i henhold til krav 15, hvori autentiseringstjenestewebserveren videre er tilpasset for: å innehente en kjøperprofil fra databasen, idet kjøperprofilen inkluderer et flertall av betalingsinstrumenter og et flertall av leveringsadresser, å sende kjøperprofilen til kjøperen over nettverket, og motta et valg av et flertall av betalingsinstrumenter og én av et flertall av leveringsadresser fra kjøperen over nettverket.

21. Systemet i henhold til krav 15, karakterisert ved at autentiseringstjenestewebserveren videre er tilpasset for: å prosessere betalingstransaksjonen via en betalingsgateway.