HU220576B1 - Elektronikus pénzterjesztő rendszer és eljárás - Google Patents
Elektronikus pénzterjesztő rendszer és eljárás Download PDFInfo
- 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
Links
- 238000009826 distribution Methods 0.000 title claims abstract description 15
- 238000012546 transfer Methods 0.000 claims abstract description 67
- 238000000034 method Methods 0.000 claims abstract description 25
- 238000013475 authorization Methods 0.000 claims abstract description 24
- 238000003860 storage Methods 0.000 claims abstract description 13
- 230000000977 initiatory effect Effects 0.000 claims description 13
- 230000008569 process Effects 0.000 claims description 12
- 230000005540 biological transmission Effects 0.000 claims description 8
- 230000000694 effects Effects 0.000 claims description 2
- 230000008859 change Effects 0.000 abstract description 4
- 239000003795 chemical substances by application Substances 0.000 description 230
- 230000006870 function Effects 0.000 description 98
- 238000011156 evaluation Methods 0.000 description 16
- 238000010200 validation analysis Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 238000005336 cracking Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 5
- 238000004900 laundering Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000000712 assembly Effects 0.000 description 2
- 238000000429 assembly Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000012012 milestone trend analyses Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 102000003712 Complement factor B Human genes 0.000 description 1
- 108090000056 Complement factor B Proteins 0.000 description 1
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- VYPSYNLAJGMNEJ-UHFFFAOYSA-N Silicium dioxide Chemical compound O=[Si]=O VYPSYNLAJGMNEJ-UHFFFAOYSA-N 0.000 description 1
- 210000000085 cashmere Anatomy 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 238000010791 quenching Methods 0.000 description 1
- 230000000171 quenching effect Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
- 239000011782 vitamin Substances 0.000 description 1
- 229940088594 vitamin Drugs 0.000 description 1
- 229930003231 vitamin Natural products 0.000 description 1
- 235000013343 vitamin Nutrition 0.000 description 1
- 150000003722 vitamin derivatives Chemical class 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment 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"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q2220/00—Business processing using cryptography
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic 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)
- SZABADALMI IGÉNYPONTOK1. 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. 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. 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. 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. 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. 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. Elektronikuspénz-terjesztő rendszer, amelynek része vevő megbízottja (2), a vevő megbízottjához (2) tar16HU 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. 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. 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. 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, hogya) 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. 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. 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. 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, hogya) 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 Bli) 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
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)
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)
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 |
-
1995
- 1995-06-07 US US08/488,248 patent/US5745886A/en not_active Expired - Lifetime
-
1996
- 1996-03-11 SK SK1673-97A patent/SK167397A3/sk unknown
- 1996-03-11 WO PCT/US1996/002569 patent/WO1996041315A1/en active IP Right Grant
- 1996-03-11 EP EP96910330A patent/EP0830656B1/en not_active Expired - Lifetime
- 1996-03-11 CA CA002223079A patent/CA2223079C/en not_active Expired - Fee Related
- 1996-03-11 BR BR9608559A patent/BR9608559A/pt not_active IP Right Cessation
- 1996-03-11 PL PL96323875A patent/PL179381B1/pl not_active IP Right Cessation
- 1996-03-11 SI SI9620073A patent/SI9620073A/sl unknown
- 1996-03-11 CZ CZ19973805A patent/CZ287663B6/cs not_active IP Right Cessation
- 1996-03-11 ES ES96910330T patent/ES2132909T3/es not_active Expired - Lifetime
- 1996-03-11 NZ NZ305540A patent/NZ305540A/en unknown
- 1996-03-11 AU AU53555/96A patent/AU697632B2/en not_active Ceased
- 1996-03-11 KR KR1019970708820A patent/KR100289956B1/ko not_active IP Right Cessation
- 1996-03-11 HU HU9801603A patent/HU220576B1/hu not_active IP Right Cessation
- 1996-03-11 AT AT96910330T patent/ATE179538T1/de not_active IP Right Cessation
- 1996-03-11 RU RU98100475/09A patent/RU2145439C1/ru not_active IP Right Cessation
- 1996-03-11 DE DE69602265T patent/DE69602265T2/de not_active Expired - Fee Related
- 1996-03-11 JP JP50042997A patent/JP3390016B2/ja not_active Expired - Fee Related
-
1997
- 1997-12-05 MX MX9709725A patent/MX9709725A/es active IP Right Grant
- 1997-12-05 NO NO975670A patent/NO975670L/no not_active Application Discontinuation
-
1998
- 1998-08-18 HK HK98109991A patent/HK1009193A1/xx not_active IP Right Cessation
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 |