[go: up one dir, main page]

NO20121157L - Konvergent kommunikasjonsplattform, samt fremgangsmate for mobil og elektronisk handel i et heterogent nettverksmiljo - Google Patents

Konvergent kommunikasjonsplattform, samt fremgangsmate for mobil og elektronisk handel i et heterogent nettverksmiljo

Info

Publication number
NO20121157L
NO20121157L NO20121157A NO20121157A NO20121157L NO 20121157 L NO20121157 L NO 20121157L NO 20121157 A NO20121157 A NO 20121157A NO 20121157 A NO20121157 A NO 20121157A NO 20121157 L NO20121157 L NO 20121157L
Authority
NO
Norway
Prior art keywords
account
customer
transaction
service
network
Prior art date
Application number
NO20121157A
Other languages
English (en)
Other versions
NO334719B1 (no
Inventor
Simon James Joyce
Prafulla C Gupta
Ashok Kumar Reddy Enuga
Manohar Sitaram Vaidya
Kalyan Chakravarthy Kasturi
Richa Gupta
Suresh Kumar Munnangi
Varma Laxmi Jagannadha Siva Kuma Jampana
Prasad Naganjaneya Vara Undavalli
Kondal Rao Nallajerla
Krishna Mohan Sistla
Amba Prasad Gudipati
Bhanu Murthy Nallagonda
Surya Sekhar Lakshmi Velpuri
Veerabhadra Rao Kalluri
Radhakrishnan Subhashree
Sundaram Mohan Kumar
Muralidhar Goparaju
Raju Waldakar
Jr Fernando Manoel Alves Santos
Original Assignee
Frnakkala Anil Kumar Reddy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=26792196&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=NO20121157(L) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority claimed from US09/894,890 external-priority patent/US9098958B2/en
Application filed by Frnakkala Anil Kumar Reddy filed Critical Frnakkala Anil Kumar Reddy
Publication of NO20121157L publication Critical patent/NO20121157L/no
Publication of NO334719B1 publication Critical patent/NO334719B1/no

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/68—Payment of value-added services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80—Rating or billing plans; Tariff determination aspects
    • H04M15/8038—Roaming or handoff
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/83—Notification aspects
    • H04M15/85—Notification aspects characterised by the type of condition triggering a notification
    • H04M15/854—Available credit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0196—Payment of value-added services, mainly when their charges are added on the telephone bill, e.g. payment of non-telecom services, e-commerce, on-line banking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/32—Involving wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/34—Roaming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/74—Rating aspects, e.g. rating parameters or tariff determination apects
    • H04M2215/7442—Roaming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H04M2215/815—Notification when a specific condition, service or event is met
    • H04M2215/8166—Available credit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13003—Constructional details of switching devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1305—Software aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13093—Personal computer, PC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13095—PIN / Access code, authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13098—Mobile subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13103—Memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13106—Microprocessor, CPU
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13109—Initializing, personal profile
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1313—Metering, billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13134—Coin boxes, payphone, prepaid
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1315—Call waiting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13152—Callback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1322—PBX
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1324—Conference call
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13274—Call rejection, call barring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13282—Call forward, follow-me, call diversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1332—Logic circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13331—Abbreviated dialling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1334—Configuration within the switch
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13349—Network management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13372—Intercepting operator
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13377—Recorded announcement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13405—Dual frequency signaling, DTMF

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Meter Arrangements (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

En fremgangsmåte og en anordning for å tilveiebringe mobil og elektronisk handel, kundebehandling og kommunikasjonstjenester via nett, som innbefatter å motta et identifikasjonsnummer i et vandringsnett og en anmodning om en tjeneste, å videresende til et hjemmenett identifikasjonsnummeret, anmodningen om tjenesten og en pris/takst for tjenesten, å verifisere ved hjelp av en konvengent kommunikasjonsplattform lokalisert i hjemmenettet, at identifikasjonsnummeret angår en gyldig brukerkonto, at en brukeranordning er autorisert til å motta tjenesten, og at den gyldige brukerkonto har tilstrekkelig verdi, å levere en autorisering til tjenesteleverandøren, og å belaste den gyldige brukerkonto på sanntidsbasis. Det konvergente kommunikasjonssystem anvender et regelsett som kan benyttes til å bestemme minst en regel som kan anvendes til autentisering av en transaksjon og debitering av en konto som tilhører den autoriserte bruker, i henhold til den minst ene regel i sann tid.

Description

BAKGRUNN FOR OPPFINNELSEN
1. Teknisk område
Foreliggende oppfinnelse vedrører et konvergent kommunikasjonssystem for å levere tjenester til individuelle kunder og bedriftskunder over hele verden. Mer spesielt angår oppfinnelsen et konvergent kommunikasjonssystem som leverer mobile handels-, elektroniske handels- og kommunikasjonstjenester gjennom eksisterende kommunika-sjonssvitsjer uten spesiell maskinvare lokalisert ved disse svitsjene. Dette systemet understøtter bruken av forhåndsbetalte og etterbetalte konti over heterogene nettverk for å tilveiebringe et bredt område med avanserte kommunikasjonstjenester uansett hvor en kunde befinner seg.
2. Beskrivelse av beslektet teknikk
Det er kjent å betale for tjenester på forskudd (forhåndsbetaling), så vel som å opprette en kredittkonto for tjenester (etterbetaling). En etterbetalt konto blir opprettet basert på kredittverdigheten til en kunde; og bedriftsenheten som oppretter den etterbetalte konto, garanterer så for den fortsatte kredittverdigheten til en kunde. Etterbetalte konti er velkjente og i utbredt bruk.
Det er for eksempel kjent å opprette en etterbetalt telefontilgangskonto. En kunde kan da gjennomføre telefonsamtaler over lange avstander eller få tilgang til telefonnettet når hun/han befinner seg i et gjestenett, til forskjell fra et hjemmenett, ved å benytte den etterbetalte konto. Telefonselskapet garanterer da for betaling til hvilke som helst andre selskaper som fremskaffer nomadetjenestene (roaming services) basert på kundens kredittverdighet. I flere år har i tillegg mobiloperatører tilbudt nomadetjenester til sine kunder. Mobiloperatører inngår vanligvis en nomadeavtale med partneroperatører i forskjellig geografiske områder, slik som andre land, og tillater deres kunder å bruke deres mobiltelefoner i disse partnerlandene eller de forskjellige nettverk. Hjemmenettet står som betalingsgarantist for de samtaler som gjennomføres av deres kunder i besøksnett. Besøksnett leverer fasiliteten med å sette opp og motta samtaler til hjemmenettets abonnenter og samler inn, behandler og videresender bruksdataene til oppringerens hjemmenett for betaling. Hjemmenettet betaler så besøksnettet.
Med et periodisk mellomrom fakturerer telefonselskaper bak hjemmenettet sin kunde og samler inn pengene fra kunden. Slike transaksjoner medfører vanligvis betydelige tidsforsinkelser, for eksempel alt mellom et par dager til et par måneder. Hjemmenettet må derfor stå som betalingsgarantist overfor besøksnettet for de samtaler som er gjennomført av dets kunder. På grunn av dette er hjemmenettene for tiden i stand til å tilby nomadetjenester bare til sine etterbetalte kunder (hvis kredittverdighet er fastslått). Med økningen i de forhåndsbetalte abonnenttjenester ønsker telekommunikasjonsoperatører over hele verden å tilby nomadetjenester også til sine forhåndsbetalende kunder. I dag, på grunn av den iboende beskaffenheten ved behandling av samtalebruk for omstreifende kunder som ikke skjer i sann tid, er opera-tørene ikke i en posisjon til å tilby virkelig forhåndsbetalt omvandring til sine kunder.
Videre er det kjent å omsette en etterbetalt kredittkonto med en bank eller en annen låneinstitusjon, og så bruke denne etterbetalte konto til å kjøpe varer og tjenester. Fra tid til annen kan en etterbetalt kredittkonto og en nomadetelefontjeneste kombineres, slik som når et kredittkortnummer blir utvekslet over en trådløs telefonforbindelse for å bestille tjenester. Disse er begrensninger i dette systemet. Kunder kan for eksempel ønske å begrense sin finansielle eksponering i en konto, eller ønsker kanskje ikke å opprette kreditt med telefonselskapet. Disse kundene kan opprette en forhåndsbetalt konto. Eksisterende forhåndsbetalte kontoarrangementer har imidlertid flere begrensninger.
En forhåndsbetalende mobil eller trådløs telefonbruker kan for eksempel ønske å benytte sin trådløse telefon i et territorium som dekkes av et annet telefonselskap. Slik uttrykket benyttes her, er dette kalt et besøks- eller nomade-territorium eller -nett. Selv om den forhåndsbetalende kunde kan ha tilstrekkelig kreditt til å fullføre telefonsamtalen ved bruk av andre konti, slik som et kredittkort, har kunden ikke opprettet "kreditt" med telefonselskapet i besøksterritoriet, eller endog sitt egentlige telefonselskap ("hjemmenettet" eller "hjemmeterritoriet"), fordi denne er en forhåndsbetalende kunde. En forhåndsbetalende kunde i et besøksterritorium ("en forhåndsbetalende nomade") har således ingen måte til å få sin forhåndsbetalte konto hos hjemmetelefonselskapet debitert under vandring, med mindre nomadenettets telefonselskap har en avtale med hjemmenettes telefonselskap, og har spesiell maskinvare ved hver svitsj for å overvåke samtalen og debitere kundens forhåndsbetalte konto. Ettersom disse avtalene vanligvis er upraktiske å få i stand, finnes det ingen effektiv forhåndsbetalt vandring (roaming).
Forhåndsbetalt telefoni har eksistert i telekommunikasjonsindustrien. En kunde eller bruker må betale en viss pengesum på forhånd til kommunikasjonstjeneste-leverandøren, og tjenesteleverandøren tillater kunden å bruke kommunikasjons tjenesten for det forhåndsbetalte beløp. Når brukerkontoens saldo når null, stenger tjenesteleverandøren fortjenesten. Kunden må da sette inn penger på sin konto ved å betale ytterligere midler til leverandøren av kommunikasjonstjenesten. Den forhåndsbetalte konto må således opprettholdes som kurant.
For å muliggjøre forhåndsbetalte kommunikasjonstjenester, må tjenesteleveran-dører regulere den aktuelle bruk av midler i kundens forhåndsbetalte konto i sann tid (dvs. mens tjenesten leveres), og tjenesteleverandøren behøver et system som kan beregne bruken av kontomidlene mens kundens samtale pågår i sann tid. Det er flere tilgjengelige systemer i markedet for tjenesteleverandørene som muliggjør en slik brukskontroll i sann tid. Kommersielt tilgjengelige teknologier gjør i dag tjeneste-leverandører i stand til å kontrollere samtalene i sann tid eller nesten sann tid ved bruk av flere forskjellige metoder.
En første metode er en forhåndsbetalt plattform som arbeider som en tjenestenode mot telefonsvitsj-nettet. Samtaler kan flyte gjennom den forhåndsbetalte plattform, eller tjenestenodens forhåndsbetalte plattform kan kontrollere samtalene på en halvintelligent nettmåte (dvs. hvor plattformen instruerer svitsjenettet om å til-kople/frakople uten at anrop i virkeligheten blir rutet gjennom systemet). En forhåndsbetalt plattform kan deretter virke som en intelligent nettnode på det IN-klargjorte telefonsvitsjenett (IN-klargjorte telefonsvitsjenett).
Det er også mulig å tilby forhåndsbetalte tjenester basert på behandling av samtaledataregistreringer ("CDR's", Cali Data Records) periodisk med meget korte intervaller. Svitsjesystemer tillater bruksinformasjon å bli videresendt til tjeneste-leverandørens faktureringssystem, for eksempel gjennom en aktiv CDR-port, hvor telefonselskapets svitsjer er konfigurert for å levere bruksinformasjonen til faktureringssystemet med korte mellomrom. Det er også mulig å tilby forhåndsbetalte tjenester basert på kredittvurderingsparametre ("AoC", Advice of Charge), som begrenser samtalebruken. Siden bruk av samtaledata-registreringer imidlertid er usatt for bedrag, har mobiloperatører over hele verden sluttet å bruke disse. AoC gir heller ikke fleksibilitet ved konfigurering av en brukshyppighet.
Tradisjonelle forhåndsbetalte systemer krever samtalekontroll-utstyr, dvs. både programvare og maskinvare, som må være samlokalisert med svitsjen. Forhånds-betalingssystemene er forbundet med delkommunikasjonssvitsjen over en signaleringsforbindelse, foreksempel SS7, MF2CR, eller ISDN-PRI, osv.). Når en opp-ringer foretar et telefonanrop, ruter svitsjen signaleringsinformasjonen over signalise- ringsforbindelsen til forhåndsbetalingssystemet. Forhåndsbetalingssystemet autoriserer så samtalen og ber svitsjen om å sette opp samtalen. Forhåndsbetalingssystemet initierer også en avgiftsberegningsprosess for samtalen. Avgiftsberegningsprosessen holder rede på bruken av den forhåndsbetalte kontoen til oppringeren, og når saldoen blir null ber systemet svitsjen om å kople ned samtalen.
Utplassering av et system av denne typen for forhåndsbetalt vandring er ineffektivt. For forhåndsbetalt vandring må alle deltakende og ofte heterogene nett ha det samme forhåndsbetalingssystem. Dette betyr at mer kontrollutstyr for forhåndsbetalte samtaler må utplasseres for hvert deltakende nett. Dette kan være et logistisk mareritt av flere grunner. For det første kan innledende utplassering av utstyr ved alle deltakende nett være tidkrevende og kostbart. For det annet blir vanlige operasjoner og vedlikehold (for eksempel oppdatering av tariffplaner, forvaltningsoperasjon, styringsinformasjon, osv.) logistisk vanskelige på daglig basis.
I tillegg krever vandringstjenester datagodkjennelse og avtaler om finansielle transaksjoner. Avtaler mellom mange parter over forskjellige nettsystemer kan være meget komplekse. Oppsetting av kundekonti og forvaltning over nett kan være komplekst, og en forsinkelse kan resultere i enorme inkonsistenser og forvirring for kundene. Kunder kan tømme sin forhåndsbetalte konto mens de er i et besøksnett. Kunden skal være i stand til å tilføre penger eller "fylle på" sin konto fra et besøksnett. Kunder som fyller på fra et besøksnett medfører flere spørsmål, innbefattende: hvordan skal påfylling av en kundekonto tillates når kunden ikke er kunde hos besøks-nettets tjenesteleverandør, hvordan skal den finansielle transaksjon administreres i forhold til betalingsadministrasjon og oppgjør for påfyllingsbeløp (for eksempel spørs-mål relatert til forhandlerkommisjoner, lettelse av påfyllingstjenesteprosessen og overføring av penger mellom hjemmenettet og besøksnettet, osv.).
Hvis kunden behøver hjelp vedrørende sin konto, for eksempel fakturerings-informasjon eller ytterligere tjenester, for eksempel spørsmålet om hvem som vil være hans/hennes kontakt for kundetjeneste. Besøksnettet kan ikke ha all informasjonen relatert til kunden, og informasjonen i hjemmenettet er ikke nødvendigvis kurant. Besøksnettet kan ønske å tilby merverditjenester, slik som tekstmeldingstjeneste (SMS), datatjenester og samtalerelaterte tjenester, for eksempel telefonkonferanse, automatisk innringningsvarsel, osv. til den vandrende kunden (hvilke merverditjenester er tilgjengelige for den samme kunde i hjemmenettet, mens hun/han ikke vandrer). Et ytterligere problem oppstår når informasjon mellom hjemmenettet og besøksnettet må synkroniseres for en forhåndsbetalende, vandrende kunde.
De fleste telefonselskaper i dag har informasjonsteknologisystemer (IT-systemer) i huset for driftsmessig og forretningsmessig forvaltning. Deres nåværende forhåndsbetalingssystemer er integrert med slike driftsmessige og forretningsmessige forvaltningssystemer i huset. Telefonselskaper vil like å ha det samme integrasjons-nivå mellom sine vandrende forhåndsbetalingssystemer og sine egne IT-systemer, slik at de kan administrere sin forretning på en effektiv måte. Utplassering av flere forhåndsbetalingssystemer for vandrende kunder kan bety flere integrasjoner. Dette kan i seg selv være tidkrevende og kostbart.
For en etterbetalingskunde er telefonselskapene villige til å ta kundebetalingen eller den finansielle risiko, ettersom hjemmenettet allerede har evaluert kredittverdigheten til kunden og hjemmenettet er villig til å underskrive på denne betalingsrisikoen. I tilfelle av en forhåndsbetalingskunde kan imidlertid hjemmenettet ikke en-gang vite hvem kunden er, for eksempel kan det være en anonym kunde. Dette betyr at både besøksnettet og hjemmenettet må ha konstante avtaler for alle typer transaksjoner (for eksempel kommunikasjonstjenester som handelstransaksjoner).
Telefonselskaper tilbyr også kundebehandling til sine kunder. Telefonselskapene tilbyr imidlertid kundebehandling til sine abonnenter bare når abonnentene er i hjemmenettet. Hvis abonnenten er på vandring, kan han/hun ringe til hjemmenettets kundebehandlingssenter og bruke denne fasiliteten. Tilbud om kundebehandling utenfor hjemmenettets tjenesteområde er imidlertid vanskelig på grunn av det faktum at kundeinformasjon ikke er tilgjengelig i besøksnettet. Visse telefonselskapsoperatører er i stand til å levere begrenset kundebehandling i besøks-nettene. Så langt kan slike systemer imidlertid bare ta seg av etterbetalingskunder.
Selv om økningen i forhåndsbetalingskunde-grunnlaget og med voksende mobile handelsmuligheter, blir kundebehandling meget viktig for forhåndsbetalings-kundene. Bredt sagt har kunder flere behov fra et kundebehandlingsperspektiv: informasjon vedrørende tjenestetilgjengelighet i besøksnettet eller territoriumposisjon (kan kunden for eksempel sende en faks ved å benytte sin mobiltelefon), informasjon ved-rørende det lokale territorium (for eksempel hvem er nærmeste doktor), informasjon vedrørende hvordan besøksnett-tjenesten skal brukes (for eksempel hvordan kunden foretar et anrop til destinasjon XYZ, hvordan kunden sender en faks ved å benytte sin mobiltelefon som er utstyrt med en besøksnett-selger), kontoinformasjonstjenester (for eksempel hva er den aktuelle saldo på kundens forhåndsbetalte konto; hva er de fem siste transaksjonene kunden har utført, og hvor meget kostet transaksjonene), modifi-kasjonstjenester med hensyn til konto/tjeneste-profilinformasjon (kunden kan for eksempel ønske å endre sin adresse; kunden kan ønske å abonnere på en ny tjeneste slik at han/hun kan sende en faks), uenigheter/klager (for eksempel har kunden for-søkt ti ganger og samtalen ble avbrutt hver gang og dermed ønsker kunden ikke å betale for samtalen; kunden utførte aldri en samtale til destinasjon XYZ), påfylling av kundens forhåndsbetalte konto fra forskjellige kilder (for eksempel har kunden ikke mer igjen på sin konto og må fylle på ved å benytte et påfyllingskort, sin bankkonto, kontanter eller andre midler).
Telefonselskap-forretningen er kompleks. Enhver tjenestelevering fra et telefonselskap krever forskjellige systemer som skal virke i tandem for å svare til kundens forventninger, for eksempel å gjøre en tjeneste tilgjengelig, så vel som å levere fullstendig og nøyaktig informasjon på rett plass til rett tid, slik at kunden blir effektivt be-tjent. Telefonselskapssystemer må også sikre at interne operasjoner i telefonselskapet blir optimalisert. Det betyr at fullstendig og nøyaktig informasjon må gjøres tilgjengelig til rett tid og på rett sted for den interne staben i telefonselskapet som skal bruke den for effektiv forretningsadministrasjon. Telefonselskapets systemer må også sikre at de sameksisterer eller er kompatible med andre tredje parts telefonselskaper og tjeneste-leverandører, slik at de kan kollektivt tilby tjenester til kundene og administrere sin forretning, dele fortjeneste, osv. For å tilfredsstille slike store og komplekse behov for telefonselskaper/ tjenesteleverandører, finnes det ikke noe enkelt system som kan tilby hele funksjonaliteten. Leverandører, integratorer og telefonselskaper arbeider vanligvis sammen for å kundetilpasse og integrere flere forskjellige systemer for å oppfylle et spesielt telefonselskaps behov.
Ettersom den forhåndsbetalte kommunikasjonstjenesteforretning til å begynne med ble forventet å være en separat tjeneste, har telefonselskapene vanligvis benyttet et eneste selskapsspesifikt system som kan styre samtalene i sann tid (eller nesten sann tid) med forskjellige definisjoner av uttrykket "sann tid"). Ettersom den forhåndsbetalte kommunikasjonsforretning har begynt å vokse hurtig over hele verden, føler tjenesteleverandører et behov for å integrere sine forhåndsbetalingssystemer med andre systemer for effektivt å betjene sine kunder og administrere forretningene.
Forhåndsbetalt vandring (roaming) medfører imidlertid flere utfordringer til tele-fonselskapsindustrien. Alle de deltakende nett må ha en felles forståelse av hvordan samtalestrømmen skal administreres, hvordan tjenester skal tilbys og hvordan forretningene skal administreres. Med flere systemer integrert på mange måter over forskjellige nett, er det imidlertid ganske få utfordringer til forhåndsbetalt vandring. En grunnleggende oppgave er hvordan en "sømløs" tjeneste kan oppnås til kunden og effektiv forretningsadministrasjon over flere deltakende nett, ofte heterogene eller forskjellige typer nett. En tjenesteleverandør-operatør kan for eksempel ha et utmerket kundebehandlingssenter, mens en annen operatør kanskje ikke har et slikt kundebehandlingssenter med høy kvalitet, eller en operatør kan ha høy kvalitet på et kort-genererings-/forvaltningssystem, mens den andre operatøren forvalter mesteparten av disse prosessene manuelt. Enkel eller kompleks integrasjon av flere forskjellige systemer til sammen gir ikke en forretningsløsning på grunn av varierte permitteringer og kombinasjoner for telefonselskapene. Det er også upraktisk å vente at ett eller flere av telefonselskapene skal kvitte seg med sine eksisterende systemer og benytte et fullstendig nytt system uansett hvor kvalitativt godt det nye systemet er.
Kjente forhåndsbetalingssystemer er enkle pakkeløsninger som tillater begrenset integrasjon med eksterne systemer. Selv i en situasjon hvor det er rimelig å integrere, er det ikke mulig for andre systemer å komme inn i forhåndsbetalingssystemet på forskjellige nivåer. Det vil si at integrasjon for å erstatte en del av funksjonaliteten til forhåndsbetalingssystemet ikke er mulig. Integrasjon for å tilføye ytterligere funksjonalitet er det som må oppnås. Dette er en hovedbegrensning for telefonselskapene for effektivt å forvalte sine forretninger. Hvis et telefonselskap allerede har et personlig identifikasjonsnummer-genereringssystem (PIN-genereringssystem), må det, hvis det skulle ønske å utplassere et forhåndsbetalingssystem for vandring, bruke PIN-genereringskapasiteten til det nye forhåndsbetalingssystemet for vandring i stedet for det gamle systemet. Det betyr at telefonselskapet nå må ha to separate PIN-generingssystemer, et for ikke-vandrende abonnenter og et annet for vandrende abonnenter. Dette forårsaker mye forvirring i markedet, og ren integrasjon med en tredje parts system vil ikke løse problemet. Det finnes andre slike problemer, for eksempel distribuert forvaltning, kundeadministrasjon, osv.
Når mobiloperatører åpner for mobil handel for en forhåndsbetalingsvandrer i et konvergent kommunikasjons- og handelsmiljø, er det i tillegg til det foregående behov for finansielle oppgjør mellom forskjellige parter som er involvert i handelstransaksjonen som foretas av den vandrende forhåndsbetalingskunde. Oppgjør for handelstransaksjoner kan i tillegg innebære følgende parametre som er relatert til handels transaksjoner som må distribueres over ett eller flere av følgende entiteter: selger, leverandør av varer/tjenester, enten fabrikant, grossist eller distributør, eller en kombinasjon av flere slike entiteter), portaler, mobilportal eller en hvilken som helst annen type portal, innbefattende en stemmeportal ("Vorta!", voice portal), e-handelsportal, osv.), internett-tjenesteleverandør (en uavhengig agent eller selve mobiloperatøren eller portalen selv), mobiltelefonselskap (hjemmenett, besøksnett eller begge), virtuell tjenesteleverandør (enten innholdstjenesteleverandør eller infrastruktur-tjeneste-leverandør, eller et varemerkeagentur eller en hvilken som helst kombinasjon), bank/kredittkortagentur eller en hvilken som helst annen finansiell institusjon (en eller flere som er involvert i transaksjonen), tredje parts betalingsagentur (for eksempel en handelssammenslutning, en betalingsbehandlingsbedrift, en elektronisk lommebok eller en hvilken som helst av slike betalingsbehandlingsbedrifter), vare/tjeneste-leveringsbedrifter (for eksempel et reiseselskap, en båndbredde-leverandør, og et forsikringsselskap). Det er også mulig at mobiltjenesteleverandører kan tilby pakker (for eksempel hvis kunden kjøper varer for 500 kroner under vandring, blir en ekstra avgift for vandring ettergitt, osv.). Dette betyr at et hvilket som helst oppgjørssystem bør være i stand til å komme til de forskjellige oppgjørsbeløp basert på tariffplanene og vandringsavtalene mellom de forskjellige parter som inngår i handelstransaksjonen.
Det er ventet at mobile håndteringsanordninger (telefoner, PDA'er, osv.) vil bli brukt til alle typer betalinger, spesielt små betalinger. En kunde vil for eksempel bruke sin mobiltelefon til å betale for artikler med liten verdi, slik som alkoholfrie drikker ved salgsautomater, sigaretter, aviser, bøker, parkeringsbilletter og andre slike betalinger av lav verdi, som vanligvis er kjent på området som mikrobetalinger.
Eksisterende teknologier gjør det i dag mulig å foreta slike betalinger på en eller flere av følgende måter: en kunde kan bruke sin mobiltelefon og ved betalingstids-punktet kan han/hun bruke sitt kredittkort eller bankkort til betaling. Dette betyr at betaling vil gå gjennom bank/kredittkontoen til kunden istedenfor kundens telefonkonto. Denne fremgangsmåten har begrensninger ved at den forutsetter at alle kunder har enten et bankbetalingskort eller et kredittkort. Den nåværende vekst i den forhåndsbetalte mobiltelefoni over hele verden, indikerer at det er et stort segment av markedet som enten ikke har noe bank/kreditt-forhold eller ganske enkelt ikke ønsker å bruke sin bank/kreditt-forbindelse til telefoni. Dette er spesielt tilfelle i visse utviklingsland med dårlige bankarrangementer. Debet/kreditt-kortforutsetningen begrenser også det totale antall kunder som kan gjennomføre mobil handel, og derfor kan telefonselskapet bare spille en meget begrenset rolle i den mobile handel. Fortjenesten til telefonselskaper er vanligvis begrenset til telefonforbindelsene og tjenestene som de har levert. En kunde kan imidlertid bruke sin mobiltelefonkonto til betaling av en kommersiell transaksjon. Det vil si at kostnaden på varer/tjenester vil bli debitert kundens telefonkonto. Ved slutten av måneden vil kunden få en telefonregning som innbefatter kostnadene på varene/tjenestene som er kjøpt. Denne metoden har begrensninger ved at den forutsetter at kunden er en kunde med etterbetalingskonto. Det betyr at systemet ikke rommer en forhåndsbetalingskunde og som derfor ikke kan gjennomføre en mobil handelstransaksjon. I stedet forutsetter systemet at betalingsrisikoen blir båret av telefonselskapet eller av selgeren. Ved slutten av faktureringsperioden, hvis kunden ikke betaler sin regning, må telefonselskapet/selgeren ta den finansielle risiko.
Kunder kan ha en e-lommebokkonto som er en konto med et personlig identifikasjonsnummer. Hver gang kunden kjøper varer, kan hun eller han taste inn PIN-koden og e-lommebokselskapet (f.eks. IPIN) kan utstede en betalingsgaranti. I denne metoden virker den elektroniske lommeboken som en forhåndsbetalt konto, og bare hvis saldoen er tilgjengelig på kontoen, vil en kjøpstransaksjon bli autorisert. Denne metoden har begrensninger, fordi hver gang et kjøp blir etterspurt, må en bruker identifisere seg (for eksempel ved å bruke et PIN som typisk er 12 sifre eller mer). Denne identifikasjonsprosessen selv kan virke som et hinder, og kunder er kanskje ikke interessert i å gå gjennom prosessen for småkjøp. Telefonselskapet vil igjen bare spille en meget begrenset rolle i mobilhandelen, ettersom dens fortjenester eller gebyrer er begrenset til telefonforbindelsen som det har levert.
For å forenkle den mobile handelskjøpsprosess søker industrien etter nye teknologier, slik som Bluetooth (Blåtann), som muliggjør direkte kommunikasjon mellom salgsautomater og en kundes mobiltelefon. Disse teknologiene har imidlertid også begrensninger ved at selgere så vel som kundene må være utstyrt med instru-menter som er i stand til å håndtere disse teknologiene. Dette betyr høyere etableringskostnader. Økonomien ved kostnadene er kanskje ikke i stand til å rett-ferdiggjøre investeringen, i det minste i de første årene, og disse teknologiene tar ikke hensyn til oppgaver vedrørende betalingsrisiko. Disse systemene forutsetter at alle kundene er pålitelige og vil gjøre opp for seg. I virkelighetens verden er dette ikke tilfelle. I tillegg tar disse teknologiene ikke hensyn til oppgavene vedrørende forhåndsbetalingskunder. Forhåndsbetalingskunder kan være anonyme, noe som betyr at verken telefonselskapet eller selgeren vet hvem kjøperen er.
I dagens elektroniske handelsverden, er lese/skrive-lagringsanordninger blitt mer populære. Lese/skrive-lagringsanordninger har evne til å lagre en kontos saldo og annen informasjon vedrørende kunden. Lese/skrive-lagringsanordninger behøver ingen nettforbindelse tilbake til endesystemene. Lesere for lese/skrive-lageranord-ninger kan være utplassert hos selgeren og en kunde som kommer inn kan benytte sitt kort til å betale med. Denne mekanismen har vist seg å være nyttig ettersom den er enkel å bruke både for selgeren og kunden og muliggjør forhåndsbetaling.
Hver gang en tjeneste blir brukt, blir betalingen som er relatert til vedkommende tjeneste, tatt ut fra kundens forhåndsbetalte konto. Det er klart at penger på en forhåndsbetalt konto vil nå en nullsaldo på et eller annet tidspunkt. Det er derfor et behov for kunden å fylle opp sin forhåndsbetalte konto. Det er flere kommersielt tilgjengelige systemer i markedet som tilbyr forhåndsbetalingsfasiliteter, og de fleste av dem tilbyr kontopåfylling. Nåværende tilgjengelige systemer gjør det mulig å fylle på kontoen ved å utstede et påfyllingskort (kortet eller kupongen har et entydig nummer, kjent som PIN, med en viss forutbestemt verdi, for eksempel 200 kroner), som kan brukes av kunden. Kunden ringer til et interaktivt talesvarsystem (IVR-system, Interactive Voice Response System) hos tjenesteleverandøren, og ved hjelp av en ledet meny vil kunden bli i stand til å fylle på sin forhåndsbetalte konto ved å taste inn det unike PIN-nummer.
Et slikt påfyllingssystem har begrensninger ved at tjenesteleverandører må trykke påfyllingskuponger eller påfyllingskort og så distribuere kortene. Dette er et stort logistikk- og kostnadsproblem. Det er også en potensiell svindelrisiko med flere mulige svindeltyper, for eksempel lekkasje av PIN-nummeret til uautoriserte brukere, uautoriserte brukere som vilkårlig forsøker flere numre og treffer det riktige nummer, og uautoriserte parter som trykker falske påfyllingskort, i likhet med falske pengesedler. Tjenesteleverandører kan dessuten ofte bare tilby forutbestemte pengebeløp per kort. Selv om de kan tilby flere typer kort eller kuponger, vil hvert kort ha et forhåndsbestemt beløp. Dette betyr at en kunde ikke kan velge det nøyaktige påfyllingsbeløp som han/hun helst vil betale inn på kontoen. Det er videre tjenesteleverandørenes manglende evne til å tilby en kredittmulighet til forhåndsbetalingskunder. Økende bruk av forhåndsbetalte konti i de høyt utviklede og kredittdrevne land, indikerer at kunder i økende grad benytter forhåndsbetalte konti på grunn av deres enkle og lette bruk, istedenfor eventuelle kredittrelaterte løsninger. Slike kunder liker ikke å forhåndsbetale for tjenester som de enda ikke har brukt. Med en kredittgrense (med forsikring om garantert betaling fra tredje parter, slik som banker osv.), vil en slik fremgangsmåte øke det antall kunder som velger forhåndsbetalte konti.
I situasjoner hvor en forhåndsbetalt konto er programmert på et kort som kan brukes av en kunde (for eksempel: et SIM-kort, et smart-kort, et kort med magnetstripe eller en hvilken som helst annen type kort), kan kunden ta med dette kortet til nærmeste sted hvor det er spesielle programmeringsmaskiner tilgjengelig for påfylling av kortet. Disse forhåndsbetalingstypene er tidligere blitt brukt. Ettersom mobil handel blir stadig mer populær, forventes det imidlertid at kundene vil like å benytte slike løsninger til mikrobetalinger. Programmering av den forhåndsbetalte konto på kortene er hensiktsmessig for kunden, ettersom denne ikke må taste inn en lang (ofte 12 sifre eller mer) kode for en transaksjon med meget liten verdi. Et slikt arrangement for påfylling av konti har imidlertid begrensninger ved at kundene bare kan gå til et begrenset antall påfyllingssteder hver gang de har behov for en påfylling. Slike kort kan ikke påfylles andre steder. Tjenesteleverandører liker heller ikke å oppdatere eller fylle på meget store summer på disse kortene, på grunn av spørsmål vedrørende svindel (for eksempel uautoriserte parter med tilgang til utstyr som kan skrive store pengebeløp inn på kortene) og tjenesteleverandørenes manglende evne til å tilby en kredittmulighet til forhåndsbetalingskunder.
Ved vanlige handelstransaksjoner (for eksempel ved bruk av kredittkort/debetkort i en vanlig butikk eller forretning), blir valideringen av transaksjonen vanligvis utført ved kopiering av kortet og fysisk signaturverifisering. Som en beskyttelse mot svindel spør noen ganger kredittkort/debetkort-selskaper selger-etablissementet/kunden om å ringe banken. Banken vil så benytte ytterligere sikkerhetsforanstaltninger slik som å spørre om en mors pikenavn, fødselsdato, osv., for å forsikre seg om at kunden ikke er en uautorisert person. I internett- og mobile internett-situasjoner i dag finnes disse ytterligere sikkerhetsforanstaltningene ikke og risiko for svindel finnes, som nevnt ovenfor, med forskjellige av de tilgjengelige, uforanderlige forhåndsbetalte kontosystemer. På grunn av begrenset sikkerhet blir svindel i forbindelse med internett-mobile internett-relaterte transaksjoner anslått å være meget høy.
Det er kjent å debitere en kundes forhåndsbetalte konto når telefonavgiftene forfaller. Regningene kan komme fra mange kilder, avhengig av kontoen. Det er for eksempel kjent å opprette en forhåndsbetalt telefontilgangskonto. En kunde kan da gjennomføre telefonsamtaler over lange avstander eller aksessere telefonnettet.
Videre er det kjent å opprette en etterbetalt kredittkonto hos en bank eller en annen låneinstitusjon, og så bruke den etterbetalte konto til å kjøpe varer og tjenester. Innimellom kan en etterbetalt kredittkonto og vandringstelefontjenester kombineres, slik som når et kredittkortnummer blir utvekslet over en trådløs telefonforbindelse for å bestille tjenester. Det er begrensninger ved dette systemet. Kunder kan for eksempel ønske å begrense sin finansielle eksponering på en konto, eller ønsker ikke av andre grunner å opprette kreditt hos telefonselskapet. Disse kundene kan opprette en forhåndsbetalt konto. Eksisterende forhåndsbetalte kontoarrangementer har imidlertid minst flere begrensninger.
En mobil eller trådløs forhåndsbetalingsbruker kan for eksempel ønske å benytte sin trådløse telefon i et territorium som dekkes av et annet telefonselskap. Dette blir i det følgende kalt et besøks- eller vandringsterritorium eller -nett. Selv om for-håndsbetalingskunden kan ha tilstrekkelig kreditt til å fullføre telefonsamtalen ved å benytte andre konti, slik som et kredittkort, har kunden ikke opprettet "kreditt" hos telefonselskapet i vandringsterritoriet eller endog hos sitt opprinnelige telefonselskap (hjemmenettet eller hjemmeterritoriet) på grunn av at vedkommende er en forhåndsbetalingskunde. En forhåndsbetalingskunde i et vandringsterritorium (en forhåndsbetalingsvandrer) har således ingen mulighet til å få sin forhåndsbetalte konto hos hjemmetelefonselskapet debitert under vandring, med mindre vandringsnettets telefonselskap har en avtale med hjemmenettets telefonselskap, og har spesifikk maskinvare ved hver svitsj for å overvåke samtalen og debitere kundens forhåndsbetalte konto. Ettersom disse avtalene vanligvis er upraktiske å få i stand, finnes det ingen effektiv, forhåndsbetalt vandring.
Forhåndsbetalt telefoni har eksistert på telekommunikasjonsområdet. En kunde eller bruker må betale et visst pengebeløp på forhånd til kommunikasjonstjeneste-leverandøren, og tjenesteleverandøren lar kunden få lov til å bruke kommunikasjonstjenesten for det forhåndsbetalte beløp. Straks brukerkontoens saldo når null, kopler tjenesteleverandøren ut tjenesten. Kunden må da fylle på sin konto ved å betale ytterligere midler til leverandøren av kommunikasjonstjenesten. Den forhåndsbetalte konto må derfor opprettholdes som kurant. Enhver transaksjon som ikke har tilstrekkelige midler, blir håndtert som en begrenset transaksjon.
Når en begrenset transaksjon inntreffer, finnes det to muligheter for håndtering av transaksjonen. Transaksjonen kan avslås. Transaksjonen kan godkjennes og underkastes senere verifisering. Når en transaksjon blir godkjent i påvente av senere verifisering, aksepterer kontoleverandøren risikoen for en svikaktig transaksjon. Hvis en stor debet inntreffer på en kredittkonto, og leverandøren av kredittkontoen god-kjenner transaksjonen etter en ytterligere telefonsamtale til kontoinnehaveren, blir vanligvis kredittkontoleverandøren, når transaksjonen blir funnet å være svikaktig, holdt ansvarlig.
Forskjellige kredittkontoleverandører vil forsøke å utporsjonere disse tapene basert på sin posisjon i et marked. En kredittleverandør kan for eksempel tvinge selgere som aksepterer deres kredittkort, til å akseptere en del av tapene ved en svikaktig transaksjon. Alternativt kan tapene reduseres ved bruk av forsikring.
På lignende måte er det kjent en kreditt-transaksjon til en konto. Nå og da blir det brukt forhåndsautoriserte kreditter, noen ganger kalt overtrekksbeskyttelse. Igjen blir et enkelt sett med restriksjoner fastsatt for kontoen. Så lenge det er midler på en sparekonto, vil for eksempel et gebyr som vil redusere en sjekk-kontosaldo til under null, bli godkjent, med en etterfølgende overføring av midler fra en konto til en annen.
Det er også kjent å ha forskjellige rabatter for tjenester i forbindelse med en spesiell konto. Kolonialvarer kan for eksempel kjøpes med rabatt hvis en kunde er del av en spareklubb. Selv om midler ikke blir holdt på en konto, er transaksjonshistorien dermed verdifull nok til å betinge rabatter ved å inneha et visst medlemskap. Rabatter kan i tillegg være betinget av visse kontovolumer eller en kontohistorie. I tillegg kan reklame og rabatter tilbys spesielt til forskjellige kunder. Det er kjent å betale for tjenester på forskudd (forhåndsbetaling), så vel som å opprette en kredittkonto for tjenester (etterbetaling). En etterbetalt konto blir opprettet basert på kredittverdigheten til en kunde, og selskapet som oppretter den etterbetalte konto garanterer så for fort-satt kredittverdighet for en kunde. Etterbetalte konti er velkjente og i utstrakt bruk.
For å muliggjøre forhåndsbetalte kommunikasjonstjenester må tjenesteleveran-dører regulere den virkelige bruk av midler på kundens forhåndsbetalte konti i sann tid (dvs. mens tjenesten blir levert), og tjenesteleverandører trenger et system som kan beregne, i sann tid, bruken av kontomidlene mens kundens samtale finner sted. Det er flere tilgjengelige systemer i markedet for tjenesteleverandørene som simulerer en slik brukskontroll i sann tid.
I tillegg krever vandringstjenester eller nomadetjenester (roaming services) klarering av data og avtale om finansielle transaksjoner. Dataklarering og avtaler mellom flere parter over forskjellige nettsystemer kan være meget komplisert. Oppsetting av kundekonti og forvaltning over nett kan være meget kompleks, og enhver forsinkelse kan resultere i enorme inkonsistenser og forvirring blant kunder. Kunder kan tømme sin forhåndsbetalte konto mens de er i et besøksnett. Kunden bør være i stand til å betale inn penger eller "påfylle" sin konto fra et besøksnett. Kunder som fyller på fra et besøksnett, medfører flere problemer, innbefattende: hvordan skal en kunde tillates å fylle på en konto når kunden ikke er en kunde hos besøksnettets tjenesteleverandør, hvordan skal den finansielle transaksjon vedrørende betalings-forvaltning og avtale om påfyllingsbeløp (for eksempel spørsmål vedrørende forhandlingskommisjoner, prosessen med påfyllingstjenester og overføring av penger mellom hjemmenettet og besøksnettet, osv.), administreres.
Forskjellige utførelseseksempler av oppfinnelsen kan gjøre det mulig for mobile betjeningsanordninger (telefoner, PDA'er, osv.) å bli brukt til alle typer betalinger, spesielt mikrobetalinger. En kunde vil vanligvis benytte sin mobiltelefon til å betale for artikler med liten verdi, slik som alkoholfrie drikker i salgsautomater, sigaretter, aviser, bøker, parkeringsavgifter og andre slike betalinger av lav verdi som vanligvis er kjent som mikrobetalinger på dette området.
Tjenesteleverandørenes manglende evne til å tilby en kredittmulighet for forhåndsbetalingskunder, kan forårsake begrensning av bruken av forhåndsbetalte konti. Økende bruk av forhåndsbetalte konti i de meget utviklede og kredittdrevne land, indikerer at kunder i økende grad benytter forhåndsbetalte konti på grunn av hensiktsmessig og enkel bruk, i stedet for andre kredittrelaterte muligheter. Disse kontiene er kjent som sanntidsautoriserte konti for kredittverdige kunder. Slike kunder liker ikke å betale på forskudd for tjenester som de ennå ikke har brukt. Med en kredittgrense (med forsikring om garantert betaling av tredje parter slik som banker osv.), vil en slik fremgangsmåte øke det antall kunder som velger forhåndsbetalte konti og sanntidsautoriserte konti.
I situasjoner hvor et forhåndsbetalt beløp er programmert på et kort som kan brukes av en kunde (for eksempel en SIM-kort, et smart-kort, et kort med magnetstripe eller et kort av en hvilken som helst type), kan kunden ta sitt kort til det nærmeste sted hvor det er spesielle programmeringsmaskiner tilgjengelige for påfylling av kortet. Disse forhåndsbetalingstypene er blitt brukt tidligere. Ettersom mobil handel blir mer og mer populær, ventes det imidlertid at kunder vil like å benytte slike løsninger til mikrobetalinger. Programmering av den forhåndsbetalte konto på kortene er hensikts-messige for kunden, ettersom han eller hun ikke må taste inn en lang kode (ofte 12 sifre eller mer) for en transaksjon med meget lav verdi.
Et slikt arrangement for kontopåfylling har imidlertid begrensninger ved at kunder kan gå til bare et begrenset sett med påfyllingssteder hver gang de må fylle på. Slike kort kan ikke påfylles på andre steder. Tjenesteleverandører liker heller ikke å oppdatere eller fylle på meget store summer på disse kortene på grunn av spørsmål vedrørende svindel (for eksempel uautoriserte parter med tilgang til utstyr som kan skrive store pengebeløp på kortene) og tjenesteleverandørenes manglende evne til å tilby en kredittfasilitet til forhåndsbetalingskunder. Et slikt påfyllingssystem blir videre i økende grad logistisk umulig jo lenger brukeren er fra sin "hjemmebase". Det er for eksempel usannsynlig at en tjenesteleverandør i London vil tilby påfyllingssentre i Paris, og enda mindre sannsynlig i Hong Kong, selv om leverandørens kunder kanskje hyppig reiser til disse stedene. Fordi tjenesteleverandøren i tilfeller hvor denne er avhengig av en annen parts eiendom, slik som en foretningseiendom eller en distribu-sjonsinfrastruktur, vil han sannsynligvis tape en betydelig andel av sin potensielle fortjeneste som kommisjon til bruken av slike eiendommer.
EP 1 107 198 A (CITIBANK NA) beskriver fremgangsmåter og systemer for utføring av elektroniske transaksjoner.
OPPSUMMERING AV OPPFINNELSEN
Hovedtrekkene ved oppfinnelsen er angitt i de selvstendige patentkrav. Ytterligere trekk ved oppfinnelsen fremgår av de uselvstendige krav.
Et utførelseseksempel av oppfinnelsen som er beskrevet i US-stamsøknad nr. 09/395.868, angår forhåndsbetalte samtaler og andre kommunikasjonstjenester ved bruk av en enkel telefonsvitsj. Den enkle telefonsvitsjen har et innsatt datamaskin/telefon-grensesnittkort (CTI) som ruter avanserte funksjoner til en annen, sikker kanal. Den andre, sikre kanal blir koplet via telefonnettet, internettet eller et hvilket som helst annet internett-protokollnett til kommunikasjonsplattformen. Kommunikasjonsplattformen blir så i stand til å sende autorisasjon for samtale, oppkoplingsinstruk-sjonene og andre kommandoer til den enkle telefonsvitsjen, slik at kunden har tilgang til avanserte funksjoner.
Bruken av den annen, sikre kanal til autorisering av betaling og håndtering av samtalestyring, muliggjør flere utførelseseksempler som beskrevet i detalj her, med modifikasjon av kommunikasjonssystemet for å øke utallige forbedringer i forbindelse med forhåndsbetalte vandringstjenester. I tillegg til den ovenfor beskrevne forhåndsbetalte vandring, tilveiebringer oppfinnelsen her for eksempel en forbedret, konvergent kommunikasjonsanordning for mobil handel, elektronisk handel, kontopåfylling, opp-gjørstransaksjoner mellom mange arter, integrert kundebetjening eller en hvilken som helst annen kommersiell transaksjon.
Et første utførelseseksempel på oppfinnelsen er således et konvergent kommunikasjonssystem som befinner seg på et sentralisert sted, som er tilgjengelig fra et hvilket som helst sted via internettet, et offentlig telefonnett, en SS7-signalerings-linje, et telefonnummer eller et hvilket som helst annet middel som er kjent nå eller som kan tenkes i fremtiden. En forhåndsbetalt vandringssamtale kan så håndteres ved en lokal telefonsvitsj ved å signalere fra den lokale telefonsvitsj til den sentraliserte, konvergente kommunikasjonsplattform, at kunden forsøker å aksessere sin konto.
Den konvergente kommunikasjonsplattform kan så autorisere telefonsamtalen etter fullføring av flere trinn. Det første trinn er å kontrollere at kunden virkelig er en autorisert kunde. Det annet trinn er å kontrollere at kunden har autorisert bruken av denne spesielle tjeneste. Det tredje trinn er å kontrollere kundens kontobalanse i det sentraliserte, konvergente kommunikasjonssystem. Hvis forespørselen kommer fra en kunde som har autorisert tjenesten og har tilstrekkelig saldo på kontoen, kan den sentraliserte, konvergente kommunikasjonsplattform utstede et autoriseringsnummer til den lokale telefonsvitsj.
Når kunden fullfører telefonsamtalen, kan den lokale telefonsvitsjen sende en melding om fullført tjeneste sammen med en medgått tid for samtalen til den sentraliserte, konvergente kommunikasjonsplattform. Hvis kunden går tom for penger på kontoen under telefonsamtalen, kan den sentraliserte, konvergente kommunikasjonsplattform sende en melding via den annen linje til svitsjen for å få telefonsamtalen avsluttet. I alle fall kan den vandrende forhåndsbetalingskunde aksessere sin konto.
På telekommunikasjonsområdet finnes det forskjellige nettverksteknologier på forskjellige geografiske steder. Det er kundens ønske å kunne reise fra et sted til et annet, for eksempel fra Europa til USA, og likevel være tilkoplet ved hjelp av telefonen i vandringsterritoriet med det samme telefonnummer. I dag er vandring mulig mellom to nett av samme type (for eksempel vandring fra et GSM-nett til et annet GSM-nett; eller fra et AMPS-nett til et annet AMPS-nett, osv.). På grunn av forskjellene i teknolo-gien er det imidlertid ikke mulig for kunder å vandre mellom en nettype til en annen nettype (for eksempel en kunde med en GSM-telefon kan ikke vandre i et CDMA-nett; en kunde med en AMPS-telefon kan ikke vandre i et GSM-nett). Den manglende vandringsmuligheten skyldes at hver teknologi opererer ved forskjellige frekvenser. Mobiltelefonene er derfor ikke kompatible, håndtering av anropsstrøm i hvert av tele-fonselskapenes nett-teknologier er forskjellige, og abonnentidentifiseringsprosesser i hver nettverkstype er forskjellige. I et GSM-nett blir for eksempel en abonnent eller kunde identifisert på grunnlag av IMSI, SIM-serienummer og MSISDN; i et CDMA-nett blir en abonnent eller kunde identifisert basert på MIN og ESN; og i et AMPS-nett blir en abonnent eller kunde identifisert basert på ESN.
Dette problemet med vandring over heterogene nett kan løses med en av de to følgende løsninger: kunder kan kjøpe en flerbånds-mobiltelefon som gjør det mulig for søkesignalet fra håndsettet å bli gjenkjent av flere typer nett (for eksempel tillater en telefon med tre bånd abonnenten å bruke den samme telefon i Europa og i USA), eller vandrende kunder kan gå til vandringstjenesteleverandøren og midlertidig leie en telefon som svarer til den forskjellige standarden i vandringsnettet. Telefonselskaper kan også sikre at kunden kan nås på det samme telefonnummer ved hjelp av videre-kopling.
Disse vandringsløsningene er imidlertid bare egnet for etterbetalingskunder. De virker ikke for forhåndsbetalingskunder når det gjelder å opprette forhåndsbetalt vandring, fordi alle de deltakende nett vil måtte virke i tandem for å autentisere, avgiftsbelegge og debitere den forhåndsbetalte konto i kundens hjemmenett. Det finnes ingen tilgjengelige, kommersielle teknologier på markedet i dag som kan under-støtte forhåndsbetalt vandring over heterogene nett.
Med veksten av forhåndsbetalingskunder vil telefonselskaper over hele verden like å kunne tilby forhåndsbetalt vandring over heterogene nett. Det er derfor et behov for en løsning som kan: ta hensyn til de forskjellige kravene i heterogene nettverkstyper, fremskaffe den relevante samtalereguleringsinformasjon og abonnentinformasjon fra det anropende eller vandrende nett, skape og sende den relevante samtale-styringsinformasjon og abonnentinformasjon til hjemmenettet til abonnenten, fremskaffe ikke bare abonnentautentiseringen uttrykt ved abonnentens validitet, men også autentisere abonnenten basert på profilen til tjenester som er tillatt for abonnenten, å videresende godkjenningen/forkastingen tilbake til det anropende nett eller vandringsnettet i det format som er nødvendig i det anropende nett eller vandringsnett, avgiftsbelegge samtalebruken i sann tid, hvis anropet er satt opp av oppringningsnettet eller det nett hvor abonnenten for tiden befinner seg, tilveiebringe bruksinformasjon og ut-føre oppgjør mellom flere parter for tjenester levert over heterogene nett.
En kundebehandlingsløsning for vandrende abonnenter, spesielt vandrere som har forhåndsbetalt, bør også ha minst følgende muligheter: mulighet til å identifisere den vandrende abonnent når abonnenten ringer til kundebehandlingssentret (CCC, customer care center); mulighet til å kommunisere med hjemmenettet og fremskaffe informasjon vedrørende kundekontoen (saldo, tidligere transaksjonshistorie osv.) og kundetjenesteprofil (hvilke tjenester som den spesielle kunde er gitt tilgang til), mulighet til å behandle kundens anmodninger om informasjonslevering/anmodningssvar; mulighet til å treffe foranstaltninger på enten kundekontoen eller tjenesteprofilen (for eksempel kreditere/reversere beløp for avbrutte samtaler; aktivere nye tjenester for kunden, osv.); abonnentens mulighet til å bli forbundet med kundebehandlings-systemet i besøksnettet, slik at kundetjenester kan leveres (for eksempel integrasjon med de lokale, interaktive talesystemer, kundetjenesteanvendelser, osv.); og muligheten til å oppdatere kundens hjemmedatabase for å opprettholde integriteten til kundekontoinformasjonen og tillate kunder å fylle på sine forhåndsbetalte konti under vandring.
Forhåndsbetalt vandring oppviser også flere utfordringer med hensyn til avtaler mellom flere parter når det gjelder konvergerte forhåndstjenester. Ved forhåndsbetalt vandring er det hjemmenettet som samler inn pengene fra kunden. Alle besøksnett sender derfor bruksdata for vandringskunden (enten direkte eller via dataklarerings-/avtale-hus) til hjemmenettet for oppgjør. Ved forhåndsbetalt vandring er det mulig at en kunde A kjøper det innledende abonnement fra nett X, men benytter det forhåndsbetalte beløp i nett Y og fyller på sin konto i nett Z. I dette scenariet er det ingen forretningsmessig forpliktelse for nett Z å betale nett Y, selv om nett Z holder på det påfyllingsbeløp som er betalt av kunden A. Nett X garanterer dessuten for kundens betalinger uten i virkeligheten å ha de penger som er betalt av kunde A. For å fremskaffe betalingsinnsamlingen eller påfyllingstjenesten, vil også nett Z kanskje belaste nett X med et tjenestegebyr.
Vandringsoppgjørsløsninger som for tiden er tilgjengelige, tar bare vare på opp-gjør for telefontjenester som er etterbetalte tjenester. De tar seg ikke av behovene til de forhåndsbetalte telefontjenester (enkle eller konvergerte tjenester), heller ikke dreier de seg om oppgjørsbehovet for handelstransaksjoner utført av en forhåndsbetalende vandringsabonnent i besøksnettet. Det er derfor et behov for en løsning på en fremgangsmåte og et system som gjør det mulig for flerparts-oppgjør for konvergerte tjenester og kommunikasjonstransaksjoner; og som gjør det mulig å konfigurere oppgjørsreglene for hver tjeneste og handelstransaksjon. Disse reglene bør muliggjøre oppgjør mellom: selgere, leverandører av varer/tjenester, for eksempel enten fabri-kanter, videreselgere eller distributører, eller en kombinasjon av flere slike entiteter (portaler, mobilportaler eller andre typer portaler som innbefatter elektroniske handelsportaler, osv.), internett-tjenesteleverandører (uavhengige agenturer eller mobil-operatører eller portaler), mobiltelefonselskaper (hjemmenett, besøksnett, eller begge), virtuelle tjenesteleverandører (innholdstjenesteleverandører eller infrastruktur-tjenesteleverandører eller varemerkeagenturer eller en hvilken som helst kombinasjon), bank/kredittkortselskaper eller hvilke som helst andre finansielle institusjoner (en eller flere som er involvert i en handelstransaksjon), tredje parts betalingsselskaper (for eksempel selgersammenslutninger, betalingsbehandlingsselskaper eller elektroniske lommebøker eller hvilke som helst av slike betalingsbehandlingsselskaper), vare/tjeneste-leveringsselskaper (for eksempel reiseselskaper, båndbreddeleveran-dører) og forsikringsselskaper.
Oppgjørsregler bør også muliggjøre konfigurering for forskjellige situasjoner, slik som: (1) oppgjør i sann tid, (2) oppgjør med tidsforsinkelse (for eksempel etter 2 dager eller 30 dager, osv.), (3) oppgjør basert på bekreftelse av visse betingelser (for eksempel at et bud bare blir betalt når varene er levert, mens et forsikringsagentur blir betalt før transport av varer), (4) oppgjør basert på en forretningsforbindelse mellom partene (for eksempel at et budselskap tilbyr rabatt basert på volum, noe som betyr at oppgjørsprosessen vil ta i betraktning mange leveringer istedenfor bare én levering), og (5) oppgjør basert på ytelse (for eksempel blir en portal betalt en liten sum hver gang en annonse blir levert til den vandrende abonnent, og den får betalt en større sum hvis den vandrende abonnenten virkelig kjøper varene/tjenestene). Oppgjør bør også ta hensyn til en vandringskontrakt mellom deltakende nett (for eksempel tilleggsavgifter for vandrere). Oppgjør bør også kunne ta i betraktning eventuelle forskrifter (for eksempel betaling av skatter og oppgjør med statlige selskaper).
For at forhåndsbetalte tjenester og handelstransaksjoner skal bli vellykket, spesielt ved mobilhandel, er det et behov for en fremgangsmåte og et system som muliggjør påfylling fra et hvilket som helst av følgende midler: påfyllingskuponger, direkte forbindelse til garantikontoen (kreditt/debet/en hvilken som helst annen type konto), påfylling av kunden fra mobiltelefonen eller en fast telefon, direkte debitering av garantikontoen (kreditt/debet/en hvilken som helst annen type konto), påfylling av kunden fra en minibank, eller påfylling ved hjelp av kontant betaling i en kasse. Hver forhåndsbetalingskunde bør også være i stand til å konfigurere sine egne kriterier for påfylling på følgende måte: for å fylle på bare fra telefon (mobil eller fast), fylle på fra nettet (internett, mobilt internett eller en hvilken som helst annen type offentlige eller private nett), påfylle bare når kunden spesielt ber om påfylling (enten ved hjelp av IVR, nett eller ved personlig fremmøte, eller på en hvilken som helst annen måte), automatisk påfylling når saldoen går under en viss verdi fra en annen spesiell konto (bank-debet/kreditt eller en hvilken som helst annen type konto), ikke påfylling av kontoen, men bruk av en annen konto som en betalingsgaranti for den forhåndsbetalte konto, påfylling av flere delkonti med forhåndskonfigurerte grenser fra hovedkontoen, påfylling på periodisk basis (for eksempel daglig, månedlig, ukentlig, osv.), og en påfyllingssum som kan bestemmes basert på brukskriterier som definert av brukeren (for eksempel ved å se på de siste 7 dagers bruk og fylle på det gjennomsnittlige beløp; eller påfyllingsbeløpet skal være lik verdien av den dyreste transaksjon som er utført i løpet av de siste "x" dager, osv.).
I et forhåndsbetalt, konvergent kommunikasjonsmiljø bør transaksjonsvalide-ring/autentisering (uansett om det er en kommunikasjonstjeneste eller en kommersiell transaksjon, eller en kombinasjon av begge) ha flere trinn eller kontroller for å validere brukeren, samt tilgjengelighet til en kredittgrense eller forhåndsbetalte summer i forbindelse med kontoen. Enhver løsning for kommunikasjonstilgangen, internett- eller mobil/internett-tilgangen, handelstransaksjon (uansett om den utføres i en fysisk forretning eller på nettet/mobilnettet), bør muliggjøre validering av en kunde basert på PIN, passord, telefonrelaterte sikkerhetstrekk, eller en kombinasjon av noen eller alle disse, validering av om den etterspurte tjeneste/transaksjon er autorisert eller ikke for vedkommende spesielle kunde med forhåndsbetalt konto (tjenesteprofil-validering), validering av tilstrekkelig tilgjengelig saldo på kundens forhåndsbetalte konto for tjenestene/transaksjonen (saldoen kan være den forhåndsbetalte kontobalanse eller en kredittkontobalanse eller en hvilken som helst annen type reell eller virtuell konto tilknyttet kundens forhåndsbetalte konto).
Basert på regler konfigurert av tjenesteleverandøren (bank, telekommunikasjonsselskap eller selger, eller en hvilken som helst annen type
tjenesteleverandør), kan ytterligere valideringer utføres. Tjenesteleverandøren kan for eksempel: be om ytterligere informasjon fra brukeren (for eksempel morens pikenavn, fødselsdato eller verdien på den foregående transaksjon som er utført, eller verdien av den foregående regning, foregående påfylling eller overensstemmelse mellom et
personlig spørsmål og svar som er forhåndsbestemt av kunden), å be om spesielle passord for transaksjoner av høy verdi (for eksempel med enn 200 kroner) eller mange transaksjoner (for eksempel mer enn 15 transaksjoner på en dag, eller mer enn 50 transaksjoner i løpet av en måned, osv.), basert på regler utformet av sluttbrukeren eller kunden, kan tjenesteleverandøren utføre ytterligere valideringer.
Kunden/brukeren kan for eksempel be om: ytterligere passord forvisse transak-sjonstyper (for eksempel kjøp av flybilletter), ytterligere informasjon som systemet skal be om (for eksempel fødselsdato, navnet på en venn, spesielle passord) i tilfelle av en transaksjonsverdi høyere enn et sett med tidligere transaksjoner (for eksempel å be om et spesielt passord hvis den aktuelle transaksjonsverdi er 50% eller mer enn summen av de samlede transaksjonene i løpet av de siste 5 dagene). Basert på regler utformet av kunden/brukeren, bør systemet være i stand til å blokkere visse typer transaksjoner (for eksempel alle elektroniske/mobile handelstransaksjoner tillatt med unntak av pornografi eller pengeoverføringer mellom land hvor det finnes valutarestriksjoner).
Basert på regler som utformet ovenfor, bør det være mulig for kundetjeneste-agenten å snakke med kunden over telefon (dvs. at et system bør muliggjøre talekommunikasjon for transaksjonsautorisering mens transaksjonen som autoriseres, er i gang). Avhengig av de regler som er utformet av tjenesteleverandøren, bør det være mulig å ikke belaste kunden for slik bruk av talekommunikasjon eller ytterligere sikker-hetskommunikasjon (for eksempel avgiftsfri tilgang).
Et aspekt ved oppfinnelsen er således å tilveiebringe en fremgangsmåte for å fremskaffe mobilhandels-, elektronisk handels-, kundebehandlings- og kommunikasjons-tjenester via et antall nett, hvor fremgangsmåten innbefatter å motta fra en brukeranordning i et vandringsnett, et identifikasjonsnummer og en anmodning om en tjeneste, å videresende fra vandringsnettet til et hjemmenett, identifikasjonsnummeret, anmodningen om tjenesten og å tilføye identifikasjonsnummeret til en tjenesteleveran-dør som er knyttet til en tjenesteleverandør og en kostnad eller avgift for tjenesten hvis tjenesten skal belastes, verifiseres av den konvergente kommunikasjonsplattform som befinner seg på hjemmenettet, at identifikasjonsnummeret vedrører en gyldig brukerkonto, at brukeranordningen er autorisert til å motta tjenesten og at den gyldige brukerkonto har tilstrekkelig verdi til å betale for tjenesten, å fremskaffe en autorisasjon til tjenesteleverandøren hvis identifikasjonsnummeret angår den gyldige brukerkonto, brukeranordningen er autorisert til å motta tjenesten og den gyldige brukerkonto har tilstrekkelig verdi, hvis tjenesten skal belastes, og å belaste den gyldige brukerkonto på sanntidsbasis, om nødvendig, for å levere tjenesten hvis tjenesten skal belastes.
Et annet aspekt ved oppfinnelsen er å tilveiebringe en anordning som leverer mobile handelstjenester via et antall nett, idet anordningen har en mottaker som mottar en forespørsel om en tjeneste, der forespørselen innbefatter et identifikasjonsnummer fra en brukeranordning som befinner seg i et vandringsnett, og hvor den etterspurte tjeneste, identifikasjonsnummeret til en tjenesteleverandør vedrørende tjeneste-leverandøren og en pris på den etterspurte tjeneste fra vandringsnettet, en verifise-ringsenhet som verifiserer at identifikasjonsnummeret angår en gyldig brukerkonto, at brukeranordningen er autorisert til å motta tjenesten og at den gyldige brukerkonto har tilstrekkelig verdi til å betale for tjenesten, en sender som leverer en autentisering til tjenesteleverandøren hvis identifikasjonsnummeret angår den gyldige brukerkonto, er brukeranordningen autorisert til å motta tjenesten, og den gyldige brukerkonto har tilstrekkelig verdi og en kreditor som belaster den gyldige brukerkonto for å levere tjenesten.
Nok et annet aspekt ved oppfinnelsen er å tilveiebringe en fremgangsmåte for å levere forhåndsbetalte vandringskommunikasjonstjenester via et antall nett, idet fremgangsmåten innbefatter å motta, i et vandringsnett fra en brukeranordning, et identifikasjonsnummer og et destinasjonsanordningsnummer, å videresende fra vandringsnettet til et hjemmenett, identifikasjonsnummeret, destinasjonsanordningsnummeret og å tilføye identifikasjonsnummeret til en tjenesteleverandør og en pris på en vandringskommunikasjonstjeneste, å verifisere, ved hjelp av en konvergent kommunikasjonsplattform anordnet i hjemmenettet, at identifikasjonsnummeret angår en gyldig brukerkonto, at brukeranordningen er autorisert til å motta tjenesten, og at brukerkontoen har tilstrekkelig verdi til å betale for en innledende bruk av tjenesten, å levere en autorisering til vandringsnettet hvis identifikasjonsnummeret angår gyldig bruker-informasjon, idet brukeranordningen er autorisert til å motta tjenesten og kontoen har tilstrekkelig verdi til å betale for en innledende bruk av tjenesten, å belaste den gyldige brukerkonto for å levere tjenesten, og å sende et signal når saldoen på brukerkontoen når et forutbestemt nivå.
Et annet aspekt ved oppfinnelsen er å tilveiebringe en anordning som leverer forhåndsbetalte vandringskommunikasjonstjenester via et antall nett, der apparatet innbefatter en mottaker som mottar en anmodning om en kommunikasjonstjeneste, der anmodningen innbefatter et identifikasjonsnummer og nummeret til en destina-sjonsanordning fra en brukeranordning som befinner seg i et vandringsnett, og et identifikasjonsnummer for en tjenesteleverandør tilknyttet tjenesteleverandøren og en pris på tjenesten fra vandringsnettet, en verifiseringsanordning som verifiserer at identifikasjonsnummeret angår en gyldig brukerkonto, at brukeranordningen er autorisert til å motta kommunikasjonstjenesten på vandringsnettet, og at den gyldige brukerkonto har tilstrekkelig verdi til å betale for tjenesten, en sender som leverer en autorisering til tjenesteleverandøren hvis identifikasjonsnumre angår den gyldige brukerkonto, idet brukeranordningen er autorisert til å motta tjenesten og den gyldige brukerkonto har tilstrekkelig verdi og sender et signal hvis den gyldige brukerkonto når et forutbestemt nivå og en kreditor som belaster den gyldige brukerkonto for å levere tjenesten.
Et ytterligere aspekt ved oppfinnelsen er å tilveiebringe en fremgangsmåte for å levere kundetjenester via et antall nett, idet fremgangsmåten innbefatter å motta, i et vandringsnett fra en brukeranordning, et identifikasjonstall og en anmodning om en kundetjeneste, å videresende fra vandringsnettet til et hjemmenett, at identifikasjonsnummeret angår en gyldig brukerkonto og å forbinde brukeranordningen med kunde-tjenesten hvis identifikasjonsnummer angår den gyldige brukerkonto.
Et annet aspekt ved oppfinnelsen er å tilveiebringe en anordning som leverer kundebehandlingstjenester via et antall nett, der anordningen innbefatter en mottaker som mottar en anmodning om en kundebehandlingstjeneste, hvor anmodningen innbefatter et identifikasjonsnummer fra en brukeranordning som befinner seg i et vandringsnett, og identifikasjonsnummeret til en tjenesteleverandør tilknyttet en tjenesteleverandør fra vandringsnettet, en verifiseringsanordning som verifiserer at identifikasjonsnummeret er tilknyttet en gyldig brukerkonto, at brukeranordningen er autorisert til å motta kundebehandlingstjenesten og en forbindelsesanordning som for-binder brukeranordningen med en tjenestebehandlingsleverandør som kan levere kundebehandlingstjenesten, hvis identifikasjonsnummeret er tilknyttet en gyldig brukerkonto.
Nok et annet aspekt ved oppfinnelsen er å tilveiebringe en fremgangsmåte for påfylling av en forhåndsbetalt konto for tjenester som skal leveres via en konvergent kommunikasjonsplattform, hvor fremgangsmåten innbefatter å motta en anmodning om autorisering til å bruke en kundekonto som befinner seg på den konvergente kommunikasjonsplattform, å bestemme at kundekontoen ikke har tilstrekkelig saldo for den tjeneste som skal leveres, å bestemme at kundekontoen har autorisert en påfyllingsmekanisme, å fylle på kundekontoen ved å bruke påfyllingsmekanismen, og å autorisere bruken av kundekontoen til tjenester via den konvergente kommunikasjonsplattform.
Et ytterligere aspekt ved oppfinnelsen er å tilveiebringe en anordning som fyller på en forhåndsbetalt konto for tjenester som skal leveres via en konvergent kommunikasjonsplattform, hvor anordningen innbefatter en mottaker som mottar en anmodning om autorisering til å bruke en kundekonto som befinner seg på den konvergente kommunikasjonsplattform, en bestemmelsesenhet som bestemmer at kundekontoen ikke har tilstrekkelig saldo til at tjenesten kan leveres, og at kundekontoen har autorisert en påfyllingsmekanisme, en påfyllingsenhet som fyller på kundekontoen ved å benytte påfyllingsmekanismen, og en sender som sender en autorisasjon for bruk av kundekontoen fortjenesten via den konvergente kommunikasjonsplattform.
Et annet aspekt ved oppfinnelsen er å tilveiebringe en fremgangsmåte for å gjøre opp for en forhåndsbetalt transaksjon til et antall leverandører i et konvergent kommunikasjonsmiljø, hvor fremgangsmåten innbefatter å belaste en avgift på en brukerkonto for en transaksjon levert via et antall nett på sanntids-basis, å bestemme et antall deler av avgiften som skal distribueres til et antall leverandører som inngår i fremskaffelsen av den forhåndsbetalte transaksjon via antallet nett, og å gjøre opp med leverandørene via antallet nett i henhold til det bestemte antall deler.
Nok et ytterligere aspekt ved oppfinnelsen er å tilveiebringe en anordning som gjør opp for en forhåndsbetalt transaksjon med et antall leverandører i et konvergent kommunikasjonsmiljø, idet anordningen innbefatter en avgiftsenhet som belaster en brukerkonto for en transaksjon levert via et antall nett på sanntidsbasis, en bestemmelsesenhet som bestemmer et antall deler av avgiften som skal fordeles mellom et antall leverandører som er involvert i leveringen av den forhåndsbetalte transaksjon via antallet nett, og en sender som gjør opp med leverandørene via antallet nett i henhold til det bestemte antall deler.
Et annet aspekt ved oppfinnelsen er å tilveiebringe en fremgangsmåte for levering av mobil handel, elektronisk handel, kundebehandlings- og kommunikasjonstjenester via et antall nett, hvor fremgangsmåten innbefatter å motta fra en brukeranordning i et vandringsnett, et identifikasjonsnummer og en anmodning om en tjeneste, å videresende fra vandringsnettet til et hjemmenett identifikasjonsnummeret, anmodningen om tjenesten og å tilføye et identifikasjonsnummer for en tjeneste- leverandør som angår en tjenesteleverandør, og en tariff for tjenesten hvis tjenesten skal belastes, å verifisere, ved hjelp av en konvergent kommunikasjonsplattform som befinner seg i hjemmenettet, at identifikasjonsnummeret angår en gyldig brukerkonto, at brukeranordningen er autorisert til å motta tjenesten og at den gyldige brukerkonto har tilstrekkelig verdi til å betale for tjenesten, å levere en autorisasjon til tjeneste-leverandøren hvis identifikasjonsnummeret angår den gyldige brukerkonto, idet brukeranordningen er autorisert til å motta tjenesten og den gyldige brukerkonto har tilstrekkelig verdi hvis tjenesten skal belastes, og å belaste den gyldige brukerkonto i sann tid om nødvendig, for å levere tjenesten hvis tjenesten skal belastes.
Et annet aspekt ved oppfinnelsen er å tilveiebringe en fremgangsmåte for levering av mobil handel, elektronisk handel, kundebehandlings- og kommunikasjonstjenester via et antall nett, hvor fremgangsmåten innbefatter å motta, fra en brukeranordning i et vandringsnett, et identifikasjonsnummer og en anmodning om en tjeneste, å videresende fra vandringsnettet til et hjemmenett identifikasjonsnummeret, anmodningen om tjenesten og å tilføye et identifikasjonsnummer vedrørende en tjenesteleverandør og en pris på tjenesten hvis tjenesten skal belastes fra et vandringsnett, en bestemmelsesenhet som bestemmer ved hjelp av en konvergent kommunikasjonsplattform som befinner seg i hjemmenettet, om identifikasjonsnummeret angår en gyldig brukerkonto, om brukeranordningen er autorisert til å motta tjenesten og om den gyldige brukerkonto har tilstrekkelig verdi til å betale for tjenesten, en sender som leverer en autorisasjon til tjenesteleverandøren hvis identifikasjonsnummeret angår den gyldige brukerkonto, brukeranordningen er autorisert til å motta tjenesten og den gyldige brukerkonto har tilstrekkelig verdi, hvis tjenesten skal belastes, og en avgiftsenhet som belaster den gyldige brukerkonto på en sanntids-basis, om nødvendig, for levering av tjenesten hvis tjenesten skal belastes.
Det er således et aspekt ved oppfinnelsen å tilveiebringe et konvergent kommunikasjonssystem og en fremgangsmåte for implementering av en eneste brukerkonto med fleksibilitet og raffinement for å håndtere kommunikasjonstjenester og transaksjoner som stammer fra mange kilder. En eneste konto som kan håndtere transaksjoner fra flere tjenesteleverandører og transaksjonsleverandører, vil muliggjøre tidligere utilgjengelige transaksjoner og redusere prisen på andre transaksjoner, slik at de vil bli mer brukt. Forskjellige utførelseseksempler av oppfinnelsen muliggjør mikro-transaksjoner i et flerselger, multisystem-miljø. De forskjellige utførelseseksemplene frembringer en hensiktsmessig måte til å autorisere, debitere og gjøre opp meget små transaksjoner. Forskjellige utførelseseksempler av oppfinnelsen sørger for et konvergent kommunikasjonssystem og en fremgangsmåte som oppfyller behovene til dagens mobile, tilkoplede kunde.
Det er et annet aspekt ved oppfinnelsen å tilveiebringe et konvergent kommunikasjonssystem og en fremgangsmåte egnet for en økende, spesialisert verden hvor mange parter må inngå for å muliggjøre visse transaksjoner. Ytterligere parter kan til-føye en transaksjon en merverdi og ønsker å motta kompensasjon basert på denne verdien. Sanntidsregelsettene som er beskrevet her, gjør det mulig for mange parter i en transaksjon å motta betaling i samsvar med en debitering og betalingsplan som partene er enige om. I en kompleks transaksjon må hver tjenesteleverandør forsikres om å få betaling. For disse komplekse tjenesteleveringene som flere samarbeider om, kan partene i leveringskjeden bare få forsikring når den komplekse tjeneste er autorisert i sann tid, mot en konto hvor det er bestemte regler for autorisasjon som er garantert å kunne anvendes på vedkommende tidspunkt (dvs. i sann tid). Forskjellige utførelseseksempler av oppfinnelsen benytter sanntidsregelsett for å muliggjøre debitering og oppgjør for flere parter på en slik måte at komplekse transaksjoner mellom flere tjenesteleverandører, blir praktisk.
Et ytterligere aspekt ved oppfinnelsen som beskrives her, er å tilveiebringe et kommunikasjonssystem og en fremgangsmåte som utvider tilpasningsdyktigheten og funksjonaliteten som tilbys, ved hjelp av en konto som sørger for komplekse regler vedrørende kontopåfylling, autorisasjon av transaksjoner, debitering i sann tid og komplekse oppgjør, samt fremgangsmåter for å bestemme reglene.
En eneste konto som gir fleksibilitet og sikkerhet for en kunde, kan sørge for komplekse transaksjoner som tidligere var utilgjengelige. Forskjellige utførelses-eksempler av oppfinnelsen fremskaffer et sofistikert regelsett som skal implementeres for å tillate fleksibilitet og hensiktsmessighet for en kunde, samtidig som sikkerheten til den ene eller de flere tjenesteleverandører opprettholdes. Sofistikerte regler for å kreditere en konto, å autorisere transaksjoner, å debitere en konto og å gjøre opp for transaksjoner med flere mottakere, vil for eksempel tilveiebringe nødvendig fleksibilitet og hensiktsmessighet i dagens og fremtidens mobile handelstransaksjoner. Det er derfor mulig å bestemme om en etterspurt transaksjon kan tillates eller ikke ved et hvilket som helst tidspunkt, og hvis ikke, hvilke inkrementale handlinger som vil gjøre den tillatt. Dette vil noen ganger innebære å presentere valgmuligheter for kunden, men ofte vil det ikke være tilfelle.
Bestemmelse av de nøyaktige betalingsbeløp til nøyaktige parter kan være kompleks og må bestemmes ved tidspunktet for en transaksjon for å sikre at alle parter blir behandlet rettferdig. Utførelseseksemplene ifølge oppfinnelsen tilveiebringer en transaksjon som kan utføres i sann tid med sanntidsautorisasjon og debitering av konti. Sanntidsregelsettet kan være bestemt basert på forskjellige betraktninger. Tidspunktet og datoen for transaksjonen, historien til kunden og selgeren og andre faktorer som kan bestemmes adaptivt eller progressivt basert på forskjellige hendelser, kan for eksempel brukes til å understøtte om en transaksjon skal autoriseres eller ikke.
En første kategori med regler som brukes i det konvergente kommunikasjonssystem og fremgangsmåten, er kontopåfylling hvor en bruker anmoder om og må betale på forhånd for en mobil handel, kommunikasjon eller en annen elektronisk handelstransaksjon fra forskjellige tjenesteleverandører gjennom et konvergent kommunikasjonssystem og fremgangsmåte i et heterogent nettmiljø. Kontopåfylling kan innbefatte en hvilken som helst type kreditt som kommer inn på en konto. Forskjellige eksempler innbefatter penger, aksjer, bonuspoeng for flyreiser, medlemskap, ytterligere medlemskapsperioder, kontokreditter, eierskapsoverdragelser eller hvilke som helst andre kjente eller senere utpønskede fremgangsmåter for overføring av verdi til en konto. Kontopåfylling kan være automatisk, halvautomatisk, manuell eller automatisk innenfor visse parametre, og ellers manuelle. Forskjellige utførelses-eksempler på oppfinnelsen tilveiebringer påfylling fra en hvilken som helst av følgende: påfyllingskupong, direkte forbindelse til garantistkontoen (kreditt/debet/en hvilken som helst annen type konto), påfylling av kunden fra mobiltelefonen eller en fast telefon, direkte debitering av garantistkontoen (kreditt/debet/en hvilken som helst annen type konto), påfylling av kunden fra en minibank eller påfylling ved hjelp av kontant betaling ved en kassedisk. En bruker kan derved sette opp komplekse, men funksjonelle scenarier for påfylling av sin kundekonto.
En annen kategori med regler som benyttes i det konvergente kommunikasjonssystem og fremgangsmåten, er autoriserings- og valideringsregler hvor en bruker anmoder om og må betale på forhånd for mobil handel, kommunikasjon eller andre elektroniske handelstransaksjoner fra forskjellige tjenesteleverandører gjennom et konvergent kommunikasjonssystem og en fremgangsmåte i et heterogent nettmiljø. Fordi utførelseseksempler av oppfinnelsen sørger for lenker til kredittjenester, telefoner og internettet, er det inkludert regler som skisserer under hvilke forhold penger kan tas ut av kontoen. Forskjellige eksempler innbefatter grenser per belastning, andre systemmeldinger, kontobelastningsgrenser, medlemskapsgrenser, eller en hvilken som helst kjent eller senere utpønsket fremgangsmåte for å begrense enkelttransak-sjoner, månedlige transaksjoner, saldo, transaksjonsleverandør og transaksjons-mottaker. En bruker kan derved sette opp komplekse, men funksjonelle scenarier for å regulere hvem som er autorisert til å benytte en konto, og hvorfor.
En tredje kategori med regler som benyttes i det konvergente kommunikasjonssystem og fremgangsmåten, er debiteringsregler hvor en bruker anmoder om og må betale på forhånd for mobil handel, kommunikasjon eller en annen elektronisk handelstransaksjon fra forskjellige tjenesteleverandører i et konvergent kommunikasjonssystem og fremgangsmåten i et heterogent nettmiljø. Forskjellige utførelses-eksempler på oppfinnelsen tilveiebringer forskjellige tjenesteleverandører til å sette opp forskjellige fremgangsmåter for å debitere enten en tjenesteleverandør eller en kundekonto. En telefontjenesteleverandør kan for eksempel sørge for en betaling til sin egen konto, en betaling til en besøksnettleverandørs konto og en tredje betaling til en fjernleverandørs konto.
Aspekter ved oppfinnelsen som er beskrevet ovenfor, kan oppnås ved hjelp av en konvergent kommunikasjonsmetode som anvender et regelsett, som har flere funksjoner, innbefattende å bestemme, for en autorisert bruker, minst én regel som kan anvendes ved tidspunktet for autorisering av en transaksjon og debitering av en konto som tilhører den autoriserte bruker, å anvende den minst ene regel til å autorisere transaksjonen, debitere kontoen i henhold til den minst ene regel for å debitere en konto i sann tid hvis transaksjonen er autorisert, og å gjøre opp sanntidsdebeten til et antall transaksjonsleverandører i samsvar med minst én oppgjørsregel.
For systemet og fremgangsmåten ovenfor kan forskjellige aspekter innbefatte å bestemme at den autoriserte bruker ikke har tilstrekkelig verdi på en autorisert brukerkonto til å debitere for transaksjonen, og påfylling av den autoriserte konto etter full-føring av en påfyllingsrutine som har flere funksjoner, innbefattende å bestemme en påfyllingsbrukerkonto for å overføre midler fra å autorisere overføring av minst én av en referanse til en forhåndsautorisert overføring og anmodning om autorisering fra den autoriserte bruker. Andre aspekter kan innbefatte hvor påfyllingen blir utført ved å benytte et antall påfyllingsbrukerkonto. Andre aspekter kan innbefatte hvor anmodningen om autorisering fra den autoriserte bruker er minst én av å anmode om et PIN, å anmode om manuell innføring, å anmode om en brukerpassfrase og å bekrefte brukeridentiteten ved hjelp av biometriske midler.
For systemet og fremgangsmåten ovenfor kan forskjellige aspekter innbefatte hvor anvendelsen blir utført ved å benytte et antall regler for å autorisere transaksjonen, hvor debiteringen blir utført under anvendelse av et antall regler for å debitere en konto og oppgjøret blir utført ved å benytte et antall oppgjørsregler, eller hvor debiteringen blir utført ved å benytte et antall regler for å debitere en konto og oppgjøret blir utført ved å benytte et antall oppgjørsregler. Andre aspekter kan innbefatte hvor oppgjøret inntreffer ved minst én av umiddelbart, etter tre dager, ved slutten av en kalendermåned, med jevne mellomrom og som en rekke delbetalinger, og hvor anvendelsen av den minst ene regel for autorisering av transaksjonen innbefatter å autorisere transaksjonen ved å benytte minst én av et bruker-PIN, manuell innføring, en brukerpassfrase og bekreftelse av brukeridentitet ved hjelp av biometriske midler.
For systemet og fremgangsmåten ovenfor kan forskjellige aspekter innbefatte å bestemme minst én regel, anvendt i sann tid, samtidig med en anmodning om transaksjonsautorisering i henhold til en algoritme ved å benytte data angående historiske hendelser, som blir betraktet å ha relevans for anmodningen om transaksjonsautorisering. Andre aspekter kan innbefatte hvor de historiske hendelser er en autorisert brukers tidligere kjøp eller aktuelle resultater av historiske risikovurderinger, eller hvor slike historiske data som er tilgjengelige, er i konstant endring. Andre aspekter kan innbefatte hvor transaksjonen blir etterspurt og en forbindelse til antallet transaksjons-leverandører er over heterogene nett.
Aspekter ved oppfinnelsen som er beskrevet ovenfor, kan også oppnås ved hjelp av en brukerinnmatingsanordning for å aksessere en konto i et konvergent kommunikasjonssystem, som har en sender som sender til det konvergente kommunikasjonssystem for å aksessere en autorisert brukerkonto, en anmodning om en transaksjon fra en kontoforvalter, hvor kontoforvalteren har en bestemmelsesenhet som bestemmer, for en autorisert bruker, minst én regel som kan anvendes ved tidspunktet for autorisering av en transaksjon og debitering av en konto, en prosessor som anvender den minst ene regel til å autorisere transaksjonen, en debiteringsenhet som debiterer kontoen i henhold til den minst ene regel for å debitere en konto i sann tid hvis transaksjonen er autorisert, og en oppgjørsenhet som gjør opp for sanntidsdebeten til et antall transaksjonsleverandører i samsvar med minst én oppgjørsregel og en mottaker som mottar minst én av en bekreftelse på aksessering av den autoriserte brukerkonto, en bekreftelse fra kontoforvalteren om debitering av den autoriserte brukerkonto og en oppgjørsmelding.
Aspekter ved oppfinnelsen som er beskrevet ovenfor, kan videre oppnås ved
hjelp av et konvergent kommunikasjonssystem som anvender et regelsett, som har en bestemmelsesenhet som bestemmer, for en autorisert bruker, minst én regel som kan anvendes ved tidspunktet for autorisering av en transaksjon og debitering av en konto som tilhører den autoriserte bruker, en prosessor som anvender den minst ene regel til å autorisere transaksjonen, en debiteringsenhet som debiterer kontoen i henhold til den minst ene regel for debitering av en konto, i sann tid hvis transaksjonen er autorisert, og en oppgjørsenhet som gjør opp debeten i sann tid til et antall transaksjons-leverandører i samsvar med minst én oppgjørsregel.
Aspekter ved oppfinnelsen som er beskrevet ovenfor, kan videre oppnås ved hjelp av et konvergent kommunikasjonssystem som anvender et regelsett, som har en bestemmelsesenhet som bestemmer, i sann tid, et antall regler for autorisering, debitering og oppgjør for en transaksjon ved et aktuelt tidspunkt, en autoriseringsenhet som autoriserer transaksjonen hvis en aktuell status for en autorisert brukers konto eller den autoriserte bruker oppfyller antallet regler for autorisering av transaksjonen ved det aktuelle tidspunkt, en debiteringsenhet som debiterer den autoriserte brukers konto i sann tid og krediterer minst én transaksjonsleverandørs konto, og en oppgjørs-enhet som gjør opp for transaksjonen i henhold til den minst ene regel for oppgjør av transaksjonen.
KORT BESKRIVELSE AV TEGNINGENE
Disse og andre aspekter og fordeler ved foreliggende oppfinnelse vil fremgå tydeligere og vil lettere bli forstått fra den følgende beskrivelse av de foretrukne utførelsesformer, tatt i forbindelse med de vedføyde tegninger, hvor: fig. 1 er et utførelseseksempel på et system som benytter konvergent kommunikasjonsplattform;
fig. 2 er et utførelseseksempel på utnyttelse av en konvergent kommunikasjonsplattform for mobil handel;
fig. 3 er et utførelseseksempel for anvendelse av en konvergent kommunikasjonsplattform til forhåndsbetalt vandring;
fig. 4 er et utførelseseksempel for utnyttelse av en konvergent kommunikasjonsplattform til kundebehandling;
fig. 5 er et utførelseseksempel på et internasjonalt system som utnytter en konvergent kommunikasjonsplattform;
fig. 6 er et utførelseseksempel på et system som benytter en konvergent kommunikasjonsplattform;
fig. 7 er et utførelseseksempel på arkitekturen for å muliggjøre forbedrede datatjenester med en konvergent kommunikasjonsplattform;
fig. 8 er et utførelseseksempel på en avgiftssaldo for en konvergent kommunikasjonsplattform;
fig. 9 er et eksempel på en fremgangsmåte for påfylling av en forhåndsbetalt kommunikasjonskonto;
fig. 10 er et eksempel på informasjonsoverføringen mellom flere parter for en konvergent kommunikasjonsplattform;
fig. 11 er et blokkskjema for å utføre mobil handel under vandring;
fig. 12 er et eksempel på en bruker som anmoder om en vandringstjeneste med en konvergent kommunikasjonsplattform;
fig. 13 er et eksempel på en bruker og en transaksjonsregistrering som brukes i en konvergent kommunikasjonsplattform;
fig. 14 er et eksempel på en brukerkonto i en konvergent kommunikasjonsplattform;
fig. 15 er et utførelseseksempel av et interaktivt talesvarsystem som benyttes på en konvergent kommunikasjonsplattform;
fig. 16 er et flytskjema som viser bruken av en forhåndsbetalt konto på en konvergent kommunikasjonsplattform for oppgjør mellom flere parter;
fig. 17 er et eksempel på en fremgangsmåte på en halvautomatisk fremgangsmåte for påfylling av en forhåndsbetalt konto og oppsetting av regler for oppgjør mellom flere parter på en konvergent kommunikasjonsplattform;
fig. 18 er et eksempel på en fremgangsmåte for å generere en oppgjørsrapport på en konvergent kommunikasjonsplattform;
fig. 19 er et eksempel på dataoverføringen i en konvergent kommunikasjonsplattform;
fig. 20A og 20B er eksempler på fremgangsmåter for oppgjør i sann tid mellom flere parter på en konvergent kommunikasjonsplattform;
fig. 21 er et blokkskjema over et eksempel på en kontoforvaltningsanordning for en konvergent kommunikasjonsplattform;
fig. 22 er et blokkskjema over et eksempel på en svitsjforvaltningsanordning for en konvergent kommunikasjonsplattform;
fig. 23 er et eksempel på forretning/forretnings-transaksjoner som benytter en konvergent kommunikasjonsplattform;
fig. 24 er et blokkskjema over et konvergent kommunikasjonssystem som utfører handel mellom forretninger;
fig. 25 er et blokkskjema over et eksempel på et system for kontopåfylling for en konvergent kommunikasjonsplattform;
fig. 26 er et blokkskjema over et eksempel på et system for påfylling av en forhåndsbetalt konto ved å benytte et interaktivt taleresponssystem på en konvergent kommunikasjonsplattform;
fig. 27 er et blokkskjema over et eksempel på et sikkerhetssystem som anvendes på en konvergent kommunikasjonsplattform;
fig. 28 er et eksempel på oppgjør mellom flere parter ved å benytte en konvergent kommunikasjonsplattform som et oppgjørshus;
fig. 29 er et eksempel på et skjermbilde med selgerinformasjon for oppgjør på en konvergent kommunikasjonsplattform;
fig. 30 er et eksempel på et skjermbilde for å tilføye selgerinformasjon til en konvergent kommunikasjonsplattform;
fig. 31 er et eksempel på et skjermbilde for å tilføye detaljer om selgere til en konvergent kommunikasjonsplattform;
fig. 32 er et eksempel på et regellager for et konvergent kommunikasjonssystem;
fig. 33 er et eksempel på en anordning som kan implementere oppgjør i et konvergent kommunikasjonssystem;
fig. 34 er et eksempel på en fremgangsmåte for sofistikert kontopåfylling ved å benytte et konvergent kommunikasjonssystem;
fig. 35 er et eksempel på en fremgangsmåte for sofistikert transaksjonsautorisering ved å benytte et konvergent kommunikasjonssystem;
fig. 36 er et eksempel på en fremgangsmåte for sofistikert kontodebitering i sann tid ved å benytte et konvergent kommunikasjonssystem; og
fig. 37 er et eksempel på en fremgangsmåte for sofistikerte oppgjørsprosedyrer under anvendelse av et konvergent kommunikasjonssystem.
DETALJERT BESKRIVELSE AV UTFØRELSESFORMENE
Som beskrevet her kan utførelseseksemplene i henhold til oppfinnelsen anvendes i forbindelse med et system, en fremgangsmåte og en plattform for bruk med heterogene nett og for konvergerte (eller konvergente) kommunikasjonssystemer, konvergert handel og konvergerte tjenester. Selv om det blir brukt forskjellige uttrykk og forkortelser som gjelder dette område, har flere uttrykk de følgende ytterligere betydninger som blir beskrevet. Eksempler på heterogene nett er nett som består av ulike eller forskjellige teknologiske komponenter eller bestanddeler i kombinasjon. Et heterogent nett kan for eksempel ha: forskjellige telekommunikasjonsstandarder, slik som GSM og CDMA; forskjellige versjoner av den samme telekommunikasjons-standard, slik som GSM 900 og 1900; forskjellige svitsjemiljøer, slik som NOKIA og ERICSSON; intelligente nett (IN) eller ikke-IN; forskjellig signalering, slik som ISDN og SS7; forskjellige operativsystemer, slik som UNIX og MICROSOFT WINDOWS NT; forskjellige valører av det samme operativsystem, slik som SOLARIS (SUN) og AIX (IMB); forskjellige versjoner av det samme operativsystem, slik som 2.0 og 2.1; forskjellig servermaskinvare, slik som IBM og COMPAQ; samme operatører, men forskjellige nettverkstyper, slik som KDDI CMDA og PDC i Japan; samme operatør, men forskjellig nett, slik som VODAFONE i forskjellige land.
Eksempler på konvergens er å kombinere en rekke teknologier og medier med hverandre for å tilveiebringe et mer fyldig tjenestenivå. Konvergerte kommunikasjoner kan for eksempel kombinere: forskjellige media, slik som tale, data, meldinger; mobil, fast eller satellitt-tale, data, meldingstjeneste tilbudt av forskjellige tjenesteleveran-dører; mobil, fast eller satellitt-tale-data, meldingsmedia tilbudt av forskjellige tjeneste-leverandører; mobile, faste eller satellitt-tale-data-meldingsmedia tilbudt av samme tjenesteleverandør; og mobile, faste eller satellitt-tale, data, meldingstjeneste tilbudt av forskjellige tjenesteleverandører. Konvergert handel innbefatter å kombinere telefon, internett, elektronisk handel eller mobil handel. Konvergert tjeneste innbefatter å kombinere kommunikasjons- og handelstjenester. Konvergert fakturering kan innbefatte slike trekk som å tilby en enkelt, integrert regning for alle kommunikasjonstjenester, og belastninger for innhold eller varer som er levert. Konvergert handel kan også referere til å integrere alle avgifter i forbindelse med en transaksjon til en transaksjon og utgift som innbefatter slike temaer som merverdigebyrer, skatter, telekommunikasjons-avgifter, osv. Konvergert tjeneste kan også referere til å tilby en eneste hjelpeoperatør som kan aksessere, se på og modifisere en kundes konto, selv om kontoen ikke befinner seg i et lokalnett.
En konvergent grensesnittanordning kan bestå av et antall nødvendige og valgfrie parametre som kan konfigureres for å bli integrert med systemet til en tredje part, ved å analysere inn/ut-parametrene som komponenten eller komponentene til den tredje part krever, å kartlegge komponentene til den tredje part til komponentparamet-rene for eksemplet på den konvergente kommunikasjonsplattform og å konfigurere komponentene for å løse eventuelle konflikter. Hvis en tredje parts system ikke kan levere visse valgfrie parametre, kan eksemplet på den konvergente kommunikasjonsplattform skape blindparametre for å sikre en korrekt kartlegging.
Eksempler på en plattform innbefatter et system som tilveiebringer en basis for ytterligere bestrebelser. En kommunikasjonsplattform, slik som et telefonsystem, gjør det mulig for data å strømme over dette for kommunikasjon på mange måter. En konvergent kommunikasjonsplattform kan likeledes gjøre det mulig å sammensmelte en rekke teknologier for å muliggjøre forbedret mobil handel, elektronisk handel og kundebehandling.
Eksempler på forbedrede tjenester innbefatter slike trekk som reformatering. En forbedret tjeneste kan for eksempel reformatere en dataanmodning fra et system, slik at det blir akseptert i et annet system; reformatert informasjon under henvisning til lagret informasjon, slik at den reformaterte informasjon innbefatter informasjon som ikke er tilgjengelig for den opprinnelige anordning.
Fig. 1 er et blokkskjema over et eksempel på et system som benytter en konvergent kommunikasjonsplattform. Som vist på fig. 1 blir kunden via sin inngang 10 forbundet gjennom anordningens IP 21, den trådløse anordning 23 eller telefonsystemets tilgangsanordning 25, og internettet 22, et trådløst nett 24 eller et offentlig telefonnett 26 med en selgertjenesteanordning 50 (dvs. en tjenesteleverandør). Selgertjenesteanordningen 50 blir så forbundet med den konvergente kommunikasjonsplattform 100 via en anmodning om betaling 52. Den konvergente kommunikasjonsplattform 100 returnerer så en betalingsautorisering 102 til selgertjenesteanordningen 50. Selgertjenesteanordningen 50 kan så levere eller bekrefte levering av tjenestene/varene 11 tilbake til kundeinngangen 10.
I dette eksemplet på et system, kan en kunde som ønsker å engasjere seg i mobil handel, hurtig og effektivt motta tjenestene/varene som han/hun ønsker. Hvis en kunde for eksempel ønsker å kjøpe en MP3-fil fra en selger av elektronisk musikk, kan transaksjonen virke som forklart nedenfor.
Kunden som betjener kundeinnmatingsanordningen 10, forsøker å kople seg til musikkselgeren via selgerens tjenesteanordning 50. Kundeinnmatingsanordningen 10 kan være forbundet med en hvilken som helst av IP-anordningen 21, den trådløse anordning 23 eller telefonsystemets tilgangsanordning 25. IP-anordningen 21 kan være et nettkort, en WAP-forbindelsesanordning, en SMS-meldingsanordning eller en hvilken som helst kjent eller senere utpønsket anordning for forbindelse med et internettprotokoll-nett.
Den trådløse anordning 23 kan være en radiotelefon, en mobiltelefon, eller en hvilken som helst annen innretning som benytter radiobølger eller elektromagnetisk energi til å kommunisere med det trådløse nettet 24. Aksessanordningen 25 til telefon-systemet kan være et modem, en ruter, et kabelmodem eller et hvilket som helst annet middel som kan koples til det offentlige telefonnett 26.
Internettet 22 kan være en hvilken som helst kombinasjon av svitsjer, rutere, nav, mikrobølgeanordninger eller annet kommunikasjonsutstyr som kan overføre internettprotokoll-meldinger fra et punkt til et annet. Det trådløse nettet 24 kan være et hvilket som helst system av radiomaster og svitsjer og andre anordninger, slik at en trådløs anordning 23 kan forbindes med en selgertjenesteanordning 50.
Det offentlige telefonnettet 26 kan være en hvilken som helst kombinasjon av llnjesvitsj, pakkesvitsj eller andre anordninger som er egnet til oppkopling av en tele-fonsystemtilgang til selgertjenesteanordningen 50.
Hvis kundeinnmatingen 10 var en trådløs anordning 23 og koples gjennom det trådløse nettet 24 til selgerens tjenesteanordning 50, kan selgerens tjenesteanordning 50 være et morse eller numerisk gjenkjennelsessystem, slik at kundeinnmatingen 10 på adekvat måte kan spesifisere en anmodning om å kjøpe MP3 fra selgerens tjenesteanordning 50.
Selgerens tjenesteanordning 50 kan være en kombinasjon av en nettserver, en taleserver, en SMS-meldingsserver eller en trådløs aksessprotokoll-server (WAP-server) som er i stand til å utføre mobil handel og levere eller bekrefte levering av tjenester eller varer til kundens innmatingsanordning 10. Selgerens tjenesteanordning 50 mottar kundeanmodningen om en MP3-fil og genererer en anmodning om betaling 52. Anmodningen om betaling 52 blir sendt til den konvergente kommunikasjonsplattform 100.
Den konvergente kommunikasjonsplattform 100 kontrollerer så at brukeren eller kunden er en autorisert bruker, at brukerens konto er blitt autorisert til å utføre denne type mobil handel og at kundekontoen inneholder nok penger eller midler til å gjennomføre tjenesten. Hvis brukerens konto har den korrekte autorisering og midler, genererer den konvergente kommunikasjonsplattform 100 en betalingsautorisering 102 og sender den tilbake til selgerens tjenesteanordning 50.
Selgeres tjenesteanordning 50 genererer så tjenesten eller varene, i dette tilfelle en MP3-fil, og sender MP3-filen til enten internett 22, det trådløse nettet 24, det offentlige telefonnettet 26, eller et hvilket som helst annet overføringsnett til kunde-nettet eller kundeinnmatingsanordningen 10.
I forskjellige utførelseseksempler kan de ovennevnte trinn automatiseres ved hjelp av systemet i større eller mindre grad. I et fullstendig automatisert miljø kan kundeinnmatingsanordningen 10 være en MP3-spiller forbundet med en trådløs anordning 23 til et trådløst nett 24, som automatisk sender enten autoriserings- eller rutings-data til selgerens tjenesteanordning 50. Alt en bruker må gjøre er derfor å åpne anordningen og velge at de skulle like å kjøpe en ny MP3-fil. Anordningen koples så automatisk til MP3-selgeren og viser en liste over sanger som brukeren kan kjøpe. Brukeren kan så ganske enkelt velge den sang han ønsker å kjøpe, og så begynne nedlasting av sangen ettersom alle andre individuelle oppgaver utføres i bakgrunnen.
I et annet utførelseseksempel kan ytterligere sikkerhet for autorisering av en anmodning om tjenester/varer og betaling benyttes ved bruk av et PIN, et smartkort, en magnetisk lese/skrive-anordning, en strekkode, en magnetstrimmel, et opphøyet alfanumerisk tegn eller eventuelle andre svindelforebyggende metoder som nå er kjent eller som kan bli kjent senere, eller som beskrevet i forbindelse med fig. 27.
Fig. 2 er et blokkskjema som viser et eksempel på et system for utnyttelse av en konvergent tjenesteanordning i mobilhandel (m)-handel eller elektronisk handel (e)-handel. Som vist på fig. 2 sender kundeinnmatingsanordningen 100 en anmodning om tjenester 105 til en selgers tjenesteanordning 110. Selgerens tjenesteanordning 110 sender så en anmodning om autorisering 115 til den konvergente tjenesteanordning 200. Den konvergente tjenesteanordning 200 sender så den gitte autorisering 125 til selgerens tjenesteanordning 110, og et varsel om betaling 135 til kundeinnmatingsanordningen 100. Den konvergente tjenesteanordning 200 sender så en betaling 150 til banken eller finansinstitusjonen til selgeren 140 og betaling 155 til transportøren 160.
I dette utførelseseksemplet anmoder kunden via sin innmatingsanordning 100 om å kjøpe billetter til en kino. Kunden kan åpne sin kundeanordning 100 eller aktivere den slik at en anmodning om tjenester 105 blir sendt til selgerens tjenesteanordning 110. Selgerens tjenesteanordning 110 kan være en hvilken som helst nåværende eller senere utviklet anordning for talegjenkjennelse eller siffertolkning, slik at brukeren kan velge de spesifiserte kinobilletter på den spesifiserte kino som han/hun ønsker å besøke. I tillegg kan selgerens tjenesteanordning 110 operere for et hvilket som helst kjent forretningsforetak, ikke bare en kino. Konsertbilletter eller andre artikler kan for eksempel kjøpes.
Etter at brukeren har innført anmodningen om tjenester 105 i selgerens tjenesteanordning 110, kan selgerens tjenesteanordning 110 generere en anmodning om autorisering 115. Anmodningen om autorisering 115 kan innbefatte slik informasjon som kundens identifikator (kunde-ID), prisen på tjenestene og selgerens identifikator (ID).
Når den konvergente tjenesteanordning 200 mottar anmodningen om autorisering 115, kan den kontrollere brukerens forhåndsbetalte konto som er tilknyttet brukerens ID, kontrollere at kontoen er autorisert for kjøp av kinobilletter og kontrollere at kundens konto har tilstrekkelig saldo. Hvis kontoen har stor nok saldo, blir kontoen autorisert for transaksjonen, og kontoen er en gyldig konto, slik at den konvergente tjenesteanordning kan sende en gitt autorisering 135 til selgerens tjenesteanordning 110 og et varsel om betaling 135 til kundens innmatingsanordning 100.
Kunden kan så hente kinobillettene fra kinoteatret eller på en hvilken som helst nåværende kjent måte eller fremtidige måter. Brukeren kan for eksempel innføre et identifikasjonsnummer i en automat og få automaten til å levere kinobillettene. Andre midler som er kjent på området, slik som Federal Express-levering, innføring av en autoriseringskode til en på forhånd eksisterende maskin, og å identifisere seg for en selgerrepresentant, kan brukes, som vel kjent på området.
I forskjellige utførelseseksempler behøver den konvergente tjenesteanordning 200 ikke å sende betalingen til selgerens tjenesteanordning 110. Den konvergente tjenesteanordning 200 kan sende betalingen til en bank eller finansinstitusjon tilknyttet selgeren 140. Alternativt kan den konvergente tjenesteanordning 200 ganske enkelt autorisere en overføring fra en bank eller finansinstitusjon tilknyttet kunden eller brukeren til banken eller finansinstitusjonen til selgeren 140. I tillegg kan det konvergente tjenestesystem 200 autorisere en betaling til transportøren 160 som så kan ut-føre leveringen.
Fig. 3 er et skjema som viser et eksempel på et system som muliggjør forhåndsbetalt vandring (roaming) med en konvergent kommunikasjonsplattform. På fig. 3 har området 310 kunde 1, kunde 2, telefonsvitsj A, tjenesteforvalter A og kontoforvalter A innenfor sitt område. En kontoforvalter A innbefatter kundekontiene for kundel, kunde 2 og kunde 3. Området 320 har kunde 3, kunde 4, telefonsvitsj B, tjenesteforvalter B og kontoforvalter B innenfor sitt område. Kontoforvalteren B innbefatter kundekontiene for kunde 4, kunde 5 og kunde 6. Området 330 har kunde 5, kunde 6, telefonsvitsj C, tjenesteforvalter C og kontoforvalter C. Området 310, området 320 og området 330 er forbundet med et offentlig telefonnett 300 og et regionnett (wide area network, WAN) 350.
Bruken av regionnettet 350 har en sikker passasje for kontoinformasjon for å muliggjøre forhåndsbetalt vandring. Hvis derfor alle kundene 1-6 er forhåndsbetalingskunder med konti i enten området 310 eller området 320, gjør utførelseseksemplet dem i stand til å bruke sine forhåndsbetalte konti uansett hvilket område de er i. Forskjellige eksempler vil bli beskrevet nedenfor.
Forhåndsbetalt vandring kan operere som illustrert i de følgende trinn. Kunde 1 i område 310 som forsøker å ringe kunde 2 i område 310, aktiverer sin anordning. Når anordningen til kunde 1 er aktivert, mottar telefonsvitsjen A signalet og videresender anmodningen om tjeneste til tjenesteforvalteren A. Tjenesteforvalteren A kontrollerer hos kontoforvalteren A at kunde 1 er en gyldig kunde og har en konto med saldo eller midler igjen på sin konto. Tjenesteforvalteren A kontrollerer også at kunde 2 er en gyldig kunde med en kontobalanse eller midler tilbake på sin konto for å motta telefonsamtalen. Tjenesteforvalteren A fullfører så oppkoplingen etter klarering av at all kontoinformasjon er korrekt.
Hvis imidlertid kunde 1 i område 310 ønsker å ringe kunde 3 i område 320, med eksisterende systemer, vil det være et problem. Kunde 1 vil aktivere sin anordning og taste inn identifikasjonsnummeret til kunde 3. Telefonsvitsjen A vil så motta anmodningen om tjeneste og videresende den til tjenesteforvalter A. Tjenesteforvalter A vil så kontrollere at kunde 1 og kunde 3 er gyldige kunder, og forsøke å sette opp kommunikasjonen. Tjenesteforvalteren A vil så virke gjennom telefonsvitsjen A og et offentlig telefonnett 300 for å forsøke å nå kunde 3. Ved telefonsvitsj B, siden kunden 3 ikke har en konto hos kontoforvalteren B, vil imidlertid telefonsvitsjen B ikke ha autorisering til å fullføre telefonanropet.
I mange utførelseseksempler av oppfinnelsen vil imidlertid telefonsvitsjen B videresende anmodningen om tjeneste til tjenesteforvalter B, som vil innse at kunde 3 ikke har noen konto i kontoforvalteren B, og derfor vil videresende anmodningen gjennom regionnettet 350 til tjenesteforvalter A. Tjenesteforvalter A vil så verifisere at kunde 3 er en gyldig kunde med midler tilbake på sin konto. Tjenesteforvalter A vil så autorisere anropet gjennom regionnettet 350 til tjenesteforvalteren B, som vil be telefonsvitsj B om å fullføre anropet. Hvis kunde 1 eller kunde 3 skulle gå tom for penger eller kontobalanse i løpet av telefonsamtalen, vil tjenesteforvalter A videresende et signal til enten telefonsvitsj A eller gjennom regionnettet 350 til tjenesteforvalter B om å avbryte telefonsamtalen.
I de eksisterende systemer for forhåndsbetalte telefontjenester, hvis kunde 1 ønsker å ta kontakt med kunde 4, vil kunde 1 aktivere sin brukeranordning for å kontakte kunde 4. Anmodningen om tjeneste vil bli mottatt av telefonsvitsj A, som så vil sende et signal til tjenesteforvalteren A for å autorisere tjenesten hvis kundens 1 forhåndsbetalte konto i kontoforvalteren A er kurant. Tjenesteforvalteren A vil så autorisere tjenesten ettersom den mottakende kunde 4 ikke var noen del av dens konto eller dens nett. Telefonsvitsjen A vil så videresende anmodningen om tjeneste gjennom det offentlige telefonnett 300 til telefonsvitsj B. Telefonsvitsj B vil så kontrollere at kunde 4 er innenfor dens område, og kontrollere hos serviceforvalteren B at kunde 4 har en konto. Tjenesteforvalter B som kontrollerer hos kontoforvalter B, vil verifisere at kunden 4 var en gyldig kontoinnehaver med en gjenværende balanse. Tjenesteforvalteren B vil så autorisere telefonsvitsjen B til å fullføre telefonanropet og så vil kunde 4 bli kontaktet.
Hvis imidlertid kunde 1 i område 310 ønsker å nå kunde 5 i område 330, vil det kjente system ikke virke av de grunner som er angitt i detalj ovenfor. Under forskjellige utførelseseksempler av foreliggende oppfinnelse vil imidlertid kunde 1 aktivere sin aksessanordning for å forsøke å ringe kunde 5. Telefonsvitsj A vil motta anmodningen om tjeneste og videresende en klareringsanmodning til tjenesteforvalter A. Tjenesteforvalter A vil så kontrollere hos kontoforvalteren A at kunde 1 er en gyldig kunde med gjenværende saldo, og at kunde 5 ikke er en kunde i dens nett. Telefonsvitsj A vil så videresende anmodningen om tjeneste gjennom det offentlige telefonnett til telefonsvitsj C, som har kunde 5 registrert i sitt område. Telefonsvitsj A vil så gå til tjenesteforvalter C som vil verifisere at kunde 5 ikke har konto hos kontoforvalter C. Tjenesteforvalter C vil så spørre kontoforvalter B gjennom regionnettet 350 om å autorisere kommunikasjonen. Når kommunikasjonen er autorisert av tjenesteforvalter B etter kontroll hos kontoforvalter B om at kunde 5 er en gyldig kunde med gjenværende saldo, vil telefonsvitsj C autorisere og fullføre telefonanropet mellom kundene.
Flere tilfeller kan oppsummeres på følgende måte:
Tilfelle 1: kunde 1 og kunde 4 er begge i hjemmenettene, kunde 1 ringer til
kunde 4.
1. Kunde 1 ringer kunde 4.
2. Siden kunde 1 er en forhåndsbetalingsabonnent, ruter telefonsvitsjen A signalet til tjenesteforvalter A.
3. Tjenesteforvalter A ruter signalet til kontoforvalter A.
4. Kontoforvalter A identifiserer at den personlige identifikasjonen til kunde 1 til-hører hjemmenettet, DNIS (MS/ISDN for kunde 4) tilhører ikke nett 310, og
anropet stammer fra nett 310.
5. Tjenesteforvalter A autentiserer kunde 1 og svarer til telefonsvitsj A.
6. Telefonsvitsj A sender anropet til telefonsvitsj B via det offentlige telefonnett (PSTN). 7. Telefonsvitsj B mottar anropet via PSTN-nettet og ruter et signal til tjenesteforvalter B ettersom kunde 4 har forhåndsbetalt. 8. Tjenesteforvalter B mottar signalet og autentiserer kunde 4 gjennom kontoforvalter B. 9. Tjenesteforvalter B sender en MAP-forespørsel og lokaliserer en betjenende telefonsvitsj B for kunde B.
10. Tjenesteforvalter B sender et søkesignal til telefonsvitsj B.
11. Telefonsvitsj B starter søking etter kunde 4.
12. Når kunde 4 besvarer anropstjenesten, starter tjenesteforvalter B takseringen for kunde 1.
Tilfelle 2: kunde 4 er i sitt hjemmenett og kunde 3 vandrer i kunde 4's hjemmenett,
og kunde 2 ringer til kunde 4.
1. Kunde 1 ringer til kunde 4.
2. Siden kunde 3 er en forhåndsbetalingsabonnent, ruter telefonsvitsj B et signal til tjenesteforvalter B.
3. Tjenesteforvalter B ruter det til tjenesteforvalter A.
4. Tjenesteforvalter A identifiserer at kunde 3 tilhører nett 310 og kunde 4 ikke til-hører nett 310.
5. Tjenesteforvalter A autentiserer kunde 3 og ruter et signal til telefonsvitsj B.
6. Telefonsvitsj B ruter et signal til tjenesteforvalter B ettersom kunde 4 er en forhåndsbetalingskunde. 7. Tjenesteforvalter B autentiserer kunde 4 som tilhørende nett 320 gjennom kontoforvalter B og sender en MAP-forespørsel for å lokalisere den betjenende
MSC for kunde 4.
8. Telefonsvitsj B svarer tilbake og blir instruert om å ringe.
9. Telefonsvitsj B starter søking etter kunde 4.
10. Når kunde 4 besvarer anropet, starter tjenesteforvalter B taksering for kunde 4, og tjenesteforvalter A starter taksering for kunde 3.
Tilfelle 3: kunde 5 og kunde 3 vandrer begge, og kunde 5 slår nummeret til
kunde 3.
1. Kunde 5 ringer kunde 3.
2. Etter verifisering av IMSI (eller en hvilken som helst slik unik identifikator) for kunde 5, bestemmer telefonsvitsj C at kunde 5 er en forhåndsbetalingsabonnent og ruter et signal til tjenesteforvalter C, som i sin tur ruter det til
tjenesteforvalter B.
3. Tjenesteforvalter B identifiserer kunde 5 som en vandrende abonnent og autentiserer denne ved forespørsel til kontoforvalter B. 4. Tjenesteforvalter B svarer tilbake til tjenesteforvalter C at kunde 5 er gyldig for ytterligere ruting.
5. Tjenesteforvalter C ruter autentiseringen til telefonsvitsj C.
6. Telefonsvitsj C ruter et signal via PSTN til telefonsvitsj A ettersom kunde 3 er en forhåndsbetalingsabonnent. 7. Tjenesteforvalter A autentiserer kunde 3 og sender en MAP-forespørsel for å lokalisere den betjenende MSC for kunde 3. 8. Tjenesteforvalter B svarer tilbake til tjenesteforvalter A, som videresender rutingsinformasjonen til telefonsvitsj C.
9. Telefonsvitsj C ruter anropet til den betjenende MSC, dvs. telefonsvitsj B.
10. Telefonsvitsj B starter søking etter kunde 3.
11. Når kunde 3 besvarer anropet, starter tjenesteforvalter A taksering for kunde 3, og tjenesteforvalter C starter taksering for kunde 6. 12. Når en av partene kopler ned samtalen, oppdaterer tjenesteforvalter C kontoforvalter B over regionnettet. Fig. 4 er et skjema som viser et utførelseseksempel av et universelt eller nett-uavhengig kundetjenestesystem. På fig. 4 aksesserer kunde 400 det offentlige telefonnett eller SS7-nettet 410 via vei 414 for å kontakte tjenesteforvalter (SM, service manager) 420. Tjenesteforvalteren 420 kan koples til kontoforvalter (AM, account manager) 442, kontoforvalter 444 eller kontoforvalter 446 gjennom regionnettet (WAN) 430. Tjenesteforvalter 420 kan så omrute kunde 400 ved å benytte vei 412 for å kople kunde 400 til en av operatør/selger 1 ved 462, operatør/selger 2 ved 464 eller opera-tør/selger 3 ved 466, som så kan aksessere den riktige kontoforvalter 442, 444 eller 446 for å gi kunden sin kundebehandlingstjeneste. Kontoforvalter 442 kan koples til kundeinformasjon i database 452 eller til kundeinformasjon i database 454 via regionnettet 430 eller kundeinformasjon i database 456 gjennom regionnettet 430. En kunde kan således ha et eneste telefonnummer å ringe til for kundebehandlingstjeneste, uansett kundens aktuelle oppholdssted. Fig. 5 er et skjema som viser at hver operatør benytter flere svitsjer i sitt hjem-land (geografisk hjemmeområde). Hver er tilsluttet en internasjonal vandringstjeneste basert på en sentralisert vandringsdatasenter-modell. Dette datasentret kan administreres enten av en eller flere telefonselskaper eller av en tredje part. Som vist på fig. 5
er operatør 1 532, operatør 2 534 og operatør 3 536 i land A 530 og er koplet til både WAN- eller TCP/IP-nett 520 og PSTN- & SS7-nettet 510. Operatør 4 546, operatør 5 544 og operatør 6 542 er videre i land B 540 og er koplet til både WAN- eller TCP/IP-nett 520 og PSTN og SS7-nett 510. Både WAN- eller TCP/IP-nett 520 og PSTN- og SS7-nett 510 er forbundet med det internasjonale vandringsdatasenter 500. Det internasjonale vandringssenter 500 kan inneholde servere 502, servere 504 og servere 506.
Hver av serverne 502, 504 og 506 kan operere som beskrevet ovenfor, til å autentisere kunder og rute anmodninger om tjeneste. Fig. 5 viser således at tjeneste-forvaltere og kontofon/altere som beskrevet ovenfor, kan være lokalisert på et hvilket som helst sted, ikke nødvendigvis innenfor anropsområdet til hjemmenettet. Nettet kan være GSM, CDMA, TDMA, AMPS, DAMPS eller en hvilken som helst annen nett-standard, innbefattende 2.5G og 3G. Det er mulig, men ikke nødvendig, å kjøre over flere SM/AM'er med en svitsj som ruter meldingene til en spesiell konvergent kommunikasjonsplattform. Svitsjen i eksemplet på det konvergente kommunikasjonsplattform-system er valgfri ved at hvis den er installert, kan adressene være lokale, til det internasjonale vandringsdatasenter. Ellers må adressene være internasjonale adresser.
Kundebehandling for vandrende kunder kan håndteres nøyaktig som nevnt ovenfor. Med store implementeringer av mange operatører over mange land, vil det imidlertid være upraktisk at hvert deltakende telefonselskap må sette opp anrops-styringsutstyr (svitsjforvalter-servere) ved alle sine svitsjesteder. Et kundekonto-forvaltnings- og forretningsunderstøttelsessystem (kontoforvalter) vil bli brukt av alle deltakende telefonselskaper til å administrere sine respektive abonnenter, skape/forvalte deres tariffplaner og å gi svitsjforvalteren eller -forvalterne IMSI/MSISDN-informasjon (unik abonnentidentifikator) om hvilken som skal identifisere og taksere hvert kundeanrop. Kontoforvalter kan eller behøver ikke være distribuert, avhengig av forretningssituasjonen.
Fig. 6 er et skjema som viser en sentralisert kontoforvalter 672. I et eksempel kan en kontoforvalter betjene flere telefonselskaper på en sentralisert måte. I et annet eksempel er det også rimelig å ha flere kontoforvaltere utplassert på en meget distribuert måte, der hver kontoforvalter betjener et spesielt telefonselskap, eller en hvilken som helst kombinasjon av dette. Som vist på fig. 6 kan en bruker 615 via radio eller en mobiltelefonmast 690, koples til mobiltelefonsvitsjen 678. Mobiltelefonsvitsjen 678 er koplet til PSTN 650 og svitsjforvalter 674. Svitsjforvalter 674 er via et nett koplet til en interaktiv talesvar-server (IVR-server, interactive voice response server) 686, en enkel meldingsserver (SMS) 684, en talepostserver (VMS) 682, en nettkontotjeneste-enhet (NAS) 680, en brannmur 676, en kontoforvalter (AM) 672 og et katalysatornav 640. IVR-serveren 686 er koplet til en hjelpefunksjon 688. AM 672 er koplet til database 670. Katalysatornavet 640 er koplet til aksess-server 628, IVR-server 632, elektroniske/mobile-handelsportalservere 630, en fullmaktsserver (proxy server) 626 og en sikkerhetsserver 624. Hjemme/kontor-brukere 610 er forbundet med internettet 600, som er koplet til PSTN 650 og stedsruter 620. Stedsruter 620 er koplet gjennom en brannmur 622 til en fullmaktsserver 626.
Det konvergente kommunikasjonssystem som er vist på fig. 6, kan således muliggjøre bruk av et internasjonalt vandringsdatasenter og romme forskjellige spesia-liserte servere for levering av tjenester. NAS-enhet 680 kan for eksempel være utformet som en avgiftsberegningsserver. Andre modifikasjoner og arrangementer for å romme forskjellige forretningspraksiser, kan inkorporeres uten å avvike fra oppfinnelsens ramme.
En svitsjforvalter kan således være sentralisert innenfor det internasjonale vandringsdatasenter (IRDC). Hvert deltakende nett kan være koplet til den sentrale
svitsjforvalter via en signaleringsforbindelse (SS7, osv.). Gitt at dette er mulig, vil hver deltakende nettoperatør behøve bare ett eksemplar av en tjenesteforvalter som kjøres ved IRDC for å administrere vedkommende operatørs vandringstjeneste. Det er mulig å utplassere flere tjenesteforvalter-eksemplarer på en eneste server, eller hvert eksemplar kan kjøres på sin egen utpekte server, eller en kombinasjon hvor en tjenesteforvaltningsserver virker som reserve for den annen.
Den SM som er tildelt hver operatør, vil kombinere aktiviteten til hver av tjenesteforvalterne som er beskrevet i avsnittet om vandring ovenfor. De enkelte MSCer i hver operatørs område vil identifisere oppringere, verifisere at deres hjemmenett er deltakende vandringspartnere, tildele dem deres MSRNN, osv. Når MSC avgir signalet til svitsjforvalteren, vil imidlertid styringstrafikken ikke bare passere svitsje-rommet, men i stedet passere det internasjonale SS7-nett til IRDC. SM (svitsjforvalteren) identifiserer opprinnelsespunktet for anropet, og den vil være i stand til å bestemme oppringerens hjemmelokalisering. SM vil så ta hånd om autentisering og taksering basert på opprinnelsessvitsjens nettkode (og opprinnelsescelle-ID, osv.) og de riktige avgiftstabellerfor MOC- og MTC-partene i samtalen.
Som beskrevet ovenfor vil avtale mellom operatører bli håndtert ved IRDC. Regelbasert deling av inntekt vil bli administrert, og sanntids-, daglige, ukentlige eller månedlige oppgjør for nettoinntekter vil bli utført. Eksemplet på den konvergente kommunikasjonsplattform håndterer anrop over heterogene nett på følgende måte: 1. SM & AM kan være konfigurert for flere nettyper; nettspesifikk informasjon for GSM, CDMA, TDMA, AMPS, osv.; signaleringsparameter-styringsinformasjon; spesifikk abonnentautentiseringsinformasjon; og kommunikasjonsprotokoll-informasjon. 2. Vandringsavtaler og regler blir satt opp for relasjonene mellom operatører av tjenester og kommersielle transaksjoner: per avgiftsenhet, tilleggsavgifter,
skatter, osv., oppgjørsformat, periode, kontoinformasjon, osv.
3. Abonnentoppsett: informasjon om tjenesteprofil, å innbefatte tilgjengelige nettyper for vandring, og abonnentidentikasjonsinformasjon for hver nett-type.
4. Anrop kan håndteres på følgende måte:
a. SM mottar det innkommende anropssignal.
b. Identifiserer nettypen.
c. Kontrollerer den informasjon som er nødvendig for vedkommende nett-type (dvs. den unike identifikator).
d. Kontrollerer om dette er et hjemme- eller besøksnettanrop.
e. Genererer et signal til hjemmenettet ved å benytte de riktige parametre
som kreves for vedkommende nettype.
f. Autentiserer brukeren/abonnenten tilbake til besøksnettet, bekrefter
tjenestegyldighet fra abonnenttjenesteprofil.
g. Takserer anropet fra besøksnettypen til brukerens konto (kontrollerer
saldo, bekrefter tilgjengelighet).
h. Hvis saldoen løper ut eller samtalen avsluttes: SM bekrefter avslutning,
sender posttransaksjonsinfo til hjemmenett-database og utfører oppgjør.
Ettersom forretningene i økende grad kan bli konkurransedyktige, forsøker mobiloperatører over hele verden å tilby flere merverditjenester, slik som data, faks, tekstmeldingsserver og mobilhandel, til sine kunder på deres hjemmenett. Disse merverditjenestene er også i økende grad blitt tilbudt etterbetalingsvandrere. Mobil-operatører vil like å tilby slike tjenester til sine forhåndsbetalende vandringsabonnenter også, men blir hindret av deres operatørspesifikke utstyr og systemer.
Fig. 7 er et skjema som viser et mobilnett 710 med et telefoniadministrasjons-system 720, et SMS-forvaltningssystem 722, et faks-forvaltningssystem 724, et datatjeneste-administrasjonssystem 726 og et annet "XYZ"-administrasjonssystem 728.
Noen av disse tjenestene som belastes kunder, kan være tidsbaserte og andre hendelsesbaserte. I forbindelse med virkelige utplasseringer kan det kanskje være mulig eller ikke mulig å styre autoriseringen/bruken av alle merverditjenestene over en signaleringsforbindelse. Telefontjenester kan styres over en signaleringsforbindelse; fortjenester slik som faks, SMS, mobilhandel, er det imidlertid kanskje ikke mulig å styre autoriseringen/bruken over signaleringsforbindelsen.
For at et telefonselskap eller andre kommunikasjonsoperatører skal tilby slike merverditjenester til de vandrende forhåndsbetalingsabonnenter, er det nødvendig at visse grensesnittanordninger blir oppbygd hvor bruksregistreringer blir samlet og prosessert med hyppige mellomrom (for eksempel hvert minutt eller hvert femte minutt). I betraktning av muligheten for transaksjoner av høy verdi, må imidlertid handelstjenester behandles i sann tid når transaksjonen finner sted.
Fig. 7 forklarer hvordan et utførelseseksempel på et konvergent kommunikasjonsplattform-system administrerer bruken av slike merverditjenester for vandrere som har forhåndsbetalt. Mobilnettet 710 kan aksessere et telefoniadministrasjons-system 720, et SMS-administrasjonssystem 722 og et faks-administrasjonssystem 724, et datatjeneste-administrasjonssystem 726 eller et XYZ-tjenesteadministrasjons-system 728. Telefoniadministrasjonen 720 kan aksessere telefontakseringen 740, som så kan forbindes med den konvergente kommunikasjonsplattformens forhåndsbetalte konto og saldo 750. SMS-administrasjonssystemet 722, fakstjenestesystemet 724, datatjeneste-administrasjonssystemet 726 og XYZ-tjenesteadministrasjonssystemet 728 kan koples til en ruter (gateway) 730, for derved å aksessere takseringen av de forbedrede datatjenester for SMS 742, taksering for forbedrede datatjenester for fax / faks 744, taksering for forbedrede datatjenester for data 746 og taksering 748 for de forbedrede datatjenester. Taksten for den forbedrede datatjeneste for SMS 742, taksten for de forbedrede datatjenester for faks 744, taksten for de forbedrede datatjenester 746 og taksten for de forbedrede datatjenester 748 kan forbindes med den konvergente kommunikasjonsplattformens forhåndsbetalte konto og saldo 750.
Før en merverditjeneste blir autorisert, foretar det eksterne system (dvs. det system som leverer merverditjenesten) en forespørsel gjennom ruteren 730 til eksemplet på det konvergente kommunikasjonsplattform-system. Detaljer ved dette eksemplet på et konvergent kommunikasjonsplattform-system er ikke vist på fig. 7, men beskrevet og/eller vist her. Basert på avgiftstabellene, den tilgjengelige saldo på den forhåndsbetalte konto og profilanalysen over tillatte tjenester, vil den konvergente kommunikasjonsplattform enten autorisere transaksjonen eller forkaste transaksjonen til det eksterne system via ruteren 730. For hver autorisert transaksjon leverer det eksterne system merverditjenesten til den vandrende forhåndsbetalingskunde. Ved slutten av bruken (eller ved slutten av et forutbestemt tidsrom) genererer det eksterne system en forbedret datataksering (EDR) som blir sendt til eksemplet på det konvergente kommunikasjonsplattform-system via ruteren 730 (gateway 730). Eksemplet på den konvergente kommunikasjonsplattform initierer en EDR-takseringsprosess for hver slik registrering og behandler EDR, og oppdaterer saldoinformasjonen om kundekontoen i databasen til den konvergente kommunikasjonsplattform.
Det er mulig at en forhåndsbetalingsvandrer kan benytte en eller flere merverditjenester selv om telefonbruken pågår. I det scenariet vil eksemplet på det konvergente kommunikasjonsplattform-systemet som forklart nærmere nedenfor, initiere en telefoni-takseringsprosess for telefonbruken. Den konvergente kommunikasjonsplattform behandler også samtidig EDR'ene ved å benytte EDR-takseringstabeller, EDR-regler og prosesser. For å unngå eventuelle gjensidige sperresituasjoner eller betydelige kontoovertrekk, sørger den konvergente kommunikasjonsplattform for prio-ritert tildeling av penger på den forhåndsbetalte kundekontoen for telefonitjenesten (for eksempel reservering av et beløp for en viss forutbestemt bruksperiode). I denne arkitekturen er det også mulig at på grunn av forsinket utsendelse av EDR-registreringer, kan saldoen på den vandrende brukers forhåndsbetalte konto gå under null. En slik situasjon blir unngått ved hjelp av forhåndstildeling av penger for merverditjenesten, når anmodningen om tjenesteautorisering ankommer.
Kunden ringer for eksempel fra området til et besøksnett. Eksemplet på den konvergente kommunikasjonsplattform håndterer samtaletakseringen på følgende måte: 1. Abonnenten ringer inn via: IVR, kiosk, internett/mobilt internett og eventuelt andre midler. 2. Den konvergente kommunikasjonsplattform validerer abonnenten enten ved hjelp av telefonnummer, et brukergitt PIN eller annen informasjon, eller ved validering som kan være automatisk eller manuell.
3. IVR lokaliserer kundens hjemmekonto.
4. IVR sender en forespørsel til kundens hjemmekonto for å tilveiebringe kontoinformasjon og tjenesteprofil. 5. IVR analyserer/behandler forespørselen: informasjonstjenesten blir håndtert av CCC, kontorelaterte tjenesteforespørsler genererer ytterligere forespørsler til hjemmenettet gjennom den konvergente kommunikasjonsplattform og påfyllingstjenesten blir håndtert, som beskrevet senere. 6. Kunden koples så til internett gjennom en WAP-tjeneste levert av besøksnettet og foretar et kjøp gjennom et salgssted. 7. For betalingsautorisering sender salgsstedet (eller en hvilken som helst annen tjenesteleverandør som ber om autorisering) en anmodning til den konvergente kommunikasjonsplattform ved hjemmenettet via et IP-nett (et offentlig eller privat nett). 8. Den konvergente kommunikasjonsplattform verifiserer så med hjemmenettets autoriseringsdatabase at kunden er autorisert for handelstransaksjonen (tjenesteprofil-validering) og fremskaffer posisjonen til kunden. 9. Den konvergente kommunikasjonsplattform sender så en anmodning til de konvergente kommunikasjonsplattform-komponentene som håndterer anropet ved besøksnettet (i en distribuert arkitektur kan disse komponentene være der hvor den besøkende er). 10. Den konvergente kommunikasjonsplattform sender en anmodning via en WAN-forbindelse, enten utpekt eller offentlig. I en sentralisert arkitektur kan disse komponentene være lokalt tilgjengelige. 11. Den konvergente kommunikasjonsplattform sender en autoriserings-anmodning via et nett. 12. Når autoriseringen går gjennom, vil de konvergente kommunikasjonsplattform-komponentene (enten i hjemmenettet eller ved besøksnettet, avhengig av hvilken type) sende den fullstendige transaksjon til hjemmenettets database for å sikre konsistent informasjon. 13. Basert på oppgjørsreglene utfører den konvergente kommunikasjonsplattform oppgjørene.
Autoriseringen kan være av to typer: Type 1: fortell meg hva som er den aktuelle saldoen til kunden; og blokker en pengesum "X" mot en handelstransaksjon (hvor "X" er den sum som selgeren anmoder om for autorisering pluss eventuelle tjenestegebyrer som påføres av hjemme/besøks-nettet basert på vandringsavtalen). I dette scenariet blir endelig autorisering håndtert av hjemmenettet selv. Type 2: håndter handelstransaksjonen og utled sum X hvis den blir autorisert ("X" er den sum som selgeren ber om for autorisering pluss eventuelle tjenesteavgifter påført av hjemme/besøks-nettet basert på vandringsavtalen). I dette scenariet er det handels-takseringsprosessen i besøksnettet som håndterer den fullstendige transaksjon og genererer oppgjørsregistreringer for ytterligere behandling.
I et annet eksempel har kunde A som er lokal i nettet X, vandret inn i nett Z. Han trenger å fylle på sin forhåndsbetalte konto. Eksemplet på den konvergente kommunikasjonsplattform kan muliggjøre dette på følgende måter:
1. Han kan kjøre en kupong fra operatør Z som er i markedet.
2. Han ringer nettets Z IVR-nummer.
3. IVR-systemet som leser hans MSISDN-nummer, bestemmer fra nettverkskoden at han ikke er en lokal abonnent. 4. Ved å ha nettets ID, foretar IVR en forespørsel over TCP/IP-nettet til LAUT-databasen i nettet X, hvor den bestemmer taletiden i kundens A hjemmenett for verdien av den kjøpte kupong.
5. LAUT-databasen blir så oppdatert på hjemmenettet
Denne prosessen sikrer at eventuelle penger vedrørende oppfylling alltid blir videresendt til hjemmenettet, selv om påfyllingen skjer i et av besøksnettene. Etter en vellykket vandringssamtale, kan inntekten som er fakturert av svitsjforvalteren for den konvergente kommunikasjonsplattform, deles mellom partnernettene i henhold til deres avtale om vandringstariff.
Vandringstariff-avtalen kan være lagret på ett av flere steder. Avtalen kan være lagret på den konvergente kommunikasjonsplattform, en separat faktureringsserver, eller et hvilket som helst annet sted som understøtter kontooppgjør. Reglene for opp-gjør kan videre befinne seg på den konvergente kommunikasjonsplattform, en separat faktureringsserver eller et hvilket som helst annet sted som er bestemt av partene i avtalen. Avtalene kan videre være mellom operatøren for den konvergente kommunikasjonsplattform, selskaper som handler med operatøren, kunden og regjeringer.
Ved utgangen av en vilkårlig tidsperiode, vanligvis en gang per dag, blir alle samtalebeskrivelsesregistreringer (CDR, Cali Description Records) for vandrings-samtaler overført til en oppgjørsprosess. Alternativt er det også mulig å skape bruksregistreringer i standardformater slik som TAP/Cyberfor videresending av informasjonen for oppgjørsformål. Dette kan være en del av hver operatørs bak-kontor eller håndteres via likviditetskontoret som kjøres på en applikasjonstjenesteleverandør-modell (ASP-modell). Eksemplet på den konvergente kommunikasjonsplattform kan sammenligne inntektene til hver operatør i forbindelse med sine partnere og organisere endelige nettooverføringer.
Disse transaksjonene kan lagres på eller utenfor den konvergente kommunikasjonsplattform, selv om den foretrukne utførelsesform er for bruk av en multidimen-sjonal database anordnet på den konvergente kommunikasjonsplattform. Hvis den foretrukne utførelsesform blir brukt, kan den multidimensjonale database lagre alle aspekter ved transaksjonen som en dimensjon, med forskjellige dimensjonsfast-settelser ved forskjellige tider i henhold til avtaler mellom partnernettene eller selgerne. Når tilgang er tilgjengelig, kan også kunden velge sin langdistanse-leverandør. I et slikt scenario vil eksemplet på den konvergente kommunikasjonsplattform gjøre opp den mobile, PSTN-terminerte samtale i besøksnettet med langdistanse-leverandøren istedenfor det mobile hjemmenettets langdistansenett. Det er også mulig at det hjemmebaserte mobile langdistansenett og det besøksbaserte mobile langdistansenett også kan være et hjemmebasert mobilnett og et besøksbasert mobilnett (dvs. for å dekke det globale, planlagte vandringssystem eller 3G-nettene). Det er også mulig at hjemmenettet og besøksnettet ikke er basert på GSM-teknologi, men i stedet kan være basert på en annen mobil teknologi.
Eksemplet på det konvergente kommunikasjonsplattform-system kan være forbundet med telefonselskapsnettet for å virke som et forhåndsbetalt vandringstjeneste-forvaltningssystem. I tillegg kan den konvergente kommunikasjonsplattform også være forbundet med et salgssystem for å administrere salgstransaksjoner. Oppgjørsregler for hver selger og nettverkspartnere er konfigurert på oppgjørssystemet på eksemplet på den konvergente kommunikasjonsplattform. Eksemplet på den konvergente kommunikasjonsplattform regulerer betalingstransaksjonen vedrørende de leverte tjenester eller handelstransaksjoner. Den konvergente kommunikasjonsplattform vil, basert på oppgjørsreglene, gjøre opp betalinger for alle involverte parter i tjenestene og/eller transaksjonene.
For ting, slik som mengderabatter, tjenestepakker, kan den konvergente kommunikasjonsplattform sende den riktige informasjon til datatabellene. Periodisk (for eksempel hvert minutt, hver dag, osv.) vil den konvergente kommunikasjonsplattform analysere slik informasjon og utføre oppgjør for slike tjenester.
Eksemplet på den konvergente kommunikasjonsplattform kan også være utplassert på et sentralt sted og forbundet med telefonselskapets nett, et selgernett og garantistens kundekontosystem. Eksemplet på den konvergente kommunikasjonsplattform muliggjør dynamisk vekselvirkning mellom en takseringsmotor eller tabell for tale, data og/eller hendelser og en kundes forhåndsbetalte konto. Ved valget av bruker (enten valgt hver gang eller systemet selv velger automatisk basert på brukerdefinerte kriterier), kan penger overføres fra en garantists kundekonto (en hvilken som helst type konto) til den konvergente kommunikasjonsplattforms forhåndsbetalte kundekonto.
Den forhåndsbetalte kundekontoen til den konvergente kommunikasjonsplattform blir brukt til betalingsbehandlingen for handels- og kommunikasjonstransaksjoner. I det tilfelle hvor kundens saldo løper ut på kontoen til den konvergente kommunikasjonsplattform, kan kontoen på den konvergente kommunikasjonsplattform fylles på etter ønske av kunden, slik som gjennom en garantists kundekonto i et bank-aksjefond eller lignende. Eksemplet på den konvergente kommunikasjonsplattform kan også muliggjøre samtidig behandling av handels-, kommunikasjons- og datatransak-sjoner på plattformens eneste forhåndsbetalte kundekonto. For hver transaksjon kan den konvergente kommunikasjonsplattform også utføre betalinger mellom alle involverte parter ved fremskaffelsen av tjenesten og/eller transaksjonen til kunden.
Hvis for eksempel John Smith har en bankkonto (BA001) og en konvergent kommunikasjonsplattform-konto (UP987), kan John Smith knytte sin bankkonto BA001 til sin forhåndsbetalte plattformkonto UP987. BA001 kan selvsagt være en sparekonto, en sjekkonto, en debetkonto, en kredittkonto eller en hvilken som helst annen type konto. Banken kan dessuten være en annen type entitet som garanterer midler til en kunde. Basert på de bankdefinerte kriterier avtaler banken å stå som garantist for et visst beløp for den konvergente kommunikasjonsplattform-kontogrense på vegne av John Smith. BA001 har for eksempel 1500 dollar på kundekontoen, og banken kan tillate at den konvergente kommunikasjonsplattformens kundekonto-grense er 100 dollar. Det aktuelle beløp på den konvergente kommunikasjonsplattform-konto kan variere, avhengig av flere faktorer, slik som John Smiths bankhistorie, det beløp som John Smith vil ha på den konvergente kommunikasjonsplattform-kontoen, eventuelle betingelser bestemt av telefonselskapet, selgerforbundet, lokale forskrifter, osv. John Smith kan bruke den forhåndsbetalte konvergente kommunikasjonsplattform-konto til å |betale for hvilke som helst mobile handels- eller kommunikasjonstjenester ved å benytte den konvergente kommunikasjonsplattform-konto, med en påfylling ved å benytte den tilknyttede kundebank- eller garantist-konto.
I det tilfelle hvor en bruker for eksempel går tom for penger på sin konvergente kommunikasjonsplattform-konto, kan han fylle på plattformkontoen fra BA001. Han kan videre skape underkonti av den konvergente kommunikasjonsplattform-konto (for eksempel UP001, UP657, osv.) og benytte dem til spesielle formål (for eksempel gaver til familien, med eller uten begrensninger på hvilke typer tjenester som er tillatt for disse, eller bruke en konto for direkte (online) og en annen for indirekte (offline) transaksjoner, osv.) Han kan også enten fastsette grenser for hver av sine underkonti (budsjettkontroll) eller benytte hovedkontogrensen (den konvergente kommunikasjonsplattform-konto) som en frittflytende grense for alle underkontiene til sammen. I alle fall er bankens garanti for kundens betaling begrenset til det beløp som er spesifisert for kontoen på den konvergente kommunikasjonsplattform.
BA001 behøver heller ikke være én enkelt konto, og grensen for UP987 behøver ikke å være en liten del av BA001. BA001 kan for eksempel være en virtuell konto som kombinerer hele den finansielle porteføljen til John Smith (for eksempel saldo på sparekonto, kredittbeløp, sjekkonto, aktuell markedsverdi på alle aksjefond, osv., som John Smith eier) og som kan tas i betraktning for å komme frem til et penge-messig beløp for BA001. Grensen på den konvergente kommunikasjonsplattform-konto kan også være høyere eller lavere eller lik beløpet på kontoen BA001.
Eksemplet på konvergent kommunikasjonsplattform muliggjør følgende scenarier: autorisering basert på bare en saldo på den konvergente kommunikasjonsplattform-konto, autorisering basert på en saldo på den konvergente kommunikasjonsplattform-konto hvor plattformkontoen integreres med kundekontoen til en autorisert garantist for sanntids- eller nesten sanntidstransaksjoner (kontroll av saldo og debet), og autorisering basert på saldoen på den konvergente kommunikasjonsplattform-konto hvor en annen institusjon garanterer for et fast beløp som er grunnlaget for autoriseringen i sann tid og saldoen i sann tid.
Det er mulig at det i visse situasjoner/markeder ikke inngår banker. I et slikt scenario kan en digital debetkonto utstedes av enten en selger eller en selger-sammenslutning eller av et telefonselskap eller en tredje part eller en kombinasjon av noen eller alle av disse entitetene. Den digitale debetkonto virker på meget lik måte som en bankkonto, bortsett fra at det er en annen part enn banken som utsteder kontoen. I dette scenariet kan utstederen av den digitale debetkonto være eller ikke være partner med en bank eller en finansinstitusjon.
Denne debetkontoen er forskjellig fra de elektroniske lommebøker som fortiden er tilgjengelige i markedet. Elektroniske lommebøker angår bare oppgaver vedrørende betaling. Lommebøker fokuserer hovedsakelig på det pengebeløp som er autorisert. Mens den digitale debetkonto ser på forskjellige andre aspekter vedrørende kunden (for eksempel om kunden er autorisert til å motta eller kjøpe tjenesten eller ikke). Elektroniske lommebøker dreier seg heller ikke om de oppgaver som angår kontinuer-lige, tidsbaserte avgiftsbelastninger (for eksempel telefonsamtaler, nedlasting av musikk belastet per minutt nedlasting, osv.). Den digitale debetkonto ser på disse oppgavene og muliggjør en riktig beregning av belastninger. Det vil si at elektroniske lommebøker ikke tar beslutninger om hvor meget penger som skal utledes fra den elektroniske lommebokkonto (de er avhengig av en tredje part for dette formål). Den digitale debetkonto som benyttes på den konvergente kommunikasjonsplattform, er i stand til å ta beslutninger om hvor meget penger som skal trekkes fra.
Eksemplet på den konvergente kommunikasjonsplattform kan være utplassert på et sentralt sted og koplet til telefonselskapets nett, enten som en tjenestenode eller en intelligent nettnode. Den konvergente kommunikasjonsplattform kan også være koplet til bankens kundekontosystem eller kundens kredittkortsystem eller en tredje parts system som tillater opplading, direkte eller indirekte, av kontoen på den konvergente kommunikasjonsplattform.
For kunden kan den konvergente kommunikasjonsplattform-konto være laget med to underkonti. En underkonto blir for eksempel brukt til direkte/sanntids-transaksjoner, som kan være for kommunikasjonstjenester eller handelstjenester eller begge deler. En annen underkonto blir brukt til ikke direkte-koplede (offline) transaksjoner. Hvis for eksempel John Smith har en konvergent kommunikasjonsplattform-konto på 50 dollar, kan han ha en konto A med 40 dollar, som vil bli brukt til direkte/sanntidstransaksjoner. John Smith haren annen underkonto B med 10 dollar. Disse 10 dollarene kan overføres til brukerens lese/skrive-lageranordning (enten en separat lese/skrive-lageranordning eller et telefoninstrument som virker som en lese/skrive-lageranordning, eller en hvilken som helst kombinasjon).
Når John Smith tar en telefonsamtale eller laster ned musikk på internett eller en lignende transaksjon som krever avgiftsberegning i sann tid, vil den konvergente kommunikasjonsplattform automatisk eller etter brukervalg (forhåndsvalgt eller ved tidspunktet for brukeranmodningen) benytte konto A til betaling. Når John Smith går til en butikk og vil kjøpe kaffe, cola eller en avis eller en eller flere slike artikler som ikke krever en direkte/sanntids-transaksjon, vil den konvergente kommunikasjonsplattform automatisk eller etter brukervalg (forhåndsvalgt eller ved tidspunktet for brukeranmodningen) bruke konto B. Hvis utstyret på salgsstedene muliggjør direkte tilkopling til den konvergente kommunikasjonsplattform, kan den konvergente kommunikasjonsplattform oppdatere (i begge retninger) informasjon vedrørende transaksjons/kunde-profilen.
Hvis saldoen på underkontoen B løper ut, kan den konvergente kommunikasjonsplattform tillate kunden (enten etter kundevalg eller ved hjelp av forutbestemte parametre) å overføre penger fra konto A til konto B. Hvis John Smith går tom for penger på konto B, kan han også gå til et salgssted (som har utstyr til å oppdatere saldoinformasjon på lese/skrive-lageranordningen) og fylle på sin konto. Hvis for eksempel John Smith går til en butikk og betaler 100 dollar, blir hans lese/skrive-lageranordning oppdatert for ytterligere 100 dollar, og neste gang han bruker et salgsutstyr som har direkte forbindelse med det konvergente kommunikasjonsplattform-system, vil den konvergente kommunikasjonsplattform automatisk oppdatere informasjonen og fordele de nye 100 dollar til hans forhåndsbetalte underkonti A og B etter John Smiths ønske.
Eksemplet på den konvergente kommunikasjonsplattform kan være forbundet med telefonselskapet, salgsnett, og bankenes kundekontosystem. Den konvergente kommunikasjonsplattform tillater kunden å definere forskjellige påfyllingskriterier basert på en konfigurerbar regelmotor for påfylling. En slik regelmotor tillater kunden å definere: forskjellige midler for påfylling som er tillatt for kunden (IVR, ATM, direkte overføring, osv.), forskjellige kriterier som sammen spesifiserer om det er på tide å fylle på kontoen eller ikke, og forskjellige kriterier som sammen bestemmer hvor meget penger som skal settes inn på kundekontoen. Det konvergente kommunikasjonsplattform-system kan dermed muliggjøre mange tjenester gjennom gateway'er eller andre midler for sine forhåndsbetalte kundekonti. Fig. 8 viser et eksempel på avgifter for kommunikasjonstjenester til bruk med det konvergente kommunikasjonsplattform-system og fremgangsmåten. Fig. 8 innbefatter en kolonne for type avgift, avgift bestemt av, beløp trukket fra, beløp skyldig til hjemmenettet og vandringsnettet, og grunnlaget for avgiftsbestemmelse. En handelstransaksjon kan for eksempel måtte betale for samtaler av mobil opprinnelse (MOC, mobile originated calls) i hjemmenettet via tjenesteleie og påfyllingsavgifter. Fig. 9 er et eksempel på en fremgangsmåte for påfylling av en forhåndsbetalt kundekonto for den konvergente kommunikasjonsplattform, samt system og fremgangsmåte. Fremgangsmåten som er vist på fig. 9 gjelder en automatisk påfylling. Andre typer påfylling er imidlertid innenfor rammen av oppfinnelsen, innbefattende ytterligere trinn for å bekrefte en påfylling med kunden, ytterligere trinn for å bekrefte en påfylling med en bank eller tredje part og ytterligere trinn vedrørende kontrolltid eller andre variabler. Fremgangsmåten begynner ved start 900 og fortsetter ved 910 for å bestemme om det er tilstrekkelig midler på kundens forhåndsbetalte konto.
I bestemmelsen, hvis det er tilstrekkelig midler på kontoen ved 910, blir det tatt en bestemmelse om verdien finnes eller ikke på brukerens forhåndsbetalte konto. Hvis det ikke er tilstrekkelig midler på kontoen, fortsetter fremgangsmåten ved 920 for å bestemme om påfyllingsregler er satt opp? Hvis det er tilstrekkelige midler på kontoen, fortsetter fremgangsmåten til trinn 912 for å autorisere tjeneste. Hvis fremgangsmåten går til autoriseringstjenestetrinnet 912, vil fremgangsmåten så fortsette til slutten 950.
Hvis fremgangsmåten fortsetter til "er påfyllingsregler satt opp?" trinn 920, blir det tatt en bestemmelse om kunden har autorisert forhåndsbetalt påfylling av sin konto eller ikke. Hvis kunden har autorisert automatisk påfylling av kontoen, fortsetter fremgangsmåten til trinnet "påfylling fra?" 930. Hvis kunden ikke har autorisert automatisk påfylling av kontoen, går fremgangsmåten til tjenesteavslag 922, idet fremgangsmåten så fortsetter til slutten 950.
Hvis fremgangsmåten fortsetter til "påfylling fra?" 930, blir det tatt en bestemmelse om å fylle på kontoen ved hjelp av en bank, kreditt, en investeringskonto, eller et forhåndsautorisert lån. Hvis "påfylling fra"-handlingen kommer fra en bank, fortsetter fremgangsmåten til E-handel med banken 932. Hvis påfyllingen skjer ved hjelp av en kreditt, fortsetter fremgangsmåten til E-handel med kredittselskapet 934. Hvis påfyllingen er fra en investeringskonto, fortsetter fremgangsmåten til E-handel med investeringsfirma 936. Hvis påfyllingsformen er ved hjelp av et forhåndsautorisert lån, fortsetter fremgangsmåten til E-handel med låneselskap 938. Uansett påfyllingsform, fortsetter fremgangsmåten til trinn 940. I trinn 940 fyller den konvergente kommunikasjonsplattform på kundens forhåndsbetalte konto og returnerer for å bestemme om tilstrekkelige midler er på kundens forhåndsbetalte konto 910.
Som diskutert ovenfor, kan brukeren fylle på sin konto fra en hvilken som helst av flere kilder. Påfyllingen kan styres av brukervalg eller regler. En bruker kan for eksempel på forhånd bestemme at de første 5000 dollar av en påfylling skal komme fra en investeringskonto, og at belastninger deretter skal komme fra en kredittkonto. I tillegg kan en bruker autorisere påfylling basert på forskjellige andre variabler, slik som tid, kontosaldo, sum som skal påfylles og andre faktorer. For hver påfyllingskonto er det satt opp en avtale mellom operatøren av den konvergente kommunikasjonsplattform og påfyllingsentiteten, og påfyllingsentiteten og kunden for både plattformen og påfyllingsentiteten. Avtalen kan gi detaljer slik som påfyllingshastigheten, tidsrammer for oppgjør, varsling fra påfyllingsentiteten om utilstrekkelige midler, varsel om kontosaldo, og andre faktorer som er kjente på området. Dataene vedrørende avtalen, reglene og prosedyrene for påfyllingskontoen vil fortrinnsvis være lagret i konto-og/eller tjenesteforvalteren på den konvergente kommunikasjonsplattform.
Fig. 10 viser et relasjonseksempel mellom forhandleren 1010, salgsagenten 1020, brukeren 1030, den eksterne transportør 1050, selskaps- og hjemmekontoer 1040, VMS-abonnent 1060 og den konvergente tjenesteforvalter 1000. En bruker 1030 kan plassere en bestilling eller bestille kansellering og innføre et PIN i den konvergerte tjenesteforvalter 1000. Brukeren 1030 kan så motta tjenester i retur. Som bytte for de tjenester som brukeren 1030 mottar, kan den konvergente tjenesteforvalter 1000 initialisere en betaling fra felles- og hjemmekontiene 1040. Hvis brukeren 1030 ønsker å fylle på sin konto, kan han gå til salgsagenten 1020. Salgsagenten 1020 kan så fylle på kontoen i den konvergente tjenesteforvalter 1000 og til gjengjeld motta en kommisjon. Den konvergente tjenesteforvalter kan så videresende kontopåfyllingene til felles-og hjemmekontiene 1040. Med den konto som er påfylt, kan brukeren så autorisere en betaling til forhandler 1010 til gjengjeld fortjenestene, som brukeren kan motta. I tillegg kan den eksterne transportør 1050 motta betaling eller autorisering fortjenester, slik som videresendingstjenester, så vel som forlik om virtuelle telefonnumre og oppdatering av takseringsinformasjon til den konvergente tjenesteforvalter 1000. Alternativt kan VMS-abonnenten 1060 motta forespørsler eller betalinger for å opprettholde talepostinformasjon, regninger og brev, svar på forespørsler, velkomstbrev og betalingspurringer.
Fig. 11 er et utførelseseksempel på et konvergent system for å muliggjøre mobilhandel i et vandringsnett. En brukeranordning 1130 er koplet til vandringsnettet 1120. Vandringsnettet 1120 er forbundet med den konvergente tjenesteleverandør 1150. Den konvergente tjenesteleverandør 1150 kan være koplet til internett 1100 og den konvergente tjenesteleverandør 1140. Selgere 1160 og 1170 kan være koplet til internett 1100. Hjemmenettet 1110 kan så også være koplet til den konvergente tjenesteleverandør 1140. De konvergente tjenesteleverandører 1150 og 1140 er begge organisasjoner som opprettholder et konvergent kommunikasjonssystem med varierende tjenesteområder.
Under drift kan tjenesteanordningen 1130, mens den er i vandringsnettet 1120, koples til en konvergent tjenesteleverandør 1150 for å initialisere en mobil handelstransaksjon. Den konvergente tjenesteleverandør 1150 kan så videresende anmodningen om den mobile handelstransaksjon til den konvergente tjenesteleverandør 1140 i hjemmenettet 1110. Den konvergente tjenesteleverandør 1150 kan også være koplet til internett 1100 for å kunne ta kontakt med selger 1160 og selger 1170 for å sørge for levering av tjenester til brukeranordningen 1130 eller bekreftelse på levering av varer til brukeranordningen 1130.
Fig. 12 viser et eksempel på en forhåndsbetalt vandringstjeneste-aktivitet i samsvar med utførelseseksempler på foreliggende oppfinnelse. Den mobile forhånds-betalingstelefonkunde Tim på sted 1200 hvis hjemmenett 1212 er i Italia 1210, reiser til Spania 1220, som har et vandringsnett 1222. Mens Tim er i Spania 1201, ønsker han å fylle på sin forhåndsbetalte kundekonto. Tim ved sted 1201, tar så kontakt med vandringsnettet 1222, som oppretter en forbindelse 1224 til SS7 1240, som oppretter en forbindelse 1242 til en konvergent tjenesteforvalter 1250. Den konvergente tjenesteforvalter 1250 sender så via en forbindelse 1244, SS7 1240 og en forbindelse 1226 Tims aktuelle kontoinformasjon til vandringsnettet 1222. Vandringsnettet 1222 kan så ta kontakt med banken 1232 i Frankrike 1230 for å fylle på Tims forhåndsbetalte kundekonto i den konvergente tjenesteforvalter 1250.
Fig. 13 viser et utførelseseksempel på informasjonsdataene og strukturen til en brukers konto for en konvergent kommunikasjonsplattform. Kundekontoen kan innbefatte, men er ikke begrenset til, hjemmetabell 1300, anmodningsinformasjonstabeller 1310 og en autoriseringsinformasjonstabell 1320. Hjemmeinformasjonstabellen 1300 kan innbefatte, men er ikke begrenset til, det hjemlige hovednummer, tittelen, fornavnet, mellomnavnet, etternavnet, adressen, telefonnummeret, faks, e-post, bemerkninger, profesjon, siste betalingsdato, avsatt beløp, kredittgrense, gjenværende kredittgrense, aktuell saldo, siste dato for betaling, aktive kort, status og status-endringsdato. Autoriseringsinformasjonstabellen 1320 kan innbefatte verdi, karantene, gyldighetsbeskrivelse, brukt konto, godkjent status, siste godkjente sekvens, topologi-kode og overført til ROC. Anmodningsinformasjonstabellen 1310 kan innbefatte, men er ikke begrenset til, eksternkode, startstreng, dekning, PIN-kode, innledende aktiveringskode og status. Fig. 14 viser et utførelseseksempel på en kundekonto forbundet med et tale-læringssystem for en konvergent kommunikasjonsplattform. Kundekontoen kan innbefatte, men er ikke begrenset til, kundetabell 1400, talepostboks 1410. Kundetabellen 1400 kan innbefatte, men er ikke begrenset til, passordet, tittelen, fornavnet, mellomnavnet, etternavnet, adressen, telefonnummeret, faks, e-poststatus, statusendrings-dato, profil-ID, profesjon, språk-ID, aktivert dato, siste regningsdato, aktuell saldo, siste betalingsdato, bemerkninger og velkomstmeldinger. Talepostboksen 1410 kan innbefatte, men er ikke begrenset til, operatørnavn-status og importerte boksnumre som skal aksepteres. En talepostsystem-profil kan tilføyes og vil innbefatte beskrivelse, en fullstendig meldingslenke, en individuell meldingslenke, meldingsalder, avgift, siste avgift, rentetype, forhåndsgebyr, gyldighetsdato, gyldig fra dato, innskudd og total-melding. Fig. 15 viser et utførelseseksempel på et interaktivt talesvarsystem som kan benyttes på en konvergent kommunikasjonsplattform. Fremgangsmåten på fig. 15 begynner ved start 1500. Fremgangsmåten fortsetter så med å avspille oppfordring nr. 1 til bruker 1510. Etter at oppfordringsnummeret 1 er avspilt til brukeren i 1510, fortsetter fremgangsmåten med å vente på et nummer 1512. Hvis et siffer blir innført, følger fremgangsmåten vedkommende nummer til kontrollnummer 1520. Hvis kontrollnummeret 1520 er et gyldig nummer, fortsetter fremgangsmåten til 1530. Hvis nummeret er et ugyldig nummer, returnerer fremgangsmåten til 1514.
11514 blir det tatt en bestemmelse om det maksimale gjenforsøk er blitt nådd. Hvis det maksimale gjenforsøk ikke er blitt nådd, fortsetter fremgangsmåten å avspille oppfordring 1 til bruker 1510. Hvis det maksimale antall forsøk er blitt nådd, fortsetter fremgangsmåten å avspille oppfordringen 4 1560.
I avspillingsoppfordringen 2 til bruker 1530 blir det tatt en bestemmelse om den mottok et nummer eller nådde slutten av en avspilling. Hvis en avspillingsoppfordring til bruker 1530 når slutten av avspillingen, går fremgangsmåten tilbake for å vente på nummer 1532. Hvis avspillingsoppfordringen til bruker 1530 fremskaffet et nummer, fortsetter fremgangsmåten å avspille oppfordring 3 til bruker 1540. I påvente av nummeret 1532 er det en ventetid inntil den får et nummer. Når et nummer er mottatt, går fremgangsmåten til avspillingsoppfordringen 3 til bruker 1540.
Avspillingsoppfordringen 3 til bruker 1540 bestemmer så om den nådde slutten av avspillingen eller om den mottok nummeret. Hvis avspillingsoppfordringen 3 til bruker 1540 når slutten av avspillingen, går fremgangsmåten til å vente på nummer 1542. Hvis avspillingsoppfordringen 3 til bruker 1540 mottar et nummer, fortsetter den å kontrollere nummer 1550. I kontrollnummeret 1550, hvis nummeret er et gyldig nummer, går fremgangsmåten til registerkortkode og aktuelt nummer i database 1570. Ellers går fremgangsmåten til avspillingsoppfordring 4 1560.
Fig. 16 er et flytskjema som viser bruken av en forhåndsbetalt konto på en konvergent kommunikasjonsplattform for oppgjør mellom flere parter. Oppfordring 1 kan oppfordre den konvergente kommunikasjonsplattform til å velge en partstype basert på tidligere opprettede regler. Partstypen kan så innføres i valget av partstypen 1610. En valgt partstype 1610 kan være en hvilken som helst av en selskaps-, hjemme-, forhandler- eller salgsagent-type. Hvis partstypen er bedriftsbasert, går fremgangsmåten videre for å velge divisjonen 1612. Hvis partstypen er en hjemmebasert type, fortsetter fremgangsmåten med å velge hjemmet 1614. Hvis partstypen er en forhandler, fortsetter fremgangsmåten med å velge forhandleren 1616. Hvis partstypen er en salgsagent, fortsetter fremgangsmåten med å velge en salgsagent 1618.
Avhengig av den valgte partstype, blir den riktige ID-type sendt for å se på utestående beløp for partskodene og betalinger av forfalte beløp 1600. Derved kan en bruker fylle på eller opprette en forhåndsbetalt konto. Den relevante informasjon blir lagret som utestående beløp for partens koder og betalinger av de forfalte beløp 1600 på den konvergente kommunikasjonsplattform.
Betalingsanmodningen med oppfordring 2, oppfordrer den konvergente kommunikasjonsplattform til å velge tidligere definerte regler. I valget av betalingsmetode 1620 blir en betalingsmetode valgt blant kredittkort, bank og kontanter. Hvis kredittkort blir valgt, går fremgangsmåten videre for å innføre kredittkortinformasjon 1640. Hvis bank blir valgt, går fremgangsmåten videre for å innføre bankinformasjon 1622. Fremgangsmåten går så videre for å se på utestående beløp og partskoder og betaling av de forfalte beløp 1600.
På bakgrunn av utestående beløp for partskodene og betaling av det forfalte beløp 1600, fortsetter fremgangsmåten så til en av am_di_info 1630, am_home_info 1632, dms_dealer 1634, dms_sales_agent 1636, pp_instr 1638, pp_credit_card 1640, pp_paid_trans_main 1642, pp_outstand_payment 1644, for derved å gjøre opp fler-partstransaksjonen.
Fig. 17 er et utførelseseksempel på en halvautomatisk fremgangsmåte for påfylling av en forhåndsbetalt konto, og oppgjørsregler for oppgjør mellom flere parter som kan inntreffe i en konvergent kommunikasjonsanordning. Fremgangsmåten starter ved start 1700 og fortsetter til enten velg partstype 1701 og kod eller se på listen over O/S-betalinger 1710.
Hvis fremgangsmåten går til betraktning av listen over utestående og oppgjørs-betaling (O/S, outstanding and settling) 1710, så vil fremgangsmåten bestemme en første eller aktuell betaling. Fremgangsmåten fortsetter så med å velge betalingsmetode 1720. Ved valg av betalingsmetode 1720 vil fremgangsmåten så bestemme betalingstype basert på tidligere definerte regler. Hvis regelen indikerte kontanter, går fremgangsmåten videre til kontanter 1722. Hvis reglene indikerte en sjekk, går fremgangsmåten videre til sjekk 1724. Hvis regelen indikerte et kredittkort, går fremgangsmåten videre til kredittkort 1726.
Hvis regelen indikerte sjekk 1724, fortsetter fremgangsmåten så med å innsette bank 1725. Hvis regelen indikerte kredittkort 1726, går fremgangsmåten videre for å innsette kredittkort-info 1727. Fremgangsmåten fortsetter så med å sette inn en transaksjonsregistrering 1730, etter innføring av passende informasjon som tidligere er lagret på den konvergente kommunikasjonsplattform. Fremgangsmåten fortsetter så til slutten 1740.
Hvis regelen indikerte en partstype og -kode, fortsetter regelen så til trinn 1712. Ved den valgte partstype og -kode bestemmer fremgangsmåten så en partstype som behøver en kontooppdatering. Hvis regelen indikerte et selskap, beveger fremgangsmåten seg til selskapsoppdatering 1702. Hvis regelen indikerte hjem, fortsetter fremgangsmåten til hjemmeoppdatering 1704. Hvis regelen indikerte forhandlere, fortsetter fremgangsmåten med å oppdatere forhandler 1706. Hvis regelen indikerte salgsagent, fortsetter fremgangsmåten til oppdatering av salgsagenter 1708. Fremgangsmåten fortsetter så til slutten 1740. Fig. 18 viser et eksempel på en fremgangsmåte for å generere en rapport for anvendelse med en konvergent kommunikasjonsplattform og et konvergent kommunikasjonssystem. Fremgangsmåten kan begynne ved en hvilken som helst informasjonssats 1820, trykking av bestillingsinformasjon 1810, utvalgsinformasjon 1830, trykt selgerinformasjon 1860 eller alle korttyper 1850. Fremgangsmåten fortsetter så til generering av rapport 1800, og fortsetter til forhåndsbetraktning av rapport 1840. Hvis fremgangsmåten starter ved satsinformasjons 1820, vil satsnummerets enhetsgebyr og satsnummeret måtte innføres fra en lagringsanordning på den konvergente kommunikasjonsplattform. Hvis fremgangsmåten starter ved trykt bestillingsinformasjon 1810, må PO-nummer, PO-status og PO-dato innføres. Hvis fremgangsmåten starter ved andelsinformasjon 1830, vil andelsnummeret og andelsstørrelsen måtte innføres. Hvis fremgangsmåten starter ved alle korttyper 1850, vil en beskrivelse av kredittkort-typen måtte innføres. Hvis fremgangsmåten starter ved skriving av selgerinformasjon 1860, vil selgerens navn måtte innføres. Fig. 19 er et eksempel på dataoverføringen på en konvergent kommunikasjonsplattform. Som vist på fig. 19 kan en brukeranordning 1900 inneholde en datalagrings-struktur slik som 1905, som inneholder sluttbrukerinformasjon, kontoinformasjon for sluttbrukeren, telekommunikasjonsinformasjon, informasjon om oppfangning av regnskapsdata og informasjon om brukerdata. Brukerdata-strukturen 1905 kan også inneholde en samtalestyrings- og faktureringsstyrings- og datainnføringsfunksjon for en kommunikasjonsanordning, som kan kommunisere med kommunikasjonsanordningen for betaling, og oppgjørsbehandling og kundebehandling 1940. Internett ISP 1910 kan inneholde en datastruktur 1915 som igjen inneholder informasjon om sluttbrukeren, sluttbrukerens konto, ISP, faktureringsdata-innfangningen og inn fangningen av brukerdata vedrørende annonsering og kommisjoner. Datastrukturen 1915 kan også inneholde en modul for rekkeviddestyring, bruksstyring og datainnfangning for kommunikasjonsanordningen som kommuniserer med kommunikasjonsanordningen eller betalings- eller oppgjørsbehandling og kundebehandling 1940. En portal 1920 kan inneholde en datastruktur 1925. Datastrukturen 1925 kan inneholde sluttbrukerinformasjon, kontotilgangsinformasjon, portalinformasjon og konto-forvaltningsinformasjon. Datastrukturen 1925 kan også inneholde en modul for kommunikasjon, anordningsbetaling, forsikring og datainnfangning som kan kommunisere med kommunikasjonsanordningen for betalings- og oppgjørsbehandling og kundebehandling 1940. Selgeren 1930 kan inneholde en datastruktur 1935. Datastrukturen 1935 kan inneholde informasjon om sluttbrukeren, påfylling av kortet på en klargjort konto, selger- og faktureringsdatainnfangning, og innfangning av brukerdata. Datastrukturen 1935 kan også inneholde en modul for kommunikasjon, anordningsbetaling, forsikring og datainnfangning som kommuniserer med kommunikasjonsanordningen for betalings- og oppgjørsbehandling i kundebehandlingsanordningen 1940. Kommunikasjonsanordningen for betalings- og oppgjørsbehandling og kundebehandling 1940 kan kommunisere med datainnsamlings/kunderelasjons-administrasjonen (CRM) 1950.
Fig. 20A er et eksempel på en fremgangsmåte og et system for oppgjør mellom flere parter i sann tid for tjenester og transaksjoner foretatt av en kunde med en konto-type som er forhåndsbetalt og påfyllbar, ved å benytte en konvergent kommunikasjonsplattform. Eksemplet på fremgangsmåten begynner med sluttbrukere 2000 som initialiserer fremgangsmåten. Fremgangsmåten fortsetter så til forhåndsbetalt påfylling 2010.
I den forhåndsbetalte påfylling 2010 bestemmer en bruker på forhånd, automatisk eller ved tidspunktet for anmodning om en tjeneste og/eller en transaksjon, hvilke andre av sine konti som ikke ligger på plattformen, og hvilke summer som skal relateres til hver av disse kontiene, som skal påfylles sin forhåndsbetalte plattformkonto. Fremgangsmåten fortsetter så til de finansielle oppgjør 2050 i sann tid.
Det finansielle oppgjør 2050 i sann tid mottar anmodninger for betaling fra telefonselskap 2060, ISP'er 2052, portal 2064, selgere 2066, og banken 2068. Selgeradministrasjonen 2070 er midlet for å oppnå det finansielle oppgjør 2050 direkte og i sann tid. Selgeradministrasjonen 2070 spesifiserer om oppgjør for de flere parter som inngår, skal være umiddelbar, forsinket, noe som innebærer ytterligere autoriseringer, eller hvilke som helst andre egenskaper som også er kjent på området. Det er derfor utførelseseksempler på den konvergente kommunikasjonsplattform som kan gjøre opp for transaksjoner ved å trekke inn flere parter over flere tidsrammer.
Fig. 20B er et annet utførelseseksempel på en fremgangsmåte og et system for oppgjør i sann tid mellom flere parter for tjenester og/eller transaksjoner foretatt av en kunde med en forhåndsbetalt, påfyllingsbar konto ved å benytte en konvergent kommunikasjonsplattform. En fremgangsmåte begynner med sluttbrukere 2000 som initialiserer fremgangsmåten. Fremgangsmåten fortsetter så til forhåndsbetalt påfylling 2010.
Ved forhåndsbetalt påfylling 2010 bestemmer en bruker på forhånd, automatisk eller ved tidspunktet for etterspørsel av en tjeneste og/eller transaksjoner, hvilke andre av sine konti som ikke ligger på plattformen, og hvilke beløp som skal relateres til hver av disse kontiene, som skal påfylles sin forhåndsbetalte plattformkonto. Fremgangsmåten fortsetter så til banken 2020. I banken 2020 blir midler overført fra banken til det finansielle oppgjør 2050 i sann tid.
Den finansielle, sanntidsoppgjørsenhet 2050 mottar anmodninger om betaling fra telefonselskapet 2060, ISP'er 2062, portal 2064 og selgere 2066. Selgeradministrasjonen 2070 er midlet for å oppnå det finansielle, i sann tid og direkte, oppgjør 2050. Selgeradministrasjonen 2070 spesifiserer om oppgjør for de flere parter som er involvert, skal være øyeblikkelig, forsinket, innebære ytterligere autoriseringer eller eventuelle andre trekk som er velkjente på området. Det er således utførelses-eksempler på den konvergente kommunikasjonsplattform som kan gjøre opp for transaksjoner som involverer flere parter over flere tidsrammer. Fig. 21 er et utførelseseksempel på en kontoadministrasjonsanordning 2100 for bruk på den konvergente kommunikasjonsplattform. Kontoadministrasjonsanordningen 2100 kan ha en abonnentkonto-forvalter 2160, en SIM-leverandør 2170, en SIM-distributør 2180, en SIM-bestillingsenhet 2190, en oppgjørsenhet2150, en kupong-leverandør 2140, en kupongdistributør 2130, en kupongbestillingsenhet2120 og en PIN-generator2110. Fig. 22 er et blokkskjema over et eksempel på en svitsjforvalter 2200 for bruk på den konvergente kommunikasjonsplattform. Svitsjforvalteren 2200 kan inneholde taksering 2230, samtalestyring 2220 og saldo 2210. Takseringen 2230 kan være i sann tid eller foregå ved hjelp av forskjellige inkrementer som takserer prisen på en etterspurt tjeneste. Taksering kan også bestemme ekstragebyrene eller de risiko som inngår i en handelstransaksjon. Samtalestyringen 2220 kan holde rede på alle samtidige belastninger på en brukers konto og sende signaler til enten brukeren eller forskjellige tredje parter for å autorisere ytterligere beløp for påfylling av brukerkontoen, eller autorisering om å utføre påfylling eller avslutning av en samtale. Saldokontroll 2210 kan holde rede på den umiddelbare saldoen på en brukers konto, eller tilveiebringe varsler når en brukers konto når et forutbestemt nivå. Fig. 23 er et blokkskjema som viser et eksempel på et konvergent kommunikasjonssystem fra en bedrift til en annen bedrift (B2B). Som vist på fig. 23 er selskap 1 2330, selskap 2 2332, gjennom selskap x 2339 forbundet via internett 2310 med det konvergente kommunikasjonssystem 2300. I tillegg er selskap A 2340, en regjering 2342, en bedrift A 2344, en bedrift B 2346, en selger 2348 og en leverandør 2349 forbundet via internett 2320 med det konvergente kommunikasjonssystem 2300. Det konvergente kommunikasjonssystem 2300 kan være tilkoplet eller integrert med en virtuell konto 2302, en vanlig konto 2304 og et banksystem 2306. Et selskap, slik som selskap 1 2330, behøver derfor bare en forbindelse til internett 2310 for å utføre transaksjoner fra bedrift til bedrift med et hvilket som helst av selskapene A 2340 til leverandør 2349. Fig. 24 er et blokkskjema som viser et annet eksempel på et konvergent kommunikasjonssystem fra bedrift til bedrift. På fig. 24 er brukere 2400 forbundet via telefon 2410, ATM 2412, WEB 2414, WAP 2416 og agenter 2418 gjennom bank 2420. Banken 2420 er forbundet med B2B gateway 2434. B2B gateway 2434 er en del av det konvergente kommunikasjonssystem 2430 som også inneholder den konvergente kommunikasjonsanordning 2432. Den konvergente kommunikasjonsanordning 2432 er forbundet med telefonselskapet eller et annet faktureringssystem 2440. Brukerne 2400 kan således avsette eller overføre midler ved å benytte en telefon 2410, en minibank (ATM) 2412, nettet 2414 eller WAP 2416 eller en agent 2418 for å overføre midler mellom konti og/eller utpeke en transaksjon fra bedrift til bedrift ved å benytte banken 2420 til et telefonselskap eller et bedriftsfaktureringssystem 2440. I tillegg, som vist på fig. 24, behøver banken 2420 bare å ha en forbindelse til det konvergente kommunikasjonssystem 2430 for å utføre handel fra bedrift til bedrift med mange forskjellige entiteter. Fig. 25 er et blokkskjema over et eksempel på et system for påfylling av en forhåndsbetalt kundekonto på en konvergent kommunikasjonsplattform. På fig. 25 er forskjellige anordninger, slik som ATM 2506, ATM 2504, ATM 2502, ATM 2508, investe-
ringsfirma 2530, bank 2 2520 og bank 1 2510, koplet til X.25-nettet 2500. X.25-nettet 2500 er forbundet med en ruter 2549 som en del av den konvergente kommunikasjonsplattform 2540. Den konvergente kommunikasjonsplattform 2540 kan inneholde en brannmur 2544, en kontoforvalter 2546, en kundebehandlingsenhet 2548 og en bank 3 2542. Kundeforvalteren 2546 kan være koplet til en database 2547. En kundebruker kan dermed aksessere sin konto på den konvergente kommunikasjonsplattform 2540 fra en fjerntliggende anordning, slik som ATM 2506.
Fig. 26 er et blokkskjema over et eksempel på et system for påfylling av en forhåndsbetalt kundekonto ved bruk av et interaktivt talesvarsystem på en konvergent kommunikasjonsplattform. Som vist på fig. 26 kan stormaskinen 2610 i bank 1 være forbundet via X.25-nettet 2600 med en hvilken som helst av ATM'ene 2602 til 2608, telefonselskap 2 2640, telefonselskap 1 2630 og stormaskinen i bank 2 2620. Den konvergente kommunikasjonsplattform 2650 kan også være koplet til X.25-nettet 2600. Den konvergente kommunikasjonsplattform 2650 kan inneholde en ruter 2660, en brannmur 2658, en kontoforvalter 2656, en database 2657, et interaktivt talesvarsystem 2654 og en operatør 2652.
En bruker som er koplet til den konvergente kommunikasjonsplattform 2650 gjennom telefonselskap 1 2630 kan dermed få sin anmodning rutet gjennom X.25-nettet 2600 til ruteren 2660. Ruteren 2660 kan autentisere brukeren ved å benytte brannmuren 2658 og bestemme at anmodningen skal benytte det interaktive talesvarsystem 2654. Det interaktive talesvarsystem 2654 kan enten håndtere kontopåfyllingen, eller hvis kunden har vanskeligheter, kan det interaktive talesvarsystem 2654 videresende anropet til operatøren 2652. Hvis det interaktive talesvarsystem 2654 kan håndtere kontopåfyllingen, kan brukeren ved å uttale kommandoer eller taste inn sifre, overføre midler fra sentralmaskinen 2620 i bank 2 ved å benytte X.25-nettet 2600 til kontoforvalteren 2656 på plattformen hvor dette blir registrert i plattformens database 2657.
Fig. 27 er et blokkskjema over et eksempel på et sikkerhetssystem som benyttes av den konvergente kommunikasjonsplattform. Som vist på fig. 27 kan et personlig identifikasjonsnummer (PIN) 2701 innføres i en brukeranordning 2700. Brukeranordningen 2700 kan inneholde en abonnentidentitetsmodul (SIM) 2702, en internasjonal mobilabonnent-identitet (IMSI) 2704 og en internasjonal mobilstasjons-utstyr-identitet (IMSEI) 2706. Brukeranordningen 2700 kan så overføre et hvilket som helst av disse numrene som er nødvendige for sikkerheten, til telefonsvitsjen 2730.
Telefonsvitsjen 2730 kan inneholde et mobilsvitsjsenter-nummer (MSCN) 2734 og et mobilstasjonsnummer (MSN) 2732. Telefonsvitsjen kan videresende et hvilket som helst av de ovennevnte numre eller identifikasjonskoder til svitsjforvalteren 2750. Svitsjforvalteren 2750 kan inneholde en brukerkonto 2752 og en autoriseringsmodul 2754.
Eksemplet på den konvergente kommunikasjonsplattform sørger for sikre finansielle transaksjoner (enten basert på ISO 8583 eller en annen slik sikker finans-transaksjonsprotokoll), som bevirker den aktuelle påfylling av en kundes forhåndsbetalte konto. Den konvergente kommunikasjonsplattform sørger for forskjellige grensesnitt som gjør det mulig å trekke penger fra tredje parts systemer (for eksempel den konvergente kommunikasjonsplattform som initierer transaksjoner for å ta penger ut av en kundes bankkonto), eller sette inn penger på det konvergente kommunikasjonsplattform-system fra en tredje parts systemer (for eksempel setter en kundes bankkontosystem penger på kundens forhåndsbetalte konto på den konvergente kommunikasjonsplattform).
Ved utførelse av en vanlig handelstransaksjon, kan således den konvergente kommunikasjonsplattform ha beskyttelse mot svindel fra uautoriserte brukere av kredittkort og betalingskort og bedrageri fra et salgsetablissement. Fremgangsmåten og plattformen i det konvergente kommunikasjonssystem kan dermed bruke ethvert nåværende eller senere kjent sikkerhetssystem til autentisering av forhåndsbetalings-brukere av den konvergente kommunikasjonsplattform. Fig. 28 viser et eksempel på en utførelsesform for oppgjør mellom flere parter ved å benytte den konvergente kommunikasjonsplattform som en oppgjørssentral. Som vist på fig. 28 kan oppgjørssentralen 2800 være relatert til banker 2840, selgere 2820, internett-tjenesteleverandører 2830 og kunder 2810. Den konvergente kommunikasjonsplattform kan således virke som en eneste kanal for finansielle oppgjør mellom flere parter, i tillegg til å virke som en eneste kanal for flere tjenester og transaksjoner via et heterogent nett. Fig. 29 er et eksempel på et skjermbilde med forhandler-, selger- og tjeneste-leverandør-informasjon for oppgjør og en konvergent kommunikasjonsplattform. Som vist på fig. 29 kan forskjellige regler for vekselvirkning og oppgjørsarrangementer med forskjellige forhandlere, tjenesteleverandører og selgere være lagret. Eksemplet på den konvergente kommunikasjonsplattform kan for eksempel lagre og vise selgeren, oppgjørstilstanden, verdien av oppgjøret, oppgjørsenhetene, tidsstempler, valuta, kontraktversjoner, gyldighetsdatoer for kontrakten og eventuelle ytterligere regler ved-rørende kontrakten. Satyam online ønsker for eksempel å gjøre opp E-handelstransaksjoner etter mottakelse, med en verdi større enn 5, hvor det blir samlet inn en prosentandel av de totale inntektene. I tillegg er kontrakten gyldig fra 23. november 2000 til 23. november 2000. Fig. 30 er et eksempel på et skjermbilde med ytterligere selger/tjeneste-leverandør/grossist-informasjon til en konvergent kommunikasjonsplattform. Som vist på fig. 30 kan en selger, for eksempel Sify@lnfo.com ha slik informasjon som kontrakt, gyldig fra, gyldig til, tilstand, betalingsmåte, verdi, tidsstempel, selger, tilstand, betalingsmåte, verdi, tidsstempel og tilgodehavende vedrørende selgeren. Fig. 31 er et eksempel på et skjermbilde med ytterligere detaljer om forhandlere/tjenesteleverandører/selgere for en kommunikasjonsplattform. Som vist på fig. 31 kan slike detaljer som fullt navn, adresse 1, adresse 2, by, stat, postnummer, fylke, kontonummer, valuta, grunnenheter, banknavn, bankfilial, bankby og kommenta-rer vedrørende selgeren, være lagret på den konvergente kommunikasjonsplattform. Fig. 32 viser et eksempel på et regeloppbevaringssted for implementering av et sofistikert regelsett i et konvergent kommunikasjonssystem. Regeloppbevaringsstedet inneholder flere tabeller. Tabellene kan kalles hovedregler 3200, abonnent 3210, tjenesteleverandør 3220 og tjeneste 3230. Hver tabell kan inneholde flere felter som inneholder data vedrørende implementering av forskjellige regelsett.
Hovedregel-tabellen 3200 kan for eksempel ha regelidentifikator, tidsbasert, dagsbasert, datobasert, volumbasert, prosent, stedsbasert, abonnentegenskaps-basert, tjenesteleverandøregenskaps-basert, tjenestebasert, siste transaksjons-basert og kontraktbaserte felter. Regelidentifikatorfeltet kan være lenket til abonnent-tabellen 3210, og tjenesteleverandør-tabellen 3220.
Abonnenttabellen 3210 kan ha abonnentidentifikator, tjenesteidentifikator, tjenesteleverandør-identifikator, saldokreditt, bruksbeløp og regelliste-felter. Tjeneste-identifikatorfeltet kan være lenket til tjenestetabellen 3230. Tjenesteleverandør-identifikatorfeltet kan være lenket til tjenesteleverandørtabellen 3220. Regelliste-feltet kan være lenket til hovedregel-tabellen 3200.
Tjenesteleverandør-tabellen 3220 kan ha tjenesteleverandør-identifikator, tjenesteidentifikator, besøkstjenesteleverandør, betalbar, mottakbar og regelliste-felter. Tjenesteleverandør-feltet kan være lenket til besøkstjeneste-leverandørfeltet og abonnenttabellen 3210. Tjenesteidentifikator-feltet kan være lenket til tjenestetabellen 3230. Regelliste-feltet kan være lenket til hovedregeltabellen 3200.
Tjenestetabellen 3230 kan ha tjenesteidentifikator, type tjeneste og tariff-felter. Tjenesteidentifikator-feltet kan være lenket til abonnent- 3210 og tjenesteleverandør-3220 feltene.
Ytterligere tabeller kan være en del av det totale konvergente kommunikasjonssystem og fremgangsmåte. Selv om beskrivende navn er brukt på de forskjellige tabeller og felter som er benyttet i eksemplet på regeloppbevaringsstedet, kan i tillegg et hvilket som helst navn, uansett om det er relatert til funksjonen til feltet eller tabellen eller ikke, benyttes. Ytterligere felter i hver av tabellene kan brukes, for eksempel et sporingsfelt for å holde rede på modifikasjonsdatoer.
Fig. 33 er et eksempel på en anordning som kan implementere oppgjørs-prosessen ved å benytte et koherent kommunikasjonssystem og en fremgangsmåte i henhold til en foretrukket utførelsesform av oppfinnelsen. Det totale system innbefatter et konvergent kommunikasjonssystem 3300, tjenesteleverandør 3340 og finansinstitusjoner 3380. Etter at en transaksjon er blitt autorisert og debitert, demonstrerer anordningen en måte på hvordan oppgjør kan skje når tjenesteleverandørene 3340 har konti i finansinstitusjoner 3380 og ikke direkte mottar midler for leverte tjenester. Selv om dette scenariet er det mest vanlige, med overføring av midler fra en konto hos en finansinstitusjon til en annen, er det ytterligere scenarier som kan benyttes ved oppgjør.
Oppgjøret begynner med at en konto i det konvergente kommunikasjonssystem 3300 blir debitert samtidig med at en tjenesteleverandør 3340 leverer en tjeneste. Det konvergente kommunikasjonssystem 3300 kan inneholde en oppgjørstjenesteleveran-dør 3301. Oppgjørstjenesteleverandøren 3301 kan inneholde en data-import/eksport 3302 som overfører informasjon mellom det konvergente kommunikasjonssystem 3300, tjenesteleverandørene 3340, finansinstitusjonene 3280 og dataformat-oppbevaringsstedet 3310.
En tjenesteleverandør 3340 kan da for eksempel levere oppgjørsregler til opp-gjørsprosessleverandøren 3301 gjennom data-importen/eksporten 3302. Oppgjørs-reglene kan så brukes til enten å fremskaffe data for dataformat-oppbevaringsstedet eller fremskaffe overføringsinstruksjoner til finansinstitusjonene 3380. Finansinstitusjonene 3380 kan så overføre midler mellom institusjoner eller konti. Hvis det konvergente kommunikasjonssystem 3300 for eksempel har en brukerkonto som befinner seg i en kredittsammenslutning 3384, og en tjenesteleverandør 3340 leverer en tjeneste som vil bli kreditert deres konto i bank 3382, kan oppgjørsprosess-leveran-døren 3301 ganske enkelt levere overføringsinstruksjoner til finansinstitusjonene 3380.
Tjenesteleverandører kan være en hvilken som helst av teleselskaper 3342, internett-tjeneste-selskaper 3344, selgere 3346, innholdsleverandører 3348, eller en hvilken som helst kjent eller fremtidig organisasjon for levering av varer eller tjenester. Finansinstitusjonene 3380 kan være en hvilken som helst av banker 3382, kreditt-sammenslutninger 3384, kredittselskaper 3386, meglere 3388 eller en hvilken som helst nåværende eller fremtidig kjent organisasjon for oppbevaring og overføring av verdier.
Fig. 34 viser et eksempel på en fremgangsmåte for påfylling av en forhåndsbetalt kundekonto for et konvergent kommunikasjonssystem og en fremgangsmåte i henhold til flere utførelseseksempler av oppfinnelse. Fremgangsmåten som er vist på fig. 34 er en lineær progresjon av spørsmål. Andre og forskjellige utførelseseksempler kan imidlertid innbefatte samtidige spørsmål, betingede spørsmål og spørsmål med udefinerte svar. Fremgangsmåten begynner ved start 3400 og fortsetter med å bestemme om overføringen skal være fra en sparekonto 3410.
Hvis den bestemmelse blir tatt ved å bestemme om overføringen skal være fra en sparekonto 3410, at overføringen ikke skal være fra en sparekonto, så fortsetter fremgangsmåten med å bestemme om overføringen skal være fra et kredittkort 3430. Hvis den bestemmelse blir tatt ved bestemmelsen om overføringen skal være fra en sparekonto 3410, at overføringen skal være fra en sparekonto, fortsetter fremgangsmåten med å bestemme om det er tilstrekkelige midler på kontoen 3420. Hvis den bestemmelse blir tatt at det er tilstrekkelig midler på kontoen, fortsetter fremgangsmåten med å overføre midlene 3490. Hvis den bestemmelse blir tatt at det ikke er tilstrekkelige midler på kontoen, fortsetter fremgangsmåten med å bestemme om overføringen skal være fra et kredittkort 3430.
Hvis den bestemmelse blir tatt ved bestemmelse om overføringen skal være fra et kredittkort 3430, at overføringen ikke skal være fra et kredittkort, fortsetter fremgangsmåten med å bestemme om overføringen skal være fra en aksjekonto 3450. Hvis den bestemmelse blir tatt ved bestemmelsen av om overføringen skal være fra et kredittkort 3430, at overføringen skal være fra et kredittkort, fortsetter fremgangsmåten med å bestemme om det er tilstrekkelig kreditt på kontoen 3440. Hvis den bestemmelse blir tatt at det er tilstrekkelig kreditt på kontoen, fortsetter fremgangsmåten til overføring av midlene 3490. Hvis den bestemmelse blir tatt at det ikke er tilstrekkelig kreditt på kontoen, fortsetter fremgangsmåten med å bestemme om overføringen skal være fra en aksjekonto 3450.
Hvis den bestemmelse blir tatt ved bestemmelsen av om overføringen skal være fra en aksjekonto 3450, at overføringen ikke skal være fra en aksjekonto, fortsetter fremgangsmåten med å bestemme om kunden skal tillates overtrekk 3470. Hvis den bestemmelse blir tatt ved bestemmelsen av om overføringen skal være fra en aksjekonto 3450, at overføringen skal være fra en aksjekonto, fortsetter fremgangsmåten med å spørre kunden om hvilke aksjer som skal selges 3460. Når kunden bestemmer et antall aksjer som skal selges, fortsetter fremgangsmåten med å over-føre midlene 3490.
Hvis den bestemmelse blir tatt ved bestemmelsen av om kunden skal tillates overtrekk 3470, at kunden ikke skal tillates overtrekk, fortsetter fremgangsmåten med å bestemme om kunden autoriserte påfylling 3480. Hvis den bestemmelse blir tatt ved bestemmelsen av om kunden skal tillates overtrekk 3470, at kunden skal tillates overtrekk, fortsetter fremgangsmåten med å overføre midlene 3490.
Hvis den bestemmelse blir tatt ved bestemmelsen av om kunden har autorisert påfylling 3480, at kunden har autorisert påfylling, fortsetter fremgangsmåten med å bestemme om overføring er mulig 3485. Hvis den bestemmelse blir tatt at kunden ikke har autorisert påfylling eller at overføringen ikke er mulig, fortsetter fremgangsmåten med å avslå transaksjonen 3495. Hvis den bestemmelse blir tatt ved bestemmelsen av om overføring er mulig 3485, at overføringen er mulig, så fortsetter fremgangsmåten med å overføre midler 3490.
Hver forhåndsbetalingskunde kan utforme sine egne kriterier for påfylling på minst følgende måte: (1) påfylling bare fra telefon (mobil eller fast), (2) påfylling fra nettet (internett, mobilt internett eller en hvilken som helst annen type offentlig eller privat nett), (3) påfylling bare når kunden spesielt ber om påfylling (enten gjennom IVR, nett eller besøk, eller på en hvilken som helst annen måte), (4) automatisk påfylling når saldoen går under en viss verdi, fra en annen spesiell konto (bank, debet eller kreditt eller en hvilken som helst annen type konto), (5) ikke påfylle kontoen, men bruke en annen konto som betalingsgaranti for den forhåndsbetalte kontoen, påfylle flere underkonti med forhåndsbestemte grenser fra hovedkontoen, (6) påfylle på periodisk basis (for eksempel daglig, månedlig, ukentlig, osv.), (7) påfylle beløp som skal bestemmes basert på brukskriterier som definert av brukeren (for eksempel se på de siste syv dagers bruk og fylle på gjennomsnittsbeløpet; eller påfyllingsbeløpet skal være lik verdien av den dyreste transaksjonen som er utført de siste "x" antall dager, osv.), (8) påfyllingsregler i henhold til tjenesteleverandøren, (9) påfyllingsregler i henhold til "eieren" av kunden (kan være en av et antall forskjellige tjenesteleverandører eller en kombinasjon av to eller flere som "eier" kunden og kan diktere reglene for denne kunden), (10) påfyllingsregler basert på hoved-"kontoholderen" istedenfor en under-kontoholder (slik som foreldre/barn eller i en hierarkisk forstand), og (11) påfyllingsregler diktert av eieren av den anordning som leverer påfyllingen (dvs. telefon, agent, ATM, POS, osv.).
Disse påfyllingsmetodene kan også variere over forskjellige typer anordninger, over forskjellige nett, over forskjellige påfyllingsmåter (IVR, agent, osv.) og i henhold til regler i landet eller det juridiske distrikt. I tillegg kan disse måtene, anordningene, nettene, osv. alle være kombinert for å lage forskjellige regler eller tillate forskjellige kombinasjoner eller permutasjoner å inntreffe. En person med en forretningskonto bruker for eksempel en IVR fra sin mobiltelefon til å tilføye penger fra forretningskontoen til sin telefon for mobil handel. Regler som dikterer hvordan dette blir gjort og hvor meget penger som kan settes inn på telefonens konto, kan være regulert av forretningsforskrifter i vedkommende land. Skulle det samme individ påfylle andre steder ved å bruke de samme regler og måter, anordninger, osv., kan reglene være forskjellige.
Fig. 35 viser et eksempel på en fremgangsmåte for autorisering av en forhåndsbetalt kundekonto for et konvergent kommunikasjonssystem og en fremgangsmåte i henhold til flere utførelseseksempler av oppfinnelsen. Den fremgangsmåte som er vist på fig. 35, er en lineær progresjon av spørsmål. Andre typer progresjon er imidlertid innenfor oppfinnelsens ramme, innbefattende samtidige spørsmål, betingede spørsmål og spørsmål med udefinerte svar. Fremgangsmåten begynner med start 3500 og fortsetter med å bestemme ved 3510 om transaksjonen er under 1 dollar.
Ved bestemmelse av om transaksjonen er under 1 dollar 3510, blir det tatt en bestemmelse om transaksjonen er under et minimumsbeløp eller ikke, nemlig 1 dollar. Hvis transaksjonen er over 1 dollar, fortsetter fremgangsmåten med å bestemme om transaksjonen er under 10 dollar 3520. Hvis transaksjonen er under 1 dollar, fortsetter fremgangsmåten med å autorisere transaksjonen 3580. Hvis den bestemmelse blir tatt ved bestemmelsen av om transaksjonen er under 10 dollar 3520, at transaksjonen er over 10 dollar, fortsetter fremgangsmåten med å bestemme om transaksjonen er under 100 dollar 3540. Hvis den bestemmelse blir tatt ved bestemmelsen av om transaksjonen er under 10 dollar 3520, at transaksjonen er under 10 dollar, fortsetter fremgangsmåten med å bestemme om transaksjonen er fra Kless 3530. Hvis den bestemmelse blir tatt at transaksjonen er fra Kless, fortsetter fremgangsmåten med å autorisere transaksjonen 3580. Hvis den bestemmelse blir tatt at transaksjonen ikke er fra Kless, fortsetter fremgangsmåten med å bestemme om transaksjonen er under 100 dollar 3540.
Ved bestemmelse av om transaksjonen er under 100 dollar 3540, blir det tatt en bestemmelse om transaksjonen er under et bestemt beløp, nemlig 100 dollar, eller ikke. Hvis transaksjonen er over 100 dollar, fortsetter fremgangsmåten med å bestemme om transaksjonen er lokal (i hjemmeterritoriet) 3560. Hvis transaksjonen er under 100 dollar, fortsetter fremgangsmåten med å bestemme om transaksjonen er for klær 3550. Hvis den bestemmelse blir tatt ved bestemmelse av om transaksjonen er for klær 3550, at transaksjonen er for klær, fortsetter fremgangsmåten med å autorisere transaksjonen 3580. Hvis den bestemmelse blir tatt at transaksjonen ikke er for klær, fortsetter fremgangsmåten tilbake til å bestemme om transaksjonen er lokal 3560. Hvis den bestemmelse blir tatt ved bestemmelse av om transaksjonen er lokal 3560, at transaksjonen ikke er lokal, fortsetter fremgangsmåten med å bestemme om det har vært noen PIN-autoriseringer i løpet av den siste timen 3570. Hvis den bestemmelse blir tatt at transaksjonen er lokal, fortsetter fremgangsmåten med å autorisere transaksjonen 3580. Hvis den bestemmelse blir tatt at det ikke har vært noen PIN-autoriseringer i løpet av den siste timen, fortsetter fremgangsmåten til slutt med å validere PIN 3585. Hvis den bestemmelse blir tatt at det har vært PIN-autoriseringer i løpet av den siste timen, fortsetter fremgangsmåten med å autorisere transaksjonen 3580.
En administrativ person i en bedrift går for eksempel til butikken OFFICE DEPOT i nærheten av arbeidsstedet for å kjøpe arbeidsutstyr. Den administrative personen velger utstyret og nærmer seg kassadisken. Den administrative personen indikerer at han vil bruke butikkens servicesystem i henhold til foreliggende oppfinnelse, til å overføre penger fra forretningskontoen til Brad Company til OFFICE DEPOT-kontoen for å dekke de valgte varer (regler: tilbyr butikken tjenestesystemet i henhold til foreliggende oppfinnelse, har ekspeditøren informasjon tilgjengelig for å bruke systemet, er forretningen en del av tjenestesystemet i henhold til oppfinnelsen, er det nødvendig med noe utover kontonummer/PIN-nummer). Ekspeditøren ringer opp kjøpet og tillater den administrative person å taste inn forretningskontokoden på tjenestestedsmaskinen (regler: stemmer kontokoden med systemets nødvendige tegnstreng, numre, bokstaver). Tjenestesystempunktet i henhold til oppfinnelsen kontrollerer at selskapets forretningskonto er en gyldig konto ved å aksessere det nasjonale bankkonto-register via tjenestesystempunktet i henhold til oppfinnelsen, og Gateway-eksemplet (regler: hvilke banker og konti er del av tjenestesystempunktet i henhold til oppfinnelsen, hva er tillatt via systemet).
Registret indikerer at selskapets forretningskonto er en gyldig konto for selskapet og krever at den administrative person skal mate inn et PIN-nummer (regler: er personen en gyldig bruker, har denne personen myndighet til å bruke midler via dette systemet, stemmer PIN-nummeret med det som er registrert og hvilken grense er tillatt). Tjenestesystempunktet i henhold til foreliggende oppfinnelse varsler ekspedi-tøren om selskapets forretningskonto er gyldig og kontrollerer så selskapets forretningskontoregler for å se om beløpet er gyldig og at kontoen kan motta belastninger (regler: aksepterer kontoen belastninger som dette, hva er grensen). Ekspeditøren mottar autentisering om at selskapets forretningskonto er gyldig og i stand til å motta belastninger (regler: ekspeditøren mottar flere valgmuligheter som hun tilbyr den administrative person, disse innbefatter kvittering eller ikke, snu kontoen eller ikke, betale noe kontant og resten på konto, eller ikke). Ekspeditøren mottar også et varsel om at den administrative persons PIN er gyldig og at den administrative person har en viss kjøpsmyndighet. Ekspeditøren fremskaffer det beløp som skal overføres/betales fra selskapets forretningskonto til butikkens konto, til den administrative person. Den administrative person er enig om betalingen. Tjenestesystempunktet i henhold til oppfinnelsen (via eksemplet på Gateway) varsler selskapets forretningskonto og butikkens (OFFICE DEPOT) konto om den aktuelle transaksjon (regler: når overføres virkelig pengene, hva er delingen mellom partene, når skjer delingen, hvilken informasjon er levert til partene). Transaksjonen blir behandlet via systemtjenestepunktet ifølge oppfinnelsen og eksemplet på Gateway (regler: tidsfastsettelse i forbindelse med behandlingen). En kvittering med bekreftelse blir levert til den administrative person (regler: hvilken informasjon er på kvitteringen, hvilke andre valgmuligheter er tilgjengelige). En bekreftelse blir fremskaffet til OFFICE DEPOT-ekspeditøren (regler: hvilke interne operasjoner er nødvendig for ekspedi-tøren, er det en utskrift av bekreftelsen, blir beløpet tilføyd kontantene, belastningene, kredittbelastningene, andre kategorier, osv.).
I et eksempel på et konvergent kommunikasjonssystem og en fremgangsmåte kan således transaksjonsvalidering/autentisering (om det er en kommunikasjonstjeneste eller en handelstransaksjon eller en kombinasjon av begge) ha flere operasjoner eller kontroller for å validere brukeren, samt tilgjengelighet på en kredittgrense eller forhåndsbetalte penger tilknyttet kontoen. Forskjellige utførelseseksempler som bruker kommunikasjonstilgangen, internett eller mobil internett-tilgang, handelstransaksjon (enten utført i en fysisk butikk eller på nettet/mobil-nettet) kan tillate validering: kundevalidering basert på PIN-innmating, validering basert på passordinnføring, validering basert på telefonirelaterte sikkerhetsforanstaltninger, en kombinasjon av noen eller alle de ovennevnte, validering av at den etterspurte tjeneste/transaksjon er autorisert eller ikke for en spesiell forhåndsbetalt kundekonto (tjenesteprofil/validering), validering om tilgjengelighet på tilstrekkelig saldo på den forhåndsbetalte kundekonto for tjenestene/transaksjonen (saldoen kan være på den forhåndsbetalte konto eller en kredittkontosaldo eller en hvilken som helst annen type reell eller virtuell konto tilknyttet kundens forhåndsbetalte konto), validering basert på en matrise over flere beløp over forskjellige tjenesteleverandører. For forskjellige beløp kan for eksempel en bank kreve en firesifret PIN-kode for autorisering, et telefonselskap kan kreve bare adressen ved en transaksjon mindre enn 20 dollar, men postnummer og personkode for en transaksjon over 50 dollar, en kredittkort-utsteder kan kreve adresse, postkode, personnummer, morens pikenavn og siste belastning som er foretatt på kontoen.
Basert på den spesifikke autoriseringsprosess kan reglene forandre seg. Hvis for eksempel en person ikke var i stand til å besvare et grunnleggende spørsmål slik som "hva er din nåværende adresse", kan reglene for autentisering umiddelbart endres for å tilføye to eller flere spørsmål som tjenesteleverandøren har bestemt er viktige for autoriseringsbehovene. Hvis personen som ber om autorisering er i stand til å besvare disse to ytterligere spørsmålene, så blir autorisering gitt. Hvis ikke blir et annet spørsmål stilt eller personen kan settes i en kø for en personlig autoriserings-anmodning basert på regler utformet av tjenesteleverandøren (bank, telefonselskap, selger eller en hvilken som helst annen type tjenesteleverandør). Tjenesteleveran-døren kan for eksempel be om ytterligere informasjon fra brukeren (for eksempel morens pikenavn, fødselsdato eller verdi på den tidligere utførte transaksjon, eller verdi på den foregående regning, den foregående påfylling eller overensstemmelse mellom et personlig spørsmål og svar som er forhåndsbestemt av kunden), be om spesielle passord for transaksjoner med høy verdi (for eksempel mer enn 20 dollar), eller transaksjoner med høyt volum (for eksempel mer enn femten transaksjoner på en dag, eller mer enn femti transaksjoner på en måned, osv.). Basert på regler utformet av kunden eller tjenesteleverandøren, kan således ytterligere valideringer brukes i stedet for bare å avslå transaksjonen. Som man kan se fra beskrivelsen ovenfor, kan reglene være en del av en interaktiv prosess basert på et sett med regler, enten opprettet av kunden eller tjenesteleverandøren, og kan hindre svindel ved interaktive kommunikasjoner mellom kunden og tjenesteleverandøren forvisse transaksjoner.
Kunden/brukeren kan for eksempel sette opp: ytterligere passord for visse typer transaksjoner (for eksempel kjøp av flybilletter), ytterligere informasjon som systemet skal be om (for eksempel fødselsdato, navnet på en venn, spesielle passord) i tilfelle av en transaksjonsverdi høyere enn et sett med tidligere transaksjoner (for eksempel be om et spesielt passord hvis den aktuelle transaksjonsverdi er 50% høyere enn summen av de fem siste dagers transaksjoner til sammen). Basert på regler utformet av kunden/brukeren, kan systemet blokkere visse typer transaksjoner (for eksempel alle e-handelstransaksjoner og mobilhandelstransaksjoner tillatt med unntak av pornografi eller pengeoverføringer mellom land hvor det finnes valutarestriksjoner).
En regel som sier at en transaksjon på 20 dollar for å kjøpe en togbillett, kan således autoriseres så lenge det er en forhåndsbetalt saldo på ikke mindre enn null (et overtrekk på 20 dollar tillates) hvor vedkommende er 60 år eller eldre og anmodningen blir fremsatt utenfor bankens åpningstider. Flere utførelseseksempler kan for eksempel bruke kriterier som er bestemt av økonomiske karakteristikker, transaksjons-type-karakteristikker, karakteristikker fra den som spør og tid på dagen. Eksemplet på systemet kan således bruke tredimensjonale regler bestemt ved hjelp av kunstig intelligens, en regelmatrise som vil bli anvendt fra transaksjon til transaksjon eller på kontobasis. Regelmatrisen kan se forskjellig ut selv for den identiske transaksjon, når en annen sammenslutning av tjenesteleverandører er involvert.
Som nevnt kan regler være basert på en adaptiv eller økonomisk basis. Reglene kan for eksempel være basert på kontosaldo; evne til påfylling; valuta som brukes; marginregler og rentestørrelser. (Disse reglene kan kalles algoritmiske regel-endringer). Andre regler kan være basert på kundeprofil, for eksempel alder, yrke, nasjonalitet, kjønn, adresse, finansiell historie, kriminell historie, medlemskap, transaksjonshistorie, transaksjonsprofil, for eksempel tjenestetype, innholdstype, etterspurt mengde, kjøp av produkter av en viss kategori. Regler kan endres basert på historie, logikk, svindel og sikkerhetsgrunner av et hvilket som helst antall personer i kjeden, innbefattende tjenesteleverandører, selgere og kunden, eller selgerprofil, for eksempel sted, type, samarbeidspartnere, osv.
Reglene som er angitt her, kan være basert på "fuzzy" eller avansert logikk, slik som kunstig intelligens. En analyse av en kundes stemme kan for eksempel rangere stemmeskjelving, stemmemodulasjon og tonefall for å bestemme stressnivået til en kunde som derved kan påvirke bestemmelsen om å autorisere en transaksjon. Det kunstige intelligenssystem kan også ha læringsegenskaper som muliggjør beslutnings-takene basert på forskjellige tidligere hendelser i forbindelse med en spesiell enkelt-kunde (selv om ingen enkelt hendelse har noen spesiell virkning på den tatte beslutning). Systemet kan for eksempel analysere debettransaksjonene over en periode på et spesifisert antall måneder og komme frem til et forbruksmønster for individet. Når en anmodning om en ny transaksjon blir innledet, kan systemet, hvis den stort sett stemmer med kjøpsmønstret, tillate transaksjonen. Hvis ikke kan systemet merke den som et potensielt svindelforsøk og utføre ytterligere valideringer. Hvis valideringene blir riktig fullført, så autoriserer systemet transaksjonen og innbefatter transaksjonen i kunnskapsbasen for å komme frem til et nytt forbruksmønster for individet.
Systemet slik det er utformet her, kan også ha læringsegenskaper som gjør det mulig å ta beslutninger basert på forskjellige tidligere hendelser for et sett med kunder (for eksempel alle lærere, alle tenåringer, alle kvinner over 55 år som bor i Dallas, osv.) Når en anmodning om en transaksjon blir innledet, kan systemet analysere kjøpsmønstret, og hvis det stort sett stemmer overens med gruppens forbruksmønster, så autoriserer systemet transaksjonen. Hva er for eksempel sjansen for at en kvinne på 62 år som tilhører en meget liten by i Texas, skal be om godkjennelse for nedlasting av pornografi fra et sted i Brasil, mens hennes fysiske oppholdssted er i Indonesia. Systemet kan tilveiebringe ytterligere autentiseringer fordi transaksjonen kan være en potensiell svindelsituasjon.
Systemet kan, slik det er utformet her, også ha læringsegenskap som gjør det mulig å ta beslutninger basert på tidligere hendelser i forbindelse med en spesiell individuell kunde (selv om ingen enkelthendelse behøver å ha noen spesiell inn-virkning på beslutningen). Systemet kan for eksempel analysere transaksjonene over en periode på et spesifisert antall måneder og komme frem til et forbruksmønster for et individ. Når en anmodning om en ny transaksjon blir innledet, så autoriserer systemet transaksjonen hvis den stort sett stemmer overens med forbruksmønstret. Hvis ikke, identifiserer systemet den som potensiell svindel og utfører ytterligere valideringer. Hvis valideringene blir fullført riktig, så autoriserer systemet transaksjonen og innbefatter transaksjonen i kunnskapsbasen for å komme frem til et nytt forbruksmønster for individet.
En spesiell egenskap for forskjellige utførelseseksempler er at debitering inntreffer i sann tid. Tjenesteleverandører er således beskyttet fra en kunde som over-trekker en konto når to belastninger ankommer omtrent samtidig. Debitering i sann tid muliggjør også dynamisk kontoføring av alle belastninger, ikke enkle engangsavgifter for tilgang. En vandringstelefonsamtale kan for eksempel kreditere vandringsnettet basert på lengden av samtalen, ikke bare en engangs-vandringsavgift. Dette gjør det mulig å hindre svindel på flere skjelnbare måter.
Tjenesteleverandører av alle typer har et felles problem ved administrasjon og kontroll av svindel. Hver gang tjenesteleverandøren tilbyr en ren kommunikasjonstjeneste eller handelstjenester eller finansielle tjenester, eller en hvilken som helst annen type tjeneste, er svindel en av de største truslene mot deres forretning. Svindel blir generelt definert som "inntektstap" forårsaket av en hvilken som helst grunn. Tradi-sjonelt har selgere og tjenesteleverandører innsett dette problemet og har kommet ut med et antall løsninger som forsøker å minimalisere svindel. Så langt analyserer til-budte løsninger potensiell svindel ved å forstå visse fundamentale trekk. Disse fundamentale trekk er motiv, hva er det fundamentale formål for svindelen (eksempler: tjene penger, kriminelle tendenser, snoking, osv.), midler, hva er beskaffenheten til svindelen (eksempler: premiesats-tjeneste, osv.), måte, hva er den generiske svindelmetode (eksempler: abonnementssvindel, surfing, ghosting, osv.) og metode, hva er den spesifikke svindelmetode (eksempler: abonnement, vandring, osv.).
De fremgangsmåter som er anvendt i de forskjellige tilfeller som er nevnt ovenfor, kan klassifiseres generelt. En første type er abonnementssvindel - når abonnenten tar et abonnement for høy bruk, men ikke har til hensikt å betale. En annen type er samtalesalg-svindel - når abonnementet blir brukt til å selge samtalene til andre med subsidier, men abonnenten ikke har til hensikt å betale. En tredje type er premiesats-tjeneste- (PRS) svindel - hvorved PRS-innholdsleverandøren selv misbruker nettet ved å generere anrop til sine egne PRS-numre for å samle inn kommisjonen; men slipper å betale operatøren for de genererte samtaler. En fjerde type er vandringssvindel - hvor den vandrende abonnent bruker nettet/tjenesten mye, men ikke har til hensikt å betale. En siste type svindel er intern svindel - hvor de ansatte hos tjenesteleverandøren benytter sin kunnskap til å tukle med systemene for dermed å hjelpe andre til å svindle.
Tjenesteleverandører over hele verden arbeider hele tiden for å lære å forstå spørsmål om de forskjellige typer svindel og hvordan tilstrekkelige forholdsregler skal settes i verk for å detektere, analysere, besvare og hindre svindel. En spesiell fordel ved systemet ifølge oppfinnelsen er at effektiviteten til virkningene av utførelses-eksemplene blir målt kontinuerlig og at funnene kan mates tilbake i systemet som forbedringer.
Et antall svindel-administrasjonssystemer er tilgjengelige i markedet i dag med varierte sofistikasjonsnivåer. Tjenesteleverandører administrerer vanligvis svindelen ved å implementere slike systemer og et sett med forretningsprosesser. For eksempel fremskaffelse av kredittvurdering fra kredittvurderingsselskaper, fysisk verifisering av kunden og dennes bolig, fremskaffelse av bekreftelse fra andre tjenesteleverandører på at personen/entiteten har gjort opp sine tidligere forpliktelser om å betale, fast-settelse av meget innviklede innsamlingsprosesser, passordbeskyttelse, øket IT-sikkerhet og opprettelse av sterkere krypteringsalgoritmer.
I dagens verden av kommunikasjoner foretrekker tjenesteleverandører i dag forhåndsbetalingskunder istedenfor etterbetalingskunder på grunn av risikoen i forbindelse med de forskjellige svindeltyper. Omdannelse av en etterbetalingskunde til en forhåndsbetalingskunde vil imidlertid ikke eliminere svindelen, men vil bare overføre svindelrisikoen fra en part til en annen. Potensielle svindlere bryr seg ikke om hvem som rammes. Det har derfor ikke noen særlig virkning på svindelproblemet.
I dagens verden med finansielle tjenester, foretrekker dagens tjenesteleveran-dører debetkort og smartkort-baserte, forhåndsbetalte kort istedenfor kredittkort av noen av de samme grunner. Utførelseseksempler av oppfinnelsen forbedrer alle disse systemer ved å integrere det konvergente kommunikasjonssystem og fremgangsmåten inn i autentiseringsprosessen ved bruk av mobiltelefoner, tilgang til det elektroniske postsystem og andre forbindelser, som beskrevet her.
En kunde kan for eksempel fremsette en anmodning om autorisering for en hvilken som helst av to eller flere tjenester (to eller flere kommunikasjonstjenester, en eller flere handelstjenester, eller en kombinasjon av kommunikasjons- og handelstjenester) ved å bruke sin telefon, internettanordning, en salgspunktanordning, et kredittkort, et debetkort eller en minibank. En slik anmodning vil gå gjennom de normale svindelvalideringsprosedyrer hos hver av tjenesteleverandørene, og hvis resultatet er positivt, vil den bli ytterligere validert av eksemplet på det konvergente kommunikasjonssystem og fremgangsmåten for kombinasjonen av tjenester. Hvis anmodningen i løpet av valideringen blir mistenkt å være en mulig svindel, så kan tjenesteleverandøren innlede en samtale med kunden (enten tale- eller datasamtale) og utføre ytterligere valideringer. Slike valideringer kan være basert på kundeut-formede parametre. Når en kunde for eksempel forsøker å kjøpe noe over 25 dollar, blir ytterligere valideringer utført. Ytterligere tjenesteleverandør-utformede parametre kan også brukes. Enhver anmodning for over 25 dollar kan for eksempel gå gjennom ytterligere valideringer, og enhver anmodning for kjøp av varer/tjenester når kunden vandrer, bør gå gjennom ytterligere valideringer basert på både hjemmetjenesteleve-randør og besøksnett-tjenesteleverandør. Andre profil/kategori/bruks-baserte konfigu-rasjonsparametre kan benyttes. Plutselige, uventede mengder med autoriseringsanmodninger, plutselige, uventede autoriseringsanmodninger fra fjerntliggende steder og tjenestetyper blir for eksempel vanligvis ikke brukt av denne kategori med kunder.
Med den økende bruk av sofistikert teknologi og mer sofistikerte forretningsprosesser, blir dermed tjenesteleverandører omkring på kloden i stand til å redusere potensiell svindel. Den største utfordringen som tjenesteleverandører står overfor i dag, er det faktum at uansett antall regler og forretningsprosesser som de har satt opp, vil svindel likevel finne sted.
Industrien har for eksempel stort sett innsett det faktum at den beste måte å eliminere/minimalisere svindel på, er å kontrollere svindelforsøket ved det punkt der
det finner sted. Enhver anmodning som har en forretningsmessig virkning kan være en potensiell svindel. Nåværende tilgjengelige svindeladministrasjonsløsninger fokuserer følgelig på å godkjenne eller forkaste anmodningen basert på et sett med regler. Disse løsningene er basert på den antakelse at en hvilken som helst anmodning som oppfyller et sett med regler, er en god anmodning, og at enhver anmodning som ikke oppfyller regelsettet, er en svindel. I den virkelige verden kan imidlertid en kunde som oppfyller alle kriteriene, fremdeles vise seg å være en svindler, og på den annen side kan en kunde som ser ut som en svindler, i virkeligheten vise seg å være en god kunde som ikke har til hensikt å svindle.
Med konvergensen av kommunikasjoner og handel må et antall parter komme sammen for å oppfylle et enkelt behov hos kunden. Hver av disse tjenesteleveran-dørene har en tilknyttet risiko som handler om svindel i deres tjenestelevering. En konvergent tjeneste samler risikoen for alle deltakende tjenesteleverandører. Virkningen blir at den resulterende svindeladministrasjonsevnen for den kombinerte tjeneste, er den minste fellesnevner for svindeladministrasjonsevnene til hver av tjenesteleverandørene (dvs. scenariet med det svakeste ledd). Potensialet for svindel øker følgelig dramatisk med antall tjenesteleverandør-parter som inngår i tjeneste-tilbudet.
For tiden tilgjengelige svindeladministrasjonssystemer tar ikke hensyn til spørsmålet vedrørende flere parter. De er enkle tjenestesvindel-administrasjons-løsninger med forskjellige sofistikasjonsnivåer. De tilbyr ikke løsninger basert på den kombinerte risiko i forbindelse med de konvergente tjenester som frembringes av forskjellige tjenesteleverandører. Forskjellige utførelseseksempler som beskrevet her, kan brukes til å redusere og eliminere svindel.
Fig. 36 viser for eksempel et eksempel på en fremgangsmåte for å debitere en forhåndsbetalt kundekonto for et konvergent kommunikasjonssystem og en fremgangsmåte i henhold til flere utførelseseksempler av oppfinnelsen. Den fremgangsmåte som er vist på fig. 36, er en lineær progresjon av spørsmål. Andre forskjellige utførelseseksempler av oppfinnelsen kan imidlertid innbefatte samtidige spørsmål, betingede spørsmål og spørsmål med ubestemte svar. Fremgangsmåten begynner ved start 3600 og fortsetter med å bestemme om denne transaksjonen skal takseres (avgiftsfri) 3610.
Hvis den bestemmelse blir tatt ved bestemmelse av om denne transaksjonen skal takseres 3610, at transaksjonen skal være avgiftsfri, fortsetter fremgangsmåten med å bestemme om debiteringen er overføring til en kredittkonto 3630. Hvis den bestemmelse blir tatt ved bestemmelse om denne transaksjonen skal takseres 3610, at overføringen skal takseres, fortsetter fremgangsmåten med å debitere en statlig konto 3620. Når debiteringen av den statlige konto 3620 er fullført, fortsetter fremgangsmåten med å gjennomføre oppgjøret 3690.
Hvis den bestemmelse blir tatt ved bestemmelse av om debiteringen er overført til en kredittkonto 3630, at overføringen ikke skal være til en kredittkonto, fortsetter fremgangsmåten med å bestemme om transaksjonen skal innbefatte transport 3650. Hvis den bestemmelse blir tatt ved bestemmelsen av om debiteringen er overføring til en kredittkonto 3630, at overføringen skal være til en kredittkonto, fortsetter fremgangsmåten med å bestemme om debiteringen skal skje umiddelbart 3640. Hvis den bestemmelse blir tatt ved 3640 at debiteringen skal være umiddelbar, fortsetter fremgangsmåten med å gjennomføre oppgjøret 3690. Hvis den bestemmelse blir tatt at debiteringen ikke skal være umiddelbar, fortsetter fremgangsmåten med å bestemme om transaksjonen innbefatter transport eller utsendelse 3650.
Hvis den bestemmelse blir tatt ved bestemmelsen av om transaksjonen innbefatter transport 3650, at transaksjonen ikke innbefatter transport, fortsetter fremgangsmåten med å bestemme om debiteringen skal deles over tid 3670. Hvis den bestemmelse blir tatt ved bestemmelsen av om transaksjonen innbefatter transport 3650, at overføringen skal innbefatte transport, fortsetter fremgangsmåten med å bestemme om transporten skal betales umiddelbart 3660. Hvis den bestemmelse blir tatt at transporten skal betales umiddelbart, fortsetter fremgangsmåten med å gjennomføre oppgjøret 3690. Hvis den bestemmelse blir tatt at transporten ikke skal betales umiddelbart, fortsetter fremgangsmåten med å bestemme om debiteringen skal deles over tid 3670.
Hvis den bestemmelse blir tatt ved bestemmelsen av om debiteringen skal deles over tid 3670, at transaksjonen ikke skal deles over tid, fortsetter fremgangsmåten med å bestemme om debiteringen skal være elektronisk 3680. Hvis den bestemmelse blir tatt ved bestemmelsen av om debiteringen skal være delt over tid 3670, at debiteringen skal deles overtid, fortsetter fremgangsmåten med å gjennom-føre oppgjøret 3690. Hvis den bestemmelse blir tatt at debiteringen ikke skal deles over tid, fortsetter fremgangsmåten med å bestemme om oppgjøret skal være elektronisk 3680. Hvis den bestemmelse blir tatt ved bestemmelsen av om oppgjøret skal være elektronisk 3680, at transaksjonen ikke skal være elektronisk, fortsetter fremgangsmåten med å skrive oppgjørsinformasjon 3695. Hvis den bestemmelse blir tatt i bestemmelsen av om oppgjøret skal være elektronisk 3680, at debiteringen skal være elektronisk, fortsetter fremgangsmåten med å planlegge overføringen 3697.
En kunde går for eksempel til en bankautomat (ATM) og velger sin butikk og mater inn kontonummeret til sin detaljhandel Renner. Et utførelseseksempel på systemet kontrollerer om butikken er medlem av systemet, om butikken tilbyr betaling gjennom systemet og om kontonummeret stemmer (tegn/numre/tall) med de for butikken. Systemet kan så bruke en Gateway til å kontakte Renner-butikkens database for å validere kontonummeret. Systemet kan så også kontrollere om kontonummeret stemmer overens. Forbrukeren kan også bruke en PIN-kode til å validere sin identitet og konto. Systemet kan så bruke en Gateway til å kontakte Renner-butikkens database for å validere kontonummeret med Renner. Systemet kan utføre den ytterligere valideringsoperasjon og kontrollere PIN-koden mot tegn i systemet og det nøyaktige kontonummer tilknyttet forbrukeren. Systemet kan så aksessere databasen og bringe tilbake saldoen til kunden. Systemet kan så kontrollere: om PIN-koden stemmer med PIN-koden i butikkens registre, er det en saldo å hente tilbake, og er kontoen i stand til å bruke systemet til å belaste ytterligere eller betale.
Forbrukeren kan så ta en beslutning om å betale en del av det hun skylder Renner via kredittkortet som betalingstype. Systemet kontrollerer: hva ønsker forbrukeren å gjøre og hva kan forbrukeren gjøre. Systemet kan kontrollere kredittkort-saldoen i banksystemet, eventuelt ikke benytte Gateway'en. Systemet kan så kontrollere: hva er saldoen på kredittkortet, hva er den totale kredittgrense, hva er differansen mellom kredittgrensen og saldoen, hvis saldoen er positiv, kan systemet presentere forbrukeren for valgmuligheter. Systemet verifiserer så videre at det er tilgjengelig kreditt på forbrukerens kredittkort. Forbrukeren kan så bli enig om å betale Renner en del av sin saldo via en overføring fra kredittkortet. Systemet kan så kontrollere: hva ønsker forbrukeren å gjøre, hvilke beløp skal håndteres, hvilke beløp skal overføres og når skal overføringen skje. Banksystemet kan så brukes til å indikere at overføringen vil finne sted, for fysisk å overføre pengene og kontrollere at pengene ble mottatt. Systemet kan så kontrollere: hvilken kontroll og bekreftelse er nødvendig for Renner og kredittkortselskapet, og hvilke kvitteringsmuligheter ønsker forbrukeren. Forbrukeren kan så motta en transaksjons-/betalings-kvittering via bankautomaten som viser betalingen. Systemet kan kontrollere: hvilken informasjon er nødvendig på kvitteringen, hvilken ytterligere informasjon ønsker forbrukeren å se, og hvilke valgmuligheter er tilgjengelige for forbrukeren. Kvitteringen kan innbefatte en bekreftelse på transaksjonen. Transaksjonen blir så fullført. Systemet kan så kontrollere: ønsker forbrukeren å foreta seg noe annet, og hva er valgmulighetene.
Disse reglene er således spesielle for når penger tas fra kontoen (i motsetning til hvis den blir kreditert etter at den er debitert). Reglene kan således være basert på regler i henhold til tjenesteleverandøren, regler i henhold til kundens behov (sannsynligvis sjelden brukt), regler i henhold til en blanding av tjenesteleverandører, regler i henhold til "eieren" av kunden, regler i henhold til "hovedleverandøren" av tjenester (dvs. hvis en kjøpmann solgte en CD til kunden for 20 dollar og transporten var 22 dollar, så kan transportøren bestemme når/hvordan debiteringen skal skje), regler som endres i henhold til finansinstitusjonenes betingelser, prosesser, prosedyrer, regler i henhold til forskjellige lovmessige forskrifter, regler i henhold til kundens historie, for- bruksgrenser, månedlig gjennomsnittlig kontobalanse og regler i henhold til forutbestemte avtaler mellom noen av tjenesteleverandørene.
Reglene kan videre være umiddelbare eller et løfte om å debitere senere/overføre senere og regler kan være en kombinasjon av det ovennevnte spredt over tid. 50% av beløpet kan for eksempel tas umiddelbart og resten kan spres over to like debiteringer om en uke. En debitering må derfor ikke ha akkurat en betaling eller øyeblikkelig debitering, den kan være flere debiteringer i tillegg til kjøpsprisen, den kan være månedlige debiteringer (som dekker "alt du kan spise"-planer), og andre kjente måter for strukturering av en betaling.
Videre vil ikke alle transaksjoner med verdi nødvendigvis innbefatte en over-føring av penger. Selv om verdi kan utveksles, kan de forskjellige transaksjoner være: gratis, en fordel i forbindelse med en tidligere kjøpt artikkel (slik som bonus i forbindelse med flybilletter), en del av en månedlig abonnementstjeneste eller utveksling av verdi, varer eller tjenester som ikke innbefatter penger (slik som en kjøpekreditt). En gratis artikkel kan for eksempel tilbys for avtale om å kjøpe ytterligere artikler innenfor en spesifisert tidsperiode. Andre utvekslinger kan innbefatte donering av en MP3-fil for tilgang til en annen MP3-fil. Eller en forbruker kan få tilgang til et kartleggingsprogram så lenge de er kunde i en viss bank. Systemet muliggjør disse utvekslingstypene innenfor det struktureksemplet som er vist på fig. 32.
Fig. 37 viser et eksempel på en fremgangsmåte for transaksjonsoppgjør for et konvergent kommunikasjonssystem og en fremgangsmåte i henhold til flere utførelseseksempler av oppfinnelsen. Fremgangsmåten på fig. 37 er en lineær progresjon av spørsmål. Andre utførelseseksempler kan imidlertid innbefatte samtidige spørsmål, betingede spørsmål og spørsmål med ubestemte svar. Fremgangsmåten begynner ved start 3700 og fortsetter med å bestemme om det er noen sanntids-oppgjør 3710.
Hvis den bestemmelse blir tatt i om det er noen sanntidsoppgjør 3710, at det er sanntidsoppgjør, fortsetter fremgangsmåten å overføre midler 3715. Ved overføring av midler 3715, blir en instruksjon gitt for umiddelbart å overføre midler mellom konti. Fremgangsmåten fortsetter så tilbake for å bestemme om det er noen datoutløste oppgjør 3720. Hvis den bestemmelse blir gjort at det ikke er noen sanntidsoppgjør, fortsetter fremgangsmåten alternativt med å bestemme om det er noen datoutløste oppgjør 3720.
Hvis den bestemmelse blir tatt ved bestemmelsen av om det er noen dato-utløste oppgjør 3720, at det er datoutløste oppgjør, fortsetter fremgangsmåten med å sette en datoutløser 3725. Ved setting av datoutløseren 3725 blir en utløser satt som vil aktivere en overføring av midler på den bestemte dato. Fremgangsmåten fortsetter så tilbake for å bestemme om det er noen hendelsesutløste oppgjør 3730. Hvis bestemmelsen blir tatt ved bestemmelsen av om det er noen datoutløste oppgjør 3720, at det ikke er noen datoutløste oppgjør, fortsetter fremgangsmåten alternativt med å bestemme om det er noen hendelsesutløste oppgjør 3730.
Hvis den bestemmelse blir tatt ved bestemmelsen av om det er noen hendelsesutløste oppgjør 3730, at det er hendelsesutløste oppgjør, fortsetter fremgangsmåten med å sette en hendelsesutløser 3735. Ved setting av hendelses-utløseren 3735, blir en utløser satt som vil aktivere overføringen av midler ved den bestemte hendelse. Fremgangsmåten fortsetter så tilbake for å bestemme om det er eventuelle satsvise oppgjør 3740. Hvis den bestemmelse blir tatt ved bestemmelse av om det er noen datoutløste oppgjør 3730, at det ikke er noen datoutløste oppgjør, fortsetter fremgangsmåten alternativt for å bestemme om det er eventuelle satsvise opp-gjør 3740.
Hvis den bestemmelse blir tatt ved bestemmelsen av om det er eventuelle satsvise oppgjør 3740, at det er satsvise oppgjør, fortsetter fremgangsmåten med å tilføye transaksjoner til satsen 3745. Ved tilføyelse av transaksjon til satsen 3745, blir transaksjonsresultatene tilføyd listen over transaksjoner som skal kjøres neste gang satsen blir påkalt. Fremgangsmåten fortsetter så tilbake til slutten 3750. Hvis den bestemmelse blir tatt ved bestemmelse om det er eventuelle satsvise oppgjør 3740, at det er ingen satsvise oppgjør, fortsetter fremgangsmåten alternativt til slutten 3750.
Hvis transaksjonen for eksempel er en ren kommunikasjonstransaksjon når det er mer enn en kommunikasjonstjenesteleverandør involvert (for eksempel vandring), så ser oppgjørsmodulen på transaksjonen så snart transaksjonen (for eksempel en telefonsamtale) er over, identifiserer partene (for eksempel tjenesteleverandører) som er involvert og anvender reglene for oppgjør (for eksempel sanntids- eller tidsforsin-kede oppgjør, partneroppgjør, tariffplaner, rabatt for volumbestilling, om en del skal betales til myndighetene osv.). Basert på reglene kan det konvergente kommunikasjonssystem og fremgangsmåten også identifisere om oppgjørene skal utføres innenfor selve systemet eller om de skal utføres ved å bruke eksterne organer. Det konvergente kommunikasjonssystem og fremgangsmåten vil så anvende reglene og ut- arbeide oppgjøret ved å knytte sammen informasjon og rapporter. For eksterne organer blir slik informasjon oversendt i et forhåndsbestemt format (for eksempel TAP-registreringer, forhåndsavtalte ASCCI-tekstfiler, MXP-registreringer, CIBER-registreringer eller IPDR-registreringer, osv.)
I henhold til et annet eksempel kan transaksjonen være en handelstransaksjon. Det konvergente kommunikasjonssystem og fremgangsmåten vil følge den samme prosess som ovenfor, men de anvendte regler kan være litt mer kompliserte ettersom reglene må ta hensyn til alle eller noen eksterne tjenesteleverandører (for eksempel kan en kjøpmann bruke et bud til å levere varene og noen av reglene vedrørende fysisk levering behøver ikke å være i sann tid, og noen ganger kan også visse prosesser ikke være automatiske). Oppgjørsregler kan også være mer komplekse (for eksempel kan oppgjørsverdien være avhengig av volum, vekt, osv.).
Hvis transaksjonen er en konvergent transaksjon (handel og kommunikasjon), kan eksemplet på det konvergente kommunikasjonssystem og fremgangsmåten være en kombinasjon av begge de typer som er nevnt ovenfor. Det konvergente kommunikasjonssystem og fremgangsmåten kan også tilføye ytterligere kompleksitet til reglene i den forstand at basert på handelsoppgjørsreglene, kan noen av reglene for kommu-nikasjonsoppgjør bli berørt. Hvis for eksempel en kunde kjøper varer verdt 50 dollar i besøksnettet, behøver besøksnettet ikke å belaste noen avgifter for bruk av telefon i vandringsnettet til hjemmenettet. Hjemmenettet kan, eller behøver ikke, videreføre denne fordelen til sluttbrukeren.
Fremgangsmåten ovenfor følger fra de følgende praktiske eksempler. En kunde Jim vandrer med sin forhåndsbetalte CDMA-mobiltelefon i Washington DC mens han er på ferie. Hans hjemmenett er North Carolina Mobile, hvor han betaler et månedlig tjenestegebyr på 50 dollar for en "alt du kan bruke av minutter i week-enden"-plan hvor som helst i hjemmenettet. Vandring blir belastet med et ytterligere gebyr på 1 dollar per samtale av hans hjemmenett.
I Washington DC lytter Jim til Santana's Greatest Hits via den Orange MusicStreamer-musikktjeneste han mottar over GSM-nettet. Han mottar en tekstmelding (SMS) og tilbys Sonys nye digitale mini-CD-spiller. Han leser annonsen mens han lytter på Carlos Santana. Etter den korte listen med CD-spillerens egenskaper, er et tilbud om å kjøpe CD-spilleren for 33% under listeprisen, hvis kjøpet skjer innenfor de neste 15 minutter. Han bestemmer seg impulsivt for å klikke på tilbudet og blir tatt til Orange MusicStreamefs nettsted for mobiltjenestehandel.
Orange MusicStreamefs nettsted ble utviklet av Aether Systems. Og gjennom en kontrakt med Orange administrerer Aether stedet. For denne administrasjonen, utviklingen og designrelasjonen, mottar Aether betaling på et antall måter. Disse innbefatter: (1) en enkel fast pris for utvikling av nettstedet; (2) et månedlig administra-sjonsgebyr for å holde stedet oppe, levere tjeneste osv.; (3) en flat pris på 2 cents for hvert mottatt klikk på en annonse på nettstedet; (4) en prosentandel av et produkts eller en tjenestes pris for hver artikkel som kjøpes som et resultat av nettstedets annonser, og (5) en fast pris på 1 dollar for hvert kundetjenesteanrop som fremskaffes på vegne av Orange MusicStreamer.
Jim fortsetter å lytte på Carlos Santana mens han klikker seg gjennom noen flere skjermbilder om Sony's CD-spiller på mobilnettstedet. Han klikker for å se pris og tilgjengelighet. Nettstedet forsyner han med to Orange MusicStreamer-partnere hvor han kan kjøpe produktet. Han velger Amazoom fremfor Electronics-R-Us og henter øyeblikkelig opp nettstedet til Amazoom-mobilshopping.
På Amazoom velger Jim den lette betalingsplanen som tilbyr CD-spilleren for 100 dollar (listeprisen var 150 dollar), og han velger å betale dette i to avdrag (50 dollar nå og 50 dollar når CD-spilleren blir levert). Han klikker på forhåndsbetalt-tasten og velger å benytte sin forhåndsbetalte konto på det konvergente kommunikasjonssystem.
Amazoom pakker Jims nye CD-spiller i en FedExtra-eske og sørger for at InsurUs forsikrer pakken. FedExtra-transport koster Amazoom 5,00 dollar og InsurUs forsikrer CD-spilleren for en total pris på 0,50 dollar.
Jim fortsetter å lytte til Carlos Santana på sin forhåndsbetalte telefon mens han ivrig venter på toget tilbake til North Carolina. Da han kommer hjem leverer FedExtra hans CD-spiller og hans signatur på konossementet utløser en verdikjede av transaksjoner over et antall tjenesteleverandører.
De følgende oppgjørstransaksjoner finner sted ved å bruke utførelsesformer av systemet og fremgangsmåten i henhold til oppfinnelsen:
Partner Transaksjons- Remittent Tidsfast- Beløp
Type settelse
Telco (hjemmenett- "Alt du kan Fra Jim via Månedlig 50 dollar tjenesteleverandør): bruke"- bankkonto på for- per måned North Carolina Mobile måneds- skudd
Tel tjeneste
Telco ( hjemmenett- | Vandring Fra Jim Sann tid 11 dollar
Oppgjørsdelen i eksemplet på konvergent kommunikasjonssystem og fremgangsmåten regulerer hvordan en betaling blir rutet og hvilket beløp som skal krediteres av betalingen. Disse transaksjonsoppgjørsreglene vil omfatte oppgjør mellom konti, fraforskjellige konto, osv., til mange konti. Systemet muliggjør derfor: oppgjør mellom flere parter for konvergente tjenester og kommunikasjonstransaksjoner, utforming av oppgjørsregler for hver tjeneste og handelstransaksjon og for oppgjør mellom kjøpmenn (leverandør av varer/tjenester, for eksempel enten fabrikant, videreselger eller distributør, eller en kombinasjon av flere slike entiteter), portaler (mobil portal eller en hvilken som helst annen type portal, innbefattende elektroniske handelsportaler, osv.), internett-tjeneste-leverandører (uavhengige organer eller mobiloperatører eller portaler), mobiltelefonselskaper (hjemmenett, besøksnett, eller begge deler), virtuelle tjenesteleverandører (innholdstjenesteleveran-dører eller infrastruktur-tjenesteleverandører eller merkevareselskaper, eller en hvilken som helst kombinasjon). Bank/kredittkort-selskaper eller hvilke som helst andre finansinstitusjoner (en eller flere involvert i en handelstransaksjon), en tredje parts betalingsselskap (for eksempel selgersammenslutninger, betalingsbehandlingsorganer eller elektroniske lommebøker eller hvilke som helst andre slike betalingsbehandlingsselskaper), vare/tjeneste-leveringsorganer (for eksempel budbyråer, båndbredde-leverandører) og forsikringsselskaper.
Som beskrevet her, kan det konvergente kommunikasjonssystem og fremgangsmåten tilveiebringe utforming av oppgjørsregler for forskjellige situasjoner, slik som: oppgjør i sann tid, oppgjør med tidsforsinkelse (for eksempel etter 2 dager eller 30 dager), oppgjør basert på bekreftelse av en viss betingelse (for eksempel blir et bud bare betalt når varene er levert, mens et forsikringsselskap blir betalt før transport av varer), oppgjør basert på et forretningsforhold mellom partene (for eksempel tilbyr et budbyrå rabatt basert på volum - det betyr at oppgjørsprosessen vil ta i betraktning flere leveringer istedenfor bare en levering), og oppgjør basert på ytelse (for eksempel blir en portal betalt et lite beløp hver gang en annonse blir levert til den vandrende abonnent og portalen får betalt et større beløp hvis den vandrende abonnent virkelig kjøper varene/tjenestene). Som beskrevet her kan det konvergente kommunikasjonssystem og fremgangsmåten sørge for oppgjør som tar i betraktning en vandringskontrakt mellom deltakende nett (for eksempel overpris på vandring). Det konvergente kommunikasjonssystem og fremgangsmåten kan videre sørge for oppgjør som tar i betraktning eventuelle lovmessige forskrifter (for eksempel pålegg om avgifter og opp-gjør med myndighetsorganer). Transaksjonen må derfor ikke være bare en transak-sjonsbetaling, eller umiddelbar kreditt, idet transaksjonen kan være delt opp i mange debiteringer som til sammen utgjør kjøpsprisen. Transaksjonen kan også være månedlige transaksjoner spredt ut over året (for å dekke "alt du kan bruke"-planer), osv.
Som beskrevet her kan det konvergente kommunikasjonssystem og fremgangsmåten sørge for oppgjør som kan være delt i følgende kategorier: kredittdager, kredittgrenser, finansvolum-terskler, rabatter for store bestillinger, forskriftsmessige kriterier, oppgjørsandeler, tjenestetype-basert, på forlangende (gjentakende, basert på lukking av forhold), online, online-sanntid og satsvis basert på forskjellige tidskriterier.
Det er flere eksempler på måter å aksessere systemet på. En av de foretrukne utførelsesformer av oppfinnelsen innbefatter for eksempel spesielt tilgang til systemet gjennom en bankautomat, en bank, en agent, et POS, et interaktivt talesvarsystem, en mobiltelefon, en fasttelefon, internett, en WAP (via mobilnett), et tekstmeldingssystem (via fastlinjetelefon og mobiltelefon), en Perto-maskin (dvs. en maskin som aksepterer kontanter for betaling av regninger) og et postkontor.
Det er flere eksempler på typer av mennesker som vil bruke systemet. Systemet kan for eksempel brukes av en forbruker, et familiemedlem, et barn, en forretningsbruker, en forretningsadministrator, en underordnet i en bedrift, en bruker av et betalingsselskap og en bankbruker.
Det er flere eksempler på typer konti som systemet kan overføre midler mellom. Systemet kan for eksempel angå en bankkonto (forskjellige typer, sjekkonto, sparekonto, vekstkonto, utdannelseskonto, feriekonto, osv.), en kontantkonto, en kredittkort-konto, en debetkortkonto, en virtuell konto, en investeringskonto, en meglerkonto og en forretningskonto. Systemeksemplet kan bruke flere formater for kommunikasjonen for kommunikasjonen om overføringer, som nevnt ovenfor, og som vanlig kjent på området.
Det er flere eksempler for påfylling av midler. Typer av betalinger foretatt generelt vil for eksempel falle i tre forskjellige kategorier: likemann til likemann, bedrift til forbruker og bedrift til bedrift. Betalingstyper kan mer spesielt innbefatte avgifter, gebyrer, skatter, andre kommunale anvendelser (lisenser, osv.), detaljhandel (mur-stein og sement), detaljhandel (elektronisk handel/internett), mobilhandel, mobiltelefoni, ISP, banker, forsikringsselskaper, veldedige organisasjoner, meglerfirmaer, gaver til familiemedlemmer og fasttelefon-regninger.
Det er flere eksempler på måter som systemet kan kommunisere med eller bestemme hvordan det skal kommunisere med andre konti for overføring av midler. Betalingskontiene kan for eksempel valideres gjennom: en nasjonal, trådløs telecom-database (cellulær); en nasjonal fastlinje-telecom database (telefon); en nasjonal bankkonto-database; individuelle konti for hvert betalingsaksepterende selskap - dvs. at detaljisbutikken Renner har en database for alle sine kunder med Renner kredittkort eller betalingstyper og en kommunal database for skatt, lisenser, osv.
De mange trekk og fordeler ved oppfinnelsen fremgår tydelig av den detaljerte beskrivelse, og derfor er det meningen at de vedføyde krav skal dekke alle slike trekk og fordeler ved oppfinnelsen som faller innenfor oppfinnelsens ramme. Siden mange modifikasjoner og endringer videre vil være lette å komme på for de som er fagkyndige på området, er det ikke ønsket å begrense oppfinnelsen til den nøyaktige utførelse og virkemåte som er illustrert og beskrevet, og følgelig er det ment at alle egnede modifikasjoner og ekvivalenter som man kan komme på, skal falle innenfor rammen av oppfinnelsen.

Claims (19)

1. Konvergent kommunikasjonssystem som anvender et regelsett, karakterisert ved : en bestemmelsesenhet som bestemmer, for en autorisert bruker, minst én regel som kan anvendes ved tidspunktet for autorisering av en transaksjon og debitering av en konto som tilhører den autoriserte bruker; en prosessor som anvender den minst ene regel for autorisering av transaksjonen; en debitor som debiterer kontoen i henhold til den minst ene regel for å debitere en konto, i sann tid, hvis transaksjonen er autorisert; og en oppgjørsenhet som gjør opp sanntids-debiteringen med et antall transak-sjonsleverandører i samsvar med minst én oppgjørsregel.
2. System ifølge krav 1, videre omfattende: en bestemmelsesenhet som bestemmer at den autoriserte bruker ikke har tilstrekkelig midler eller verdi på en autorisert brukerkonto til å debitere transaksjonen; og en påfyllingsenhet som fyller på den autoriserte brukerkonto etter fullføring av en påfyllingsrutine som omfatter å bestemme en brukerpåfyllingskonto til å overføre midler fra, og å autorisere overføringen ved hjelp av minst én av: å referere til en forhåndsautorisert overføring og å anmode om autorisering fra den autoriserte bruker.
3. System ifølge krav 1, hvor anvendelsen blir utført ved å benytte et antall regler for autorisering av transaksjonen, debiteringen blir utført ved å benytte et antall regler for debitering av en konto, og oppgjøret blir utført ved å benytte et antall oppgjørs-regler.
4. System ifølge krav 1, videre omfattende bestemmelse av minst én regel, anvendt i sann tid ved tidspunktet for en anmodning om transaksjonsautorisering i henhold til en algoritme som benytter data vedrørende historiske hendelser, som antas å ha relevans for anmodningen om transaksjonsautorisering.
5. System ifølge krav 1, videre omfattende bestemmelse av minst én regel, anvendt i sann tid ved tidspunktet for en anmodning om transaksjonsautorisering i henhold til en algoritme som benytter data vedrørende historiske hendelser, som antas å ha relevans for anmodningen om transaksjonsautorisering, og hvor innholdet av slike historiske data som er tilgjengelige, konstant blir endret.
6. Konvergent kommunikasjonssystem som anvender et regelsett, karakterisert ved : en bestemmelsesenhet som bestemmer i sann tid et antall regler for å autorisere, debitere og gjøre opp en transaksjon ved et aktuelt tidspunkt; en autoriseringsenhet som autoriserer transaksjonen hvis en aktuell status for en autorisert brukers konto eller en autorisert bruker oppfyller antallet regler for autorisering av transaksjonen ved det aktuelle tidspunkt; en debiteringsenhet som debiterer den autoriserte brukers konto i sann tid og krediterer minst én transaksjonsleverandør-konto; og en oppgjørsenhet som gjør opp for transaksjonen i henhold til den minst ene regel for oppgjør av transaksjonen.
7. System ifølge krav 6, videre omfattende: en annen bestemmelsesenhet som bestemmer at den autoriserte bruker ikke har tilstrekkelige midler eller verdi på en autorisert brukerkonto til å debitere for transaksjonen; og en påfyllingsenhet som fyller på den autoriserte brukerkonto etter fullføring av en påfyllingsrutine som omfatter å bestemme en brukerpåfyllingskonto til å overføre midler fra, og å autorisere overføringen ved hjelp av minst én av: å referere til en forhåndsautorisert overføring og å anmode om autorisering fra den autoriserte bruker.
8. System ifølge krav 2 eller 7, hvor påfyllingen blir utført under anvendelse av et antall brukerpåfyllingskonti.
9. System ifølge krav 1 eller 6, hvor autoriseringsanmodningen fra den autoriserte bruker er i det minste én av: å anmode om en PIN, å be om manuell inntasting, å be om et passord og å bekrefte identitet ved hjelp av biometriske midler.
10. System ifølge krav 1 eller 6, hvor debiteringen blir utført ved å benytte et antall regler for debitering av en konto, og oppgjøret blir utført ved å benytte et antall oppgjørsregler.
11. System ifølge krav 6, hvor autoriseringsenheten benytter et antall regler for autorisering av transaksjonen, debiteringsenheten benytter et antall regler for å debitere en konto, og oppgjørsenheten benytter et antall oppgjørsregler.
12. System ifølge krav 1 eller 6, hvor oppgjøret inntreffer minst enten umiddelbart, etter tre dager, ved slutten av en kalendermåned, med jevne mellomrom eller som en rekke delbetalinger.
13. System ifølge krav 1 eller 6, hvor anvendelsen av den minst ene regel for autorisering av transaksjonen, innbefatter autorisering av transaksjonen ved å benytte minst én av: en PIN-kode, en manuell innføring, et brukerpassord og bekreftelse av brukeridentiteten ved hjelp av biometriske midler.
14. System ifølge krav 1 eller 6, videre omfattende bestemmelse av minst én regel, anvendt i sann tid ved tidspunktet for anmodning om transaksjonsautorisering i henhold til en algoritme som inneholder tidspunktet for anmodningen om transaksjonsautorisering som en funksjon av algoritmen.
15. System ifølge krav 6, videre omfattende en bestemmelsesenhet som bestemmer minst én regel, anvendt i sann tid ved tidspunktet for en anmodning om en transaksjonsautorisering i henhold til en algoritme som benytter data vedrørende historiske hendelser, som antas å ha relevans for anmodningen om transaksjonsautorisering.
16. System ifølge krav 6, hvor bestemmelsesenheten som bestemmer den minst ene regel, anvendt i sann tid ved tidspunktet for en anmodning om transaksjons-autentisering i henhold til en algoritme som benytter data vedrørende historiske hendelser, som antas å ha relevans for anmodningen om transaksjonsautorisering, og hvor innholdet av slike tilgjengelige historiske data konstant blir endret.
17. System ifølge et av krav 4, 5, 15 og 16, hvor de historiske hendelser er en autorisert brukers tidligere kjøp eller aktuelle resultater av historiske risikovurderinger.
18. System ifølge krav 1 eller 6, hvor transaksjonen blir etterspurt og en forbindelse til antallet transaksjonsleverandører er over heterogene nett.
19. System ifølge krav 1 eller 6, hvor debiteringsenheten debiterer ved minst én av: å kontrollere at et medlemskap er gyldig, å redusere eller øke et antall flybonuspoeng, å øke eller minske en kjøpskreditt og å registrere en avtale.
NO20121157A 2001-06-29 2002-06-28 Konvergent kommunikasjonsplattform, samt fremgangsmåte for mobil og elektronisk handel i et heterogent nettverksmiljø NO334719B1 (no)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US09/894,890 US9098958B2 (en) 1998-09-15 2001-06-29 Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment
US10/096,912 US7248855B2 (en) 1998-09-15 2002-03-14 Convergent communications system and method with a rule set for authorizing, debiting, settling and recharging a mobile commerce account
PCT/GB2002/002997 WO2003003704A2 (en) 2001-06-29 2002-06-28 Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment

Publications (2)

Publication Number Publication Date
NO20121157L true NO20121157L (no) 2002-12-30
NO334719B1 NO334719B1 (no) 2014-05-12

Family

ID=26792196

Family Applications (2)

Application Number Title Priority Date Filing Date
NO20121157A NO334719B1 (no) 2001-06-29 2002-06-28 Konvergent kommunikasjonsplattform, samt fremgangsmåte for mobil og elektronisk handel i et heterogent nettverksmiljø
NO20035769A NO333711B1 (no) 2001-06-29 2003-12-22 Konvergent kommunikasjonsplattform, samt fremgangsmate for mobil og elektronisk handel i et heterogent nettverksmiljo

Family Applications After (1)

Application Number Title Priority Date Filing Date
NO20035769A NO333711B1 (no) 2001-06-29 2003-12-22 Konvergent kommunikasjonsplattform, samt fremgangsmate for mobil og elektronisk handel i et heterogent nettverksmiljo

Country Status (17)

Country Link
US (1) US7248855B2 (no)
EP (1) EP1405236A2 (no)
JP (3) JP2004535014A (no)
KR (1) KR101231436B1 (no)
CN (1) CN100444137C (no)
AU (2) AU2008203853B2 (no)
BR (1) BR0211306A (no)
CA (1) CA2452287C (no)
EA (1) EA005965B1 (no)
HK (1) HK1066289A1 (no)
HU (2) HU228541B1 (no)
IL (1) IL159629A0 (no)
MX (1) MX336287B (no)
NO (2) NO334719B1 (no)
PL (1) PL368067A1 (no)
TW (1) TW579634B (no)
WO (1) WO2003003704A2 (no)

Families Citing this family (304)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070055582A1 (en) 1996-11-12 2007-03-08 Hahn-Carlson Dean W Transaction processing with core and distributor processor implementations
US20050165699A1 (en) * 1996-11-12 2005-07-28 Hahn-Carlson Dean W. Processing and management of transaction timing characteristics
US8392285B2 (en) * 1996-11-12 2013-03-05 Syncada Llc Multi-supplier transaction and payment programmed processing approach with at least one supplier
US20080172314A1 (en) * 1996-11-12 2008-07-17 Hahn-Carlson Dean W Financial institution-based transaction processing system and approach
US8396811B1 (en) 1999-02-26 2013-03-12 Syncada Llc Validation approach for auditing a vendor-based transaction
MXPA01002722A (es) 1998-09-15 2002-06-04 In Touch Technologies Ltd Plataforma de comunicacion mejorada y metodo de comunicacion relacionado usando la plataforma.
US7058817B1 (en) 1999-07-02 2006-06-06 The Chase Manhattan Bank System and method for single sign on process for websites with multiple applications and services
US6968365B2 (en) * 1999-12-01 2005-11-22 Telefonaktiebolaget L M Ericsson (Publ) Device and a method for operating an electronic utility device from a portable telecommunication apparatus
JP2001188841A (ja) * 1999-12-28 2001-07-10 Ibm Japan Ltd 料金計算を行なうためのデータ処理システム
EP1247234A1 (en) * 2000-01-14 2002-10-09 Marconi Commerce Systems Inc. A data retail system
US9813564B1 (en) * 2000-04-27 2017-11-07 Peter D. Wendt Secured pre-payment for portable communication unit
FR2809260B1 (fr) * 2000-05-16 2003-07-18 Gemplus Card Int Procede d'approvisionnement d'un compte prepaye
US6707894B1 (en) * 2000-05-24 2004-03-16 At&T Wireless Prepaid calling time processing: a method and apparatus for processing pre-paid calling time in a telephone communication system
US7426530B1 (en) 2000-06-12 2008-09-16 Jpmorgan Chase Bank, N.A. System and method for providing customers with seamless entry to a remote server
US7653377B1 (en) * 2000-07-07 2010-01-26 Bellsouth Intellectual Property Corporation Pre-paid wireless interactive voice response system with variable announcements
US7676030B2 (en) 2002-12-10 2010-03-09 Ewi Holdings, Inc. System and method for personal identification number distribution and delivery
US20050229003A1 (en) 2004-04-09 2005-10-13 Miles Paschini System and method for distributing personal identification numbers over a computer network
FI20001740L (fi) * 2000-08-02 2002-02-03 Nokia Networks Oy Tilaajasuhteen kautta saavutettavien palveluiden määrittäminen
US7000001B2 (en) * 2000-09-12 2006-02-14 Research In Motion Limited Bookmark beacon system and method
US6959183B2 (en) * 2000-10-20 2005-10-25 Leap Wireless International, Inc. Operations method for providing wireless communication services and network and system for delivering same
US8000679B2 (en) * 2000-10-20 2011-08-16 Cricket Communications, Inc. Business method for providing wireless communication services and network and system for delivering same
US7457777B1 (en) * 2000-11-13 2008-11-25 At&T Intellectual Property I, L.P. Carried-forward service units and commoditization thereof
US6487401B2 (en) * 2000-12-18 2002-11-26 Sbc Technology Resources, Inc. Prepaid wireless telephone account regeneration in a wireless access protocol system
US7242922B2 (en) * 2000-12-29 2007-07-10 Vesta Corporation Toll free calling account recharge system and method
EP1362309A1 (en) * 2001-02-19 2003-11-19 Nokia Corporation Control of billing in a communications system
GB0107925D0 (en) * 2001-03-29 2001-05-23 Nokia Networks Oy Content charging
US7529700B1 (en) * 2001-07-10 2009-05-05 Wageworks, Inc. Single-source multi-conduit apparatuses and methods for adjudicating pretax expenses
GB0119488D0 (en) * 2001-08-10 2001-10-03 Cellectivity Ltd E-commerce method for mobile telephones
US20080208787A1 (en) 2001-11-14 2008-08-28 Retaildna, Llc Method and system for centralized generation of a business executable using genetic algorithms and rules distributed among multiple hardware devices
US8577819B2 (en) 2001-11-14 2013-11-05 Retaildna, Llc Method and system to manage multiple party rewards using a single account and artificial intelligence
US8600924B2 (en) 2001-11-14 2013-12-03 Retaildna, Llc Method and system to manage multiple party rewards using a single account and artificial intelligence
US7327833B2 (en) * 2002-03-20 2008-02-05 At&T Bls Intellectual Property, Inc. Voice communications menu
FI116169B (fi) * 2002-04-24 2005-09-30 Comptel Corp Menetelmä asiakastilien hallitsemiseksi Pre-Paid IN-alustan yhteydessä ja Pre-Paid mediaattori
US20040185827A1 (en) * 2002-05-03 2004-09-23 Michael Parks System and method for replenishing an account
US20030208444A1 (en) * 2002-05-06 2003-11-06 Hermann Sauer Payment system and method
US7509117B2 (en) * 2002-05-31 2009-03-24 Nokia Corporation Apparatus, and associated method, for notifying a user in a radio communication system of a commercially-related transaction
EP1512096A1 (de) * 2002-06-10 2005-03-09 Rudolph Volker Elektronisches zahlungsmittel mit individuell einstellbaren sicherheitseigenschaften f r das internet oder mobile netze
US7039593B2 (en) * 2002-06-20 2006-05-02 Robert David Sager Payment convergence system and method
US7539629B1 (en) * 2002-06-20 2009-05-26 At&T Intellectual Property I, L.P. System and method for replenishing a wireless terminal account
US7209890B1 (en) * 2002-06-20 2007-04-24 Bellsouth Intellectual Property Corp. System and method for replenishing a wireless terminal account
TW537466U (en) * 2002-08-01 2003-06-11 Handlink Technologies Inc Portable network transmission device
JP4199503B2 (ja) * 2002-09-20 2008-12-17 富士通株式会社 システム利用支援方法、サーバ、プログラム
US20040122697A1 (en) * 2002-09-20 2004-06-24 Fortis, Inc. Systems and methods for providing insurance and non-insurance products
US8783561B2 (en) 2006-07-14 2014-07-22 Modiv Media, Inc. System and method for administering a loyalty program and processing payments
US11257094B2 (en) 2002-10-23 2022-02-22 Catalina Marketing Corporation System and method of a media delivery services platform for targeting consumers in real time
US10430798B2 (en) 2002-10-23 2019-10-01 Matthew Volpi System and method of a media delivery services platform for targeting consumers in real time
US8626130B2 (en) * 2005-08-23 2014-01-07 Modiv Media, Inc. System and method for user controlled log-in; interacting and log-out
US9811836B2 (en) 2002-10-23 2017-11-07 Modiv Media, Inc System and method of a media delivery services platform for targeting consumers in real time
US10657561B1 (en) 2008-08-20 2020-05-19 Modiv Media, Inc. Zone tracking system and method
US10205721B2 (en) 2002-12-10 2019-02-12 Ewi Holdings, Inc. System and method for distributing personal identification numbers over a computer network
US20040193752A1 (en) * 2003-01-02 2004-09-30 Harpreet Singh System and method for providing fee-based data services
EP1435596A1 (en) * 2003-01-02 2004-07-07 Toshiba Corporation System and method for providing fee-based data services to mobile users
US20040193751A1 (en) * 2003-01-02 2004-09-30 Harpreet Singh System and method for providing fee-based data services
EP1450316B1 (de) * 2003-02-21 2014-08-27 Swisscom AG Verfahren und Modul zur Verwaltung eines Wertkontos
US7333809B2 (en) * 2003-03-18 2008-02-19 At&T Mobility Ii Llc Multi-standard prepaid communication services
US7131578B2 (en) 2003-05-28 2006-11-07 Ewi Holdings, Inc. System and method for electronic prepaid account replenishment
US8595074B2 (en) 2003-07-15 2013-11-26 American Express Travel Related Services Company, Inc. System and method for activating or changing the status of an account associated with a prepaid card
US10621521B1 (en) * 2003-07-22 2020-04-14 Versata Development Group, Inc. Efficient reprocessing of compensation calculations
US20080312941A1 (en) * 2007-06-14 2008-12-18 Qualcomm Incorporated Separable billing for personal data services
AU2004272083B2 (en) * 2003-09-12 2009-11-26 Emc Corporation System and method for risk based authentication
US20070078761A1 (en) * 2003-11-04 2007-04-05 Kagan Gershon M Universal mobile electronic commerce
US8069113B2 (en) * 2003-12-17 2011-11-29 Fmr Llc Financial account management
GB0329499D0 (en) * 2003-12-19 2004-01-28 Nokia Corp Communication network
US7450928B1 (en) * 2004-01-09 2008-11-11 At&T Mobility Ii Llc Methods for providing overdraft protection for post-paid communication service plans
US8554876B2 (en) * 2004-01-23 2013-10-08 Hewlett-Packard Development Company, L.P. User profile service
US7280644B2 (en) 2004-12-07 2007-10-09 Ewi Holdings, Inc. Transaction processing platform for faciliating electronic distribution of plural prepaid services
US11599873B2 (en) 2010-01-08 2023-03-07 Blackhawk Network, Inc. Systems and methods for proxy card and/or wallet redemption card transactions
US11475436B2 (en) 2010-01-08 2022-10-18 Blackhawk Network, Inc. System and method for providing a security code
US12260396B2 (en) 2010-01-08 2025-03-25 Blackhawk Network, Inc. System for payment via electronic wallet
PL1751966T3 (pl) * 2004-06-03 2008-05-30 Ericsson Telefon Ab L M Procedury obciążania kosztami za usługi IP Multimedia
EP1782259A4 (en) 2004-06-09 2009-04-22 Us Bancorp Licensing Inc DISTRIBUTOR BASED TRANSACTION PROCESSING AND APPROACH
WO2005124638A2 (en) 2004-06-09 2005-12-29 U.S. Bancorp Licensing, Inc. Order-resource fulfillment and management system and approach
US8762238B2 (en) * 2004-06-09 2014-06-24 Syncada Llc Recurring transaction processing system and approach
JP2006085353A (ja) 2004-09-15 2006-03-30 Nec Corp コンテンツ配信システム、その方法、会計装置、コンテンツ配信装置およびプログラム
FR2878100B1 (fr) * 2004-11-17 2007-05-11 Cit Alcatel Procede d'etablissement de connexions pour l'acces de terminaux d'utilisateurs itinerants a des reseaux de donnees
US20060116903A1 (en) * 2004-11-30 2006-06-01 Assurant Solutions Systems and methods for providing insurance coverage to a customer
JP4672351B2 (ja) * 2004-12-07 2011-04-20 株式会社日立製作所 電話交換システム
FI20041668A0 (fi) 2004-12-23 2004-12-23 Nokia Corp Menetelmä veloitusominaisuuksien muodostamiseksi
US20060167792A1 (en) * 2004-12-29 2006-07-27 Hahn-Carlson Dean W Multi-supplier transaction and payment programmed processing system and approach
CA2922293C (en) * 2005-01-28 2018-10-30 Cardinal Commerce Corporation System and method for conversion between internet and non-internet based transactions
US7532875B1 (en) 2005-02-18 2009-05-12 Virgin Mobile Usa, Llc Scaleable communications management network
US20060233332A1 (en) * 2005-03-24 2006-10-19 Toms Alvin D Credit worthiness rating method
US20060229998A1 (en) 2005-03-31 2006-10-12 Mark Harrison Payment via financial service provider using network-based device
US20060258397A1 (en) * 2005-05-10 2006-11-16 Kaplan Mark M Integrated mobile application server and communication gateway
US7970671B2 (en) * 2005-04-12 2011-06-28 Syncada Llc Automated transaction processing system and approach with currency conversion
DE602005000315T2 (de) * 2005-05-25 2007-06-06 Alcatel Lucent Telekommunikationsdienste
CN101248657B (zh) * 2005-05-31 2013-08-21 艾利森电话股份有限公司 通信系统中输送计费通知的方法和装置
CA2609012A1 (en) * 2005-06-03 2006-12-14 Cingular Wireless Ii, Llc System and method for providing airtime overdraft protection
US7831520B2 (en) * 2005-06-28 2010-11-09 Ebay Inc. Mobile device communication system
US7706792B1 (en) 2005-08-10 2010-04-27 At&T Mobility Ii Llc Intelligent customer care support
US20070043638A1 (en) * 2005-08-19 2007-02-22 Tabs Mark A System architecture and related methods for monitoring financial positions of an entity on a group-wide basis
US20070043639A1 (en) * 2005-08-19 2007-02-22 Tabs Mark A Systems and methods for monitoring financial positions
US7565506B2 (en) 2005-09-08 2009-07-21 Qualcomm Incorporated Method and apparatus for delivering content based on receivers characteristics
US8528029B2 (en) 2005-09-12 2013-09-03 Qualcomm Incorporated Apparatus and methods of open and closed package subscription
US8893179B2 (en) 2005-09-12 2014-11-18 Qualcomm Incorporated Apparatus and methods for providing and presenting customized channel information
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US7697827B2 (en) 2005-10-17 2010-04-13 Konicek Jeffrey C User-friendlier interfaces for a camera
US8571570B2 (en) 2005-11-08 2013-10-29 Qualcomm Incorporated Methods and apparatus for delivering regional parameters
US8533358B2 (en) 2005-11-08 2013-09-10 Qualcomm Incorporated Methods and apparatus for fragmenting system information messages in wireless networks
US8600836B2 (en) 2005-11-08 2013-12-03 Qualcomm Incorporated System for distributing packages and channels to a device
GB0525244D0 (en) * 2005-12-12 2006-01-18 Nokia Corp Providing communication service sessions
US20070208618A1 (en) * 2006-03-06 2007-09-06 First Data Corporation Coupon code systems and methods
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US20070244752A1 (en) * 2006-04-17 2007-10-18 Anthony Jeremiah Bayne System and method for the integrated distribution of advertising via the internet and mobile terminals
AU2007201639B2 (en) * 2006-04-17 2009-12-10 Anthony J. Bayne System and Method for the Integrated Distribution of Advertising via the Internet and Mobile Terminals
DE102006019465B4 (de) * 2006-04-26 2008-01-03 Siemens Ag Verfahren und Server zur Verwaltung von Teilnehmergebühren
US7680737B2 (en) * 2006-07-06 2010-03-16 Moneygram International, Inc. Systems and methods for processing payments with payment review features
US8069084B2 (en) 2006-07-14 2011-11-29 Wells Fargo Bank, N.A. Customer controlled account, system, and process
US10296895B2 (en) 2010-01-08 2019-05-21 Blackhawk Network, Inc. System for processing, activating and redeeming value added prepaid cards
US20080057916A1 (en) * 2006-08-29 2008-03-06 James Gamm Real-time, interactive balance check for wireless service
US20090070257A1 (en) * 2006-09-12 2009-03-12 Daniel Csoka Systems and methods for transferring funds from a sending account
US20080109281A1 (en) * 2006-09-12 2008-05-08 Daniel Csoka Systems and methods for transferring funds from a sending account
US20080077514A1 (en) * 2006-09-19 2008-03-27 Hart Matt E Method and apparatus for performing a financial transaction
US20170011391A1 (en) * 2006-09-24 2017-01-12 Rfcyber Corp. Method and apparatus for mobile payment
DE102006047114A1 (de) * 2006-09-27 2008-04-03 T-Mobile International Ag & Co. Kg Verfahren zur Bereitstellung eines konvergenten Nachrichtendienstes für mindestens ein Endgerät in einem Mobilfunknetzsystem und entsprechende Arbeitseinheit
US9025742B1 (en) * 2006-10-03 2015-05-05 United Services Automobile Association (Usaa) Method and system for providing targeted messages
US8712884B2 (en) * 2006-10-06 2014-04-29 Syncada Llc Transaction finance processing system and approach
US20110029404A1 (en) * 2006-10-06 2011-02-03 Hahn-Carlson Dean W Transaction payables processing system and approach
JP4955775B2 (ja) * 2006-11-01 2012-06-20 ノキア コーポレイション Ｏｍａブロードキャストにおけるブロードキャスト・ローミング
TWI326544B (en) 2006-11-15 2010-06-21 Ind Tech Res Inst An intelligent heterogeneous network packet dispatcher methodology
US8472598B2 (en) * 2006-11-30 2013-06-25 Motorola Mobility Llc Prepaying usage time for another communication device
JP5550068B2 (ja) * 2006-12-18 2014-07-16 ヴィザ ケープ タウン （プロプライエタリー） リミテッド 電子データのための支払いシステム
US8666892B2 (en) * 2006-12-19 2014-03-04 Datacap Systems, Inc. Electronic payment processing system
US7626504B2 (en) * 2007-04-13 2009-12-01 At&T Intellectual Property I, L.P. System and apparatus for silencing communication devices
WO2008132856A1 (ja) * 2007-04-19 2008-11-06 Mobitechno Co., Ltd. 電子決済システム、電子決済サーバ、有価価値提供装置、移動体通信端末、並びに電子決済方法
US8090343B2 (en) 2007-05-29 2012-01-03 At&T Mobility Ii Llc Optimized camel triggering for prepaid calling
US8165938B2 (en) * 2007-06-04 2012-04-24 Visa U.S.A. Inc. Prepaid card fraud and risk management
US7983655B2 (en) 2007-06-20 2011-07-19 At&T Mobility Ii Llc Conditional call treatment for prepaid calls
US20100250368A1 (en) * 2007-06-22 2010-09-30 My Screen Mobile Inc. System and method of mobile device advertising
US20080318559A1 (en) * 2007-06-22 2008-12-25 Porco Gino M System and method of mobile device advertising
US7945238B2 (en) 2007-06-28 2011-05-17 Kajeet, Inc. System and methods for managing the utilization of a communications device
US8929857B2 (en) 2007-06-28 2015-01-06 Kajeet, Inc. Policy management of electronic devices
US8090344B2 (en) 2007-07-23 2012-01-03 At&T Mobility Ii Llc Dynamic location-based rating for prepaid calls
GB2452699B (en) * 2007-08-24 2012-08-01 King S College London Mobility and quality of service
US8160544B2 (en) * 2007-08-27 2012-04-17 At&T Intellectual Property I, L.P. Methods and platforms for refreshing a pre-paid account upon detecting the occurrence of a refresh triggering event
US20090061868A1 (en) * 2007-08-28 2009-03-05 Cingular Wireless Ii, Llc Decisionmaking for dynamic local time updates in a prepaid terminating call
US20090061856A1 (en) * 2007-08-28 2009-03-05 Cingular Wireless Ii, Llc Peak off-peak rating for prepaid terminating calls
US8774798B2 (en) 2007-08-28 2014-07-08 At&T Mobility Ii Llc Determining capability to provide dynamic local time updates in a prepaid terminating call
US8108257B2 (en) * 2007-09-07 2012-01-31 Yahoo! Inc. Delayed advertisement insertion in videos
US8180321B2 (en) * 2007-09-26 2012-05-15 At&T Mobility Ii Llc Recovery of lost revenue in prepaid calls
DE102007045909A1 (de) * 2007-09-26 2009-08-06 T-Mobile Internationale Ag Verfahren zum Schutz vor Viren/Spam in Mobilfunknetzen
US20090089207A1 (en) * 2007-09-27 2009-04-02 Verizon Business Network Services Inc. Prepaid budget calling accounts with overruns billed to a credit card
US20090106151A1 (en) * 2007-10-17 2009-04-23 Mark Allen Nelsen Fraud prevention based on risk assessment rule
US8775475B2 (en) * 2007-11-09 2014-07-08 Ebay Inc. Transaction data representations using an adjacency matrix
US8791948B2 (en) * 2007-11-09 2014-07-29 Ebay Inc. Methods and systems to generate graphical representations of relationships between persons based on transactions
US8046324B2 (en) 2007-11-30 2011-10-25 Ebay Inc. Graph pattern recognition interface
US8751337B2 (en) * 2008-01-25 2014-06-10 Syncada Llc Inventory-based payment processing system and approach
US8693737B1 (en) * 2008-02-05 2014-04-08 Bank Of America Corporation Authentication systems, operations, processing, and interactions
US8213585B2 (en) * 2008-02-07 2012-07-03 Hewlett-Packard Development Company, L.P. Automated distribution and indexing of prepaid calling card information
US10540712B2 (en) 2008-02-08 2020-01-21 The Pnc Financial Services Group, Inc. User interface with controller for selectively redistributing funds between accounts
US8401938B1 (en) 2008-05-12 2013-03-19 The Pnc Financial Services Group, Inc. Transferring funds between parties' financial accounts
US8751385B1 (en) 2008-05-15 2014-06-10 The Pnc Financial Services Group, Inc. Financial email
US8165933B2 (en) * 2008-05-23 2012-04-24 Bank Of America Corporation Systems, methods, and computer program products for performing item level transaction processing
WO2010011681A1 (en) * 2008-07-21 2010-01-28 Syncada Llc Resource-allocation processing system and approach with resource pooling
EP2321776A4 (en) * 2008-07-21 2012-01-04 Syncada Llc SYSTEM AND METHOD FOR RESOURCE ALLOCATION PROCESSING WITH ADAPTIVE EVALUATION PROCESSING
US8447669B2 (en) 2008-08-26 2013-05-21 Visa U.S.A. Inc. System and method for implementing financial assistance programs
CN101667275A (zh) * 2008-09-04 2010-03-10 阿里巴巴集团控股有限公司 一种离线充值方法及系统
US8756082B1 (en) * 2008-11-25 2014-06-17 Allstate Insurance Company Virtuous cycle business growth
BRPI0916146A2 (pt) * 2008-11-26 2015-11-10 Smartconnect Holdings Pte Ltd Company Registration No 200710925M "sistema para prover crédito a um assinante, sistema para prover tempo no ar a um assinante de um serviço de comunicações, método para facilitar a provisão de crédito para um assinante selecionado através de um central de pagamento conectada a uma pluralidade de redes, método para prover tempo no ar a um assinante de uma rede de comunicações móvel através de uma central de pagamento conectada a uma pluralidade de redes de comunicações móveis, sistema para facilitar as transações entre assinantes e método para facilitar as transações entre um assinante e terceiros através de uma central de pagamento conectada a uma pluralidade de redes"
GB2466225B (en) * 2008-12-15 2013-10-02 King S College London Inter-access network handover
GB2466226B (en) 2008-12-15 2012-11-14 King S College London Improvements in or relating to network mobility
US10891037B1 (en) 2009-01-30 2021-01-12 The Pnc Financial Services Group, Inc. User interfaces and system including same
US8965798B1 (en) 2009-01-30 2015-02-24 The Pnc Financial Services Group, Inc. Requesting reimbursement for transactions
TWI496097B (zh) * 2009-02-10 2015-08-11 Alibaba Group Holding Ltd Off - line value - added method and system
US8249552B1 (en) * 2009-03-04 2012-08-21 Sprint Communications Company L.P. Pre and post-paid service plan manager
JP2010244329A (ja) * 2009-04-07 2010-10-28 Sony Corp 情報処理装置および情報処理方法、通信装置および通信方法、並びに情報処理システム
US8600873B2 (en) * 2009-05-28 2013-12-03 Visa International Service Association Managed real-time transaction fraud analysis and decisioning
US20100325040A1 (en) * 2009-06-23 2010-12-23 Craig Stephen Etchegoyen Device Authority for Authenticating a User of an Online Service
US10068282B2 (en) * 2009-06-24 2018-09-04 Uniloc 2017 Llc System and method for preventing multiple online purchases
US9075958B2 (en) 2009-06-24 2015-07-07 Uniloc Luxembourg S.A. Use of fingerprint with an on-line or networked auction
US20110004498A1 (en) * 2009-07-01 2011-01-06 International Business Machines Corporation Method and System for Identification By A Cardholder of Credit Card Fraud
US20110047052A1 (en) * 2009-08-18 2011-02-24 Kevin Terrill Cornish Method and process for an energy management system for setting and adjusting a minimum energy reserve for a rechargeable energy storage device
US8214853B2 (en) * 2009-09-02 2012-07-03 Ericsson Television, Inc Systems and methods for providing content to a subscriber through a foreign service provider and for facilitating the subscriber incurring a fee for viewing the content
CN101646153A (zh) * 2009-09-03 2010-02-10 中兴通讯股份有限公司 支持漫游用户的移动电话支付系统、方法及相关装置
US8452267B2 (en) * 2009-11-27 2013-05-28 Eazybreak Oy System and method for granting access to a system
EP2521999A4 (en) 2010-01-08 2015-01-07 Blackhawk Network Inc SYSTEM FOR PROCESSING, ENABLING AND REIMBURSING PREPAID CARDS WITH ADDED VALUE
US10037526B2 (en) 2010-01-08 2018-07-31 Blackhawk Network, Inc. System for payment via electronic wallet
US8321339B2 (en) * 2010-01-15 2012-11-27 Apollo Enterprise Solutions, Inc. System and method for resolving transactions with variable offer parameter selection capabilities
US20110191238A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Variable merchant settlement options
US20110225067A1 (en) * 2010-03-12 2011-09-15 The Western Union Company Fraud prevention using customer and agent facing devices
US8791949B1 (en) 2010-04-06 2014-07-29 The Pnc Financial Services Group, Inc. Investment management marketing tool
US8780115B1 (en) 2010-04-06 2014-07-15 The Pnc Financial Services Group, Inc. Investment management marketing tool
US8458088B2 (en) 2010-04-08 2013-06-04 The Western Union Company Money transfer smart phone methods and systems
US20120198046A1 (en) * 2010-04-29 2012-08-02 Mehul Jayant Shah Mobile device bandwidth throttling
TWI425437B (zh) * 2010-05-21 2014-02-01 Mitake Information Corp 觸控式行動設備金融商品報價軟體之下載系統與方法
US20120130731A1 (en) * 2010-06-27 2012-05-24 Matt Steven Canetto Scheduled funds transfer platform apparatuses, methods and systems
JP5633730B2 (ja) * 2010-06-28 2014-12-03 ソニー株式会社 情報処理装置および方法、並びにプログラム
WO2012000438A1 (zh) * 2010-06-29 2012-01-05 飞天诚信科技股份有限公司 一种对电子钱包进行操作的方法
US11475524B1 (en) 2010-07-02 2022-10-18 The Pnc Financial Services Group, Inc. Investor retirement lifestyle planning tool
US8423444B1 (en) 2010-07-02 2013-04-16 The Pnc Financial Services Group, Inc. Investor personality tool
US8417614B1 (en) 2010-07-02 2013-04-09 The Pnc Financial Services Group, Inc. Investor personality tool
US11475523B1 (en) 2010-07-02 2022-10-18 The Pnc Financial Services Group, Inc. Investor retirement lifestyle planning tool
CN102137373B (zh) * 2010-08-16 2014-03-12 华为技术有限公司 一种基于计费系统的QoS控制方法、装置和系统
AU2011293250A1 (en) 2010-08-27 2013-03-21 Blackhawk Network, Inc. Prepaid card with savings feature
WO2012054786A1 (en) 2010-10-20 2012-04-26 Playspan Inc. Flexible monetization service apparatuses, methods and systems
US10204327B2 (en) 2011-02-05 2019-02-12 Visa International Service Association Merchant-consumer bridging platform apparatuses, methods and systems
WO2012109628A2 (en) 2011-02-10 2012-08-16 Visa International Service Assocation Electronic coupon issuance and redemption apparatuses, methods and systems
CN106803175B (zh) 2011-02-16 2021-07-30 维萨国际服务协会 快拍移动支付装置，方法和系统
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US10223691B2 (en) 2011-02-22 2019-03-05 Visa International Service Association Universal electronic payment apparatuses, methods and systems
AU2012223415B2 (en) 2011-02-28 2017-05-18 Visa International Service Association Secure anonymous transaction apparatuses, methods and systems
US9665908B1 (en) 2011-02-28 2017-05-30 The Pnc Financial Services Group, Inc. Net worth analysis tools
US8321316B1 (en) 2011-02-28 2012-11-27 The Pnc Financial Services Group, Inc. Income analysis tools for wealth management
US9852470B1 (en) 2011-02-28 2017-12-26 The Pnc Financial Services Group, Inc. Time period analysis tools for wealth management transactions
US8374940B1 (en) 2011-02-28 2013-02-12 The Pnc Financial Services Group, Inc. Wealth allocation analysis tools
US9996838B2 (en) 2011-03-04 2018-06-12 Visa International Service Association Cloud service facilitator apparatuses, methods and systems
US11113669B1 (en) 2011-04-19 2021-09-07 The Pnc Financial Services Group, Inc. Managing employee compensation information
CA2835734A1 (en) 2011-05-11 2012-11-15 Mark Itwaru Split mobile payment system
WO2012155081A1 (en) 2011-05-11 2012-11-15 Visa International Service Association Electronic receipt manager apparatuses, methods and systems
BR112013031147A2 (pt) 2011-06-03 2017-02-07 Visa Int Service Ass aparelhos, métodos e sistema de seleção de cartão de carteira virtual
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
US9198038B2 (en) * 2011-06-13 2015-11-24 Qualcomm Incorporated Apparatus and methods of identity management in a multi-network system
US20120323777A1 (en) * 2011-06-20 2012-12-20 Liberty Michael A Business to business mobile vault
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
AU2012278963B2 (en) 2011-07-05 2017-02-23 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US10438176B2 (en) 2011-07-17 2019-10-08 Visa International Service Association Multiple merchant payment processor platform apparatuses, methods and systems
EP2608139A4 (en) * 2011-07-27 2014-05-21 Wanin Internat Co Ltd METHOD OF PAYING MOBILE DEVICE
US8838575B2 (en) * 2011-08-03 2014-09-16 Sap Ag Generic framework for historical analysis of business objects
US20130046689A1 (en) * 2011-08-16 2013-02-21 Bank Of America Corporation System and Method for Facilitating Transactions
US10318941B2 (en) 2011-12-13 2019-06-11 Visa International Service Association Payment platform interface widget generation apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US8635134B2 (en) * 2011-09-07 2014-01-21 Fiserv, Inc. Systems and methods for optimizations involving insufficient funds (NSF) conditions
US9117225B2 (en) 2011-09-16 2015-08-25 Visa International Service Association Apparatuses, methods and systems for transforming user infrastructure requests inputs to infrastructure design product and infrastructure allocation outputs
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
US10637820B2 (en) 2011-10-21 2020-04-28 Uniloc 2017 Llc Local area social networking
US9137389B2 (en) 2011-11-08 2015-09-15 Kajeet, Inc. Master limits and filters for electronic devices
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US10438196B2 (en) 2011-11-21 2019-10-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
WO2013090611A2 (en) 2011-12-13 2013-06-20 Visa International Service Association Dynamic widget generator apparatuses, methods and systems
US9953378B2 (en) 2012-04-27 2018-04-24 Visa International Service Association Social checkout widget generation and integration apparatuses, methods and systems
CN103186853B (zh) * 2011-12-31 2016-07-13 北大方正集团有限公司 一种服务器端和客户端移动支付方法、装置及系统
US10223710B2 (en) 2013-01-04 2019-03-05 Visa International Service Association Wearable intelligent vision device apparatuses, methods and systems
US11308227B2 (en) 2012-01-09 2022-04-19 Visa International Service Association Secure dynamic page content and layouts apparatuses, methods and systems
US10262148B2 (en) 2012-01-09 2019-04-16 Visa International Service Association Secure dynamic page content and layouts apparatuses, methods and systems
US8918080B2 (en) 2012-01-17 2014-12-23 Kajeet, Inc. Mobile device management
US10169812B1 (en) 2012-01-20 2019-01-01 The Pnc Financial Services Group, Inc. Providing financial account information to users
US10643191B2 (en) 2012-01-27 2020-05-05 Visa International Service Association Mobile services remote deposit capture
WO2013116153A1 (en) * 2012-01-30 2013-08-08 DoDat Process Technology, LLC Distributive on-demand administrative tasking apparatuses, methods and systems
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
CN103260143A (zh) * 2012-02-15 2013-08-21 富泰华工业（深圳）有限公司 通讯费用转移系统及方法
JP4970629B1 (ja) * 2012-02-29 2012-07-11 楽天株式会社 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体
US9305310B2 (en) * 2012-03-19 2016-04-05 Uber Technologies, Inc. Enabling a user to verify a price change for an on-demand service
US11042870B2 (en) 2012-04-04 2021-06-22 Blackhawk Network, Inc. System and method for using intelligent codes to add a stored-value card to an electronic wallet
SG11201407699UA (en) * 2012-05-18 2014-12-30 Jpmorgan Chase Bank Na Dynamic management and netting of transactions using executable rules
US9014662B1 (en) * 2012-06-25 2015-04-21 Sprint Communications Company L.P. Pre-paid phone cash wallet
US8699993B2 (en) * 2012-08-03 2014-04-15 Tracfone Wireless, Inc. Device initiated replenishment procedures for wireless devices
KR20140020055A (ko) * 2012-08-07 2014-02-18 주식회사 케이티 결제 방법 및 그 시스템
US10154483B2 (en) 2012-09-12 2018-12-11 Qualcomm Incorporated Coverage enhancement techniques for machine type communication devices in a wireless network
KR102129949B1 (ko) * 2012-10-04 2020-07-06 페이 잇 심플 엘티디. 신용거래를 용이하게 하기 위한 방법, 시스템, 및 관련한 컴퓨터 실행가능한 코드
US10970714B2 (en) 2012-11-20 2021-04-06 Blackhawk Network, Inc. System and method for using intelligent codes in conjunction with stored-value cards
US20140248908A1 (en) 2013-03-01 2014-09-04 Uniloc Luxembourg S.A. Pedestrian traffic monitoring and analysis
CA2937440A1 (en) 2013-03-14 2014-09-25 Movencorp Inc. Methods and apparatus for promoting financial behavioral change
MX2015014381A (es) * 2013-04-12 2016-07-07 Riavera Corp Sistema de pago movil que usa subcuentas de titular de cuenta.
CN103413216B (zh) * 2013-05-16 2018-02-09 深圳市淘淘谷信息技术有限公司 一种多账户管理支付方法
US10313532B2 (en) 2013-06-13 2019-06-04 Kajeet, Inc. Platform for enabling users to sign up for sponsored functions on computing devices
US10757267B2 (en) 2013-06-13 2020-08-25 Kajeet, Inc. Platform for enabling sponsors to sponsor functions of a computing device
KR20140147906A (ko) * 2013-06-19 2014-12-31 (주)토스트씨 콘텐츠 다운로드 장치 및 방법
US9026464B2 (en) * 2013-08-15 2015-05-05 Teleperformance SA Securely and efficiently processing telephone orders
CN104717598A (zh) * 2013-12-13 2015-06-17 香港优克网络技术有限公司 一种服务分享系统及装置
US9256876B2 (en) 2014-02-03 2016-02-09 Fmr Llc Real-time spend management with savings goals
US9767471B1 (en) 2014-03-24 2017-09-19 Square, Inc. Determining recommendations from buyer information
WO2016041176A1 (zh) * 2014-09-18 2016-03-24 华为技术有限公司 一种信息显示的方法、终端、服务器
US10565642B1 (en) 2014-10-23 2020-02-18 Square, Inc. Inventory management with capital advance
US11216468B2 (en) 2015-02-08 2022-01-04 Visa International Service Association Converged merchant processing apparatuses, methods and systems
US11017369B1 (en) 2015-04-29 2021-05-25 Square, Inc. Cloud-based inventory and discount pricing management system
CN106296154B (zh) * 2015-06-11 2021-08-24 创新先进技术有限公司 事务处理方法和系统
US10909486B1 (en) 2015-07-15 2021-02-02 Square, Inc. Inventory processing using merchant-based distributed warehousing
US10949796B1 (en) 2015-07-15 2021-03-16 Square, Inc. Coordination of inventory ordering across merchants
CN106452814B (zh) * 2015-08-10 2019-11-26 阿里巴巴集团控股有限公司 一种采用外部账户操作资源的方法和装置
US20170116604A1 (en) 2015-10-21 2017-04-27 Mastercard International Incorporated Systems and Methods for Identifying Payment Accounts to Segments
US20170116584A1 (en) * 2015-10-21 2017-04-27 Mastercard International Incorporated Systems and Methods for Identifying Payment Accounts to Segments
US9792597B1 (en) 2015-10-30 2017-10-17 Square, Inc. Product catalog services
US20170186003A1 (en) * 2015-12-28 2017-06-29 Ncr Corporation Secondary authentication of network transactions
US20170213213A1 (en) * 2016-01-25 2017-07-27 Sigue Corporation Enhanced authentication security applicable in an at least partially insecure network environment
US10115092B1 (en) 2016-03-04 2018-10-30 Sprint Communications Company L.P. Service composition in a mobile communication device application framework
US10529016B2 (en) * 2016-03-18 2020-01-07 Mastercard International Incorporated Method and system for pre-transaction installment payment solution and simulation of installment
US20170344985A1 (en) 2016-05-25 2017-11-30 Netspend Corporation System and method for account security
US10152315B1 (en) * 2016-07-27 2018-12-11 Intuit Inc. Live rule deployment with deployment log
CN106651565A (zh) * 2016-12-06 2017-05-10 中国银联股份有限公司 一种充值转接方法、处理方法及充值转接平台
US20180322523A1 (en) * 2017-05-05 2018-11-08 Walmart Apollo, Llc Rules-based voucher management system and method for processing self-service substantiation voucher
EP3416122A1 (en) * 2017-06-15 2018-12-19 IDEMIA France Mobile payment roaming
CN107705108A (zh) * 2017-09-15 2018-02-16 公安县凯翔网络软件开发有限公司 海外手机充值平台
US10970459B2 (en) 2017-12-07 2021-04-06 Paypal, Inc. Dynamic web content based on contextual profile
US10318569B1 (en) 2017-12-29 2019-06-11 Square, Inc. Smart inventory tags
US11093972B1 (en) * 2018-03-18 2021-08-17 Edatanetworks Inc Linking a transaction between a merchant and a resident of the same vicinity to the resident viewing the merchant broadcast advertisement
US10838739B2 (en) 2018-04-19 2020-11-17 Circle Media Labs Inc. Network-connected computing devices and methods for executing operating programs in RAM memory
CN109191110B (zh) * 2018-07-27 2023-05-23 创新先进技术有限公司 后付费交易数据处理方法、装置、处理设备、及服务器
US11861579B1 (en) 2018-07-31 2024-01-02 Block, Inc. Intelligent inventory system
CN109189398B (zh) * 2018-08-21 2022-05-24 郑州云海信息技术有限公司 一种jenkins编译构建空间的优化系统、方法及装置
US10878394B1 (en) 2018-11-29 2020-12-29 Square, Inc. Intelligent inventory recommendations
US12210511B2 (en) * 2019-03-05 2025-01-28 International Business Machines Corporation Smart contract endorsement architecture
US11790368B2 (en) 2019-03-05 2023-10-17 International Business Machines Corporation Auto-evolving database endorsement policies
CN111738727B (zh) * 2019-03-25 2023-02-28 顺丰速运有限公司 一种结算方法和结算装置
CN110766399B (zh) * 2019-10-23 2023-03-24 广东岭南通股份有限公司 一种一卡通聚合充值方法、装置及系统
US20210133756A1 (en) * 2019-10-30 2021-05-06 Bank Of America Corporation Extended payment instrument
CN115016031B (zh) * 2021-05-31 2024-09-03 西安交通大学 一种用水下多物理场复合探测系统的探测阵列优化方法
US11611601B1 (en) * 2021-07-07 2023-03-21 Eventuall, Inc. Event presentation system for hosting panel discussions with remote audience participation
US20230054343A1 (en) * 2021-08-23 2023-02-23 Bank Of America Corporation System and method for generating two-sided electronic interaction requests for completing resource transfers
US12081602B1 (en) * 2021-09-14 2024-09-03 Amazon Technologies, Inc. Metering client-side features
JP7362837B1 (ja) 2022-05-25 2023-10-17 株式会社インターネットイニシアティブ 方法、情報処理装置およびシステム
US20240169358A1 (en) * 2022-11-21 2024-05-23 Igt Debit card integrated with multiple gaming establishment account management systems

Family Cites Families (158)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4087630A (en) 1977-05-12 1978-05-02 Centigram Corporation Continuous speech recognition apparatus
US4439636A (en) 1982-03-09 1984-03-27 Martha Newkirk Credit card actuated telecommunication access network
JPS60174547U (ja) 1984-04-26 1985-11-19 三菱瓦斯化学株式会社 植物栽培用鉢
JP2672085B2 (ja) 1985-01-13 1997-11-05 ツヴィ カミル 電話の通話制御システム
JPS61245664A (ja) 1985-04-24 1986-10-31 Fujitsu Ltd 電話交換システムにおける代金決済方式
US5008926A (en) 1986-07-17 1991-04-16 Efrat Future Technology Ltd. Message management system
US4807275A (en) 1987-04-14 1989-02-21 Centigram Corporation Dispatch board system with displays for indicating the status of various messages
US4825130A (en) 1987-04-14 1989-04-25 Centigram Corporation Dispatch board system
JPH0528457Y2 (no) 1988-02-26 1993-07-21
FR2629296B1 (fr) 1988-03-28 1994-05-06 Schlumberger Industries Systeme de transmission d'informations a pre-paiement
JP2824777B2 (ja) 1989-03-14 1998-11-18 日本電信電話株式会社 即時課金方式
US4975942A (en) 1989-07-21 1990-12-04 The Boston Communications Group Credit/calling card pay telephone method and system employing telephone unit local card-checking and other intelligence cooperative with local personal host computer
JP2554380B2 (ja) * 1990-02-28 1996-11-13 株式会社テック クレジット端末機
US5003584A (en) * 1990-04-16 1991-03-26 At&T Bell Laboratories Method and apparatus for the billing of value-added communication calls
US5222120A (en) * 1990-04-23 1993-06-22 Mci Communications Corporation Long distance telephone switching system with enhanced subscriber services
US5301223A (en) 1990-05-22 1994-04-05 Cellular Technical Services Company, Inc. Cellular telephone system with remote programming, voice responsive registration and real time billing
JPH05508759A (ja) 1990-10-12 1993-12-02 ティーピーアイ，インコーポレイテッド テレコミュニケーションブースと利用方法
JP2980289B2 (ja) 1991-02-08 1999-11-22 株式会社北海道沖電気システムズ 現金取引装置
JPH0715564Y2 (ja) 1991-02-18 1995-04-12 旺基 劉 ラケットの保護帯
US5265155A (en) 1991-07-31 1993-11-23 Integrated Communications, Ltd. Method and apparatus for prepayment of telecommunication connections in a telecommunication switching network
US5148474A (en) * 1991-08-21 1992-09-15 Nancy Haralambopoulos Interactive value-added telecommunications system and method
US5206899A (en) * 1991-09-05 1993-04-27 At&T Bell Laboratories Arrangement for outbound telecommunications
US5276444A (en) 1991-09-23 1994-01-04 At&T Bell Laboratories Centralized security control system
US5265033A (en) 1991-09-23 1993-11-23 Atm Communications International, Inc. ATM/POS based electronic mail system
US5737395A (en) 1991-10-28 1998-04-07 Centigram Communications Corporation System and method for integrating voice, facsimile and electronic mail data through a personal computer
US5349636A (en) 1991-10-28 1994-09-20 Centigram Communications Corporation Interface system and method for interconnecting a voice message system and an interactive voice response system
US5359642A (en) 1991-10-30 1994-10-25 International Integrated Communications, Inc. Method and apparatus for prepayment of telecommunication connections by registered groups of subscribers in a telecommunication switching network
JP2763082B2 (ja) 1992-04-01 1998-06-11 国際電信電話株式会社 プリペイドカード残金額・残度数集中管理装置
US5321735A (en) 1992-06-29 1994-06-14 Motorola, Inc. Method and apparatus for selective real time authorization and billing of calls in a public telepoint system
US5353335A (en) 1992-08-03 1994-10-04 At&T Bell Laboratories Multilingual prepaid telephone system
JPH06121075A (ja) * 1992-10-01 1994-04-28 Nippon Telegr & Teleph Corp <Ntt> 携帯端末を用いたプリペイド方式
US5919266A (en) 1993-04-02 1999-07-06 Centigram Communications Corporation Apparatus and method for fault tolerant operation of a multiprocessor data processing system
US6694300B1 (en) * 1997-03-21 2004-02-17 Walker Digital, Llc Method and apparatus for providing supplementary product sales to a customer at a customer terminal
JPH0793428A (ja) * 1993-09-21 1995-04-07 Toshiba Corp 自動取引装置
US5590181A (en) 1993-10-15 1996-12-31 Link Usa Corporation Call-processing system and method
US5537464A (en) * 1993-11-02 1996-07-16 Lewis; C. Alan Method and apparatus for the billing of value-added communication calls
US5524142A (en) * 1993-11-02 1996-06-04 Lewis; C. Alan Method and apparatus for the billing of value-added communication calls
US5978775A (en) 1993-12-08 1999-11-02 Lucent Technologies Inc. Information distribution system using telephone network and telephone company billing service
US5557516A (en) 1994-02-04 1996-09-17 Mastercard International System and method for conducting cashless transactions
US5793762A (en) * 1994-04-12 1998-08-11 U S West Technologies, Inc. System and method for providing packet data and voice services to mobile subscribers
US5920562A (en) * 1996-11-22 1999-07-06 Sprint Communications Co. L.P. Systems and methods for providing enhanced services for telecommunication call
US5878215A (en) 1994-05-23 1999-03-02 Mastercard International Incorporated System and method for processing multiple electronic transaction requests
JPH07327094A (ja) 1994-06-02 1995-12-12 Sony Corp 情報提供システム
US5511114A (en) 1994-06-06 1996-04-23 Call Processing, Inc. Telephone pre-paid calling card system and method
US5577109A (en) 1994-06-06 1996-11-19 Call Processing, Inc. Pre-paid card system and method
US5719926A (en) * 1994-06-10 1998-02-17 Communications Product Development, Inc. Prepaid long-distance telephone service system with flexible operating parameters
US5557539A (en) 1994-06-13 1996-09-17 Centigram Communications Corporation Apparatus and method for testing an interactive voice messaging system
US5633909A (en) 1994-06-17 1997-05-27 Centigram Communications Corporation Apparatus and method for generating calls and testing telephone equipment
CA2154089A1 (en) 1994-07-22 1996-01-23 Gerald W. Weare Remote subscriber migration
ZA956867B (en) 1994-08-19 1996-03-22 Alcatel Nv Telephony accounts method
US5608778A (en) 1994-09-22 1997-03-04 Lucent Technologies Inc. Cellular telephone as an authenticated transaction controller
FI945346L (fi) 1994-11-14 1996-05-15 Finland Telecom Oy Menetelmä ja järjestelmä puhelukustannusten perimiseksi
US5826185A (en) * 1994-11-16 1998-10-20 Banana Cellular, Inc. Cellular phone system wherein the air time use is predetermined
US5722067A (en) 1994-12-23 1998-02-24 Freedom Wireless, Inc. Security cellular telecommunications system
US5854975A (en) 1994-12-23 1998-12-29 Freedom Wireless, Inc. Prepaid security cellular telecommunications system
US5634084A (en) 1995-01-20 1997-05-27 Centigram Communications Corporation Abbreviation and acronym/initialism expansion procedures for a text to speech reader
US5577100A (en) 1995-01-30 1996-11-19 Telemac Cellular Corporation Mobile phone with internal accounting
US5787403A (en) 1995-03-08 1998-07-28 Huntington Bancshares, Inc. Bank-centric service platform, network and system
US5692037A (en) 1995-03-31 1997-11-25 Cellular Development Systems On demand real time telephone billing equipment
US5677955A (en) 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
NZ308081A (en) 1995-04-28 1999-01-28 Koninkl Kpn Nv Interface between ic card and telephone network
US5661781A (en) 1995-05-01 1997-08-26 At&T Message notification system for card users
DE69636065T2 (de) * 1995-05-24 2006-08-31 Walker Digital, LLC., Stamford Abrechnungs- und sammlungssystem für 900-nummern und verfahren für online-rechnerdienste
US5717604A (en) 1995-05-25 1998-02-10 Wiggins; Christopher Network monitoring system for tracking, billing and recovering licenses
US5749075A (en) 1995-06-06 1998-05-05 Interactive Media Works, L.L.C. Method for providing prepaid internet access and/or long distance calling including the distribution of specialized calling cards
US5692132A (en) 1995-06-07 1997-11-25 Mastercard International, Inc. System and method for conducting cashless transactions on a computer network
US5748711A (en) 1995-06-07 1998-05-05 Matrixx Marketing Inc. Telephone transaction processing as a part of call transport
US6115458A (en) * 1995-07-14 2000-09-05 American Express Travel Related Services Company, Inc. Method and apparatus for summaries of prepaid instrument transaction activity
US5852812A (en) 1995-08-23 1998-12-22 Microsoft Corporation Billing system for a network
US5671280A (en) 1995-08-30 1997-09-23 Citibank, N.A. System and method for commercial payments using trusted agents
US5621787A (en) 1995-09-13 1997-04-15 Bell Atlantic Network Services, Inc. Prepaid cash card
US5745556A (en) * 1995-09-22 1998-04-28 At&T Corp. Interactive and information data services telephone billing system
US6009469A (en) * 1995-09-25 1999-12-28 Netspeak Corporation Graphic user interface for internet telephony application
AU7246996A (en) 1995-09-29 1997-04-17 Boston Technology, Inc. Multimedia architecture for interactive advertising
NL1001387C2 (nl) 1995-10-10 1997-04-11 Nederland Ptt Stelsel voor het elektronisch bestellen en betalen van diensten via een communicatienetwerk.
US6061664A (en) 1995-10-10 2000-05-09 Koninklijke Ptt Nederland N.V. System for facilitating the ordering and paying of services by means of a communication network
US5699528A (en) 1995-10-31 1997-12-16 Mastercard International, Inc. System and method for bill delivery and payment over a communications network
US5778313A (en) * 1995-12-08 1998-07-07 Cellexis International, Inc. Pre-paid cellular telephone system
US5825863A (en) * 1995-12-11 1998-10-20 Walker Asset Management Limited Partnership Prepaid limited usage calling card
US6246755B1 (en) 1996-12-31 2001-06-12 Walker Digital, Llc Method and system for connecting a caller to a content provider
US5870473A (en) 1995-12-14 1999-02-09 Cybercash, Inc. Electronic transfer system and method
DE19547194A1 (de) * 1995-12-16 1997-06-19 Sel Alcatel Ag Verfahren zur Vergebührung der Nutzung eines Telekommunikations-Dienstes sowie Vermittlungssystem, Dienststeuereinrichtung und Netzwerkmanagementeinrichtung
US5712908A (en) 1995-12-22 1998-01-27 Unisys Corporation Apparatus and method for generating call duration billing records utilizing ISUP messages in the CCS/SS7 telecommunications network
US5893076A (en) 1996-01-16 1999-04-06 Sterling Commerce, Inc. Supplier driven commerce transaction processing system and methodology
US5784442A (en) 1996-02-02 1998-07-21 Telefonaktiebologet Lm Ericsson (Publ) System and method for real-time billing in a radio telecommunications network
JPH09214640A (ja) 1996-02-07 1997-08-15 Fujitsu Ltd 料金代理徴収処理方法
US5956391A (en) 1996-02-09 1999-09-21 Telefonaktiebolaget Lm Ericsson Billing in the internet
US6137870A (en) 1996-03-06 2000-10-24 Convergys Customer Management Group, Inc. System for providing caller information to called party via call standard data field
WO1997033416A1 (en) 1996-03-07 1997-09-12 American Express Travel Related Services Company, Inc. Methods and apparatus for providing a prepaid, remote memory transaction account with voice indicia
JPH09245104A (ja) 1996-03-14 1997-09-19 Mitsubishi Electric Corp 電子財布装置
JPH09259193A (ja) * 1996-03-19 1997-10-03 Fujitsu Ltd 電子マネーシステムの取引方法
US6185198B1 (en) 1996-03-20 2001-02-06 Aeris Communications, Inc. Time division multiple access downlink personal communications system voice and data debit billing method
JPH09259085A (ja) 1996-03-27 1997-10-03 Toppan Printing Co Ltd データベースの管理方法、データベース管理装置及びデータベースシステム
US5841966A (en) 1996-04-04 1998-11-24 Centigram Communications Corporation Distributed messaging system
US5867562A (en) 1996-04-17 1999-02-02 Scherer; Gordon F. Call processing system with call screening
US5915226A (en) 1996-04-19 1999-06-22 Gemplus Card International Prepaid smart card in a GSM based wireless telephone network and method for operating prepaid cards
EP0896705B1 (en) 1996-04-26 2000-01-05 Koninklijke KPN N.V. Device for playing games via a communications network, and a games system using a communications network
JP3462343B2 (ja) * 1996-05-23 2003-11-05 株式会社エヌ・ティ・ティ・ドコモ プリペイド移動通信システム
US5960069A (en) 1996-06-05 1999-09-28 David Felger Method of billing a multiple service representative conference call
US5897621A (en) 1996-06-14 1999-04-27 Cybercash, Inc. System and method for multi-currency transactions
JP3786708B2 (ja) * 1996-06-18 2006-06-14 クランベリー、プロパティーズ、リミテッド、ライアビリティー、カンパニー 音声、ファクシミリ、電子メール統合メッセージ・システム
JPH1027196A (ja) * 1996-07-09 1998-01-27 Hitachi Ltd 電子商取引決済システム
US5930767A (en) * 1997-05-28 1999-07-27 Motorola, Inc. Transaction methods systems and devices
US6119109A (en) 1996-09-30 2000-09-12 Digital Vision Laboratories Corporation Information distribution system and billing system used for the information distribution system
KR19990076696A (ko) 1996-10-23 1999-10-15 요트.게.아. 롤페즈 이동 통신 서비스 요금 지불 체계
US6188752B1 (en) 1996-11-12 2001-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for providing prepaid telecommunications services
US5828740A (en) 1996-11-14 1998-10-27 Sprint Communications Co., L.P. Prepaid calling card external/adjunct database processor
WO1998031161A2 (en) 1997-01-11 1998-07-16 Tandem Computers, Incorporated Method and apparatus for automated a-key updates in a mobile telephone system
US6058300A (en) * 1997-02-04 2000-05-02 National Telemanagement Corporation Prepay telecommunications system
US5960416A (en) 1997-02-27 1999-09-28 Block; Robert S. Real time subscriber billing at a subscriber location in an unstructured communication network
US5909486A (en) 1997-03-19 1999-06-01 Walker Asset Management Limited Partnership Method and apparatus for awarding and redeeming prepaid telephone time
US6104704A (en) 1997-03-20 2000-08-15 At&T Corp. Methods and apparatus for gathering and processing billing information for internet telephony
US6036086A (en) 1997-03-28 2000-03-14 Lucent Technologies Inc. Apparatus and method for initiating a telephone transaction using a scanner
US5915093A (en) * 1997-04-24 1999-06-22 Howard Berlin Computer network debit disk used for prepayment to transfer information from a central computer
US6606603B1 (en) 1997-04-28 2003-08-12 Ariba, Inc. Method and apparatus for ordering items using electronic catalogs
US6070185A (en) 1997-05-02 2000-05-30 Lucent Technologies Inc. Technique for obtaining information and services over a communication network
US6014636A (en) 1997-05-06 2000-01-11 Lucent Technologies Inc. Point of sale method and system
US6047284A (en) 1997-05-14 2000-04-04 Portal Software, Inc. Method and apparatus for object oriented storage and retrieval of data from a relational database
US6047267A (en) 1997-05-14 2000-04-04 Portal Software, Inc. Method and apparatus for tracking multiple payment resources and charging transactions to payment resources in on line transaction processing system
US6092055A (en) 1997-05-14 2000-07-18 Portal Software, Inc. Method and apparatus for providing a clean accounting close for a real time billing system
AU7687498A (en) 1997-05-14 1998-12-08 Portal Information Network Method and apparatus for object oriented storage and retrieval of data from a relational database to implement real time billing system
FR2764460B1 (fr) * 1997-06-10 1999-07-16 France Telecom Procede de gestion dynamique d'un abonnement d'un terminal en mode "prepaye" et carte de prepaiement pour la mise en oeuvre de ce procede
US6097939A (en) 1997-07-11 2000-08-01 Compaq Computer Corporation Method and apparatus for event data maintenance per MIN/ESN pair in a mobile telephone system
US6122632A (en) 1997-07-21 2000-09-19 Convergys Customer Management Group Inc. Electronic message management system
US5974146A (en) 1997-07-30 1999-10-26 Huntington Bancshares Incorporated Real time bank-centric universal payment system
JP3103326B2 (ja) * 1997-08-08 2000-10-30 エヴァー プロスペクト インターナショナル リミテッド 携帯電話機の料金支払いシステム及び料金支払い方法
US5943406A (en) * 1997-09-30 1999-08-24 Leta; John T. Telephone call tracking and billing system and method
US6070067A (en) * 1997-10-31 2000-05-30 Telefonaktiebolaget Lm Ericsson Prepayment method utilizing credit information stored in mobile terminals for accessing wireless telecommunication networks
US6023499A (en) 1997-11-26 2000-02-08 International Business Machines Corporation Real time billing via the internet for advanced intelligent network services
EP0921487A3 (en) 1997-12-08 2000-07-26 Nippon Telegraph and Telephone Corporation Method and system for billing on the internet
US6081791A (en) 1997-12-23 2000-06-27 U S West, Inc Enhanced ATM for facilitating telephony access
US6453306B1 (en) * 1998-01-26 2002-09-17 Ict Software S.A. Internet commerce method and apparatus
US6058173A (en) 1998-02-19 2000-05-02 Lhs Group Inc. Real-time call rating and debiting system
US6115714A (en) 1998-03-20 2000-09-05 Kenan Systems Corp. Triggering mechanism for multi-dimensional databases
US5915007A (en) 1998-04-14 1999-06-22 Catalina Marketing International, Inc. Method and system for using a frequent shopper card as a phone calling card
HU220728B1 (hu) 1998-04-28 2002-05-28 René Molnár Eljárás automata áruvásárlási rendszer megvalósítására
JPH11338924A (ja) * 1998-05-25 1999-12-10 Omron Corp カード決済システム
US6208719B1 (en) 1998-06-09 2001-03-27 Hewlett-Packard Company Method and apparatus for telecommunications having automatic network adaptations and silent mode operations
KR100573532B1 (ko) * 1998-07-16 2006-04-26 텔레맥 코포레이션 무선 선불 서비스를 관리하기 위한 시스템 및 방법
US6185414B1 (en) 1998-07-24 2001-02-06 Telefonaktiebolaget Lm Ericsson (Publ) Wireless telecommunication system with prepaid architecture
US6356752B1 (en) * 1998-07-31 2002-03-12 Avaya Technology Corp. Wireless telephone as a transaction device
US6195542B1 (en) * 1998-07-31 2001-02-27 Avaya Technology Corp. Identification by a central computer of a wireless telephone functioning as a transaction device
MXPA01002722A (es) 1998-09-15 2002-06-04 In Touch Technologies Ltd Plataforma de comunicacion mejorada y metodo de comunicacion relacionado usando la plataforma.
US6092053A (en) 1998-10-07 2000-07-18 Cybercash, Inc. System and method for merchant invoked electronic commerce
CN1224984A (zh) * 1998-10-16 1999-08-04 董小武 数字移动台终端关机状态实现寻呼通信的方法
ATE294488T1 (de) 1998-11-24 2005-05-15 Boston Communications Group Inc Anrufszuführungssystem für vorausbezahlte fremdnetzbenützungsbeträge
KR100338483B1 (ko) * 1999-01-07 2002-05-30 비센트 비.인그라시아, 알크 엠 아헨 전자지갑 자동 충전 및 징수장치와 그 처리방법
JP2000250988A (ja) * 1999-03-01 2000-09-14 Hitachi Ltd 決済処理方法及びその実施装置並びにその処理プログラムを記録した媒体
AU3320900A (en) 1999-03-17 2000-10-04 Star Home Gmbh System and method for roaming for prepaid mobile telephone service
JP2002544732A (ja) * 1999-05-06 2002-12-24 テレフオンアクチーボラゲツト エル エム エリクソン（パブル） 移動通信ネットワークにおけるタリフ決定
GB9915658D0 (en) 1999-07-06 1999-09-01 Jpm Int Ltd Electronic money transfer
WO2001011857A1 (en) 1999-08-05 2001-02-15 On Point Technology Systems, Inc. Pre-paid mobile telephone air-time replenishing system and method
DE19938201A1 (de) 1999-08-12 2001-02-22 Mannesmann Ag SMS-e-commerce
KR100359695B1 (ko) * 1999-11-20 2002-11-07 웹케시 주식회사 금융포털서비스시스템 및 방법
AU784041B2 (en) * 1999-11-30 2006-01-19 Citibank, N.A. System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
EP1238509B1 (en) 1999-12-13 2005-11-30 Markport Limited A wap service personalisation, management and billing object-oriented platform
JP2000331095A (ja) * 2000-07-31 2000-11-30 Sumitomo Credit Service Co Ltd 決済システムにおける取引要求情報の振分サーバ、決済システムおよび決済方法
WO2003010951A1 (en) 2001-07-24 2003-02-06 Citibank, N.A. Method and system for data management in electronic payments transactions

Also Published As

Publication number Publication date
AU2010200439B2 (en) 2011-03-17
BR0211306A (pt) 2004-08-24
HU228542B1 (en) 2013-03-28
HU1000479D0 (en) 2010-11-29
CA2452287A1 (en) 2003-01-09
NO20035769L (no) 2004-03-01
WO2003003704A3 (en) 2003-11-27
HU228541B1 (en) 2013-03-28
MX336287B (es) 2016-01-14
EA200400101A1 (ru) 2004-06-24
TW579634B (en) 2004-03-11
MXPA03011821A (es) 2005-04-08
NO333711B1 (no) 2013-09-02
US7248855B2 (en) 2007-07-24
CN100444137C (zh) 2008-12-17
JP5249165B2 (ja) 2013-07-31
AU2008203853B2 (en) 2009-11-19
JP2004535014A (ja) 2004-11-18
EA005965B1 (ru) 2005-08-25
US20030026404A1 (en) 2003-02-06
PL368067A1 (en) 2005-03-21
KR101231436B1 (ko) 2013-02-08
NO334719B1 (no) 2014-05-12
WO2003003704A2 (en) 2003-01-09
HK1066289A1 (en) 2005-03-18
HUP0400342A2 (en) 2004-10-28
AU2010200439A1 (en) 2010-03-04
IL159629A0 (en) 2004-06-01
KR20100058683A (ko) 2010-06-03
JP2010081614A (ja) 2010-04-08
CN1524245A (zh) 2004-08-25
CA2452287C (en) 2017-06-20
EP1405236A2 (en) 2004-04-07
AU2008203853A1 (en) 2008-09-04
JP2011066910A (ja) 2011-03-31

Similar Documents

Publication Publication Date Title
CA2452287C (en) Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment
US9098958B2 (en) Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment
US6424706B1 (en) Method and system for transferring telecommunication-time units among accounts and exchanging same for goods or services
US20160055583A1 (en) Mobile global exchange platform
US20140201070A1 (en) Monetary transaction system
US20080162348A1 (en) Electronic-Purse Transaction Method and System
KR101195670B1 (ko) 이종 네트워크 환경에서 융합 통신 플랫폼과 모바일 및 전자 상거래 방법
JP5695685B2 (ja) 異種ネットワーク環境における移動体及び電子商取引に対する集中通信プラットホーム及び方法
WO2018189597A1 (en) Mobile bank account management systems
WO2016073519A1 (en) Mobile global exchange platform
KR20020030058A (ko) 전화번호를 이용한 은행계좌 운용시스템과 지불방법
AU2002311491A1 (en) Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment
EP4016426A1 (en) Method and system for exchanging sms, mms and/or call into cash or funds in a bank account
KR20030051572A (ko) 유무선통합 밴시스템의 신용 결제와 결제 대행 중계방법
KR20110106561A (ko) Ａｒｓ를 이용한 비용 결제 방법과 그 시스템 및 ａｒｓ를 이용한 비용결제 기능을 갖춘 서버
KR20040080687A (ko) 휴대폰 및 유선전화를 이용한 대출 서비스 방법
WO2006021221A1 (fr) Procede de paiements et de transferts de moyens financiers utilisant les communications mobiles

Legal Events

Date Code Title Description
CHAD Change of the owner's name or address (par. 44 patent law, par. patentforskriften)

Owner name: UPAID SYSTEMS LTD, GB

MM1K Lapsed by not paying the annual fees