HU220576B1 - Elektronikus pénzterjesztő rendszer és eljárás - Google Patents

Elektronikus pénzterjesztő rendszer és eljárás Download PDF

Info

Publication number
HU220576B1
HU220576B1 HU9801603A HUP9801603A HU220576B1 HU 220576 B1 HU220576 B1 HU 220576B1 HU 9801603 A HU9801603 A HU 9801603A HU P9801603 A HUP9801603 A HU P9801603A HU 220576 B1 HU220576 B1 HU 220576B1
Authority
HU
Hungary
Prior art keywords
agent
money
service provider
module
connection
Prior art date
Application number
HU9801603A
Other languages
English (en)
Inventor
Sholom S. Rosen
Original Assignee
Citibank, N.A.
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
Application filed by Citibank, N.A. filed Critical Citibank, N.A.
Publication of HUP9801603A2 publication Critical patent/HUP9801603A2/hu
Publication of HUP9801603A3 publication Critical patent/HUP9801603A3/hu
Publication of HU220576B1 publication Critical patent/HU220576B1/hu

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)
  • Polyurethanes Or Polyureas (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
  • Macromolecular Compounds Obtained By Forming Nitrogen-Containing Linkages In General (AREA)
  • Graft Or Block Polymers (AREA)

Abstract

A találmány elektronikuspénz-terjesztő rendszer, amelynek része vevőmegbízottja (2), a vevő megbízottjához (2) tartozó, vele védettüzenetváltásra alkalmas első pénzmodul (6), a vevő megbízottjával (2)első, kódolással védett kapcsolat létesítésére alkalmas, szolgáltatómegbízottja (4), a szolgáltató megbízottjához (4) tartozó, vele védettüzenetváltásra alkalmas, az első pénzmodullal (6) második, kódolássalvédett kapcsolatot létesítő, második pénzmodul (6’), amely rendszerbenvevő megbízottja (2) elektronikuspénz-vásárlási szándék és -pénzlehívási feltételek információt közöl a szolgáltató megbízottjával(4), amely információ vételét a szolgáltató megbízottja átvételi jegyadásával visszaigazolja, a szolgáltató megbízottja (4)engedélyezőhálózatnál a vevő megbízottjától (2) kapott pénzlehívásifeltételekkel történő pénzlehívás engedélyezését kezdeményezi, amelyengedélyezés után a szolgáltató megbízottja (4) elektronikus pénznek amásodik pénzmodulból (6’) első pénzmodulba (6) juttatásátkezdeményezi. A találmány továbbá elektronikuspénz-terjesztő eljárás,a rendszerben történő alkalmazásra, amely rendszernek része vevőmegbízottja (2), a vevő megbízottjához (2) tartozó első pénzmodul (6),a szolgáltató megbízottja (4), a szolgáltató megbízottjához (4)tartozó második pénzmodul (6’), amely eljárás során a) kódolássalvédett, első kapcsolatot létesítenek a vevő megbízottja (2) és aszolgáltató megbízottja (4) között, b) vevő megbízottjából (2) akódolással védett első kapcsolatban elektronikuspénz-vásárlási szándékés -pénzlehívási feltételek információt közölnek a szolgáltatómegbízottjával (4), c) amely információ vételének igazolásaként aszolgáltató megbízottjával (4) átvételi jegyet készíttetnek, azátvételi jegybe belefoglalva, legalább részben, a vételi szándékinformációt és a szolgáltató bankszámlaszámát, d) szolgáltatómegbízottjából (4) a kódolással védett, első kapcsolatban eljuttatjákaz átvételi jegyet vevő megbízottjához (2), amely vevő megbízottja (2)ideiglenesen tárolja a megkapott átvételi jegyet, e) a szolgáltatómegbízottjával (4) engedélyezőhálózatnál a vevő megbízottjától (2)kapott pénzlehívási feltételekkel történő pénzlehívás engedélyezésétkezdeményezik, f) az első és második pénztármodul (6, 6’) közöttkódolással védett, második kapcsolatot létesítenek, g) amely másodikkapcsolatban elektronikus pénzt a szolgáltató megbízottja (4) másodikpénzmoduljából (6’) első pénzmodulba (6) juttatnak, amely elsőpénzmodulban (6) az átutalt elektronikus pénzt ideiglenesen tárolják,h) az első pénzmodulban (6) a kapcsolat lezárását kezdeményezik, akapcsolat lezárásával az elektronikus pénz tárolásának ideiglenesjellegét véglegesre változtatják, és biztonságosan informálják vevőmegbízottját (2) a sikeres elektronikuspénz-vételéről, i) a másodikpénztármodulban (6’) a második kapcsolatot lezárják

Description

A leírás terjedelme 60 oldal (ezen belül 41 lap ábra)
HU 220 576 Bl
c) amely információ vételének igazolásaként a szolgáltató megbízottjával (4) átvételi jegyet készíttetnek, az átvételi jegybe belefoglalva, legalább részben, a vételi szándék információt és a szolgáltató bankszámlaszámát,
d) szolgáltató megbízottjából (4) a kódolással védett, első kapcsolatban eljuttatják az átvételi jegyet vevő megbízottjához (2), amely vevő megbízottja (2) ideiglenesen tárolja a megkapott átvételi jegyet,
e) a szolgáltató megbízottjával (4) engedélyezőhálózatnál a vevő megbízottjától (2) kapott pénzlehívási feltételekkel történő pénzlehívás engedélyezését kezdeményezik,
f) az első és második pénztármodul (6,6’) között kódolással védett, második kapcsolatot létesítenek,
g) amely második kapcsolatban elektronikus pénzt a szolgáltató megbízottja (4) második pénzmoduljából (6’) első pénzmodulba (6) juttatnak, amely első pénzmodulban (6) az átutalt elektronikus pénzt ideiglenesen tárolják,
h) az első pénzmodulban (6) a kapcsolat lezárását kezdeményezik, a kapcsolat lezárásával az elektronikus pénz tárolásának ideiglenes jellegét véglegesre változtatják, és biztonságosan informálják vevő megbízottját (2) a sikeres elektronikuspénz-vételéről,
i) a második pénztármodulban (6’) a második kapcsolatot lezáqák és vevő megbízottját (2) biztonságos úton informálják a pénztranszfer sikerességéről,
j) a vevő megbízottjában (2) az első kapcsolat lezárását kezdeményezik, a kapcsolat lezárásával az átvételi jegy tárolásának ideiglenes jellegét véglegesre változtatják,
k) szolgáltató megbízottjában (4) az első kapcsolatot lezárják.
A találmány tárgya elektronikuspénz-terjesztő rendszer, amelynek része vevő megbízottja, a vevő megbízottjához tartozó, vele védett üzenetváltásra alkalmas első pénzmodul, a vevő megbízottjával első, kódolással védett kapcsolat létesítésére alkalmas, szolgáltató megbízottja, a szolgáltató megbízottjához tartozó, vele védett üzenetváltásra alkalmas, az első pénzmodullal második, kódolással védett kapcsolatot létesítő, második pénzmodul. A találmány tárgya továbbá elektronikuspénz-terjesztő eljárás, a rendszerben történő alkalmazásra.
Számos, különböző elektronikus fizetési rendszer van, részben fejlesztés alatt, részben alkalmazásban. Ilyen elektronikus fizetési rendszer van ismertetve jelen bejelentő alábbi, amerikai egyesült államokbeli szabadalmi bejelentéseiben: US 5453601 (1991. november
15.), US 5557518 (1994. április 28.), US 5799087 (1995. április 21.). A fenti bejelentések mellékleteiben elektronikus eszközökkel történő fizetésre alkalmas elektronikus pénzrendszer is le van írva, amely eszközök helyettesíthetik a hagyományos készpénzre váltást, készpénzzel, csekkel, bankkártyával történő fizetést, és a hagyományos pénzátutalásokat. A rendszerben feltörésnek mechanikusan ellenálló házakba zárt pénzmodulok vannak alkalmazva, amely pénzmodulokban elektronikuspénz-megjelenítő van tárolva. A pénzmodulok alkalmasak azonnali, off-line fizetésekre pénzmodulok között [például egy, a vevő zsebében hordott pénzmodul és a szolgáltató (kereskedő) italautomatája között], és alkalmasak hálózaton át történő, on-line fizetésekre is (például hálózaton át beszerzett információért, repülőjegy, színházjegy foglalásért stb.).
Az e bejelentésben említett „vevő megbízottja” és „szolgáltató megbízottja” részletesen ismertetve van az US 5557518 szabadalmi leírásban (benyújtva 1994. április 28-án). Az említett bejelentésben elektronikus vásárlás során, elektronikus áruk biztonságos továbbításának eszközei és módjai vannak ismertetve real-time, anonim és pénzlehívási feltételekkel történő fizetés esetén. Az ott ismertetett megoldás lehetővé teszi, hogy mind a szolgáltató, mind a szolgáltatás vevője biztonságban érezze az érdekeit.
Készpénzhez bankokból széles körűen hozzá lehet jutni. Ahhoz, hogy az elektronikus pénz használata elterjedjen, ugyancsak arra van szükség, hogy széles körben hozzá lehessen jutni. A találmányunkban arra adunk megoldást, hogyan lehet széles körben, a megbízottak (ezek készülékek) és elektronikuspénz-teijesztő szolgáltatók pénzlehívást engedélyező (bankkártya) hálózattal összekapcsolt megbízottja bevonásával elektronikus pénzhez jutni. Az elektronikus pénz vásárlása az új megoldás szerint a szolgáltatótól távoli helyen és a banki hálózatba történő bekapcsolódás nélkül is megtörténhet, ami jelentősen kibővíti az elektronikus pénz vásárlásának lehetőségeit. A rendszer lehetővé teszi a pénznemek közötti átváltást is, például USD vásárlását angol fontért.
Az említett US 5453601 számú szabadalmi leírás szerinti pénzrendszer alkalmas elektronikus pénz és hagyományos pénz átváltására, cseréjére. Az ilyen váltás lebonyolítására a banki pénztárak és pénzkiadó automaták alkalmasak leginkább. Elektronikus pénzzel, helyben történő fizetésnek feltétele, hogy az elektronikus pénz elfogadására a pénzkiadó és árukiadó automaták alkalmasak legyenek, és a terminálok alkalmasak legyenek a tranzakció biztonságának garantálására.
A jelen találmány olyan, a szolgáltatótól távoli helyen történő, biztonságos fizetésekre vonatkozik, amelyek nem igényelnek speciális terminált vagy pénzkiadó, árukiadó automatát. A vevő számára a biztonságot megbízott igénybevétele jelenti. Nincs szükség a vevő számára ismeretlen, speciális terminálokra, amelyek ellenszolgáltatás nélkül elnyelhetnék a vevő pénzét vagy megszerezhetnék a bankszámlájához történő hozzáféréshez szükséges információt.
Célunk a találmánnyal az ismert megoldások hiányosságainak kiküszöbölése.
Célunk megbízottak bevonása a tranzakciókba, főként az elektronikus pénz lehívásának, terjesztésének
HU 220 576 Bl megkönnyítése érdekében. További célunk elektronikus pénz, szolgáltatótól távoli helyen történő megvásárlásának és eladásának lehetővé tétele. Olyan rendszert kívánunk létrehozni, amelyben a szolgáltató a vevő elektronikus pénz vásárlására irányuló igényét akkor is ki tudja elégíteni, ha nincs a birtokában az ehhez szükséges elektronikus pénz.
A feladat találmány szerinti megoldása elektronikuspénz-terjesztő rendszer, amelynek része vevő megbízottja, a vevő megbízottjához tartozó, vele védett üzenetváltásra alkalmas első pénzmodul, a vevő megbízottjával első, kódolással védett kapcsolat létesítésére alkalmas, szolgáltató megbízottja, a szolgáltató megbízottjához tartozó, vele védett üzenetváltásra alkalmas, az első pénzmodullal második, kódolással védett kapcsolatot létesítő, második pénzmodul, amely rendszerben vevő megbízottja elektronikuspénz-vásárlási szándék és -pénzlehívási feltételek információt közöl a szolgáltató megbízottjával, amely információ vételét a szolgáltató megbízottja átvételi jegy adásával visszaigazolja, a szolgáltató megbízottja engedélyezőhálózatnál a vevő megbízottjától kapott pénzlehívási feltételekkel történő pénzlehívás engedélyezését kezdeményezi, amely engedélyezés után a szolgáltató megbízottja elektronikus pénznek a második pénzmodulból első pénzmodulba juttatását kezdeményezi.
Előnyösen a vevő pénzlehívási feltételei egy debit vagy kredit bankkártyán vannak adva.
Célszerűen a vevő megbízottja továbbá elektronikuspénz-eladási szándék információt is közöl a szolgáltató megbízottjával, amely szolgáltató megbízottja a kapott eladási szándék és pénzlehívási feltételek információt felhasználva, engedélyezőhálózatnál pénzlehívás engedélyezését kéri, amely engedélyezés után a szolgáltató megbízottja elektronikus pénznek az első pénzmodulból a második pénzmodulba juttatását kezdeményezi.
Előnyösen a szolgáltató megbízottja más, elektronikus pénznek közös tulajdonú pénzmodulból, a második pénzmodulba juttatását kezdeményezi, majd a második pénzmodulba juttatott elektronikus pénznek az első pénzmodulba juttatását kezdeményezi.
Célszerűen a szolgáltató második pénzmodul elektronikus pénzt kibocsátó bank banki hálózatához fordul, ahonnan elektronikus pénzt hív le, és ezt továbbítja vevő első pénztármoduljába.
Előnyösen az átvételi jegy a vevő bankjának azonosítóját, a vevő bankszámlaszámát és a lehívásra engedélyezett összeget tartalmazza.
A találmány szerinti megoldás továbbá elektronikuspénz-teijesztő rendszer, amelynek része vevő megbízottja, a vevő megbízottjához tartozó, vele védett üzenetváltásra alkalmas első pénzmodul, a vevő megbízottjával első, kódolással védett kapcsolat létesítésére alkalmas, szolgáltató megbízottja, a szolgáltató megbízottjához tartozó, vele védett üzenetváltásra alkalmas, az első pénzmodullal második, kódolással védett kapcsolat létesítésére alkalmas, második pénzmodul, amely rendszerben vevő megbízottja elektronikuspénz-eladási szándék és -pénzlehívási feltételek információt közöl a szolgáltató megbízottjával, amely információ vételét a szolgáltató megbízottja átvételi jegy adásával visszaigazolja, a szolgáltató megbízottja engedélyezőhálózatnál, a vevő megbízottjától kapott pénzlehívási feltételekkel történő és pénzeladási szándéknak megfelelő pénzlehívás engedélyezését kezdeményezi, amely engedély birtokában a szolgáltató megbízottja elektronikus pénznek az első pénzmodulból a második pénzmodulba juttatását kezdeményezi.
Előnyösen a pénzlehivási feltételek egy debit vagy kredit bankkártyán vannak adva.
Célszerűen az átvételi jegy a szolgáltató bankjának azonosítóját, a szolgáltató bankszámlaszámát és a lehívásra engedélyezett összeget tartalmazza.
A találmány továbbá elektronikuspénz-teijesztó eljárás a rendszerben történő alkalmazásra, amely rendszernek része vevő megbízottja, a vevő megbízottjához tartozó első pénzmodul, a szolgáltató megbízottja, a szolgáltató megbízottjához tartozó második pénzmodul, amely eljárás során
a) kódolással védett, első kapcsolatot létesítünk a vevő megbízottja és a szolgáltató megbízottja között,
b) vevő megbízottjából a kódolással védett első kapcsolatban elektronikuspénz-vásárlási szándék és -pénzlehívási feltételek információt közlünk a szolgáltató megbízottjával,
c) amely információ vételének igazolásaként a szolgáltató megbízottjával átvételi jegyet készíttetünk, az átvételi jegybe belefoglalva, legalább részben, a vételi szándék információt és a szolgáltató bankszámlaszámát,
d) szolgáltató megbízottjából a kódolással védett, első kapcsolatban eljuttatjuk az átvételi jegyet vevő megbízottjához, amely vevő megbízottja ideiglenesen tárolja a megkapott átvételi jegyet,
e) a szolgáltató megbízottjával engedélyezőhálózatnál a vevő megbízottjától kapott pénzlehívási feltételekkel történő pénzlehívás engedélyezését kezdeményezzük,
f) az első és második pénztármodul között kódolással védett, második kapcsolatot létesítünk,
g) amely második kapcsolatban elektronikus pénzt a szolgáltató megbízottja második pénzmoduljából első pénzmodulba juttatunk, amely első pénzmodulban az átutalt elektronikus pénzt ideiglenesen tároljuk,
h) az első pénzmodulban a kapcsolat lezárását kezdeményezzük, a kapcsolat lezárásával az elektronikus pénz tárolásának ideiglenes jellegét véglegesre változtatjuk, és biztonságosan informáljuk vevő megbízottját a sikeres elektronikuspénz-átvételről,
i) a második pénztármodulban a második kapcsolatot lezárjuk, és vevő megbízottját biztonságos úton informáljuk a pénztranszfer sikerességéről,
j) a vevő megbízottjában az első kapcsolat lezárását kezdeményezzük, a kapcsolat lezárásával az átvételi jegy tárolásának ideiglenes jellegét véglegesre változtatjuk,
k) szolgáltató megbízottjában az első kapcsolatot lezárjuk.
Előnyösen a pénzlehívási feltételeket egy debit vagy kredit bankkártyával adjuk meg.
HU 220 576 Β1
Célszerűen a vevő megbízottja kiértékeli a megkapott átvételi jegyet.
A találmány továbbá olyan elektronikuspénz-teijesztő eljárás, a rendszerben történő alkalmazásra, amely rendszernek része: vevő megbízottja, a vevő megbízottjához tartozó első pénzmodul, a szolgáltató megbízottja, a szolgáltató megbízottjához tartozó második pénzmodul, amely eljárás során
a) kódolással védett, első kapcsolatot létesítünk a vevő megbízottja és a szolgáltató megbízottja között,
b) vevő megbízottja útján az első kapcsolatban elektronikuspénz-eladási szándék és -pénzlehívási feltételek információt közlünk a szolgáltató megbízottjával,
c) amely információ vételének igazolásaként a szolgáltató megbízottjával átvételi jegyet készíttetünk, az átvételi jegybe belefoglalva legalább részben a pénzeladási szándék információt és a szolgáltató bankszámlaszámát,
d) szolgáltató megbízottjától az első kapcsolatban eljuttatjuk az átvételi jegyet vevő megbízottjához, amely vevő megbízottja ideiglenesen tárolja a megkapott átvételi jegyet,
e) a szolgáltató megbízottja útján engedélyezőhálózatnál a vevő megbízottjától kapott pénzeladási szándékkal és pénzlehívási feltételekkel összhangban történő pénzlehívás engedélyezését kezdeményezzük,
f) az első és második pénztármodul között kódolással védett, második kapcsolatot létesítünk,
g) amely második kapcsolatban elektronikus pénzt a vevő megbízottja első pénzmoduljából a szolgáltató második pénzmoduljába juttatunk, amely pénzt a második pénzmodulban ideiglenesen tároljuk,
h) az első pénzmodulban a kapcsolat lezárását kezdeményezzük, és vevő megbízottját biztonságos úton informáljuk a pénztranszfer sikerességéről,
i) a második pénztármodulban a második kapcsolatot lezárjuk, a kapcsolat lezárásával az elektronikus pénz tárolásának ideiglenes jellegét véglegesre változtatjuk, és szolgáltató megbízottját biztonságos úton informáljuk a pénz vételéről,
j) a vevő megbízottjában az első kapcsolat lezárását kezdeményezzük, a kapcsolat lezárásával az átvételi jegy tárolásának ideiglenes jellegét véglegesre változtatjuk,
k) szolgáltató megbízottjában az első kapcsolatot lezárjuk.
Előnyösen a pénzlehívási feltételeket egy, a vevő bankszámlaszámát tartalmazó debit vagy kredit bankkártyával adjuk meg.
Célszerűen a vevő megbízottja kiértékeli a megkapott átvételi jegyet.
A találmány továbbá elektronikuspénz-terjesztő rendszer, amelynek része egy feltörés ellen védett, első elektronikus tranzakciós eszköz, amelynek első processzora van, továbbá része egy feltörés ellen védett, második elektronikus tranzakciós eszköz, amelynek második processzora van, és amely második tranzakciós eszköz az első tranzakciós eszközzel, kódolással védett kapcsolat létesítésére alkalmasan van kialakítva, amely rendszerben az első processzor elektronikuspénz-vételi szándék és -pénzlehívási feltételek információ második processzorral történő közlésére alkalmasan van kialakítva, a második processzor az első processzortól megkapott pénzvételi szándék és a pénzlehívási feltételek átvételi jegybe foglalására és az átvételi jegy kódolással védett kapcsolatban, az első processzorhoz továbbítására alkalmasan van kialakítva, a második processzor egy engedélyezőhálózatnál az első processzortól kapott pénzvételi szándék információnak megfelelő és a pénzlehívási feltételekkel történő pénzlehívás engedélyezésére alkalmasan van kialakítva, a második tranzakciós eszköz az engedély birtokában, elektronikus pénznek az első tranzakciós eszközből a második tranzakciós eszközbe, vevő bankjának pénzterjesztő tevékenységétől függetlenül történő juttatására alkalmasan van kialakítva.
Előnyösen a második elektronikus tranzakciós eszköz szolgáltató banki hálózatával és vevő banki hálózatával kapcsolatban lévő, a pénzlehívást engedélyező, engedélyezőhálózattal van kapcsolatban.
Célszerűen a második elektronikus tranzakciós eszköz szolgáltató banki hálózatának elektronikus pénzt terjesztő bankjával van kapcsolatban.
Előnyösen az első processzortól megkapott pénzlehívási feltételek vevő debit vagy kredit bankkártyáján vannak adva, és tartalmazzák a vevő bankszámlaszámát.
A találmány végül elektronikuspénz-teqesztő rendszer, amelynek része egy feltörés ellen védett, első elektronikus tranzakciós eszköz, amelynek első processzora van, továbbá része egy feltörés ellen védett, második elektronikus tranzakciós eszköz, amelynek második processzora van, és amely második tranzakciós eszköz az első tranzakciós eszközzel, kódolással védett kapcsolat létesítésére alkalmasan van kialakítva, amely rendszerben az első processzor elektronikuspénz-eladási szándék és -pénzlehívási feltételek információ második processzorral történő közlésére alkalmasan van kialakítva, a második processzor az első processzortól megkapott pénzeladási szándék és a pénzlehívási feltételek átvételi jegybe foglalására és az átvételi jegy kódolással védett kapcsolatban, az első tranzakciós modulhoz továbbítására alkalmasan van kialakítva, a második processzor egy engedélyezőhálózatnál az első processzortól kapott pénzeladási szándék információnak megfelelő és a pénzlehívási feltételekkel történő pénzlehívás kezdeményezésére alkalmasan van kialakítva, a második tranzakciós eszköz, az engedély birtokában, elektronikus pénznek az első tranzakciós eszköztől történő lehívására alkalmasan van kialakítva.
Előnyösen a második elektronikus tranzakciós eszköz szolgáltatóhálózatával és vevő banki hálózatával kapcsolatban lévő, a pénzlehívást engedélyező, engedélyezőhálózattal van kapcsolatban.
Célszerűen a második elektronikus tranzakciós eszköz szolgáltató banki hálózatának elektronikus pénzt teqesztő bankjával van kapcsolatban.
HU 220 576 Bl
Előnyösen a pénzlehívási feltételeket egy, a vevő bankszámlaszámát tartalmazó debit vagy kredit bankkártya tartalmazza.
Az alábbiakban kiviteli példákra vonatkozó rajz alapján részletesen ismertetjük a találmány lényegét. A rajzon az
1. ábra vevő és szolgáltató megbízottja, valamint pénzmoduljaik közötti tranzakciók szemléltető ábrája, a
2. ábra különböző átvételi jegyek mezőit szemléltető ábra, a
3. ábra tranzakciós eszköz funkciós egységeinek tömbvázlata, a
4A-4D. ábra tranzakciós eszköz funkciós egységeinek összetevői, az
5. ábra elektronikuspénz-teijesztő hálózat szerkezete, tömbvázlat, a
6A. ábra sikeres kapcsolat lezárása, protokoll, a 6B. ábra sikertelen kapcsolat megszakítása, protokoll, a
7A-7G. ábra elektronikus pénz vásárlása pénzlehívási feltételes fizetéssel, a
8A-8E. ábra kapcsolat létesítése, protokoll, a
9. ábra üzenetküldés-protokoll, a
10. ábra fizetési feltételek ellenőrzése, protokoll, a
11. ábra tranzakció visszafejtése, protokoll, a
12A-12E. ábra fizetés elektronikus pénzzel, protokoll, a
13. ábra üzenetek kódolási rétegeinek szemléltető ábrája, a
14A-14E. ábra pénzmodulok közötti kapcsolat létesítésének protokollja, a
15. ábra irányított üzenetküldés protokollja, a
16. ábra MM/ΤΑ üzenetküldés protokollja, a
17. ábra ΤΑ/MM üzenetküldés protokollja, a
18A-18B. ábra pénzmodulok tranzakciómegszakító protokollja, a
19. ábra E-irányított üzenetküldés protokollja, a
20A-20B. ábra bankjegytranszfer-protokoll, a
21. ábra pénzmodulok tranzakcióskapcsolat-lezáró protokollja.
Amint az az említett US 5557518 számú szabadalmi leírásban ismertetve van, egy megbízott (megbízott ügynök) egy eszköz, amelynek hardver- és szoftverrészei vannak. A tokozása ellenáll a feltörési kísérleteknek és biztonsági protokollok biztosítják a szolgáltatás és a fizetés szimultán és biztonságos lebonyolítását. Az elektronikus pénz előnyösen elektronikus bankjegyek formájában kerül tárolásra, illetve megbízottak közötti mozgatásra. Az elektronikus bankjegy jellege lehet kredit (hitelpénz) és debit (pozitív) pénz. A pénzmodulok is képesek egymással pénzátutaló adatátviteli, kódolással védett kapcsolatot létesíteni. E bejelentés szerinti megoldásban is előnyösen alkalmazhatók a US 5453601 és US 5799087 számú leírás szerinti pénzmodulok.
Hálózaton keresztül történő elektronikus vásárlásnál az áru és a pénz cseréje a vevő és szolgáltató megbízottja között történik. A találmány szerint 4 szolgáltató megbízottja (MTA) 2 vevő megbízottjához (CTA) átvételi jegyet küld (1. ábra). Válaszul - ha a vevő elektronikus pénzt ad el - a vevő 6 pénzmodulja elektronikus pénzt küld a szolgáltató 6’ pénzmoduljába, a 2 vevő megbízottján és a szolgáltató 4 megbízottján keresztül. Ha a vevő vásárol elektronikus pénzt, akkor az elektronikus pénz útja fordított: a szolgáltató 6’ pénzmoduljából a vevő 6 pénzmoduljába kerül.
Átvételi jegyek
Az 1. ábra szerinti 4 szolgáltató megbízottja a 2. ábra szerinti átvételi 8 jegyet küld a 2 vevő megbízottjának egy tranzakcióban. Az átvételi 8 jegy úgy fogható fel, mint a megbízottak tulajdona. A 2 vevő megbízottjának tulajdonosa (előfizető, vevő) csak akkor használhatja az átvételi jegyet, ha a pénztranzakció sikeresen befejeződött.
Amint az az US 5557518 számú szabadalmi leírásban ismertetve van, a megbízottak különböző célra, különböző típusú átvételi jegyeket állíthatnak ki. A jelen bejelentés vonatkozásában főleg a pénzlehívási feltételeket igazoló átvételi jegynek és a pénz átvételét igazoló átvételi jegynek van jelentősége. A feltételeket igazoló átvételi jegy azonosítja a tulajdonost, és meghatározott kiváltságokat biztosít. Egy szemléletes példa a feltételeket igazoló jegyre a kredit vagy debit bankkártya (bankkártyaadatok), amelynek bemutatásával feltételes pénzlehívás (kifizetés bankszámláról) kezdeményezhető. A vevő pénzátvételét igazoló (elektronikus pénz vásárlásakor vagy eladásakor kiállított) átvételi jegye vita estén felhasználható bizonyításra.
A 2. ábrán egy átvételi 8 jegy egy lehetséges kialakítása van szemléltetve. Az átvételi 8 jegynek hat szekciója van: 10 azonosító, igazolt 12 komponensek, 14 jegykibocsátó szignója, 16 kibocsátó bizonylata, 18 jegytranszferlista és 20 küldőszignók. Az egyes szekciók is különböző mezőkből állnak.
A 10 azonosító szekció például az alábbi mezőkből tevődik össze: 22 szolgáltató vagy hatóság, amely mezőben a jegyet kiállító szolgáltató vagy hatóság azonosítója (például a pénzlehívási feltételekből kimásolt neve) van feltüntetve, továbbá tartalmazza a feltételek lejártának dátumát is. Egy 24 vevő megbízottja adatai mező tartalmazza a jegyet vevő megbízott azonosító számát, és a megbízott meghatalmazásának lejárati dátumát is. Egy 26 jegytipusmezőben van megjelölve a jegy típusa (például kredit vagy debit kártya, átvételi jegy stb.).
A 12 komponensek szekció a jegy törzsét képező, a jegy típusától és alkalmazási céljától függően különböző adatokat tartalmaz. A 2. ábrán példák vannak bemutatva a 12 komponensek szekciótartalmára.
Ha a jegy egy feltételes pénzlehívási jegy, azaz kredit vagy debit bankkártya, akkor a 12 komponensek szekció például tartalmazhat egy 36 bankazonosító mezőt, a pénzlehívási feltételeket kibocsátó (kártyakezelő) bank azonosítójával, egy 38 bankszámlaszámmezőt, egy 40 érvényesség kezdete mezőt, a kártyaérvényesség adatával, egy 42 lejárat dátuma mezőt, a kártya lejárati dátumával, és egy 44 vevő neve mezőt.
Ha az átvételi 8 jegy egy elektronikuspénz-vásárlásával kapcsolatos pénzátvételi jegy, akkor a 12 komponensek szekció például tartalmazhat 46 kártyakezelő
HU 220 576 Β1 bank (a vevő pénzlehívási feltételeiben megadott bank) azonosító mezőt, 48 bankszámlaszám-mezőt, 50 tranzakció típusa (például elektronikuspénz-vásárlás vagy -eladás) mezőt, 52 engedélyezett összegmezőt, 54 küldött vagy vett összegmezőt, 56 szolgáltató díja mezőt, 58 tranzakció dátuma mezőt. Az engedélyezett összeg megegyezik a vett összeg és a szolgáltató díja összegével vagy a küldött összeg és az eladó díja különbségével.
A 14 jegykibocsátó szignója szekció a jegy készítőjének a 10 azonosítóhoz és 12 komponensekhez fűzött digitális szignóját tartalmazza. Ilyen digitális szignó a kibocsátó megbízott ügynökének egyéni kulcsával készül.
A 16 kibocsátó bizonylata szekció egy harmadik fél, a megbízott ügynökség által kiállított bizonylat, a kibocsátó digitális szignójával, amely szignó igazolja a kibocsátott átvételi 8 jegy autentikusságát. Az ilyen bizonylat a kibocsátó megbízott ügynöke tulajdonának tekinthető. A bizonylatok és digitális szignók alkalmazása ismert, és le van írva például D. W. Davies and W-L. Price, Security Fór Computer Networks (John Wiley & Sons, 1984) irodalmi helyen.
A 18 jegytranszferlista-szekció a jegy megbízottak közötti transzferéivel kapcsolatos Információkat tartalmaz, a kibocsátástól kezdve, sorrendben. A 18 jegytranszferlista például az alábbi mezőket tartalmazza : 28 vevő megbízottját azonosító kód, 30 küldő megbízottját azonosító kód, 32 küldő megbízott bizonylata, 34 jegytranszfer dátum/idő mező. A 18 jegytranszferlista feljegyzést tartalmaz a jegy mindegyik tranzakciójáról, így leírja a jegy történetét (múltját). Megjegyzendő, hogy a megbízottak azonosítójának a 28 vevőazonosító kódmezőben egyeznie kell a 30 küldő megbízottazonosító mezőben előző feljegyzés szerinti azonosítóval. Valahányszor az átvételi 8 jegy transzferálva van megbízottak között, a küldő mindannyiszor szignálja a jegyet a megelőző öt szekciót átfogóan, erre a küldő megbízott egyedi kulcsát alkalmazva.
A 20 küldőszignók-szekció minden tranzakciónál frissítve van a legújabb digitális szignóval, így a küldők szignóiból egy lista képződik.
Tranzakciós eszközök
A 3. ábrán egy 122 tranzakciós eszköz tömbvázlata van feltüntetve. A 122 tranzakciós eszköz lehet például vevő tranzakciós eszköze, vagy szolgáltató (eladó) tranzakciós eszköze, mindkét célra hasonló felépítésű 122 tranzakciós eszköz használható. A 122 tranzakciós eszköz három egységből tevődik össze: 124 hőst processzorból, 120 megbízottból (megbízott ügynök feladatát ellátó egység), és 6 pénzmodulból, A 122 tranzakciós eszköz egységei közötti kapcsolat ellátására például 126 busz szolgál. A 2 vevő megbízottja (CTA) a vevő (B) tranzakciós eszközének (CTD) része, a 4 szolgáltató megbízottja a szolgáltató (A) tranzakciós eszközének (MTD) része.
A 3. ábrán a 124 hőst processzor funkcionális egységei fel vannak tüntetve. Ezek az alábbiak: 128 kapcsolatok, 130 tranzakcióalkalmazások, 132 humán/gépi interfész, 136 dátum/idő, 134 üzenetmenedzser.
A 128 kapcsolatok funkciós egység a 122 tranzakciós eszköz külső kapcsolatait támogatja. A külső kapcsolatok lehetnek vezetékes vagy vezeték nélküli, széles sávú vagy keskeny sávú, kompatibilis kapcsolatok eszközök között. A 128 kapcsolatok funkció létesít kapcsolatot két 122 tranzakciós eszköz között, vagy egy hálózattal, a hálózaton át közvetett kapcsolatot létesít más 122 tranzakciós eszközzel vagy megbízott szerverrel.
A 130 tranzakciós alkalmazások funkció számos feladatot lát el. így például megkutatja a szolgáltató hálózatát a legkedvezőbb szolgáltatási díj, vagy a legjobb átváltási arány megkeresése érdekében egy elektronikus pénzzel lebonyolítandó tranzakció előtt. Általában az mondható, hogy a 130 tranzakciós alkalmazás elvégzi a tranzakciós döntést előkészítő tájékozódást elektronikus áru, elektronikus pénz és más eszközök, például átvételi 8 jegyek vonatkozásában.
A 132 humán/gépi interfész útján tart kapcsolatot a tulajdonos a 122 tranzakciós eszközével, ezt látja és érzékeli. A 132 humán/gépi interfészt alkothatja billentyűzet, egér, ceruza, hang, érzékeny ernyő, ikonok, menük stb. A 132 humán/gépi interfész a 122 tranzakciós eszköz egységeivel van a 134 üzenetmenedzser közvetítésével kapcsolatban. Számos alkalmazásban elhagyható a 132 humán/gépi interfész: teljesen automatizált tranzakciós eszközök esetében.
A 136 dátum/idő funkció óráját a tulajdonos állítja be. Az általa szolgáltatott adatok, például az aktuális dátum, időpont és időzóna. A dátum/idő információt a funkció mindannyiszor megadja a 120 megbízott számára, amikor azt használatra megnyitották.
A134 üzenetmenedzser vezérli a 122 tranzakciós eszközön belüli kapcsolatokat: így a 124 hőst processzor, a 120 megbízott és a 6 pénzmodul közötti kapcsolattartást.
Megbízottak
A 4A. ábrán a 120 megbízott funkcionális egységei vannak tömbvázlatszerűen szemléltetve. Az elektronikuspénz-teijesztő rendszerben háromféle 120 megbízottat alkalmazunk, amelyek néhány sajátos 146 átutalófunkcióban eltérnek egymástól. A 4B. ábrán a 2 vevő megbízottjában alkalmazott 146 átutalófunkció, a 4C. ábrán a 4 szolgáltató megbízottjában alkalmazott 146 átutalófunkció, a 4D. ábrán hatóság tranzakciós eszközébe (ATD) ágyazott megbízott 146 átutalófunkciói vannak szemléltetve. Hatóság tranzakciós eszköze (ATD) például kártyakibocsátó és a pénzlehívási feltételeket ellenőrző, feltételes fizetést engedélyező banknál kerül alkalmazásra.
A 4A. ábrán feltüntetett 120 megbízott 138 külső interfész funkciója fizikai kapcsolatot létesít a 124 hőst processzorral és a 6 pénzmodullal, amelyek a 122 tranzakciós egységbe vannak beágyazva. Egy 140 üzenetinterfész-funkció kidolgozza és irányítja a megbízotton belüli és a megbízottak közötti üzeneteket. Egy 142 kapcsolatmenedzser létesíti, és megszakítja, illetve lezáija a megbízottak közti és a megbízott-megbízott szerver közti kapcsolatokat. Egy 144 biztonsági menedzser fenntartja a biztonsági információkat (mint például az ügynökök bizonylata és a megbízhatatlanok listája) továbbá biztonságos kapcsolatot létesít a másik üzletfél megbízottjával (a 124 hőst processzor útján), és a saját megbízott 6 pénzmoduljával. Egy 146 átutalófunkció a
HU 220 576 Bl tranzakció lebonyolításához szükséges protokollokat tartalmazza. Ezek különbözőek lehetnek aszerint, hogy vevő megbízottjáé (CTA), szolgáltató megbízottjáé (MTA) vagy hatóság megbízottjáé (ATA) a 146 átutalófunkció.
A 4B. ábrán vevő megbízottjának 146 átutalófunkcióját részletező példa van feltüntetve. Egy 158 vásárlásfunkció 8 jegyért vagy elektronikus árukért történő kifizetést valósít meg. Egy 160 host-hoz funkció egy interfészt képez a 124 hőst processzor felé. Egy 164 jegyet bemutat funkció információ vagy szolgáltatás elnyerése érdekében a 8 jegy bemutatásáról gondoskodik. Egy 166 feltételeket lekér funkció a pénzlehívási feltételeket tartalmazó jegy vételében működik közre. Egy 162 tranzakció lóg funkció feljegyzéseket tárol a megbízott tranzakcióiról. Mind a 2 vevő megbízottja, mind a 4 szolgáltató megbízottja készít tranzakciófeljegyzéseket, amelyek az alábbi adatokat tartalmazzák: tranzakció típusa (például jegy típusú), a jegy tranzakció előtti alakja, vitainformáció a vita dátumával (amit mindegyik megbízott használ a vita dialógusában), állapot, szolgáltató döntése (például kicserél, visszaszolgáltat, megtagad), és bizonylatfrissítő információk (például az újrabizonylatolás dátuma). Egy 168 „párbeszédet kezdeményez” funkció mutatja be az árut, ha a vevő elégedetlen vele.
A 4C. ábrán szolgáltatói 146 átutalófunkció összetétele van szemléltetve. Egy 170 vásárlásfunkció 8 jegyet, illetve elektronikus árukat cserél fizetéssel. Egy 172 host-hoz funkció egy interfész a tranzakciós eszköz 124 hőst processzora felé. Egy 176 jegyet átvesz funkció feldolgozza az átvett jegyet a szolgáltatásnyújtás vagy információszolgáltatás érdekében. Egy 177 feltételeket lekér funkció lekéri a szolgáltató feltételeit. Egy 174 tranzakció lóg funkció tárolja a megbízott tranzakcióiról készült feljegyzéseket. Egy 178 vitamegoldó funkció veszi a 8 jegyet és az elektronikus tárgyat (árut), a vevő kifogásai okának megszüntetése érdekében.
A 4D. ábrán hatósági 146 átutalófunkció összetétele van szemléltetve. Egy 180 „feltételeket készít” funkció állítja össze és szállítja a pénzlehívási feltételeket kérőnek a feltételeket tartalmazó kártyát (például kredit vagy debit bankkártyát), illetve kártyaadatokat. Egy 182 host-hoz funkció: interfész a tranzakciós eszköz 124 hőst processzora felé. Egy 184 jegyet átvesz funkció feldolgozza az átvett jegyet a szolgáltatásnyújtás vagy információszolgáltatás érdekében. Egy 186 feltételeket megújít funkció elfogadja az eddigi feltételeket, és azokat újra kibocsátja, új lejárati dátummal ellátva. Egy 183 tranzakció lóg funkció tárolja a megbízott tranzakcióiról készült feljegyzéseket. Egy 185 feltételeket lekér funkció megszerez hatósági feltételeket.
A 4A. ábra szerinti 150 pénzmodulhoz funkció egy interfész a saját tranzakciós eszköz 6 pénzmodulja felé, amelyen át fizetési utasítás adható. Egy 152 rejtjelezés-funkció közös kulccsal és szimmetrikus kulccsal rejtjelező funkciókat lát el. Bármely ismert rejtjelező eljárás alkalmazható, így például az ismert RSA és DES eljárások is. Egy 148 jegytartó funkció készít átvételi 8 jegyet a 4 szolgáltató megbízottjában, vagy tárol és kiad 8 jegyet a 2 vevő megbízottjában. Egy 156 véletIenszám-generátor véletlen számokat generál a rejtjelező kulcsok előállításához. Egy 154 dátum/idő funkció a hőst processzor által szállított dátum- és időadatokkal megdátumozza a 8 jegyet és értékeli a bizonylatokat, bemutatott jegyeket. A pillanatnyi órainformációt betápláljuk a 120 megbízottba minden alkalommal, amikor tranzakció céljából megnyitjuk (bekapcsoljuk és bejelentkezünk). A 120 megbízott az információt kikapcsolásáig tartja meg.
A megbízott/pénzmodul hardver állhat például az alábbiakból: egy a tranzakciós protokollokat lefuttató mikrovezérlő (például az INTEL 196 családból), egy nagy sebességű, felejtőmemória (SRAM), az operációs rendszernek, az alkalmazási rutinok egy részének, a rejtjelezési adatoknak a műveletvégzések idején történő tárolására, egy nemfelejtő memória az operációs rendszer, az alkalmazási szoftverek, jegyek, elektronikus pénz, transzferfeljegyzések és más adatok állandó tárolására, egy integrált áramkörös óra, amely referenciaidő-adatot szolgáltat, akkumulátor az óra számára, zajdióda vagy más véletlen jelforrás a véletlenszám-generátor számára.
Rendszeráttekintés
Az 5. ábrán elektronikuspénz-terjesztő rendszer példakénti felépítése van szemléltetve. 188 vevő tranzakciós eszköze a 198 szolgáltató tranzakciós eszközével előnyösen 190 bekötőhálózaton és szolgáltatói 192 hálózaton át tarthat kapcsolatot. A vevő megkutathatja a szolgáltatói 192 hálózatot, ha elektronikus pénzt kíván venni vagy eladni, a legkedvezőbb szolgáltatói díj és átváltási arány megtalálására. A rendszerben a tranzakció biztonságossága érdekében feltételes fizetési mód van alkalmazva, amely feltételes fizetési mód általában debit vagy kredit bankkártyával történő fizetést jelent. A vevő bankkártyaadatai a 188 vevő tranzakciós eszközében pénzlehívási feltételekként, tárolva van.
A helyi 192 szolgáltatói hálózat kapcsolatban van a szolgáltató 200 banki hálózatával (lásd bővebben az US 5453601 számú szabadalmi leírást), így hozzájuthat elektronikus pénzhez annak 202 pénzformátum-generátora, 204 banki pénztármodulja, és a bank on-line könyvelést végző 206 banki belső rendszere útján.
A debit vagy kredit kártya adataival (pénzlehívási feltételek) egy 208 engedélyezőhálózat pénzlehívási engedélyének megszerzése után lehet bankszámláról pénzt lehívni. A kártyahasználatot engedélyező rendszer ismert és általánosan elterjedt rendszer. E rendszerbe tartozik a bankkártya-kibocsátó vagy ügynöke, amelyek minden egyes kifizetést egyedileg engedélyeznek, ha a kártyaszámlán elegendő fedezet vagy engedélyezett hitelkeret van. A bankkártya-kibocsátó nemcsak leemelhet pénzt a bankszámláról, hanem pénzbefizetést is eszközölhet, például pénz visszatérítése esetén. A 208 engedélyezőhálózat össze van kötve a szolgáltató 200 banki hálózatával, amely 200 bankhálózat viszont a kártyaszámlát vezető bank 206 banki belső rendszerével van kapcsolatban.
Ez a felépítés lehetővé tesz elektronikus pénzhez jutást olyanoknak is, akik nem ügyfelei az elektronikus
HU 220 576 Β1 pénzrendszer bankjainak, a pénzhez jutás olyan szolgáltatók útján történhet, akiknek kapcsolatuk van az elektronikus pénzrendszer bankjaival. Ez a rendszerfelépítés az ilyen, nem ügyfél személyek számára úgy teszi lehetővé elektronikuspénz-vételét és eladását, mintha a saját bankszámlájáról venné azt ki, illetve saját bankszámláján helyezné el.
Megjegyzendő, hogy az elektronikus pénz terjesztését elláthatja az elektronikus pénzrendszerben részt vevő bank is, ha van 198 szolgáltatói tranzakciós eszköze. Természetesen, ez esetben nincs szükség a 192 szolgáltatói hálózatra, a szolgáltató 200 banki hálózata egyszerűen a bank 202 pénzformátum-generátora, 204 banki pénztármodulja 206 banki belső rendszere, a 208 engedélyezőhálózat és a 190 bekötőhálózat kapcsolatában látja el a feladatot.
Folyamatábrák
A további ábrákon feltüntetett folyamatábrákon A általában a szolgáltatóra, B általában a vevőre, illetve 122 tranzakciós eszközükre utaló jelölés az egymással kapcsolatot létesítő tranzakciós eszközök fő részeinek (120 megbízott, 124 hőst processzor, 6, 6’ pénzmodul) és funkciós egységeinek azonosításában. „B biztonsági menedzser” például a B vevő 188 tranzakciós eszközének (CTD) és ezen belüli 120 megbízottjának a 144 biztonsági menedzser funkciós egységét (4A. ábra) jelöli.
A folyamatábrák némelyik kockája egy-egy szubrutin lefuttatását fedi, az A szolgáltató 122 tranzakciós eszközében futó szubrutint és funkciós egységeit X jelöléssel, a B vevő 122 tranzakciós eszközében futó szubrutint és funkciós egységeit Y jelöléssel láttuk el. így például „kapcsolat létesítése ΧψΥ” a folyamatábrában egy szubrutin lefuttatását jelenti. Az ezzel előhívott szubrutin folyamatábrájában X=A, Y=B értendő.
Kapcsolat megszakítása, lezárása
A vevő megbízottja és szolgáltató megbízottja közötti kapcsolatban 8 jegyek és elektronikus pénz cserélnek gazdát. Ezeket a tranzakciókat biztonságosan kell lebonyolítani, hogy egyik oldalon se keletkezhessen vagy maradhasson fenn többlet. így nem engedhető meg, hogy az elektronikus pénz vagy jegy duplikálódjék, így a tranzakciók végén valamiből kétszer annyi legyen, mint a tranzakciók megkezdése előtt. Ugyanígy megengedhetetlen elektronikus pénz vagy jegy elvesztése a tranzakció megszakadása esetén. Ha például a kölcsönös tranzakció kezdetén A-nak van egy 8 jegye, amit átküld B-nek, az szükséges, hogy a tranzakció végén a 8 jegy B-nél legyen és A-nak ne legyen meg ez a 8 jegye. Különben előfordulhatna az, hogy a tranzakció végén A is, B is birtokol egy ilyen jegyet (jegy duplikálása), vagy előfordulhatna az is, hogy sem A, sem B nem lenne a 8 jegy birtokában (jegy elvesztése).
Annak érdekében, hogy a duplikálás vagy elvesztés valószínűségét egy minimumra szorítsuk le, tranzakciófeljegyzéseket szükséges készíteni, annak a lehetőségnek a figyelembevételével, hogy természetes, véletlen okból vagy szándékosan, a tranzakció lezárása előtt megszakadhat a kapcsolat. Ilyen természetes ok lehet például, ha megszakad az adatátviteli vonal, amelyen a kapcsolat folyamatban van. A duplikáció vagy elvesztés lehetőségének leszorítása elérhető oly módon, hogy azt az időablakot, amelyben ilyen esemény bekövetkezhet, minél kisebbre alakítjuk. A szándékos megszakító beavatkozás lehetőségének csökkentése érdekében csökkenteni szükséges egy ilyen beavatkozáshoz fűződő érdekeket, hogy ne élje meg megkísérelni a beavatkozást. Ha például egy beavatkozó csak veszíthet, például elveszíti a jegyét vagy pénzét, akkor nem éri meg neki beavatkozni a tranzakciós folyamatba.
Ezek a koncepciók érvényesülnek a találmány szerinti elektronikuspénz-terjesztő rendszerben és eljárásban, az alkalmazott protokollokban. Ezt annak megvalósításával értük el, hogy az ügynökök, illetve pénzmodulok kapcsolatában a megszakítást vagy lezárást mindig konzekvensen, szimmetrikusan alkalmazzuk. Ha például A a tranzakció (sikeres) lezárását választja, akkor B oldalán is automatikusan lezárás történik, ha viszont A egy tranzakció megszakítását választja, akkor automatikusan megszakítás történik B oldalán is. Egy inkonzisztencia fellépésekor a konzisztencia elérése és a duplikáció vagy elvesztés valószínűségének minimumra csökkentése érdekében a tranzakcióprotokollok időhatárt szabnak a tranzakció sikeres befej ezhetőségének.
A 6A. ábrán kapcsolat lezárása (sikeres tranzakció), a 6B. ábrán kapcsolat megszakítása (sikertelen tranzakció) protokolljának folyamatábrája van feltüntetve.
A megszakítás szubrutin az adott 120 megbízotton belül fut le, a tranzakció során bekövetkezett valamilyen hiba esetén. A megszakítás szubrutin lefutása visszafejti az addigi lépéseket és visszaállítja a tranzakció megkezdése előtti állapotot a 120 megbízottban. A szolgáltató 120 megbízottja, ha a megszakítás akkor történik, amikor a pénzlehívás már engedélyezve van a 208 engedélyezőhálózat által, az engedélyt is visszavonatja.
Kapcsolat lezárása szubrutin az adott megbízotton belül fut le, ha a tranzakció sikeresen befejeződött. Ekkor a 120 megbízott feljegyzést készít a sikeres tranzakcióról a tranzakció log-jában történő megőrzésre és ezután készen áll újabb tranzakcióra. Ha például egy jegytranszfer során a szolgáltató A megbízottja elektronikus 8 jegyet készít és ad át vevő B megbízottjának, és ez a kapcsolat megszakítása nélkül sikerült, A ideiglenesen tartja meg a 8 jegyet. Amikor A és B lezáiják a kapcsolatot, ezzel a jegy birtoklása elveszti feltételes jellegét, és véglegessé válik. Ha viszont A és B nem lezátják, hanem megszakítják a kapcsolatot, akkor A-nál megmarad a 8 jegy, amelynek másolatát átküldte és B-nél a lépések visszafejtése során törlődik az ideiglenesen tárolt 8 jegy. A törlésnek számos, ismert módja van.
Hasonló a helyzet a 6, 6’ pénzmodulok kapcsolatában, amelyben elektronikus pénz átutalása történik. Elektronikus pénz vásárlása során elektronikus pénz (elektronikus bankjegyek formájában) vándorol A pénzmodulból B pénzmodulba. Ennek során A pénzmodul a pénzállományából ideiglenesen levonja az átutalt összeget, B pénzmodul pedig ideiglenesen tárolja az átutalt összeget. Ha mindkét A és B pénzmodul lezárja a kapcsolatot, akkor a levonása és B pénz tárolása elveszti feltételes jellegét és véglegessé válik.
HU 220 576 Bl
A 6A. ábra szerinti „kapcsolat lezárása” szubrutin az alábbi lépéseket foglalja magában: A host-hoz: tranzakció lóg frissítése (230 lépés), „tranzakció befejezve” üzenet (232 lépés), A kapcsolatmenedzser: megjegyzi : a tranzakció befejezve (234 lépés).
A 6B. ábra szerinti „kapcsolat megszakítása” szubrutin az alábbi lépéseket foglalja magában: A kapcsolatmenedzser visszafejti a lépéseket és megjegyzi a megbízottak közötti kapcsolat megszakadását (236 lépés), A host-hoz funkció: üzenet host-nak: tranzakció megszakadt (238 lépés).
A kapcsolatmegszakító szubrutin közvetlenül, automatikusan beindul, ha például a 120 megbízott megállapítja, hogy egy bizonylat nincs érvényben. Beindítható a megszakítószubrutin akkor is, ha egy várt akció nem következik be. Ha például két 120 megbízott egymással kapcsolatban áll, mindketten figyelik az idő múlását egy időzítőprotokoll futtatásával. Például, ha egy első 120 ügynök üzenetet küldött a vele kapcsolatban lévő, másik 120 ügynöknek, és arra választ vár, az első 120 megbízott A kapcsolatmenedzsere beállít egy időzítőt, és az időzítő lefutásakor megszakít. Az A kapcsolatmenedzser sorszámozhatja is az elküldött üzeneteket, amely sorszám megjelenik a másik B 120 megbízott válaszüzenetében.
Ha az időzítés lefut, mielőtt a válaszüzenet megérkezett volna, az A kapcsolatmenedzser rákérdez B kapcsolatmenedzsemél, hogy a tranzakció folyamatban van-e még B-ben. Ha B nem válaszol, akkor A kapcsolatmenedzser megszakítja a tranzakciót. Ha A kapcsolatmenedzser azt a választ kapja, hogy a tranzakció B-ben még folyamatban van, akkor az időzítőjét későbbi időpontra állítja be. Ha A kapcsolatmenedzser egymás után, meghatározott számú alkalommal azt a választ kapja, hogy a tranzakció B-ben még folyamatban van, anélkül, hogy a várt válaszüzenet megérkezne, akkor megszakítja a tranzakciót. A 6, 6’ pénzmodulok közötti kapcsolatban ehhez hasonló időzítési rendszer érvényesül.
Elektronikus pénzvétele, eladása
A 7. (7A-7G.) ábrán feltételes fizetéssel történő elektronikuspénz-vásárlás és -eladás folyamatábrái vannak feltüntetve. Amikor egy A vevő elektronikus pénzt kíván venni a bankszámlája terhére, vagy elektronikus pénzt kíván eladni a bankszámlája javára (700 lépés), ehhez a 188 vevő tranzakciós eszközét veszi igénybe, amely eszköz tranzakcióalkalmazás-funkciója először megkutatja a 192 szolgáltató hálózatát a vevő számára legkedvezőbb lehetőséget (legkisebb szolgáltatói díj, legkedvezőbb átváltási arány) megkeresve (702 lépés), amit ez esetben a B 198 szolgáltató tranzakciós eszközénél talál meg. Megjegyzendő, hogy egy alternatív megoldásban az engedélyező hatóság szabhatja meg az átváltási arányt.
Az A hőst tranzakciós alkalmazás funkciója (HTA) ezután kapcsolatot keres a szolgáltató B hőst tranzakciós alkalmazás funkciójával (HTB), amire a vevő kiválasztja a tranzakció típusát, azaz megadja, hogy vásárolni vagy eladni kíván elektronikus pénzt (704 lépés). A hőst tranzakciós alkalmazás funkciója (HTA) ezután üzenetet küld a saját A megbízottnak, hogy vásároljon (vagy eladjon) elektronikus pénzt (706 lépés). Szolgáltató B hőst tranzakciós alkalmazás funkciója (HTB) üzenetet küld a saját B megbízottnak, hogy adjon át (vagy elfogadjon) elektronikus pénzt (708 lépés).
A szolgáltató és a vevő megbízottai között kódolással védett kapcsolat A—>B létesül (az US 08/234,461 bejelentésünkben leírtak szerint) kapcsolatlétesítő szubrutin lefuttatásával (710 lépés).
A 8, (8A-8E.) ábra szerinti szubrutinban A kapcsolatmenedzser A megbízott (ATA) bizonylatát kéri (296 lépés), A biztonsági menedzser a megbízott bizonylatát átküldi B kapcsolatmenedzsemek (298 lépés), A kapcsolatmenedzser A bizonylatát megküldi B megbízott kapcsolatmenedzserének (300 lépés). B kapcsolatmenedzser veszi a bizonylatot (302 lépés), B biztonsági menedzser átveszi a bizonylatot B kapcsolatmenedzsertől (304 lépés).
A B megbízottjának közös kulcsfunkciója értékeli A megbízott bizonylatának érvényességét (306 lépés) az US 5557518 és US 5799087 számú szabadalmi leírás szerinti protokollal. 308 lépés: A megbízott A-tól kapott bizonylata érvényes?
Ha A megbízott bizonylata nem érvényes, akkor B kapcsolatmenedzser ezt megjegyzi, és üzenetet küld A kapcsolatmenedzsernek: a kapcsolat megszakad (310 lépés). A kapcsolatmenedzser ezt megjegyzi (312 lépés). Ha A megbízott bizonylata érvényes, akkor B biztonsági menedzser leellenőrzi, nincs-e A megbízott a megbízhatatlanok listáján (314 lépés). 316 lépés: A megbízott a megbízhatatlanok listáján van? Ha A megbízott a megbízhatatlanok listáján van, a kapcsolat a 310-312 lépések szerint megszakad.
Ha A megbízott nincs a megbízhatatlanok listáján, akkor B véletlenszám-generátora R(B) véletlen számot és B értékelőüzenetet (ami egy másik véletlen szám) generál (318 lépés). Az R(B) véletlen szám egy esetleg használandó kapcsolatkulcs alapját képezi. A B értékelőüzenet is egy véletlen szám, amely az üzenet ismétlésének megakadályozását szolgálja. A B biztonsági menedzser összegyűjti az R(B) véletlen számot, a B értékelőüzenetet és A bizonylatát egy, az A ügynöknek küldendő üzenetbe (320 lépés). B közös kulcsfunkciója ezt az üzenetet kódolással titkosítja, kódoláshoz A megbízott közös kulcsát [TA(PK)] használva, amely közös kulcsot B ügynök az A megbízott bizonylatával együtt kapott meg (322 lépés). B kapcsolatmenedzser a kódolt üzenetet A kapcsolatmenedzserhez küldi (324 lépés). A kapcsolatmenedzser veszi az üzenetet B kapcsolatmenedzsertől (326 lépés).
A közös kulcs funkció dekódolja az üzenetet, a saját (közös kulcsának megfelelő) egyéni kulcsát használva (328 lépés), és értékeli az A bizonylat egyezését az eredetivel, tehát az érvényességét (330 lépés). Ha A megbízott visszakapott bizonylata nem érvényes, akkor az A kapcsolatmenedzser ezt megjegyzi és tranzakciómegszakító üzenetet küld B kapcsolatmenedzsemek (332 lépés). B kapcsolatmenedzser veszi az üzenetet és megjegyzi, hogy a kapcsolat megszakadt (334 lépés). Ha A bizonylata érvényes, akkor A biztonsági menedzser ellenőrzi, nincs-e B megbízott a megbízhatatlanok listá9
HU 220 576 Bl ján (336 lépés). 338 lépés: B megbízott a megbízhatatlanok listáján van? Ha B megbízott a listán van, akkor a kapcsolat a 332-334 lépésekben megszakad.
Ha B megbízott nincs a megbízhatatlanok listáján, akkor A véletlenszám-generátor R(A) véletlen számot és A értékelőüzenetet generál (340 lépés), A dátum/idő funkció dátum/idő adatot küld A biztonsági szervernek (342 lépés). A dátum és idő adatokat A és B kicserélik egymás között, hogy esetleg feljegyezhessék a tranzakció log-jukban. A biztonsági menedzser ezután formál és tárol egy megbízottak közötti TA/TA=R(A)xorR(B) kapcsolatkulcsot (344 lépés). A TA/TA kapcsolatkulcsot a két 120 megbízott közötti kapcsolatban az adatátvitel titkosító kódolására használjuk. A kapcsolatmenedzser összegyűjti egy üzenetbe az A és B értékelőüzeneteket, a dátum/idő adatot és az R(A) véletlen számot (344 lépés), A közös kulcs funkció kódolja az üzenetet a B megbízott közös kulcsával (amit A az A megbízott bizonylatával együtt megkapott) (346 lépés), és megküldi a kódolt üzenetet B megbízott B kapcsolatmenedzserének (348 lépés), B kapcsolatmenedzser veszi az üzenetet (350 lépés).
B közös kulcs funkció dekódolja a vett üzenetet, a dekódoláshoz saját (közös kulcsnak megfelelő) egyéni kulcsát használva (352 lépés). B kapcsolatmenedzser ellenőrzi a B értékelőüzenet helyességét, azaz azt, hogy az A-tól kapott üzenet szerinti B értékelőüzenet egyezik-e az eredeti B értékelőüzenettel, amit B küldött A-nak (354 lépés). 356 lépés: B értékelőüzenet helyes? Ha ez a feltétel teljesül, akkor B kapcsolatmenedzser ezt megjegyzi és indítja a tranzakciós kapcsolatot (358 lépés).
B kapcsolatmenedzser ezután formál és tárol egy megbízottak közötti TA/TA=R(A)XORR(B) kapcsolatkulcsot (360 lépés). Ezen a ponton A és B kapcsolatmenedzser is formált egy-egy kapcsolatkulcsot az egymás között fennálló kapcsolatban történő használatra. Ezután B dátum/idő funkció a pillanatnyi dátum/idő adatát megküldi B biztonsági menedzsernek (362 lépés). B biztonsági menedzser összeállít egy üzenetet, amely tartalmaz egy A-nak szóló, tudomásulvevő üzenetet, az A értékelőüzenetet és B dátum/idő adatát (364 lépés). Az üzenet B-től A-hoz küldése az üzenetküldő szubrutin lefuttatásával történik: kódolással védett üzenetküldés B-»A (366 lépés).
A 9. ábrán az üzenetküldés-protokoll folyamatábrája van feltüntetve. B megbízott szimmetrikus kulcsfunkciója kódolja az üzenetet a TA/TA kapcsolatkulcs alkalmazásával (376 lépés). B üzenetinterfész formálja az üzenetet és a hőst processzor üzenetmenedzseréhez továbbítja (378 lépés). B hőst üzenetmenedzser az üzenetet A hőst üzenetmenedzserrel fennálló kapcsolatában A megbízott hőst processzoréba továbbítja (380 lépés). A hőst üzenetmenedzser az üzenetet A megbízott üzenetinterfészéhez továbbítja (382 lépés), amely funkció az üzenetet lecsupaszítja (384 lépés). A szimmetrikus kulcsfunkció dekódolja az üzenetet a TA/TA kapcsolatkulcs alkalmazásával, azaz a kapcsolatkulcs alkalmazásával teszi kompletté az üzenetváltást (a megbízottmegbízott kapcsolatot) (386 lépés).
A 8. ábrára visszatérve: A biztonsági menedzser veszi az üzenetet, amely tartalmaz egy A-nak szóló, tudomásulvevő üzenetet, az A értékelőüzenetet és B dátum/idő adatát (368 lépés). A biztonsági menedzser leellenőrzi A értékelőüzenetet, hogy az megfelel-e annak, amit korábban A küldött B-nek (370 lépés). 372 lépés: A értékelőüzenet helyes? Ha A értékelőüzenet nem egyezik az eredetivel, A kapcsolatmenedzser megszakítja a kapcsolatot a 332-334 lépésekben. Ha A értékelőüzenet egyezik az eredetivel, tehát helyes, akkor az A kapcsolatmenedzser ezt megjegyzi és indítja a kapcsolatot (374 lépés).
A 7. ábrára visszatérve: a kapcsolat létrejötte után A megbízott kéri és ellenőrzi a szolgáltató B megbízottjának igazoló adatait, a már említett US 08/234,461 szabadalmi bejelentésünkben ismertetett módon. A 712 lépésben a 10. ábra szerinti „feltételek ellenőrzése” szubrutint futtatjuk le. Mindegyik szolgáltató tranzakciós eszköze tartalmaz igazoló adatokat (feltételek), amelyek azonosítják a szolgáltató tulajdonost (például NYREX, Ticketron stb.). Ilyen, szolgáltatói feltételeket például egy kereskedelmi hatóság bocsát ki és egy ezzel megbízott ügynökség ellenőriz. A 188 vevő tranzakciós eszközében tárolt feltételek viszont lehetnek gépjárművezetőijogosítvány-, bankkártyaadatok, amelyek különböző hatóságok által lettek kiadva. A 10. ábra szerint A vásárlásfunkció B vásárlásfunkciójának küld üzenetet, amelyben kéri a szolgáltató feltételeit: egy 444 lépésben A vásárlásfunkció tanúsítványt kér B-től, egy 446 lépésben szubrutin lefuttatásával kódolással védett A—>B üzenetben küldi el a kérését, 448 lépésben B vásárlásfunkció veszi az üzenetet. B jegytartó előveszi a szolgáltatói feltételeket (tanúsítványt) (450 lépés) és a 452 lépésben elküldi azt A-nak, ellenőrzésre. Egy 454 lépésben A biztonsági menedzser értékeli a megküldött szolgáltatói feltételeket: 456 lépés: feltételek érvényesek?
A szolgáltatói feltételek vagy bármilyen más típusú jegy értékelése az alábbiak szerint történhet:
1. értékeljük a kibocsátó bizonylatát és ellenőrizzük a kibocsátó szignóját,
2. értékelünk minden transzfert, a tekintetben, hogy egyeznek-e a vevő és küldő azonosítói (azaz So kibocsátó=Ro első átvevő, aztán RrS1+1, ahol i>0
3. értékelünk minden küldő bizonylatot és minden küldőszignót,
4. értékeljük, hogy az utolsó átvevő azonosítója egyezik-e a jelen kapcsolatban lévő megbízott bizonylatával.
Ha a szolgáltatói feltételek nem érvényesek, akkor a tranzakció megszakad a megszakítószubrutin lefuttatásával (458 lépés). All. ábra szerint A megbízott szakít meg a szubrutin lehívásával (458 lépés) és az A kapcsolatmenedzser küld üzenetet B megbízott kapcsolatmenedzserének arról, hogy a kapcsolat megszakad. Részletesebben: A megszakít (388 lépés), A kapcsolatmenedzser üzenetet küld: kapcsolat megszakítva (390 lépés), üzenetküldés A—>B (szubrutin) (392 lépés), B kapcsolatmenedzser veszi az üzenetet (394 lépés) és B megszakítja a kapcsolatot (396 lépés). A 10. ábra szerint, ha a szol10
HU 220 576 Β1 gáltatói feltételek érvényesek, akkor A host-hoz funkció a feltételek információt a hőst transzfer alkalmazásnak küldi megerősítésre (például a vevő vizuálisan ellenőrzi a szolgáltató nevét és jóváhagyja) (460-462 lépések).
A 7. ábra szerint az elektronikuspénz-vásárlás/eladás folyamata folytatódik. A host-hoz funkció vásárolni vagy eladni kívánt elektronikuspénz-összeg és -pénznem (dollár, font stb.)-adatot kér (714 lépés). A vevő vagy egy, a vevőt helyettesítő műveletsor beviszi az információt és továbbítja B megbízotthoz az alábbi lépésekben: 716 lépés: A vásárlásfunkció veszi az összegadatot és B-nek továbbítja, 718 lépés: kódolással védett üzenetküldés ΑψΒ (szubrutin).
B vásárlásfunkció veszi az üzenetet és ellenőrzi, kell-e elektronikus pénzt kapnia (720 lépés), 722 lépés: kell elektronikus pénzt kapni? Ha igen, akkor B vásárlásfunkció A megbízottól üzenetben kér pénzlehívási (bankkártya) feltételeket (750). 752 lépés: kódolással védett üzenetküldés ΒψΑ. A jegytartó veszi az üzenetet és kilistázza a lehetséges feltételeket A hőst tranzakciós alkalmazásnak (754 lépés). A hőst tranzakciós alkalmazás: választ a feltételek választékából és választását megküldi A megbízottnak (756 lépés). A jegytartó ezután előveszi a kiválasztott kredit vagy debit bankkártya feltételeit (758 lépés) és A vásárlásfunkció a kiválasztott feltételeket megküldi B megbízottnak (760 lépés). 762 lépés: kódolással védett üzenetküldés ΑψΒ (szubrutin).
B vásárlásfunkció a már leírt módon értékeli a feltételeket (764 lépés), 766 lépés: feltételek érvényesek? Ha a feltételek nem érvényesek, a tranzakció megszakad. Ha a feltételek érvényesek, B jegytartó elektronikuspénz-átvételéről átvételi 8 jegyet állít ki (768 lépés), B vásárlásfunkció a jegyet A hosthoz küldi (770 lépés). 772 lépés: kódolással védett üzenetküldés Β ψΑ (szubrutin).
A vásárlásfunkció veszi a jegyet és leellenőrzi annak érvényességét (774 lépés). 776 lépés: érvényes a bizonylat? Ha a jegy nem érvényes, a tranzakció megszakad (778 lépés). Ha a jegy érvényes, akkor A vásárlásfunkció elismerő üzenetet küld A host-hoz a vevő tájékoztatására és jóváhagyásra (780 lépés). Ha A vevő nem hagyja jóvá egy 782 lépésben, megszakad a tranzakció. Ha A vevő jóváhagyja, A vásárlásfunkció a jegyet A jegytartóhoz továbbítja (784 lépés). A jegytartó veszi a bizonylatot (786 lépés).
A vásárlásfunkció átvételt igazoló üzenetet küld B megbízottnak (788 lépés). 790 lépés: kódolással védett üzenetküldés ΑψΒ (szubrutin). B vásárlásfunkció megvizsgálja, van-e átveendő elektronikus pénz (792 lépés). 794 lépés: elektronikus pénz átvéve? Ha van átveendő elektronikus pénz, B host-hoz funkció az összeget és a pénzlehívási feltételeket tartalmazó üzenetet küld 208 engedélyezőhálózathoz (796 lépés), és ha a pénzlehívást a 208 engedélyezőhálózat engedélyezi (798 lépés), lehívja a bankszámláról az összeget az alábbi módon: B vásárlófunkció ellenőrzi a lehívás engedélyezését (800 lépés), 802 lépés: engedélyezve? Ha nincs engedélyezve, a tranzakció megszakad. Ha a pénzlehívás engedélyezve van, B vásárlásfunkció erről tájékoztató üzenetet küld A megbízottnak (804 lépés). 806 lépés: kódolással védett üzenetküldés ΑψΒ (szubrutin).
A megbízott erre végrehajt egy pénzmodulfizetést (részletesen leírva az US 5557548 számú szabadalmi leírásban) úgy, hogy a 808 lépésben lehív egy pénzmodul-fizetésszubrutint. A 12. ábra szerint A véletlenszám-generátor R(l) véletlen számot generál (520 lépés). A vásárlásfunkció pénzmodul fizetés és R(l) üzenetet küld B megbízottnak (522 lépés). 524 lépés: kódolással védett üzenetküldés ΑψΒ (szubrutin). B vásárlásfunkció veszi az üzenetet (526 lépés), B biztonsági menedzser veszi R(l) véletlen számot (528 lépés), B véletlenszám-generátor R(2) véletlen számot generál és küld A biztonsági menedzsernek (530 lépés). 532 lépés: kódolással védett üzenetküldés ΒψΑ (szubrutin). A és B biztonsági menedzserek mindegyike formál egy TA/MM=R(1)xorR(2) kapcsolatkulcsot (354, 356 lépés).
A 13. ábrán egy tranzakció során felépített, négy, kódolással védett 436,438,440,442 csatorna van szemléltetve. A 436 csatorna két 120 megbízott között épül fel, és TA/TA kapcsolatkulccsal kódolt üzeneteket hordoz. A 438 és 440 csatornák egy 120 megbízott és a hozzá tartozó 6 pénzmodul között épül fel, és TA/MM kapcsolatkulccsal kódolt üzeneteket hordoz. A 442 csatorna különböző 122 tranzakciós eszközök 6, 6’ pénzmoduljai között épül fel és MM/MM kapcsolatkulccsal kódolt üzeneteket hordoz.
A TA/MM kapcsolatkulcs a 120 megbízott és 6 pénzmodulja közötti üzenetek rejtjelező kódolására szolgál, a 438, illetve a 440 csatornában történő átvitel céljára. A folyamat azon pontján, ameddig a leírásban eljutottunk, csak a két 120 megbízottnak van TA/MM kapcsolatkulcsa. Mindkét 6, 6’ pénzmodul csak a folyamat további részében fogja lemásolni a TA/MM kapcsolatkulcsot, hogy használja azt a 120 megbízottjával tartandó kapcsolatban.
Megjegyzendő, hogy a 120 megbízott és 6 pénzmodulja lehetnek különálló, mechanikusan feltörés ellen védett, külön tokokba zárt egységek helyett, közös tokban elrendezett 122 tranzakciós eszközök is, amely esetben nem szükséges kódolással védett kapcsolatot létesíteni a 120 megbízott és 6 pénzmodulja között. A különálló 120 megbízott és 6 pénzmodul kialakításnak azonban előnye a nagyobb mobilitás, a pénzmodul jobb hordozhatósága (zsebben elfér).
A 12. ábra szerint A pénzmodulhoz funkció „fizess” üzenetet és R(l) véletlen számot küld A pénzmodulhoz (538 lépés). Ugyanakkor B pénzmodulhoz funkció R(2) véletlen számot és „fogadd a fizetést” üzenetet küld B pénzmodulhoz (540 lépés). A pénzmodul veszi az üzenetet (542 lépés), B pénzmodul is veszi a neki szóló üzenetet (544 lépés).
Ekkor A pénzmodul és B pénzmodul kapcsolatot létesítenek egymással úgy, hogy mindkét 6, 6’ pénzmodul megszerzi az MM/MM kapcsolatkulcsot (546 lépés). A pénzmodul-pénzmodul kapcsolat felépítése során a pénzmodulok üzeneteket váltanak a 120 megbízottak között már meglévő kapcsolaton át. A 13. ábra sze11
HU 220 576 Bl rinti 442 csatorna kapcsolatkulcsa a kódolt 436 csatornán át történő üzenetváltás során alakul ki. így a pénzmodulok közötti kapcsolatban küldött üzenetek, legalábbis a 120 megbízottak közötti csatornában kétféle kódolással lesznek ellátva: egyrészt a pénzmodulok közötti MM/MM kapcsolatkulccsal, másrészt a megbízottak közötti kapcsolat TA/TA kapcsolatkulcsával.
Egy előnyös kialakításban a 6, 6’ pénzmodulok közötti kapcsolat ugyanúgy épül fel, mint a 120 megbízottak közötti kapcsolat. Mindegyik pénzmodulnak van saját azonosító bizonylata és van közös kulcsa, amelyek tárolva vannak benne. A bizonylatok és véletlen számok (XOR) cseréje lehetővé teszi pénzmodulok közötti, biztonságos MM/MM kapcsolatkulcs alkotását. (A kapcsolatprotokollt lásd Az US 5799087 számú szabadalmi leírásban és a 14. ábrán). A 14. ábra szerint A biztonságőr a modul bizonylatát a kapcsolatmenedzserhez küldi (1464 lépés), A kapcsolatmenedzser ellenőrzi, hogy A pénzmodul a hálózaton van-e (1466 lépés). 1468 lépés: pénzmodul a hálózatra van kapcsolva? Ha A pénzmodul a hálózatra van kapcsolva, akkor A kapcsolatmenedzser A pénzmodul bizonylatát B-hez küldi (1476 lépés).
Ha viszont A pénzmodul nincs a hálózatra kapcsolva, akkor A szimmetrikus kulcsfunkció kódolja A pénzmodul bizonylatát egy K kulccsal (1470 lépés), A kapcsolatmenedzser a kódolt bizonylatot hálózati szerverhez küldi (1472 lépés), a hálózati szerver dekódolja a bizonylatot K kulccsal és B-hez küldi (1474 lépés).
Függetlenül attól, hogy a bizonylatot a hálózati szervertől vagy A kapcsolatmenedzsertől kapta, B kapcsolatmenedzser veszi a bizonylatot (1480 lépés), és továbbadja B biztonságőmek, B biztonságőr (ha B egy biztonságőr, akkor a biztonsági szerver látja el ezt a feladatot) veszi és értékeli a bizonylatot (1482 lépés). 1484 lépés: bizonylat érvényes? Ha a bizonylat nem érvényes, B kapcsolatmenedzser megjegyzi, hogy a kapcsolat megszakadt és informálja vagy a vevőt, vagy a bankot: 1486 lépés: B kapcsolatmenedzser megjegyzi : kapcsolat megszakítva, 1488 lépés: van-e folyamatban pénzmodul-tranzakció?, 1490 lépés: B szolgáltatóhoz üzenet: tranzakció megszakítva, 1492 lépés: B bankhoz üzenet: tranzakció megszakítva. Ha B egy biztonsági szerver, akkor B csupán megjegyzi a tranzakció megszakadását.
Ha A pénzmodul bizonylata érvényes, akkor B biztonságőr megvizsgálja, A pénzmodul nincs-e a megbízhatatlanok listáján (1494 lépés). 1496 lépés: A a megbízhatatlanok listáján van? Ha A pénzmodul rajta van a megbízhatatlanok listáján, akkor a kapcsolat megszakad. Ha a pénzmodul nincs a megbízhatatlanok listáján, akkor B véletlenszám-generátor R(B) véletlen számot és B értékelőüzenetet generál (1498 lépés). B óra/időzítő idő- és dátumadatot ad B biztonságőmek (1500 lépés). B biztonságőr összegyűjti egy üzenetben R(B) véletlen számot, B értékelőüzenetet és a dátum/idő adatot (1502 lépés). B közös kulcs funkció kódolja az üzenetet A közös kulcsával (1504 lépés), B kapcsolatmenedzser ehhez a kódolt üzenethez B bizonylatát hozzáfűzi, és A-nak küldi (1506 lépés).
A kapcsolatmenedzser veszi az üzenetet (1508 lépés), A közös kulcs funkció dekódolja az üzenet kódolt részét (1510 lépés). A biztonságőr értékeli a bizonylatot (1512 lépés). 1514 lépés: bizonylat érvényes? Ha a bizonylat nem érvényes, A kapcsolatmenedzser megjegyzi a kapcsolat megszakadását (1516 lépés), és megnézi, van-e folyamatban pénzmodul-tranzakció (1518 lépés), A ügyfélhez üzenet: a tranzakció megszakítva (1520 lépés) vagy A bankhoz üzenet: tranzakció megszakítva (1522 lépés). Ha a bizonylat érvényes, A biztonságőr ellenőrzi, B azonosítója nincs-e a megbízhatatlanok listáján (1524 lépés), 1526 lépés: B a megbízhatatlanok listáján van? Ha B a megbízhatatlanok listáján van, a kapcsolat megszakad. Ha B nincs a megbízhatatlanok listáján, akkor A biztonságőr lehívja a dátum/idő adatot és összehasonlítja B dátum/idő adatával (1528 lépés). 1530 lépés: dátumeltérés tűréshatáron túl? Ha a dátum egy adott tűréshatáron belül nem egyezik, a kapcsolat megszakad.
Ha a dátum egy adott tűréshatáron belül egyezik, A véletlenszám-generátor R(A) véletlen számot és A értékelőüzenetet generál (1532 lépés). A biztonságőr R(A)xorR(B) kapcsolatkulcsot képez (1534 lépés). B közös kulcs funkciója az A értékelőüzenetet, a B értékelőüzenetet, a dátum/idő adatot és R(A) véletlen számot egy üzenetbe gyűjti (1534 lépés), A közös kulcs funkció kódolja az üzenetet B közös kulcsával (1536 lépés), A kapcsolatmenedzser a kódolt üzenetet B-nek küldi (1538 lépés).
B kapcsolatmenedzser veszi az üzenetet (1540 lépés), B közös kulcs funkció dekódolja az üzenetet (1542 lépés), B biztonságőr ellenőrzi B értékelőüzenetet (1544 lépés). 1546 B értékelőüzenet korrekt? Ha B értékelőüzenet korrekt, akkor B biztonságőr R(A)xorR(B) kapcsolatkulcsot képez, lehívja az óra/időzítő dátum/idő adatát és összehasonlítja azt A dátum/idő adatával (1548 lépés). 1550 lépés: dátumeltérés kívül van a tűréshatáron? Ha a dátum egy adott tűréshatáron belül nem egyezik, a kapcsolat megszakad. Ha a dátum egy adott tűréshatáron belül egyezik, B kapcsolatmenedzser megjegyzi a kapcsolat megnyitását (startját) (1552 lépés).
B kapcsolatmenedzser tudomásulvevő és A értékelőüzenetet küld (1554 lépés), 1556 lépés: kódolással védett üzenetküldés ΒψΑ. A kapcsolatmenedzser veszi a tudomásul vevő és A értékelőüzenetet (1558 lépés), A biztonságőr ellenőrzi az A értékelőüzenetet (1560 lépés). 1562 lépés: A értékelőüzenet korrekt? Ha az A értékelőüzenet nincs rendben, a kapcsolat megszakad. Ha az A értékelőüzenet korrekt, akkor A kapcsolatmenedzser megjegyzi a kapcsolat kezdetét (1564 lépés).
A pénzmodulos rendszer biztonságának átfogó felügyelete integrálható a 120 megbízottak biztonságának felügyeleti rendszerébe, de előnyösen attól függetlenül van kialakítva, amivel növelhető a rendszer biztonsága és főként a flexibilitása.
A 12. ábra szerint A pénzmodul (RÍ) véletlen számot küld B pénzmodulhoz (548 lépés). Ezt a lépést kezdeményezheti a pénzmodul (MM) A biztonságőre. (lásd az US 5453601 számú szabadalmi leírást, ennek módo12
HU 220 576 Β1 sításait és az US 555718 számú szabadalmi leírást, ahol a pénzmodul (MM)-funkciókat MM jelzéssel különbözettük meg).
Az R(l) véletlen számot egy „irányított üzenetküldés” szubrutin lefuttatásával A pénzmodulból B pénzmodulba küldjük (550 lépés). A 15. ábra szerint A pénzmodul közös kulcs funkciója kódolja az üzenetet [(Rl)-t is] egy MM/MM kapcsolatkulccsal (640 lépés). A pénzmodul kapcsolatmenedzsere üzenetet küld A hőst üzenetmenedzsemek (642 lépés), amely A hőst üzenetmenedzser üzenetet küld A üzenetinterfésznek (644 lépés). A üzenetinterfész üzenetet küld B üzenetinterfésznek (646 lépés) ΑψΒ üzenetküldés szubrutin lefuttatásával (648 lépés), amely szubrutin kódolja, majd dekódolja az üzenetet a TA/TA kapcsolatkulccsal a 120 megbízottak közötti átvitelhez. B üzenetinterfész azután üzenetet küld B hőst üzenetmenedzsemek (650 lépés), B hőst üzenetmenedzser üzenetet küld B pénzmodulnak (652 lépés). B pénzmodul kapcsolatmenedzsere veszi az üzenetet (654 lépés), B pénzmodul szimmetrikus kulcsfunkciója dekódolja az üzenetet MM/MM kapcsolatkulcs alkalmazásával (656 lépés).
A 12. ábra szerint B pénzmodul biztonságőre TA/MM=R(1)xorR(2) kapcsolatkulcsot formál és az R(2) véletlen számot A pénzmodulnak küldi (552 lépés). 554 lépés: irányított üzenetküldés ΒψΑ. A pénztármodul biztonságőr is TA/MM=R(1)xorR(2) kapcsolatkulcsot formál (556 lépés). A folyamatnak ezen a pontján három kapcsolat áll fenn (13. ábra): MM/MM, MM/ΤΑ és TA/TA kapcsolatok, azaz mind a négy kódolt csatorna használatban van.
A 12. ábra szerint az A pénzmodul A előfizetőhöz funkciója felhívja (promt) A megbízottat összeg (a kiválasztott áru ára) és pénznem (dollár, yen, font stb.) megadására (558 lépés). Egy, az US 5453601 számú leírás szerinti pénzmodul közvetlenül az előfizetőhöz (a pénzmodul birtokosához) fordult volna, a jelen találmány szerint a pénzmodul A megbízotton át kommunikál az előfizetővel. Itt a 120 megbízott szállítja az összeg- és pénznemadatokat, amelyeket előbb beszerzett a 2 vevő megbízottja (illetve a tranzakciós eszköz) előfizetőjétől.
A 6’ pénzmodul 120 megbízotthoz a promt üzenetküldés egy „küldj MM/ΤΑ üzenetet” szubrutin lefuttatásával történik (560 lépés).
A 16. ábra szerint az A pénzmodul szimmetrikus kulcsfunkciója a ΤΑ/MM kapcsolatkulcs alkalmazásával kódolja az üzenetet (658 lépés), A pénzmodul kapcsolatmenedzsere elküldi az üzenetet A megbízott üzenetinterfészének A hőst üzenetmenedzser útján: 660 lépés: A pénzmodul kapcsolatmenedzsere üzenetet küld hosthoz, hőst üzenetmenedzser üzenetet küld A üzenetmenedzsemek (662 lépés), A üzenetinterfész veszi az üzenetet (664 lépés). A szimmetrikus kulcsfunkció dekódolja az üzenetet a ΤΑ/MM kapcsolatkulccsal (666 lépés).
A 12. ábra szerint A vásárlásfunkció megadja az összeget (a kiválasztott áru árát) és pénznemet a pénzmoduljának (562 lépés) a ΤΑ/MM üzenetküldés-szubrutin lefuttatásával (564 lépés). A pénzmodul fizet/vált funkciója veszi az összeg- és pénznem-információt (566 lépés).
A 17. ábra (ΤΑ/MM üzenetküldés szubrutin) szerint A szimmetrikus kulcsfunkció kódolja az üzenetet ΤΑ/MM kapcsolatkulccsal (668 lépés), A üzenetinterfész az üzenetet hőst üzenetmenedzseren át (670 lépés) A pénzmodul kapcsolatmenedzserének küldi (672 lépés). A pénzmodul-kapcsolatmenedzser veszi az üzenetet (674 lépés), A pénzmodul szimmetrikus kulcsfunkciója ΤΑ/MM kapcsolatkulcs alkalmazásával dekódolja az üzenetet (676 lépés).
A 12. ábra szerint A pénzmodul bankjegy könyvtára ellenőrzi, van-e a 6 pénzmodulban a kifizetéshez szükséges összegű betét (568 lépés). 570 lépés: van elég pénz? Ha nincs elegendő pénz, a tranzakció megszakad A és B pénzmodulok között: előbb A pénzmodul A előfizetőtől új összeg megadását kéri (MM/ΤΑ üzenet) egy 572 lépésben, 574 lépés: MM/ΤΑ üzenetküldés (szubrutin), A vásárlásfunkció üzenetben kéri az új összeg megadását (576 lépés), 578 lépés: ΤΑ/MM üzenet elküldése (szubrutin), 580 lépés: van megadva új összeg?, A pénzmodul szubrutin lefuttatásával megszünteti a kapcsolatot B pénzmodullal (582 lépés).
Az 582 lépésben alkalmazható, kapcsolatmegszüntető protokoll van ismertetve például az US 5799087 számú szabadalmi leírásban és jelen bejelentés szerinti 18. ábrán. A 18. ábra szerinti szubrutinban X kapcsolatmenedzser visszafejti a meghiúsult tranzakció során végzett változtatásokat és megjegyzi, hogy a kapcsolat megszűnt (1726 lépés). X kapcsolatmenedzser ezután ellenőrzi, ment-e „lezárásra kész” üzenet (1728 lépés). 1730 lépés: „lezárásra kész” üzenet elküldve? Ha igen, X felfrissíti transzfer log-ját (1732 lépés) feljegyezve, hogy X megszakított, miután elküldte a „lezárásra kész” üzenetet és feljegyezte a bankjegytranszfer protokoll futása során kapott mindegyik bankjegy azonosítóját és összegét a transzferlistába. Amikor tehát egy megszakítás (hibás lezárás)-szubrutin előhív egy megszakításszubrutint, a megszakításprotokoll mindig hozzáfűz információt a tranzakció log-hoz.
Ha X egy tranzakciós modul és a „lezárásra kész” üzenet elküldésre került, akkor X előfizetőhöz funkció informálja előfizetőjét hogy a tranzakció, valószínű pénztranszferhiba miatt, meghiúsult: 1734 lépés: vanefolyamatbanpénzmodul-tranzakció?, 1736 lépés: üzenet elküldve?, X előfizetőhöz: tranzakció meghiúsult, lehetséges pénztranszferhiba (1738 lépés). Ha X egy banki pénztármodul, akkor X bankhoz funkció informálja a bankot, hogy vissza kell fejtenie a tranzakciók könyvelését is: 1740 lépés: van-e folyamatban banki pénztármodul-tranzakció?, 1742 lépés: X bankhoz: tranzakció könyvelését visszafejteni. Ha X egy tranzakciós pénzmodul, és nem volt „lezárásra kész” üzenet küldve, akkor X előfizetőhöz funkció informálja az előfizetőt, hogy a tranzakció megszakadt (1744 lépés).
X kapcsolatmenedzser minden fenti esetben küld üzenetet Y-nak, arról, hogy a tranzakció nem fejezhető be (1746 lépés). 1748 lépés: üzenetküldés ΧψΥ. X kapcsolatmenedzser visszafejti a változásokat és megjegyzi a kapcsolat megszakadását (1750 lépés). Y megnézi, van-e folyamatban pénzmodul-tranzakció (1752 lépés), és informálja előfizetőjét arról, hogy a tranzakció meg13
HU 220 576 Bl hiúsult (1754 lépés), vagy 1756 lépés: van-e folyamatban banki pénztármodul-tranzakció?, 1758 lépés: Y bankhoz informálja a bankot, meghiúsult tranzakciót visszakönyvelni!
Amint azt említettük, ha egy tranzakciós kapcsolat a sikeres lezárás előtt megszakad, bankjegyek vagy más jegyek duplikációja vagy elvesztése következhet be. Elvesztés akkor következhet be, ha például az elektronikus bankjegyátutalást átvevő akkor szakít meg, amikor az átutaló lezárta a kapcsolatot. Ilyen esetben a pénzt átvevő modul feljegyzi a kétes bankjegyek adatait, és értesíti előfizetőjét, hogy a pénz átvételével esetleg probléma van (nem kapta meg A átvételi jegyét). Megjegyzendő, hogy az átutaló-pénzmodul ez esetben rendesen átutalta a pénzt.
Az átutalást átvevő pénzmodul előfizetője ezt az elveszett pénzt a bizonylatoló (engedélyező) hatóságtól követelheti. A követelésnek tartalmaznia kell a meghiúsult tranzakció transzfer lóg feljegyzéseit. A bizonylatoló hatóság egyeztet a bankjegyeket kibocsátó bankkal arról, hogy nem kerültek-e ki a forgalomból az érintett bankjegyek. Egy meghatározott várakozási idő leteltével, ha a bankjegyeket nem vonták be, az előfizető, kérelmére visszakapja az elveszett összeget.
A 12. ábra szerint az A és B pénzmodulok közötti üzenetváltások E-irányított üzenetszubrutin lefuttatásával kerültek átvitelre, amely szubrutin használja mindhárom (MM/MM, TA/MM, TA/TA) kapcsolatkulcsot. A 19. ábra szerint A pénzmodul szimmetrikus kulcsfunkciója kódolja az üzenetet MM/MM kapcsolatkulccsal (678 lépés), majd a kódolt üzenet, elküldés előtt, az MM/ΤΑ kapcsolatkulccsal történő felülkódolásnak lesz alávetve (680 lépés). A üzenetinterfész az üzenetet B üzenetinterfészhez küldi (682 lépés), 684 lépés: üzenetküldés ΑψΒ. A 120 megbízottak közötti kapcsolatban az üzenet TA/TA kapcsolatkulccsal van kétszeresen kódolva. B üzenetinterfész ehhez hasonló módon küld üzenetet B pénzmodul szimmetrikus kulcsfunkciójának, végleges dekódolás céljából: 686 lépés: B üzenetinterfész veszi az üzenetet, 688 lépés: ΤΑ/MM kódolt üzenetküldés B-nek, 690 lépés: A pénzmodul szimmetrikus kulcsfiinkció dekódolja az üzenetet MM/MM kapcsolatkulccsal. A 13. ábrán fel vannak tüntetve a különböző kódolási rétegek.
A 12. ábra szerint az A és B pénzmodulok a megszakítószubrutinjaiban (582 lépés) A és B pénzmodulok üzeneteket generálnak a saját A és B megbízottjuknak, informálva azokat arról, hogy megszüntették a kapcsolatot, a fizetés sikertelen volt: 584 lépés: A pénztármodul MM/ΤΑ üzenetet küld, 586 lépés: B pénzmodul MM/ΤΑ üzenetet küld. A és B kapcsolatmenedzserek meggyőződnek a fizetés sikertelenségéről és megszakítanak: 588 lépés: A kapcsolatmenedzser ellenőrzi a fizetés sikerességét, 590 lépés: B kapcsolatmenedzser ellenőrzi a fizetés sikerességét, 592 sikeres a fizetés?, 594 lépés: sikeres a fizetés?, 596 lépés: A megszakít, 598 lépés: B megszakít.
Ha, másrészt, a 2 vevő megbízottjához tartozó pénzmodulban van elég pénz a kifizetéshez, akkor A pénzmodul fizet/vált funkciója üzenetet küld a szolgáltató pénzmoduljához, közölve az átutalás összegét és a bankjegyek típusát (600 lépés). Ezt az üzenetet Eirányított üzenetként küldi (602 lépés).
B pénzmodul veszi az üzenetet az A pénzmodultól kapott adatokkal. B pénzmodul előfizetőhöz funkciója ekkor promt üzenetet küld B megbízotthoz, a fizetendő összeg értékelését kérve (604 lépés). 606 lépés: MM/TA üzenetküldés B előfizetőhöz. B megbízott vásárlásfunkciója értékeli az összeg helyességét (608 lépés). 610 lépés : helyes az összeg? Ha a közölt összeg helyes, akkor B megbízott vásárlásfunkciója „helyes az összeg” üzenetet küld B pénzmodulnak (612 lépés), vagy „helytelen összeg” üzenetet küld (614 lépés). 616 lépés: TA/MM üzenetküldés. Az esetben, ha az összeg nem helyes, B pénzmodul informálja erről A pénzmodult E-irányított üzenetben (622 lépés). A pénzmodul erre A megbízottól újabb összeg megküldését kéri vagy megszakítást kér: 618 lépés: helyes az újabb összeg? B megbízott vásárlásfunkciója „helytelen összeg” üzenetet küld (620 lépés). A megszakítás szubrutin az 572-582 lépésekben megszakítás történik. Pénzmodulok közötti vásárlás esetén a megbízott nem küld újabb összegadatot, így mindkét pénzmodul és mindkét megbízott megszakít.
Ha viszont a B pénzmodul a B megbízottól „helyes összeg” üzenetet kap (624 lépés), akkor B pénzmodul elfogadóüzenetet küld (E-irányított üzenetben) a vevő A pénztármoduljához (626 lépés), amit A pénzmodul fizet/vált funkciója vesz és az összegnek megfelelő bankjegyeket az A pénzmodul pénztartójába küldi (628 lépés), amely pénztartó-alkalmazás tartalmazza és kezeli a pénz elektronikus megjelenítőjét.
Megjegyzendő, hogy az imént leírt, a fizető által kezdeményezett protokoll helyett alkalmazható a fizetést átvevő által kezdeményezett protokoll is, mint amilyen a POS fizetés protokollja. Egy ilyen protokoll szerint a szolgáltató megbízottja utasítja a pénzmodulját a várt pénzösszeg átvételére, ezt az információt megküldik a vevő pénzmoduljának is, amely a vevő megbízottjától az üzenet értékelését kéri, és ha az összeg helyes, erről a vevő megbízottja értesíti a vevő pénzmodulját.
A 12. ábra szerint A vevő A pénzmodulja az elektronikus bankjegyeket a szolgáltató pénzmoduljának Eirányított üzenetben, meghatározott összegben átutalja a szolgáltató B pénzmoduljába (630 lépés). A 20. ábra szerinti bankjegy transzfer protokollban (leírva az US 5799087 számú leírásban) X bankjegykönyvtár kiválaszt egy vagy több bankjegyet, amelyek összege a kifizetendő összeggel egyezik, frissíti a bankjegyek összegét és sorszámát, üzenetet küld a pénztartónak (bankjegytámak) (1566 lépés). X bankjegytár veszi az üzenetet, és transzferfeljegyzést készít mindegyik bankjegyhez (1568 lépés). X közöskulcsfunkció-szignót készít a bankjegyek számára (1570 lépés), X pakettmenedzser pakettet állít össze a bankjegyekből, transzferfeljegyzésekből és szignókból, a pakettet Y-hoz küldi (1572 lépés). A bankjegyek választása különböző szempontok szerint történhet: (1) a digitális szignók számának minimalizálása (a hosszú processzorfoglaltság megelőzésére), (2) a pakett méretének minimalizálása, (3) a maradó elektronikus bankjegyek lehető hosszú maradék élet14
HU 220 576 Bl tartamának biztosítása (lejáratig). Az ilyen célok az alábbi bankjegytranszfer-algoritmussal érhetők el: (1) meghatározandók a legkevesebb számú bankjegyet tartalmazó összeállítások, (2) meghatározandó ezen összeállítások közül melyikek igénylik a legkisebb számú transzferműveletet, (3) ha egynél több választási lehetőségünk maradt, azt választjuk, amely pénzegységre vetítve a legkevesebb érvényességi egységnapot tartalmazza. Érvényességi egységnap=a bankjegyek maradék értékének és lejáratig maradó érvényességi napjainak szorzata a pakett teljes tartalmára.
A megadott szempontok szerinti választás algoritmusa: X bankjegytár veszi az üzenetet X bankjegykönyvtártól, és feljegyzést készít mindegyik bankjegy számára (1568 lépés). X közöskulcsfunkció-szignót készít a bankjegyek számára (1570 lépés). X pakettmenedzser pakettet állít össze a bankjegyekből, transzferfeljegyzésekből és szignókból, a pakettet Y pakettmenedzserének küldi (1572 lépés). Kódolással védett üzenetküldés ΧψΥ (1574 lépés). Y pakettmenedzser veszi a pakettet és szétszedi (1576 lépés).
Y értékelő érvényesíti a bizonylatokat (azaz a pénzformátum-generátor bizonylatát és minden transzfer bizonylatait), értékeli a bizonylatok transzferadatait (a korábbiakat is, megállapítva, hogy az azonosító számaik egyeznek-e a küldőmodulok digitális szignóba foglalt azonosítójával), a transzferösszegek konzisztenciáját bankjegyenként, és a végösszeget (1578 lépés). 1580 lépés : érvényes? Ha az értékelés nem talál mindent rendben, a tranzakció megszakad ΥψΧ (1582 lépés).
Ha az értékelés mindent rendben és érvényesnek talál és Y egy tranzakciós eszköz, akkor Y értékelő megvizsgálja a bankjegyek lejáratát: 1584 lépés: van-e folyamatban pénzmodul-tranzakció? Ha igen, 1586 lépésben Y értékelő értékeli a lejárati dátumokat. 1588 lépés: van lejárt bankjegy? Ha bármelyik bankjegy lejárt, a tranzakció megszakad. Ha nincs lejárt bankjegy, akkor Y értékelő összevet minden transzferazonosítót a megbízhatatlanok listájával (1590 lépés), 1592 lépés: van vizsgált azonosító a listán? Ha bármelyik elektronikus bankjegy azonosítója szerepel a listán, a kapcsolat megszakad.
Ha Y értékelő nem talált rossz vagy megbízhatatlan bankjegyet (vagy Y nem egy tranzakciós eszköz), akkor Y közös kulcs funkció értékeli a bankjegyek szignóit (1594 lépés), 1596 lépés: szignó érvényes? Ha a szignók bármelyike érvénytelen, a tranzakció megszakad. Ha a szignó(k) érvényes(ek), akkor Y értékelő összehasonlítja a bankjegytörzseket a tranzakció lóg szerinti bankjegytörzsekkel és ellenőrzi, nincs-e duplikáció (1598 lépés). 1600 lépés: egyezés van? Ha az ellenőrzés kimutatott duplikált bankjegyet, a tranzakció megszakad. Ez az ellenőrzés (1598-1604 lépések) alkalmas arra, hogy csalók kedvét elvegye az „önkiszolgálástól”, attól, hogy tranzakciós eszközét úgy manipulálja, hogy azzal pénze keletkezzék duplikálás útján.
Y bankjegytár transzferfát készít a bankjegytörzsekkel és ellenőrzi, nincs-e duplikáció (1602 lépés). 1604 lépés: van duplikáció? Ha nincs duplikált bankjegy és a bankjegytörzsek is egyeznek, akkor Y bankjegy tár a bankjegyeket tartóba helyezi (1606 lépés). Végül Y bankjegykönyvtár frissíti a bankjegyek tárolási hely- és összegadatait, sorszámot ad (1608 lépés).
Amint a fentiekből következik, az elektronikus bankjegy transzfer eljárás magában foglal frissítő- és sorszámozó lépéseket is, ami lehetővé teszi a bankjegyek azonosítását, a küldő ellenőrzését a tekintetben, hogy az nincs-e a megbízhatatlanok listáján, és lehetővé teszi a duplikált bankjegyek kiszűrését. Ezek a többletjellemzők és -lépések megnehezítik a duplikált bankjegyek keletkeztetését és forgalmazását, azonnal felfedezhetővé teszik, és automatikusan kiszűrik a duplikált bankjegyet a tranzakció során.
A 12. ábra szerint Y pénzmodul lezátja a kapcsolatot egy szubrutin alkalmazásával, E-irányított üzenetben (MM ΥψΜΜ X) (632 lépés). Egy kapcsolatlezáró protokoll van szemléltetve a 21. ábrán (hasonló van ismertetve az US 08/427,287 szabadalmi bejelentésünkben). Eszerint X kapcsolatmenedzser „lezárásra kész” üzenetet ad Y-nak (1702 lépés). 1704 lépés: üzenetküldés ΧψΥ. Ebben az üzenetben a lezárás kötelezettségét átruházza az üzenetet vevő modulra. Egy hagyományos pénztranszfer folyamatban ez a kötelezettségátruházás használatos arra, hogy mindig a pénzt küldő zátja le előbb a transzferkapcsolatot, hogy ne legyen módja a pénz duplikálására.
Y kapcsolatmenedzser tudomásulvétel-üzenetet küld X-nek (1706 lépés). (1708 lépés: üzenetküldés ΥψΧ) és lezárja még nyitott kapcsolatait a transzfer lóg frissítésével (1710 lépés). Ha Y egy tranzakciós eszköz, akkor egy 1712 lépés: van-e folyamatban pénzmodul-tranzakció? és 1714 lépésben az Y előfizetőhöz funkció tranzakció lezárult kijelzést ad az előfizető felé. Y kapcsolatmenedzser megjegyzi a kapcsolat végét (1716 lépés).
X transzfer lóg frissíti a tran.log feljegyzését (1718 lépés), 1720 lépésben megnézi, van-e folyamatban pénzmodul-tranzakció, ha igen, lezárja minden külső kapcsolatát, ugyanúgy, mint Y tette: X előfizetőhöz funkció tranzakció lezárult kijelzést ad előfizető felé (1722 lépés), X kapcsolatmenedzser megjegyzi, a kapcsolat lezárult (1724 lépés).
Hasonló folyamatábra szerinti protokollt alkalmazunk 6 pénzmodul és 120 megbízottja kapcsolatának lezárásánál is, azzal a különbséggel, hogy az üzenetküldés-lépésben E-irányított üzenetküldés szubrutinját futtatjuk le, és hogy az előfizetőhöz funkció nem az előfizető számára ír ki üzenetet, hanem a 120 megbízott számára küld üzenetet. A fentiek szerint B pénzmodul kapcsolatmenedzsere küld „kapcsolat lezárására kész” üzenetet A pénzmodul kapcsolatmenedzserének egy E-irányított üzenetben (szubrutin: 1702-1704 lépések), A pénzmodul küld tudomásulvevő üzenetet B pénzmodulnak és A pénzmodul lezáqa a kapcsolatát (1706-1716 lépések). Amikor B pénzmodul vette a tudomásulvevő üzenetet, B pénzmodul is lezárja kapcsolatát (1718-1724 lépésekben).
A és B pénzmodulok kapcsolatát lezáró rutinok szerint A és B pénzmodul üzeneteket generálnak és küldenek a hozzájuk tartozó megbízott számára (1714,
HU 220 576 Bl
1722 lépés), informálva őt hogy részükről a kapcsolat le van zárva és a fizetés sikeres volt.
A 12. ábra szerint mindkét pénzmodul az említett „sikeres fizetés” üzenetet küldi a saját megbízottjának (584, 586 lépések), amely üzenetek ΤΑ/MM kapcsolatkulccsal kódoltak. A kapcsolatmenedzser ellenőrzi a fizetés sikerességét (588 lépés), 592 lépés: sikeres a fizetés? B kapcsolatmenedzser is ellenőrzi a fizetés sikerességét (590 lépés), 594 lépés: sikeres a fizetés? Ha nem, akkor 596 lépésben A megszakít, 598 lépésben B megszakít. Ha az 594 lépés szerint a fizetés sikeres volt, akkor Y lezárja a kapcsolatot (638 lépés), így. Ha az 592 lépésben a fizetés sikeresnek bizonyult, A jegytartó frissíti az átvételi jegyet a fizetési információval (634 lépés) és A lezárja a kapcsolatot (636 lépés), így a jegy tárolása A pénzmodulban véglegessé válik.
Az előző ismertetés olyan szituációra vonatkozott, ahol az előfizető eladni kívánt elektronikus pénzt a szolgáltatónak azért, hogy az az elektronikus pénz ellenértékét az ő bankszámláján helyezze el. Az esetben, ha az előfizető (vevő) vásárolni kíván elektronikus pénzt a szolgáltatótól, (7. ábra) B vásárlásfünkció megnézi, van-e a pénztár-moduljában az ellenértéknek megfelelő elektronikus pénz (724 lépés). 726 lépés: van elég pénz a modulban? Ha a szolgáltató B pénzmoduljában nincs elegendő elektronikus pénz, akkor B host-hoz funkció kéri, hogy hőst vezérelje az ügyletet (728 lépés). B hőst ellenőrzi, van-e más tranzakciós modulnál a kért összeg (730 lépés). 732 lépés: más modulban van megfelelő összeg? Ha igen, B hőst C host-tól kéri, küldje át az összeget (734 lépés). 736 lépés: kapcsolatlétesítés C\|/B pénzmodulok között (736 lépés), pénzmodul-fizetés Cv|/B (738 lépés). Megjegyzendő, hogy ez egy egyszerűsített folyamat, ahol nincs átvételi jegy (eltérően a 634 lépésben történő pénzmodul-fízetéstől).
Ha más pénzmodulban sincs megfelelő, lehívható összeg, B hőst megvizsgálja nem tudja-e lehívni a kért összeget a bankszámláját vezető banktól. Ez a lépés is átugorható indokolt esetben.
Ha tehát más pénzmodulban sincs megfelelő, lehívható összeg, B hőst megvizsgálja, lehívhat-e ilyen összeget a bankjától (740 lépés). 742 lépés: B lehívhat ilyen összeget? Ha igen, akkor A pénzmodul a kért elektronikus pénzt közvetlenül a banktól lehívhatja (748 lépés), a bank 202 pénzformátum-generátorának, 204 banki pénztármoduljának és 206 banki belső rendszerének (könyvelésének) közreműködésével (részletesen ismertetve US 5453601 számú leírásban). Ha nincs lehívható elektronikus pénz, akkor B hőst a kapcsolat megszakítását kéri (744 lépés), amire a tranzakció megszakad ΒψΑ (746 lépés).
Ha a szolgáltató pénzmoduljában van elegendő elektronikus pénz a vevő igényének kielégítésére, akkor a tranzakció a 750-794 lépésekben megtörténik. B host-hoz üzenetet küld az összeg és pénzlehívási feltételek megadásával a (kártyahasználatot) 208 engedélyező hatósághoz, hogy a feltételekben megjelölt bankszámláról az elektronikus pénz ellenértékét lehívhassa (810 lépés). A hatóság a kártyahasználatot 811 lépésben engedélyezi. B vásárlásfünkció ellenőrzi, engedélyezve vane a vevő bankszámlájának megterhelése (813 lépés). 815 lépés: kifizetés engedélyezve? Ha nem, a tranzakció megszakad. Ha igen, akkor B pénzmodul fizetést teljesít A-nak (817 lépés), ezzel befejezve a tranzakciót.

Claims (23)

  1. SZABADALMI IGÉNYPONTOK
    1. Elektronikuspénz-terjesztő rendszer, amelynek része vevő (B) megbízottja (2), a vevő megbízottjához (2) tartozó, vele védett üzenetváltásra alkalmas első pénzmodul (6), a vevő megbízottjával (2) első, kódolással védett kapcsolat létesítésére alkalmas, szolgáltató (A) megbízottja (4), a szolgáltató megbízottjához (4) tartozó, vele védett üzenetváltásra alkalmas, az első pénzmodullal (6) második, kódolással védett kapcsolatot létesítő, második pénzmodul (6’), azzal jellemezve, hogy a rendszerben vevő megbízottja (2) elektronikuspénz-vásárlási szándék és -pénzlehívási feltételek információt közöl a szolgáltató megbízottjával (4), amely információ vételét a szolgáltató megbízottja átvételi jegy (8) adásával visszaigazolja, a szolgáltató megbízottja (4) engedélyezőhálózatnál (208) a vevő megbízottjától (2) kapott pénzlehívási feltételekkel történő pénzlehívás engedélyezését kezdeményezi, amely engedélyezés után a szolgáltató megbízottja (4) elektronikus pénznek a második pénzmodulból (6’) első pénzmodulba (6) juttatását kezdeményezi.
  2. 2. Az 1. igénypont szerinti rendszer, azzal jellemezve, hogy a vevő pénzlehívási feltételei egy debit vagy kredit bankkártyán vannak adva.
  3. 3. Az 1. igénypont szerinti rendszer, azzal jellemezve, hogy a vevő megbízottja (2) továbbá elektronikus pénzeladási szándék információt is közöl a szolgáltató megbízottjával (4), amely szolgáltató megbízottja (4) a kapott eladási szándék és pénzlehívási feltételek információt felhasználva, engedélyezőhálózatnál (208) pénzlehívás engedélyezését kéri, amely engedélyezés után a szolgáltató megbízottja (4) elektronikus pénznek az első pénzmodulból (6) a második pénzmodulba (6’) juttatását kezdeményezi.
  4. 4. Az 1. igénypont szerinti rendszer, azzal jellemezve, hogy a szolgáltató megbízottja (4) elektronikus pénznek más, közös tulajdonú pénzmodulból a második pénzmodulba (6’) juttatását kezdeményezi, majd a második pénzmodulba (6’) juttatott elektronikus pénznek az első pénzmodulba (6) juttatását kezdeményezi.
  5. 5. Az 1. igénypont szerinti rendszer, azzal jellemezve, hogy szolgáltató második pénzmodul (6’) elektronikus pénzt kibocsátó bank banki hálózatához (200) fordul, ahonnan elektronikus pénzt hív le és ezt továbbítja vevő első pénztármoduljába (6).
  6. 6. Az 1. igénypont szerinti rendszer, azzal jellemezve, hogy az átvételi jegy (8) a vevő bankjának azonosítóját, a vevő bankszámlaszámát és a lehívásra engedélyezett összeget tartalmazza.
  7. 7. Elektronikuspénz-terjesztő rendszer, amelynek része vevő megbízottja (2), a vevő megbízottjához (2) tar16
    HU 220 576 Β1 tozó, vele védett üzenetváltásra alkalmas első pénzmodul (6), a vevő megbízottjával (2) első, kódolással védett kapcsolat létesítésére alkalmas, szolgáltató megbízottja (4), a szolgáltató megbízottjához (4) tartozó, vele védett üzenetváltásra alkalmas, az első pénzmodullal (6) második, kódolással védett kapcsolat létesítésére alkalmas, második pénzmodul (6’), azzal jellemezve, hogy a rendszerben vevő megbízottja (2) elektronikuspénz-eladási szándék és -pénzlehívási feltételek információt közöl a szolgáltató megbízottjával (4), amely információ vételét a szolgáltató megbízottja átvételi jegy (8) adásával visszaigazolja, a szolgáltató megbízottja (4) engedélyezőhálózatnál (208) a vevő megbízottjától (2) kapott pénzlehívási feltételekkel történő és pénzeladási szándéknak megfelelő pénzlehívás engedélyezését kezdeményezi, amely engedély birtokában a szolgáltató megbízottja (4) elektronikus pénznek az első pénzmodulból (6) a második pénzmodulba (6’) juttatását kezdeményezi.
  8. 8. A 7. igénypont szerinti rendszer, azzal jellemezve, hogy a pénzlehívási feltételek egy debit vagy kredit bankkártyán vannak adva.
  9. 9. A 7. igénypont szerinti rendszer, azzal jellemezve, hogy az átvételi jegy (8) a szolgáltató bankjának azonosítóját, a szolgáltató bankszámlaszámát és a lehívásra engedélyezett összeget tartalmazza.
  10. 10. Elektronikuspénz-terjesztő eljárás, az 1-9. igénypontok bármelyike szerinti rendszerben történő alkalmazásra, amely rendszernek része vevő (B) megbízottja (2), a vevő megbízottjához (2) tartozó első pénzmodul (6), a szolgáltató (A) megbízottja (4), a szolgáltató megbízottjához (4) tartozó második pénzmodul (6’), azzal jellemezve, hogy
    a) kódolással védett, első kapcsolatot létesítünk a vevő megbízottja (2) és a szolgáltató megbízottja (4) között,
    b) vevő megbízottjából (2) a kódolással védett első kapcsolatban elektronikuspénz-vásárlási szándék és -pénzlehívási feltételek információt közlünk a szolgáltató megbízottjával (4),
    c) amely információ vételének igazolásaként a szolgáltató megbízottjával (4) átvételi jegyet (8) készíttetünk, az átvételi jegybe (8) belefoglalva, legalább részben, a vételi szándék információt és a szolgáltató bankszámlaszámát,
    d) szolgáltató megbízottjából (4) a kódolással védett, első kapcsolatban eljuttatjuk az átvételi jegyet (8) vevő megbízottjához (2), amely vevő megbízottja (2) ideiglenesen tárolja a megkapott átvételi jegyet (8),
    e) a szolgáltató megbízottjával (4) engedélyezőhálózatnál (208) a vevő megbízottjától (2) kapott pénzlehívási feltételekkel történő pénzlehívás engedélyezését kezdeményezzük,
    f) az első és második pénztármodul (6, 6’) között kódolással védett, második kapcsolatot létesítünk,
    g) amely második kapcsolatban elektronikus pénzt a szolgáltató megbízottja (4) második pénzmoduljából (6’) első pénzmodulba (6) juttatunk, amely első pénzmodulban (6) az átutalt elektronikus pénzt ideiglenesen tároljuk,
    h) az első pénzmodulban (6) a kapcsolat lezárását kezdeményezzük, a kapcsolat lezárásával az elektronikus pénz tárolásának ideiglenes jellegét véglegesre változtatjuk, és biztonságosan informáljuk vevő megbízottját (2) a sikeres elektronikuspénz-vételéről,
    i) a második pénztármodulban (6’) a második kapcsolatot lezáijuk és vevő megbízottját (2) biztonságos úton informáljuk a pénztranszfer sikerességéről,
    j) a vevő megbízottjában (2) az első kapcsolat lezárását kezdeményezzük, a kapcsolat lezárásával az átvételi jegy (8) tárolásának ideiglenes jellegét véglegesre változtatjuk,
    k) szolgáltató megbízottjában (4) az első kapcsolatot lezárjuk.
  11. 11. A 10. igénypont szerinti eljárás, azzal jellemezve, hogy a pénzlehívási feltételeket egy debit vagy kredit bankkártyával adjuk meg.
  12. 12. A 10. igénypont szerinti eljárás, azzal jellemezve, hogy a vevő megbízottja (2) kiértékeli a megkapott átvételi jegyet (8).
  13. 13. Elektronikuspénz-teqesztő eljárás, az 1-9. igénypontok bármelyike szerinti rendszerben történő alkalmazásra, amely rendszernek része vevő (B) megbízottja (2), a vevő megbízottjához (2) tartozó első pénzmodul (6), a szolgáltató (A) megbízottja (4), a szolgáltató megbízottjához (4) tartozó második pénzmodul (6’), azzal jellemezve, hogy
    a) kódolással védett, első kapcsolatot létesítünk a vevő megbízottja (2) és a szolgáltató megbízottja (4) között,
    b) vevő megbízottja (2) útján az első kapcsolatban elektronikuspénz-eladási szándék és -pénzlehívási feltételek információt közlünk a szolgáltató megbízottjával (4),
    c) amely információ vételének igazolásaként a szolgáltató megbízottjával átvételi jegyet (8) készíttetünk, az átvételi jegybe (8) belefoglalva legalább részben a pénzeladási szándék információt és a szolgáltató bankszámlaszámát,
    d) szolgáltató megbízottjától (4) az első kapcsolatban eljuttatjuk az átvételi jegyet (8) vevő megbízottjához (2), amely vevő megbízottja (2) ideiglenesen tárolja a megkapott átvételi jegyet (8),
    e) a szolgáltató megbízottja (4) útján, engedélyezőhálózatnál (208), a vevő megbízottjától (2) kapott pénzeladási szándékkal és pénzlehívási feltételekkel összhangban történő pénzlehívás engedélyezését kezdeményezzük,
    f) az első és második pénztármodul (6, 6’) között kódolással védett, második kapcsolatot létesítünk,
    g) amely második kapcsolatban elektronikus pénzt a vevő megbízottja (2) első pénzmoduljából (6) a szolgáltató második pénzmoduljába (6’) juttatunk, amely pénzt a második pénzmodulban (6’) ideiglenesen tároljuk,
    h) az első pénzmodulban (6) a kapcsolat lezárását kezdeményezzük, és vevő megbízottját (2) biztonságos úton informáljuk a pénztranszfer sikerességéről, ί
    HU 220 576 Bl
    i) a második pénztármodulban (6’) a második kapcsolatot lezárjuk, a kapcsolat lezárásával az elektronikus pénz tárolásának ideiglenes jellegét véglegesre változtatjuk és szolgáltató megbízottját (4) biztonságos úton informáljuk a pénz vételéről,
    j) a vevő megbízottjában (2) az első kapcsolat lezárását kezdeményezzük, a kapcsolat lezárásával az átvételi jegy (8) tárolásának ideiglenes jellegét véglegesre változtatjuk,
    k) szolgáltató megbízottjában (4) az első kapcsolatot lezárjuk.
  14. 14. A 13. igénypont szerinti eljárás, azzal jellemezve, hogy a pénzlehívási feltételeket egy, a vevő bankszámlaszámát tartalmazó debit vagy kredit bankkártyával adjuk meg.
  15. 15. A 13. igénypont szerinti eljárás, azzal jellemezve, hogy a vevő megbízottja (2) kiértékeli a megkapott átvételi jegyet (8).
  16. 16. Elektronikuspénz-teijesztő rendszer, amelynek része egy feltörés ellen védett, első elektronikus tranzakciós eszköz (122), amelynek első processzora van, továbbá része egy feltörés ellen védett, második elektronikus tranzakciós eszköz (122), amelynek második processzora van, és amely második tranzakciós eszköz (122) az első tranzakciós eszközzel (122), kódolással védett kapcsolat létesítésére alkalmasan van kialakítva, azzal jellemezve, hogy az első processzor elektronikuspénz-vételi szándék és -pénzlehívási feltételek információ második processzorral történő közlésére alkalmasan van kialakítva, a második processzor az első processzortól megkapott pénzvételi szándék és a pénzlehívási feltételek átvételi jegybe (8) foglalására és az átvételi jegy (8) kódolással védett kapcsolatban, az első processzorhoz továbbítására alkalmasan van kialakítva, a második processzor egy engedélyezőhálózatnál (208), az első processzortól kapott pénzvételi szándék információnak megfelelő és a pénzlehívási feltételekkel történő pénzlehívás engedélyezésére alkalmasan van kialakítva, a második tranzakciós eszköz az engedély birtokában, elektronikus pénznek az első tranzakciós eszközből a második tranzakciós eszközbe, vevő bankjának pénzteijesztő tevékenységétől függetlenül történő juttatására alkalmasan van kialakítva.
  17. 17. A 16. igénypont szerinti rendszer, azzaljellemezve, hogy a második elektronikus tranzakciós eszköz (122) szolgáltató banki hálózatával (200) és vevő banki hálózatával kapcsolatban lévő, a pénzlehívást engedélyező, engedélyezőhálózattal (208) van kapcsolatban.
  18. 18. A 17. igénypont szerinti rendszer, azzaljellemezve, hogy a második elektronikus tranzakciós eszköz (122) szolgáltató banki hálózatának (200) elektronikus pénzt terjesztő bankjával van kapcsolatban.
  19. 19. A 16. igénypont szerinti rendszer, azzal jellemezve, hogy az első processzortól megkapott pénzlehívási feltételek vevő debit vagy kredit bankkártyán vannak adva, és tartalmazzák a vevő bankszámlaszámát.
  20. 20. Elektronikuspénz-teijesztő rendszer, amelynek része egy feltörés ellen védett, első elektronikus tranzakciós eszköz (122), amelynek első processzora van, továbbá része egy feltörés ellen védett, második elektronikus tranzakciós eszköz (122), amelynek második proceszszora van, és amely második tranzakciós eszköz (122) az első tranzakciós eszközzel (122), kódolással védett kapcsolat létesítésére alkalmasan van kialakítva, azzal jellemezve, hogy az első processzor elektronikuspénz-eladási szándék és -pénzlehívási feltételek információ második processzorral történő közlésére alkalmasan van kialakítva, a második processzor az első processzortól megkapott pénzeladási szándék és a pénzlehívási feltételek átvételi jegybe (8) foglalására és az átvételi jegy (8) kódolással védett kapcsolatban, az első tranzakciós modulhoz továbbítására alkalmasan van kialakítva, a második processzor egy engedélyezőhálózatnál (208) az első processzortól kapott pénzeladási szándék információnak megfelelő és a pénzlehívási feltételekkel történő pénzlehívás kezdeményezésére alkalmasan van kialakítva, a második tranzakciós eszköz, az engedély birtokában, elektronikus pénznek az első tranzakciós eszköztől történő lehívására alkalmasan van kialakítva.
  21. 21. A 20. igénypont szerinti rendszer, azzal jellemezve, hogy a második elektronikus tranzakciós eszköz (122) szolgáltatóhálózatával (192) és vevő banki hálózatával kapcsolatban lévő, a pénzlehívást engedélyező, engedélyezőhálózattal (208) van kapcsolatban.
  22. 22. A 21. igénypont szerinti rendszer, azzal jellemezve, hogy a második elektronikus tranzakciós eszköz (122) szolgáltató banki hálózatának (200) elektronikus pénzt teijesztő bankjával van kapcsolatban.
  23. 23. A 20. igénypont szerinti rendszer, azzal jellemezve, hogy a pénzlehívási feltételeket egy, a vevő bankszámlaszámát tartalmazó debit vagy kredit bankkártya tartalmazza.
HU9801603A 1995-06-07 1996-03-11 Elektronikus pénzterjesztő rendszer és eljárás HU220576B1 (hu)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US08/488,248 US5745886A (en) 1995-06-07 1995-06-07 Trusted agents for open distribution of electronic money
PCT/US1996/002569 WO1996041315A1 (en) 1995-06-07 1996-03-11 Trusted agents for open distribution of electronic money

Publications (3)

Publication Number Publication Date
HUP9801603A2 HUP9801603A2 (hu) 1998-10-28
HUP9801603A3 HUP9801603A3 (en) 1999-03-01
HU220576B1 true HU220576B1 (hu) 2002-03-28

Family

ID=23938951

Family Applications (1)

Application Number Title Priority Date Filing Date
HU9801603A HU220576B1 (hu) 1995-06-07 1996-03-11 Elektronikus pénzterjesztő rendszer és eljárás

Country Status (21)

Country Link
US (1) US5745886A (hu)
EP (1) EP0830656B1 (hu)
JP (1) JP3390016B2 (hu)
KR (1) KR100289956B1 (hu)
AT (1) ATE179538T1 (hu)
AU (1) AU697632B2 (hu)
BR (1) BR9608559A (hu)
CA (1) CA2223079C (hu)
CZ (1) CZ287663B6 (hu)
DE (1) DE69602265T2 (hu)
ES (1) ES2132909T3 (hu)
HK (1) HK1009193A1 (hu)
HU (1) HU220576B1 (hu)
MX (1) MX9709725A (hu)
NO (1) NO975670L (hu)
NZ (1) NZ305540A (hu)
PL (1) PL179381B1 (hu)
RU (1) RU2145439C1 (hu)
SI (1) SI9620073A (hu)
SK (1) SK167397A3 (hu)
WO (1) WO1996041315A1 (hu)

Families Citing this family (213)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2735261B1 (fr) * 1995-06-08 1997-07-11 France Telecom Procede de realisation d'un paiement utilisant un gestionnaire de comptes
FR2737032B1 (fr) * 1995-07-19 1997-09-26 France Telecom Systeme de paiement securise par transfert de monnaie electronique a travers un reseau interbancaire
US6223168B1 (en) * 1995-07-25 2001-04-24 Bottomline Technologies, Inc. Automatic remittance delivery system
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
JP2942478B2 (ja) * 1995-09-14 1999-08-30 日立ソフトウエアエンジニアリング株式会社 ネットワーク課金方法
US10586282B2 (en) 1996-03-25 2020-03-10 Cfph, Llc System and method for trading based on tournament-style events
US6505174B1 (en) 1996-03-25 2003-01-07 Hsx, Inc. Computer-implemented securities trading system with a virtual specialist function
US7487123B1 (en) * 1996-03-25 2009-02-03 Cfph, Llc Computer-implemented securities trading system with virtual currency and virtual specialist
US6945457B1 (en) 1996-05-10 2005-09-20 Transaction Holdings Ltd. L.L.C. Automated transaction machine
US5987434A (en) * 1996-06-10 1999-11-16 Libman; Richard Marc Apparatus and method for transacting marketing and sales of financial products
US7774230B2 (en) 1996-06-10 2010-08-10 Phoenix Licensing, Llc System, method, and computer program product for selecting and presenting financial products and services
US6999938B1 (en) 1996-06-10 2006-02-14 Libman Richard M Automated reply generation direct marketing system
US5897621A (en) * 1996-06-14 1999-04-27 Cybercash, Inc. System and method for multi-currency transactions
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
JP3387330B2 (ja) * 1996-09-12 2003-03-17 株式会社日立製作所 電子マネー保有装置およびこれを用いる電子マネー支払い方法
US5839119A (en) * 1996-09-27 1998-11-17 Xerox Corporation Method of electronic payments that prevents double-spending
US5884290A (en) * 1996-10-22 1999-03-16 Unisys Corporation Method of transferring funds employing a three-node real-time electronic interlock
DE69603971T2 (de) * 1996-12-13 2000-03-30 Ericsson Telefon Ab L M Verfahren und System zur Durchführung von Geldtransaktionen
US5980078A (en) * 1997-02-14 1999-11-09 Fisher-Rosemount Systems, Inc. Process control system including automatic sensing and automatic configuration of devices
WO1998041918A1 (en) * 1997-03-14 1998-09-24 Ian Charles Ogilvy Method and apparatus for controlling communications
JP3994466B2 (ja) 1997-03-26 2007-10-17 ソニー株式会社 ユーザ端末及び携帯再生装置
US6341353B1 (en) * 1997-04-11 2002-01-22 The Brodia Group Smart electronic receipt system
JP3483441B2 (ja) * 1997-10-16 2004-01-06 富士通株式会社 電子マネーの管理所有装置および管理所有方法
US6157924A (en) 1997-11-07 2000-12-05 Bell & Howell Mail Processing Systems Company Systems, methods, and computer program products for delivering information in a preferred medium
US6134550A (en) * 1998-03-18 2000-10-17 Entrust Technologies Limited Method and apparatus for use in determining validity of a certificate in a communication system employing trusted paths
US7139915B2 (en) * 1998-10-26 2006-11-21 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US6609199B1 (en) * 1998-10-26 2003-08-19 Microsoft Corporation Method and apparatus for authenticating an open system application to a portable IC device
US7194092B1 (en) * 1998-10-26 2007-03-20 Microsoft Corporation Key-based secure storage
US7174457B1 (en) 1999-03-10 2007-02-06 Microsoft Corporation System and method for authenticating an operating system to a central processing unit, providing the CPU/OS with secure storage, and authenticating the CPU/OS to a third party
US7047416B2 (en) * 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
US6820202B1 (en) * 1998-11-09 2004-11-16 First Data Corporation Account authority digital signature (AADS) system
IL139006A0 (en) * 1998-12-12 2001-11-25 Brodia Group Trusted agent for electronic commerce
RU2222046C2 (ru) * 1999-02-17 2004-01-20 Дайболд, Инкорпорейтед Способ и система для подсоединения услуг к автоматизированному устройству для осуществления транзакций
US7451114B1 (en) * 1999-02-19 2008-11-11 Visa International Service Association Conducting commerce between individuals
US6651171B1 (en) * 1999-04-06 2003-11-18 Microsoft Corporation Secure execution of program code
US6775779B1 (en) * 1999-04-06 2004-08-10 Microsoft Corporation Hierarchical trusted code for content protection in computers
US8099359B1 (en) 1999-04-19 2012-01-17 The Western Union Company System and method for issuing negotiable instruments by licensed money transmitter from direct deposits
US6704714B1 (en) 1999-05-03 2004-03-09 The Chase Manhattan Bank Virtual private lock box
US6609113B1 (en) 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
WO2000070487A1 (en) 1999-05-14 2000-11-23 Frenkel Marvin A Anonymous on-line cash management system
US20010034705A1 (en) * 1999-05-19 2001-10-25 Rhoads Geoffrey B. Payment-based systems for internet music
EP1208499A4 (en) * 1999-05-19 2007-11-07 Digimarc Corp METHOD AND SYSTEM WITH DIGITAL WATERMARKS IN MUSIC AND OTHER MEDIA.
IES990584A2 (en) * 1999-07-12 2000-07-12 Mainline Corporate Holdings Dynamic currency conversion for card payment systems
US6963857B1 (en) * 1999-07-12 2005-11-08 Jsa Technologies Network-accessible account system
AU4933799A (en) 1999-08-02 2001-02-19 E-Mark Systems Inc. Electronic settlement system, settlement device, and terminal
US7644037B1 (en) 1999-08-16 2010-01-05 Vladimir Ostrovsky Method and system for transferring electronic funds
WO2001015100A1 (en) 1999-08-26 2001-03-01 Eluv Holdings Ltd. Electronic currency, electronic wallet therefor and electronic payment systems employing them
BR0007026A (pt) * 1999-08-27 2002-06-18 Netspend Corp Sistema e método de compra on-line
US6799166B2 (en) * 1999-09-02 2004-09-28 International Business Machines Corporation Method and apparatus for preventing duplicate transactions on batch mode failure recovery in a data processing system
AU5759699A (en) * 1999-09-22 2001-04-24 Keiichi Nakajima Electronic settlement system, settlement device, and terminal
US6488203B1 (en) * 1999-10-26 2002-12-03 First Data Corporation Method and system for performing money transfer transactions
US7617157B2 (en) * 2002-01-03 2009-11-10 The Western Union Company Method for receiving electronically transferred funds using an automated teller machine
US7104440B2 (en) * 1999-10-26 2006-09-12 First Data Corporation Money transfer systems and methods for travelers
US6814282B2 (en) * 1999-10-26 2004-11-09 First Data Corporation Systems and methods of introducing and receiving information across a computer network
US8494956B2 (en) 1999-10-26 2013-07-23 The Western Union Company Internet funds transfer system using ATM pickup
US7664703B2 (en) * 1999-10-26 2010-02-16 The Western Union Company Value transfer systems and methods
AU1104601A (en) * 1999-10-29 2001-05-14 Singleshop.Com System and method of aggregate electronic transactions with multiple sources
US6332134B1 (en) * 1999-11-01 2001-12-18 Chuck Foster Financial transaction system
US6789068B1 (en) * 1999-11-08 2004-09-07 At&T Corp. System and method for microbilling using a trust management system
SE516782C2 (sv) * 1999-11-23 2002-03-05 Ericsson Telefon Ab L M Metod för betalning av varor i ett elektroniskt handelssystem samt ett betalningssystem
US8571975B1 (en) 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
US6757824B1 (en) 1999-12-10 2004-06-29 Microsoft Corporation Client-side boot domains and boot rules
AU2261501A (en) * 1999-12-16 2001-06-25 Debit.Net, Inc. Secure networked transaction system
US7003789B1 (en) * 1999-12-21 2006-02-21 International Business Machines Corporation Television commerce payments
US7376587B1 (en) * 2000-07-11 2008-05-20 Western Union Financial Services, Inc. Method for enabling transfer of funds through a computer network
US7593898B1 (en) 1999-12-30 2009-09-22 First Data Corporation Method and system for payment transactions and shipment tracking over the internet
US7177836B1 (en) * 1999-12-30 2007-02-13 First Data Corporation Method and system for facilitating financial transactions between consumers over the internet
US7613653B2 (en) 1999-12-30 2009-11-03 First Data Corporation Money order debit from stored value fund
CA2396266C (en) * 2000-01-12 2007-03-13 Metavante Corporation Integrated systems for electronic bill presentment and payment
US20010037295A1 (en) * 2000-01-31 2001-11-01 Olsen Karl R. Push model internet bill presentment and payment system and method
US7366695B1 (en) * 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
US20030126036A1 (en) * 2000-02-29 2003-07-03 First Data Corporation Online payments
US7848972B1 (en) 2000-04-06 2010-12-07 Metavante Corporation Electronic bill presentment and payment systems and processes
AU2001263013B2 (en) * 2000-05-09 2006-06-29 Metavante Corporation Electronic bill presentment and payment system
US7516100B1 (en) 2000-05-12 2009-04-07 The Western Union Company Method and system for transferring money in business-to-business internet transactions
US8725656B1 (en) 2000-05-18 2014-05-13 United Parcel Service Of America, Inc. Freight rate manager
US8321356B2 (en) * 2000-05-18 2012-11-27 United Parcel Service Of America, Inc. System and method for calculating real-time costing information
JP2001344537A (ja) * 2000-05-31 2001-12-14 Ntt Docomo Inc 電子バリューシステム、通信端末及びサーバ
US7076445B1 (en) 2000-06-20 2006-07-11 Cartwright Shawn D System and methods for obtaining advantages and transacting the same in a computer gaming environment
US7366690B1 (en) 2000-06-23 2008-04-29 Ebs Group Limited Architecture for anonymous trading system
US7949600B1 (en) 2000-06-27 2011-05-24 Western Union Financial Services, Inc. Method for facilitating payment of a computerized transaction
US7249098B2 (en) 2000-07-11 2007-07-24 First Data Corporation Subscription-based payment
US7398252B2 (en) * 2000-07-11 2008-07-08 First Data Corporation Automated group payment
US20020152168A1 (en) * 2000-07-11 2002-10-17 First Data Corporation Automated transfer with stored value fund
US7606734B2 (en) * 2000-07-11 2009-10-20 The Western Union Company Wide area network person-to-person payment
US7523067B1 (en) 2000-08-02 2009-04-21 Softbankbb Corporation Electronic settlement system, settlement apparatus, and terminal
US7082533B2 (en) * 2000-08-04 2006-07-25 First Data Corporation Gauging risk in electronic communications regarding accounts in ABDS system
US7552333B2 (en) * 2000-08-04 2009-06-23 First Data Corporation Trusted authentication digital signature (tads) system
US6983368B2 (en) * 2000-08-04 2006-01-03 First Data Corporation Linking public key of device to information during manufacture
EP1320956A4 (en) * 2000-08-04 2006-06-21 First Data Corp DIGITAL SIGNATURE SYSTEM WITH CERTIFICATION OF AUTHENTITICITY
US7096354B2 (en) * 2000-08-04 2006-08-22 First Data Corporation Central key authority database in an ABDS system
US7010691B2 (en) * 2000-08-04 2006-03-07 First Data Corporation ABDS system utilizing security information in authenticating entity access
US6978369B2 (en) * 2000-08-04 2005-12-20 First Data Corporation Person-centric account-based digital signature system
US6789189B2 (en) * 2000-08-04 2004-09-07 First Data Corporation Managing account database in ABDS system
US7558965B2 (en) * 2000-08-04 2009-07-07 First Data Corporation Entity authentication in electronic communications by providing verification status of device
US7346577B1 (en) 2000-08-28 2008-03-18 Javien Digital Payment Solutions, Inc. Third-party billing system and method
WO2002019282A2 (en) * 2000-08-31 2002-03-07 Atm Direct, Inc. System and method for online atm transaction with digital certificate
JP2002117169A (ja) * 2000-10-12 2002-04-19 Hitachi Ltd 個人情報管理方法及びその実施装置並びにその処理プログラムを記録した記録媒体
JP2002140630A (ja) * 2000-11-01 2002-05-17 Sony Corp チケットに基づくコンテンツ料金精算システムおよびチケットに基づくコンテンツ料金精算方法
WO2002037383A2 (en) * 2000-11-06 2002-05-10 Electronic Warfare Associates A system and method for controlling online purchases using an online account
US7290133B1 (en) 2000-11-17 2007-10-30 Entrust Limited Method and apparatus improving efficiency of end-user certificate validation
US6938164B1 (en) 2000-11-22 2005-08-30 Microsoft Corporation Method and system for allowing code to be securely initialized in a computer
US7266533B2 (en) 2000-12-15 2007-09-04 The Western Union Company Electronic gift greeting
US7130817B2 (en) 2000-12-15 2006-10-31 First Data Corporation Electronic gift linking
US20020107790A1 (en) * 2001-02-07 2002-08-08 Nielson James A. System and method for extending automatically secured credit to building project owners and to building contractors for purchasing building supplies from building supply wholesalers
JP2002259605A (ja) * 2001-02-26 2002-09-13 Sony Corp 情報処理装置及び方法、並びに記憶媒体
US7165052B2 (en) 2001-03-31 2007-01-16 First Data Corporation Payment service method and system
US7103577B2 (en) * 2001-03-31 2006-09-05 First Data Corporation Systems and methods for staging transactions, payments and collections
US7117183B2 (en) 2001-03-31 2006-10-03 First Data Coroporation Airline ticket payment and reservation system and methods
US7184989B2 (en) * 2001-03-31 2007-02-27 First Data Corporation Staged transactions systems and methods
WO2002079939A2 (en) * 2001-03-31 2002-10-10 First Data Corporation Electronic identifier payment system and methods
US9853759B1 (en) 2001-03-31 2017-12-26 First Data Corporation Staged transaction system for mobile commerce
US8150763B2 (en) * 2001-03-31 2012-04-03 The Western Union Company Systems and methods for staging transactions, payments and collections
US6807640B2 (en) * 2001-05-08 2004-10-19 Intersil Americas, Inc. Programmable interface controller suitable for spanning clock domains
US8346659B1 (en) * 2001-07-06 2013-01-01 Hossein Mohsenzadeh Secure authentication and payment system
US20040128508A1 (en) * 2001-08-06 2004-07-01 Wheeler Lynn Henry Method and apparatus for access authentication entity
CA2355785C (en) * 2001-08-16 2010-06-01 Ibm Canada Limited-Ibm Canada Limitee Electronic presentation of invoices using a trusted document repository
US7752266B2 (en) 2001-10-11 2010-07-06 Ebay Inc. System and method to facilitate translation of communications between entities over a network
US8244632B2 (en) 2001-10-26 2012-08-14 First Data Corporation Automated transfer with stored value
US8374962B2 (en) * 2001-10-26 2013-02-12 First Data Corporation Stored value payouts
US7370014B1 (en) 2001-11-01 2008-05-06 Metavante Corporation Electronic bill presentment and payment system that obtains user bill information from biller web sites
US6670569B2 (en) * 2001-11-08 2003-12-30 First Data Corporation Mail handling equipment and methods
US7137004B2 (en) * 2001-11-16 2006-11-14 Microsoft Corporation Manifest-based trusted agent management in a trusted operating system environment
US7243230B2 (en) * 2001-11-16 2007-07-10 Microsoft Corporation Transferring application secrets in a trusted operating system environment
US7159240B2 (en) * 2001-11-16 2007-01-02 Microsoft Corporation Operating system upgrades in a trusted operating system environment
US7159180B2 (en) 2001-12-14 2007-01-02 America Online, Inc. Proxy platform integration system
US7596529B2 (en) * 2002-02-13 2009-09-29 First Data Corporation Buttons for person to person payments
EP1485844A4 (en) * 2002-03-04 2010-03-31 First Data Corp METHOD AND SYSTEM FOR PROCESSING CREDIT CARD RELATED TRANSACTIONS
FR2837643A1 (fr) * 2002-03-25 2003-09-26 France Telecom Procede de securisation d'un paiement par carte de credit
US7487365B2 (en) * 2002-04-17 2009-02-03 Microsoft Corporation Saving and retrieving data based on symmetric key encryption
US7890771B2 (en) * 2002-04-17 2011-02-15 Microsoft Corporation Saving and retrieving data based on public key encryption
US8751384B2 (en) * 2002-05-08 2014-06-10 Metavante Corporation Integrated bill presentment and payment system and method of operating the same
US8799157B1 (en) 2002-05-08 2014-08-05 Metavante Corporation Business combined bill management system and method
US8078505B2 (en) 2002-06-10 2011-12-13 Ebay Inc. Method and system for automatically updating a seller application utilized in a network-based transaction facility
US10395484B2 (en) 2002-08-20 2019-08-27 The Western Union Company Multi-purpose kiosk and methods
AU2003200960B2 (en) * 2002-09-18 2005-01-06 Mackinnon, Sebastian Mr System for Ordering, Tracking and Payment of Goods and Services
US7729984B1 (en) 2002-09-27 2010-06-01 Abas Enterprises Llc Effecting financial transactions
US8032452B2 (en) 2002-11-06 2011-10-04 The Western Union Company Multiple-entity transaction systems and methods
US7478057B2 (en) * 2002-11-29 2009-01-13 Research In Motion Limited Method for conducting an electronic commercial transaction
US7571140B2 (en) * 2002-12-16 2009-08-04 First Data Corporation Payment management
US20040135805A1 (en) * 2003-01-10 2004-07-15 Gottsacker Neal F. Document composition system and method
US7827101B2 (en) 2003-01-10 2010-11-02 First Data Corporation Payment system clearing for transactions
US7003493B2 (en) * 2003-01-22 2006-02-21 First Data Corporation Direct payment with token
US8353763B2 (en) 2003-03-31 2013-01-15 Cantor Index, Llc System and method for betting on a participant in a group of events
US9881308B2 (en) 2003-04-11 2018-01-30 Ebay Inc. Method and system to facilitate an online promotion relating to a network-based marketplace
US7063473B2 (en) * 2003-04-18 2006-06-20 Canon Kabushiki Kaisha Both-side recording apparatus
US20040215560A1 (en) * 2003-04-25 2004-10-28 Peter Amalraj Integrated payment system and method
US20040215574A1 (en) 2003-04-25 2004-10-28 First Data Corporation Systems and methods for verifying identities in transactions
US7742985B1 (en) 2003-06-26 2010-06-22 Paypal Inc. Multicurrency exchanges between participants of a network-based transaction facility
US20050177510A1 (en) * 2004-02-09 2005-08-11 Visa International Service Association, A Delaware Corporation Buyer initiated payment
US7725406B2 (en) * 2004-03-30 2010-05-25 United Parcel Service Of America, Inc. Systems and methods for international shipping and brokerage operations support processing
US7219832B2 (en) * 2004-06-17 2007-05-22 First Data Corporation ATM machine and methods with currency conversion capabilities
US20080147525A1 (en) * 2004-06-18 2008-06-19 Gene Allen CPU Banking Approach for Transactions Involving Educational Entities
US20050289030A1 (en) * 2004-06-24 2005-12-29 Smith Maurice R System and method for financial institution account deposits via retail merchants
US7015823B1 (en) 2004-10-15 2006-03-21 Systran Federal Corporation Tamper resistant circuit boards
US7641109B2 (en) * 2005-05-18 2010-01-05 The Western Union Company Money transfer cards, systems and methods
US8152054B2 (en) 2004-10-19 2012-04-10 The Western Union Company Money transfer systems and methods
WO2006052963A2 (en) * 2004-11-04 2006-05-18 Telcordia Technologies, Inc. System and method for trust management
JP2006252462A (ja) 2005-03-14 2006-09-21 Ntt Docomo Inc 電子価値交換方法、利用者装置及び第三者装置
US7392940B2 (en) 2005-05-18 2008-07-01 The Western Union Company In-lane money transfer systems and methods
US8672220B2 (en) 2005-09-30 2014-03-18 The Western Union Company Money transfer system and method
US20070214091A1 (en) * 2005-05-18 2007-09-13 The Western Union Company Electronic payment instrument system and method
WO2007011786A2 (en) * 2005-07-15 2007-01-25 Revolution Money, Inc. System and method for establishment of rules governing child accounts
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
US9704174B1 (en) 2006-05-25 2017-07-11 Sean I. Mcghie Conversion of loyalty program points to commerce partner points per terms of a mutual agreement
US8668146B1 (en) 2006-05-25 2014-03-11 Sean I. Mcghie Rewards program with payment artifact permitting conversion/transfer of non-negotiable credits to entity independent funds
US7703673B2 (en) 2006-05-25 2010-04-27 Buchheit Brian K Web based conversion of non-negotiable credits associated with an entity to entity independent negotiable funds
US10062062B1 (en) 2006-05-25 2018-08-28 Jbshbm, Llc Automated teller machine (ATM) providing money for loyalty points
WO2008005581A2 (en) * 2006-07-07 2008-01-10 United Parcel Service Of America, Inc. Compiled data for software applications
US20070100773A1 (en) * 2006-08-11 2007-05-03 Regions Asset Company Transaction security system having user defined security parameters
US8639782B2 (en) 2006-08-23 2014-01-28 Ebay, Inc. Method and system for sharing metadata between interfaces
US8060437B2 (en) 2006-10-31 2011-11-15 International Funding Partners Llc Automatic termination of electronic transactions
US20080103966A1 (en) * 2006-10-31 2008-05-01 Chuck Foster System and/or method for dynamic determination of transaction processing fees
US8719128B2 (en) * 2006-12-15 2014-05-06 Tcf Financial Corporation Computer-facilitated secure account-transaction
US20080147526A1 (en) * 2006-12-15 2008-06-19 Gene Allen Computer-Facilitated Account-Transaction System and Method with Multi-Entity Control Logic
US20080208748A1 (en) * 2006-12-22 2008-08-28 Frank Ozment Transaction system and method
US7933835B2 (en) 2007-01-17 2011-04-26 The Western Union Company Secure money transfer systems and methods using biometric keys associated therewith
US8818904B2 (en) 2007-01-17 2014-08-26 The Western Union Company Generation systems and methods for transaction identifiers having biometric keys associated therewith
US8504473B2 (en) 2007-03-28 2013-08-06 The Western Union Company Money transfer system and messaging system
US7783571B2 (en) 2007-05-31 2010-08-24 First Data Corporation ATM system for receiving cash deposits from non-networked clients
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
US20090112759A1 (en) * 2007-10-30 2009-04-30 Chuck Foster Accumulated transactions
US20090319427A1 (en) * 2008-06-23 2009-12-24 Jeffrey Gardner Methods for electronic payments using a third party facilitator
US7860772B2 (en) * 2008-09-30 2010-12-28 Ebay, Inc. Funding on-line accounts
WO2013106047A1 (en) * 2011-04-07 2013-07-18 Fotec Group Llc Broker-mediated payment systems and methods
US20130030924A1 (en) 2011-07-28 2013-01-31 American Express Travel Related Services Company, Inc. Systems and methods for generating and using a digital pass
US10346823B2 (en) 2011-08-12 2019-07-09 Citibank, N.A. Methods and systems for activating an electronic payments infrastructure
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US20130238488A1 (en) 2012-03-07 2013-09-12 Clearxchange, Llc System and method for transferring funds
RU2584506C1 (ru) * 2014-10-22 2016-05-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ защиты операций с электронными деньгами
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10776780B2 (en) 2016-05-27 2020-09-15 Visa International Service Association Automated reissuance system for prepaid devices
US11151567B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
RU2678655C1 (ru) * 2017-11-20 2019-01-30 Публичное Акционерное Общество "Сбербанк России" (Пао Сбербанк) Способ и система осуществления транзакций с помощью механизма реверсалов

Family Cites Families (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4529870A (en) * 1980-03-10 1985-07-16 David Chaum Cryptographic identification, financial transaction, and credential device
US4443027A (en) * 1981-07-29 1984-04-17 Mcneely Maurice G Multiple company credit card system
US4454414A (en) * 1982-06-16 1984-06-12 Vericard Corporation Funds transfer system using optically coupled, portable modules
US4926480A (en) * 1983-08-22 1990-05-15 David Chaum Card-computer moderated systems
IL75702A0 (en) * 1984-07-27 1985-11-29 Technion Res & Dev Foundation Apparatus for effecting and recording monetary transactions
US4644493A (en) * 1984-09-14 1987-02-17 International Business Machines Corporation Implementing a shared higher level of privilege on personal computers for copy protection of software
US4823264A (en) * 1986-05-27 1989-04-18 Deming Gilbert R Electronic funds transfer system
US5117457A (en) * 1986-11-05 1992-05-26 International Business Machines Corp. Tamper resistant packaging for information protection in electronic circuitry
US4817140A (en) * 1986-11-05 1989-03-28 International Business Machines Corp. Software protection system using a single-key cryptosystem, a hardware-based authorization system and a secure coprocessor
US5109413A (en) * 1986-11-05 1992-04-28 International Business Machines Corporation Manipulating rights-to-execute in connection with a software copy protection mechanism
US5148534A (en) * 1986-11-05 1992-09-15 International Business Machines Corp. Hardware cartridge representing verifiable, use-once authorization
US4916738A (en) * 1986-11-05 1990-04-10 International Business Machines Corp. Remote access terminal security
US5162989A (en) * 1987-02-20 1992-11-10 Oki Electric Industry Co., Ltd. Information rental system including processor equipped IC card having data erasing means
US4999806A (en) * 1987-09-04 1991-03-12 Fred Chernow Software distribution system
GB8814471D0 (en) * 1988-06-17 1988-07-20 Gore & Ass Security enclosure
US5185717A (en) * 1988-08-05 1993-02-09 Ryoichi Mori Tamper resistant module having logical elements arranged in multiple layers on the outer surface of a substrate to protect stored information
FR2642202B1 (fr) * 1989-01-25 1994-02-18 Urba 2000 Systeme de paiement electronique de transports et de services publics par cartes a microcircuit
DE3906349A1 (de) * 1989-03-01 1990-09-13 Hartmut Hennige Verfahren und vorrichtung zur vereinfachung des gebrauchs einer vielzahl von kreditkarten u. dgl.
GB8920446D0 (en) * 1989-09-09 1989-10-25 Schlumberger Ind Ltd Electricity metering systems
DE69031614T2 (de) * 1990-01-29 1998-05-07 Security Techn Corp Wahlweise moderierte Transaktionssysteme
EP0474360A3 (en) * 1990-08-29 1993-07-07 Visa International Service Association A system for validating the authenticity of a transaction employing electronic receipts
FR2671889A1 (fr) * 1991-01-22 1992-07-24 Pailles Jean Claude Procede d'echange de droits entre cartes a microprocesseur.
CA2059078C (en) * 1991-02-27 1995-10-03 Alexander G. Fraser Mediation of transactions by a communications system
US5202921A (en) * 1991-04-01 1993-04-13 International Business Machines Corporation Method and apparatus for authenticating users of a communication system to each other
GB2257557B (en) * 1991-07-08 1994-11-16 Amstrad Plc Video recorder system
GB9121995D0 (en) * 1991-10-16 1991-11-27 Jonhig Ltd Value transfer system
US5453601A (en) * 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5334823A (en) * 1992-01-10 1994-08-02 National Bancard Corporation Systems and methods for operating data card terminals for transaction chargeback protection
JPH0619933A (ja) * 1992-05-11 1994-01-28 Nobuyuki Sonoya 無形信号販売集計システム
AU4667793A (en) * 1992-07-08 1994-01-31 Northwest Starscan Limited Partnership Financial transaction system for electronic services
US5319705A (en) * 1992-10-21 1994-06-07 International Business Machines Corporation Method and system for multimedia access control enablement
US5416840A (en) * 1993-07-06 1995-05-16 Phoenix Technologies, Ltd. Software catalog encoding method and system

Also Published As

Publication number Publication date
HK1009193A1 (en) 1999-05-28
ATE179538T1 (de) 1999-05-15
AU5355596A (en) 1996-12-30
CA2223079A1 (en) 1996-12-19
NO975670D0 (no) 1997-12-05
SK167397A3 (en) 1998-09-09
KR100289956B1 (ko) 2001-05-15
JP3390016B2 (ja) 2003-03-24
AU697632B2 (en) 1998-10-15
BR9608559A (pt) 1999-07-06
PL179381B1 (en) 2000-08-31
EP0830656B1 (en) 1999-04-28
CZ380597A3 (cs) 1998-04-15
PL323875A1 (en) 1998-04-27
HUP9801603A2 (hu) 1998-10-28
WO1996041315A1 (en) 1996-12-19
CA2223079C (en) 2005-03-01
NO975670L (no) 1998-01-20
DE69602265T2 (de) 1999-12-09
EP0830656A1 (en) 1998-03-25
JPH10511788A (ja) 1998-11-10
HUP9801603A3 (en) 1999-03-01
RU2145439C1 (ru) 2000-02-10
ES2132909T3 (es) 1999-08-16
SI9620073A (sl) 1998-08-31
KR19990022340A (ko) 1999-03-25
US5745886A (en) 1998-04-28
CZ287663B6 (en) 2001-01-17
MX9709725A (es) 1998-07-31
NZ305540A (en) 1999-10-28
DE69602265D1 (de) 1999-06-02

Similar Documents

Publication Publication Date Title
HU220576B1 (hu) Elektronikus pénzterjesztő rendszer és eljárás
HU218134B (hu) Elektronikus kereskedelmi fizető rendszer és eljárás, továbbá rendszer, elektronikus kereskedelmi fizetés és átutalási utasítás összekapcsolására
US7280984B2 (en) Money card system, method and apparatus
US6834270B1 (en) Secured financial transaction system using single use codes
EP1212734B1 (en) Electronic currency, electronic wallet therefor and electronic payment systems employing them
HU221396B1 (en) A method for exchanging currencies
US20010032878A1 (en) Method and system for making anonymous electronic payments on the world wide web
PL179928B1 (pl) Sposób otwartego handlu elektronicznego PL PL PL PL PL PL PL PL
CN111951106B (zh) 基于区块链智能合约技术的数据交易系统及其方法
US20040128247A1 (en) Bank system program, credit service program and IC card
EP2553890A1 (en) Message storage and transfer system
AU775065B2 (en) Payment method and system for online commerce
US7472092B2 (en) Money order device with identity verification and method
JPH09114904A (ja) 情報販売方法およびシステム
KR20010068434A (ko) 소액 전자상거래 방법
JP2003507824A (ja) 電子商取引を行うための保証システムおよびそれに用いる方法
US8510217B1 (en) Internet-calling card
KR20020021413A (ko) 케이블 텔레비전 시스템 및 결합된 엔터테인먼트 단말을매개로 전자 상거래 및 쇼핑을 제공하기 위한 방법 및시스템
KR20020061719A (ko) 전자상거래의 보안결제시스템
Leon Digital Cash Payments

Legal Events

Date Code Title Description
HMM4 Cancellation of final prot. due to non-payment of fee