PL180151B1 - Sposób realizacji elektronicznych platnosci handlowych PL PL PL PL PL PL PL - Google Patents

Abstract

1 . Sposób realizacji elektronicznych platnosci handlowych, w którym przeprowadza sie wymiane pieniedzy elektronicznych przy wykorzystaniu modulu zaufanego agenta klienta, pierwsze- go modulu finansowego, modulu zaufanego agenta sprzedawcy i drugiego modulu pienieznego, z utworzeniem zabezpieczonego srodowiska transakcyjnego, znam ienny tym, ze przesyla sie dane zlecenia przelewu, za pomoca modulu zaufanego agenta klienta, do modulu zaufanego agenta sprzedawcy, tworzy sie za pomoca modulu zaufanego agenta sprzedawcy note platnosci handlowej zawierajaca, przynajmniej w czesci, dane zlecenia przelewu, przesyla sie za pomoca modulu zaufanego agenta sprzedawcy note platnosci handlowej, do modulu zaufanego agenta klienta, który tymczasowo zatrzymuje te note, przesyla sie za pomoca pierwszego modulu pienieznego elektroniczna reprezentacje pieniedzy, do drugiego modulu pienieznego, który tymczasowo zatrzymuje te elektroniczna reprezentacje pieniedzy, dokonuje sie zatwierdzenia za pomoca pierwszego modulu pienieznego i bezpiecznie informuje sie modul zaufanego agenta klienta o prawidlowo zakonczonym transferze pienieznym, nastepnie dokonuje sie zatwierdzenia za pomoca drugiego modulu pieniez- nego, w wyniku czego zatrzymanie elektronicznych pieniedzy przestaje byc tymczasowe i bezpiecznie informuje sie modul zaufanego agenta sprzedawcy o prawidlowo zakonczonym odbiorze elektronicznych pieniedzy, nastepnie dokonuje sie zatwierdzenia za pomoca modulu zaufanego agenta klienta, w wyniku czego zatrzymanie noty platnosci handlowej przestaje byc tymczasowe, a nastepnie dokonuje sie zatwierdzenia za pomoca modulu zaufanego agenta sprzedawcy Fig. 1 P L 1 8 0 1 5 1 B 1 PL PL PL PL PL PL PL

Description

Przedmiotem wynalazku jest sposób realizacji elektronicznych płatności handlowych, bez wykorzystania pośredników, a zwłaszcza sposób wykorzystujący zabezpieczone przed niepowołanym dostępem jednostki elektroniczne, nazywane zaufanymi agentami, w połączeniu z modułami pieniężnymi, tak by powstały odpowiednie warunki bezpieczeństwa transakcji dla obsługi handlowych płatności i związanej z nimi informacji o przelewach.

Stosowane są liczne elektroniczne systemy płatnicze w związku z rozwojem elektronicznych rozliczeń handlowych. Jednym ze znanych sposobów realizacji elektronicznych płatności jest sposób przedstawiony w amerykańskich opisach patentowych nr 5 453 601, 5 557 518 i 5 799 087. Te dokumenty opisują elektroniczne systemy pieniężne do realizacji elektronicznych płatności pieniężnych jako alternatywnego rozwiązania do stosowania gotówki, czeków, kart kredytowych, kart debetowych i elektronicznych przelewów kapitału. W szczególności, opisane systemy wykorzystują moduły pieniężne umieszczone w zabezpieczonych przed niepowołanym dostępem obudowach, przeznaczone do przechowywania i transferów elektronicznych rachunków. Wspomniane moduły mogą realizować płatności pieniężne w czasie rzeczywistym, bądź w trybie off-line, na przykład pomiędzy modułem pieniężnym zawartym w elektronicznym portfelu klienta i modułem pieniężnym umieszczonym w terminalu w punkcie sprzedaży, bądź w trybie on-line w przypadku usług sieciowych, takich jak pobieranie informacji i rozmowy telefoniczne, lub zakup biletów lotniczych, teatralnych i tym podobnych.

Moduły zaufanego agenta są przedstawione w opisie patentowym US nr 5 557 518. W opisie tym przedstawiono system do umożliwiania bezpiecznej realizacji elektronicznej sprzedaży z wykonywaną w czasie rzeczywistym anonimową płatnością lub z autoryzowaną płatnością. System zapewnia, że sprzedający i kupujący mogą, mieć pewność, że ich interesy są odpowiednio obsługiwane.

Płatności handlowe są najczęściej wykonywane poprzez czeki, chociaż zauważa się tendencję w kierunku elektronicznych przelewów kapitału - EFT (electronic funds transfer). Płatność handlowa, wykonywana czekiem lub poprzez przelewy EFT zawiera zlecenie przelewu, które pozwala odbiorcy na realizację płatności w odpowiedzi na nieuregulowaną fakturę (jedną lub wiele) klienta. Ważne jest dopasowanie płatności do zlecenia przelewu, tak by płatnik i odbiorca pieniędzy mogli dowieść swych poczynań w przypadku wszelkich niejasności.

W przypadku zapłaty czekiem, zlecenie przelewu jest z reguły drukowane wraz z czekiem. Opłaty czekiem są kosztowne tak dla płatnika, jak i dla odbiorcy pieniędzy. Płatnik musi wydrukować, wysłać i uzgodnić czeki, a odbiorca musi otworzyć przesyłkę, odczytać informację i zaczekać do wyjaśnienia czeku. Z powodu takiej nieefektywności coraz powszechniej stosuje się pośredników oferujących wypłatę lub zamknięte skrytki.

Widoczna jest również tendencja w kierunku płatności EFT, ponieważ obniża to koszty zarówno płatnika, jak i odbiorcy. Obecnie płatności typu EFT stanowią poniżej 5% płatności handlowych. Jedną z przeszkód w rozwoju płatności EFT jest potrzeba, by bank pośredniczył w transakcji. Przetwarzanie transakcji jest ograniczone przez wydajność systemów bankowych i nie może być zrealizowane, gdy banki płatnika i odbiorcy nie pozwalają na transakcje typu EFT. System EFT musi być zdolny do przesyłania zleceń przelewu wraz z komunikatem o płatności, tak by informacja o płatności mogła być dopasowana do płatności. Płatność EFT wymaga ustalonej relacji pomiędzy bankami, płatnikami i odbiorcami płatności. Ta zależność jest statyczna i trudna do zmiany.

Sposób realizacji elektronicznych płatności handlowych, w którym przeprowadza się wymianę pieniędzy elektronicznych przy wykorzystaniu modułu zaufanego agenta klienta, pierwszego modułu finansowego, modułu zaufanego agenta sprzedawcy i drugiego modułu pieniężnego, z utworzeniem zabezpieczonego środowiska transakcyjnego, według wynalazku charakteryzuje się tym, że przesyła się dane zlecenia przelewu, za pomocą modułu zaufanego agenta klienta, do modułu zaufanego agenta sprzedawcy, tworzy się za pomocą modułu zaufanego agenta sprzedawcy notę płatności handlowej zawierającą, przynajmniej w części, dane zlecenia przelewu, przesyła się za pomocą modułu zaufanego agenta sprzedawcy notę płatności handlowej, do modułu zaufanego agenta klienta, który tymczasowo

180 151 zatrzymuje tę notę, przesyła się za pomocą pierwszego modułu pieniężnego elektroniczną reprezentację pieniędzy, do drugiego modułu pieniężnego, który tymczasowo zatrzymuje tę elektroniczną reprezentację pieniędzy, dokonuje się zatwierdzenia za pomocą pierwszego modułu pieniężnego i bezpiecznie informuje się moduł zaufanego agenta klienta o prawidłowo zakończonym transferze pieniężnym, następnie dokonuje się zatwierdzenia za pomocą drugiego modułu pieniężnego, w wyniku czego zatrzymanie elektronicznych pieniędzy przestaje być tymczasowe i bezpiecznie informuje się moduł zaufanego agenta sprzedawcy o prawidłowo zakończonym odbiorze elektronicznych pieniędzy, następnie dokonuje się zatwierdzenia za pomocą modułu zaufanego agenta klienta, w wyniku czego zatrzymanie noty płatności handlowej przestaje być tymczasowe, a następnie dokonuje się zatwierdzenia za pomocą modułu zaufanego agenta sprzedawcy.

Korzystnym jest, że za pomocą modułu zaufanego agenta sprzedawcy tworzy się cyfrowy podpis pod danymi zlecenia przelewu i dołącza się ten podpis do noty płatności handlowej. Ponadto, za pomocą modułu zaufanego agenta klienta weryfikuje się cyfrowy podpis przed rozpoczęciem transferu elektronicznych pieniędzy.

W odmiennym wykonaniu, sposób realizacji elektronicznych płatności handlowych, w którym przeprowadza się wymianę pieniędzy elektronicznych przy wykorzystaniu pierwszego urządzenia transakcyjnego i drugiego urządzenia transakcyjnego, z utworzeniem zabezpieczonego środowiska transakcyjnego, według wynalazku charakteryzuje się tym, że za pomocą pierwszego urządzenia transakcyjnego przesyła się dane zlecenia przelewu do drugiego urządzenia transakcyjnego, następnie za pomocą drugiego urządzenia transakcyjnego zestawia się notę płatności handlowej zawierającą dane klienta, dane sprzedawcy, dane płatności, kwotę płatności oraz cyfrowy podpis i za pomocą tego drugiego urządzenia transmisyjnego przesyła się notę płatności handlowej do pierwszego urządzenia transakcyjnego, a za pomocą pierwszego urządzenia transakcyjnego weryfikuje się tę notę płatności handlowej i przesyła się elektroniczną reprezentację pieniędzy do drugiego urządzenia transakcyjnego.

Korzystnym jest, że cyfrowy podpis jest cyfrowym podpisem pod danymi zlecenia przelewu. Podczas weryfikacji noty płatności handlowej sprawdza się ważność cyfrowego podpisu. Dane zlecenia przelewu obejmują dane klienta i sprzedawcy, numer odniesienia klienta, adres sieciowy sprzedawcy, kwotę do zapłaty, datę i listę faktur do zapłaty. Ponadto, ustala się kryptograficznie zabezpieczony kanał za pomocą pierwszego urządzenia transakcyjnego i drugiego urządzenia transakcyjnego.

Rozwiązanie według wynalazku zapewnia sposób realizacji płatności handlowych, który umożliwia bezpieczne wykonywanie w sposób elektroniczny płatności handlowych pomiędzy płatnikiem i odbiorcą bez konieczności istnienia pośredników, oraz który zapewnia dopasowanie płatności do zlecenia przelewu. Transakcja może być przeprowadzona wygodnie dla obu stron i zapewnia odpowiednie udokumentowanie dla płatnika i odbiorcy w przypadku ich niezgody.

Wynalazek zapewnia sposób, który dopasowuje informację o płatności do płatności, tak że płatność jest gotowa i nie ma potrzeby dopasowywania informacji o płatności do rzeczywistej płatności po jej realizacji. W systemie płatniczym zapewniona jest informacja o płatności w postaci elektronicznego podpisu przez moduł zaufanego agenta odbiorcy, tak że odbiorca nie może się wyprzeć faktu otrzymania zależności.

Nota przelewu handlowego zawiera podpis cyfrowy modułu zaufanego agenta sprzedawcy dotyczący zlecenia przelewu. Następnie moduł zaufanego agenta klienta sprawdza cyfrowy podpis przed rozpoczęciem realizacji elektronicznej płatności pieniężnej.

Przedmiot wynalazku zostanie bliżej objaśniony w przykładach wykonania na rysunku, na którym fig. 1 przedstawia schematycznie współdziałanie pomiędzy modułami zaufanego agenta i modułami pieniężnymi, fig. 2A i 2B - dane zawarte w zleceniu przelewu utworzonym przez system płatniczy klienta, fig. 3 - sekcje i pola noty płatności handlowej, fig. 4 - komponenty urządzenia do realizacji transakcji, fig. 5A do 5D - elementy funkcjonalne modułów zaufanego agenta, fig. 6 - schemat pokazujący strukturę sieci dla handlowych płatności modułów pieniężnych, fig. 7A - protokół zatwierdzenia, fig. 7B - protokół przerwania, fig. 8A do 8D - płatność handlową modułów pieniężnych, fig. 9A do 9E - protokół ustanawiania sesji, fig. 10 - protokół wysyłania komunikatu, fig. 11 - protokół sprawdzania wierzytelności, fig. 12 - protokół przerwania transakcji, fig. 13A do 13E - protokół płatności modułu pieniężnego, fig. 14 - różne warstwy kodowania pomiędzy modułami zaufanych agentów i modułami pieniężnymi, fig. 15A do 15E - protokół ustanawiania sesji dla modułów pieniężnych, fig. 16 - protokół wysyłania skierowanego komunikatu, fig. 17 protokół wysyłania komunikatu MM/ΤΑ, fig. 18 - protokół wysyłania komunikatu TA/MM, fig. 19A do 19B - protokół transakcji przerwania dla modułów pieniężnych, fig. 20 - protokół wysyłania zakodowanego-skierowanego komunikatu, fig. 21A - 21B - protokół przesyłania not, a fig. 22 przedstawia protokół zatwierdzenia dla modułów pieniężnych.

W skład modułu zaufanego agenta wchodzą, sprzęt i oprogramowanie. Jest on zabezpieczony przed niepowołanym dostępem i przewiduje bezpieczne protokoły do współpracy z modułami pieniężnymi, tak by synchronizować bezpieczne dostarczanie płatności. Moduły pieniężne są urządzeniami zabezpieczonymi przed niepowołaną manipulacją, zdolnymi do przechowywania i transferu elektronicznych pieniędzy. Elektroniczne pieniądze mają korzystnie postać rachunków elektronicznych, które reprezentują środek płatniczy lub kredyt. Moduły pieniężne są również w stanie ustanowić kryptograficznie zabezpieczone sesje komunikacyjne z innymi urządzeniami. Korzystny przykład realizacji niniejszego wynalazku wykorzystuje znane moduły do transakcji pieniężnych, przedstawione w opisach patentowych US 5 453 601 i US 5 799 087.

W czasie wykonywania zakupu w sieci, moduły zaufanego agenta wymieniają elektroniczne operacje sprzedaży i zapłaty. Zgodnie z wynalazkiem, do wykonywania płatności handlowych, jak pokazano na fig. 1, moduł zaufanego agenta klienta CTA 2 wysyła informację zlecenia przelewu do modułu zaufanego agenta sprzedawcy MTA 4. Moduł zaufanego agenta sprzedawcy 4 wysyła następnie notę płatności handlowej do modułu zaufanego agenta klienta 2. W odpowiedzi, moduł pieniężny klienta 6 wysyła elektroniczną reprezentację pieniędzy do modułu pieniężnego sprzedawcy 6 przez moduł CTA 2 i moduł MTA 4.

System kont płatniczych klienta tworzy zlecenie przelewu, które ma być zapłacone przez zaufane urządzenie klienta. Zlecenie przelewu jest wysyłane do zaufanego urządzenia w sieci klienta. Jak pokazano na fig. 2A, zlecenie przelewu zawiera informację niezbędną do realizacji transakcji, na przykład informację o kliencie i sprzedawcy 46, 47, taką jak nazwa i adres klienta i sprzedawcy, numer referencyjny klienta, adres sieciowy sprzedawcy, sumę do zapłaty 49, datę płatności 48, i listę faktur 50 do zapłacenia. Jak to pokazano na fig. 2B, faktura zawiera wystarczające informacje dla sprzedawcy, tak by odpowiadały systemowi kont odbiorczych i mogły być użyte do odpowiednich wyjaśnień. Informacja o fakturze może zawierać numer faktury 51, numer porządkowy zakupu 52, datę płatności 53, sumę należności dla faktury 54, wielkość zniżek 55, oraz sumę netto 56.

Nawiązując do fig. 1 i 4, nota 8 jest elektroniczną pozycją wykreowaną przez moduł MTA 4 i przesyłaną do modułu CTA 2 w czasie transakcji. Noty mogą być uważane jako własność modułów zaufanego agenta. Klient, którego moduł CTA 2 właśnie odebrał notę, może użyć tej noty jedynie do prawidłowego dokończenia transakcji.

Moduły zaufanego agenta obsługują różne typy not stosowane do różnych celów. Jednakże, dla niniejszego wynalazku podstawowe znaczenie mają noty płatności handlowych. Nota płatności handlowej identyfikuje szczegóły płatności handlowej, posiada cyfrowy podpis odbiorcy pod zleceniem przelewu, oraz może być użyta przez klienta w przypadku wystąpienia niejasności.

Na fig. 3 pokazano korzystny przykład realizacji noty 8 składającej się z sześciu głównych sekcji: identyfikatora 10, komponentów 12, podpisu wystawcy 14, certyfikatu wystawcy 16, historii transferu 18 i podpisów nadawców 20. Z kolei wspomniane sekcje składają się z licznych pól zawierających różne informacje.

Sekcja identyfikacyjna 10 posiada pole 22 przechowujące informację, która identyfikuje sprzedawcę i instytucję kreujących notę. Taka informacja, na przykład nazwa sprzedawcy lub instytucji, jest kopiowana z uwierzytelnienia klienta przechowywanego przez wystawcę noty. Pole 24 zawiera numer identyfikacyjny modułu zaufanego agenta odbiorcy.

180 151

Pole 24 zawiera również datę wygaśnięcia wierzytelności modułu zaufanego agenta odbiorcy noty. Pole 26 określa typ noty (na przykład, nota karty kredytowej lub debetowej, nota płatności handlowej, i tym podobne). .

Sekcja komponentów 12 zawiera podstawowe dane, które różnią się w zależności od typu noty i jej konkretnego celu. Na fig. 3 pokazano przykład zawartości dla noty płatności handlowej.

Nota płatności handlowej zawiera korzystnie: pole informacji o kliencie 36, pole informacji o sprzedawcy 38, pole z datą płatności 40, pole zapłaconej sumy 42, pole 44 z podpisem zlecenia przelewu, które stanowi cyfrowy podpis modułu zaufanego agenta sprzedawcy MTA pod informacją zlecenia przelewu.

Sekcja podpisu wystawcy 14 noty 8 zawiera cyfrowy podpis, utworzony przez twórcę noty, pod sekcjami identyfikacyjną i komponentów 10 i 12. Taki podpis powstaje przy użyciu klucza prywatnego należącego do modułu zaufanego agenta wystawcy. Sekcja certyfikatu wystawcy 16 zawiera certyfikat wystawiony przez odpowiedni zaufany organ (trusted agency) użyty w połączeniu z podpisem wystawcy dla sprawdzenia autentyczności wystawionej noty 8. Taki certyfikat przynależy do modułu zaufanego agenta wystawcy. Zastosowanie certyfikatów i cyfrowych podpisów jest znane i opisane na przykład w publikacji D.W. Davies i W.L. Price, Security For Computer Networks (Bezpieczeństwo w sieciach komputerowych), John Wiley & Sons, 1984).

Sekcja historii transferu 18 zawiera informację generowaną, gdy noty są przesyłane pomiędzy modułami zaufanych agentów po wstępnym wystawieniu noty 8 przez odpowiedniego sprzedawcę lub instytucję. Pole identyfikatora ID odbiorcy 28 zawiera numer identyfikacyjny modułu zaufanego agenta odbiorcy. Pole ID nadawcy 30 zawiera numer identyfikacyjny modułu zaufanego agenta nadawcy. Pole certyfikatu nadawcy 32 zawiera certyfikat modułu zaufanego agenta nadawcy. Pole data/czas 34 zawiera datę i czas przesłania noty 8. W czasie wykonywania kolejnych przesłań odpowiednie ID nadawcy i odbiorcy, certyfikaty nadawcy, oraz wartości daty i czasu są dołączane do każdego pola, w wyniku czego tworzy się lista określająca historię transferu. Można zauważyć, że ID modułu zaufanego klienta w polu odbiorcy sekcji identyfikacyjnej powinno mieć taką samą wartość jak pierwszy ID w polu ID nadawcy.

Ponadto, gdy tylko nota 8 jest przesyłana pomiędzy modułami zaufanego agenta, nadawca cyfrowo podpisuje notę w pięciu poprzednich sekcjach noty, przy wykorzystaniu klucza prywatnego należącego do modułu zaufanego klienta nadawcy. Sekcja podpisów nadawcy 20 jest następnie zaktualizowana poprzez dodanie nowo utworzonego podpisu cyfrowego, w wyniku czego tworzy się lista podpisów nadawcy.

Obecnie objaśnione zostaną urządzenia do realizacji transakcji. Nawiązując do fig.4, moduł zaufanego klienta 120 jest wbudowany w urządzenie do realizacji transakcji 122. Urządzenie 122 składa się z trzech głównych komponentów, tak dla sprzedawcy, jak i dla klienta. Są to główny procesor 124, moduł zaufanego agenta 120 i moduł pieniężny 6. Te komponenty są połączone na przykład szyną 126. Gdy modułem zaufanego agenta 120 jest moduł MTA 2, urządzenie 122 jest określane jako urządzenie sprzedawcy do realizacji transakcji MTD. Gdy modułem zaufanego agenta 120 jest moduł CTA 4, urządzenie 122 jest określane jako urządzenie klienta do realizacji transakcji CTD.

Na fig.4 pokazano funkcjonalne komponenty głównego procesora 124. Główny procesor zapewnia następujące funkcje: komunikacyjne 128, obsługi transakcji 130, interfejsu człowiek-urządzenie 132, obsługi daty i czasu 136, oraz zarządzania komunikatami 134.

Funkcje komunikacyjne 128 zapewniają komunikację pomiędzy urządzeniem do realizacji transakcji 122 i światem zewnętrznym. Komunikacja może odbywać się w sposób przewodowy lub bezprzewodowy, przez szerokie lub wąskie pasmo, tak by była zapewniona zgodność między urządzeniami. Funkcje komunikacyjne 128 ustalają połączenie pomiędzy urządzeniami do realizacji transakcji 122, albo zapewniają podłączenie urządzenia do realizacji transakcji do sieci, co zapewnia pośrednie połączenie z innym urządzeniem do realizacji transakcji lub zaufanym serwerem.

180 151

Aplikacja do obsługi transakcji 130 może wykonywać różne zadania, na przykład aplikacja do obsługi transakcji może opłacać faktury pobrane przy wcześniejszych transakcjach. Generalnie, urządzenie do realizacji transakcji 122 zapewnia wszelkie procesy do obsługi wyboru, kupna i zastosowania elektronicznych reprezentacji obiektów, elektronicznej reprezentacji pieniędzy, wierzytelności, oraz innych not 8, oraz ponadto analogiczne procesy dla sprzedaży.

Interfejs człowiek-urządzenie 132 zapewnia wygodną obsługę urządzenia do realizacji transakcji 122. Może on wykorzystywać klawiaturę, mysz, pióro, głos, ekran dotykowy, ikony, układy menu, i tym podobne. Interfejs człowiek-urządzenie 132 zapewnia komunikację z różnymi funkcjami modułu zaufanego agenta 120 i modułu pieniężnego 6, przy wykorzystaniu zarządcy komunikatów 134 (Message Manager). W pewnych zastosowaniach, interfejs człowiek-urządzenie 132 może nie być konieczny, na przykład we w pełni zautomatyzowanym urządzeniu do obsługi transakcji, znajdującym się u klienta lub sprzedawcy.

Dane daty i czasu 136 są ustawiane przez właściciela urządzenia do realizacji transakcji 122 i w ich skład wchodzą data, czas i strefa czasowa. Dane daty i czasu są dostarczane do wbudowanego modułu zaufanego agenta 120, gdy tylko moduł zaufanego agenta rozpoczyna pracę.

Zarządca komunikatów 134 odpowiednio skierowuje między systemowe komunikaty, na przykład komunikaty pomiędzy urządzeniami do realizacji transakcji, oraz komunikaty pomiędzy głównym procesorem 124, modułem zaufanego agenta 120 i modułem pieniężnym 6.

Na fig. 5A przedstawiono funkcjonalne komponenty modułu zaufanego agenta 120. Rozważany system do otwartej elektronicznej wymiany handlowej wykorzystuje trzy typy modułów zaufanego agenta 120, które różnią się pewnymi specyficznymi funkcjami transakcyjnymi. Na fig. 5B pokazano funkcje transakcyjne w module CTA 2. Na fig. 5C pokazano funkcje transakcyjne w module MTA 4. Na fig. 5D pokazano funkcje transakcyjne w module zaufanego agenta instytucji ATA, który z kolei jest wbudowany w urządzenie do realizacji transakcji odpowiedniej instytucji ATD. Urządzenia ATD są związane z instytucjami uwierzytelniającymi, takimi jak bank.

Interfejs zewnętrzny 138 zapewnia fizyczną komunikację z głównym procesorem 124 i modułem pieniężnym 6 urządzenia do realizacji transakcji 122, w które wbudowany jest moduł zaufanego agenta 120. Interfejs komunikatów 130 przetwarza i odpowiednio kieruje komunikaty między modułowe i wewnątrzmodułowe. Zarządca sesji 142 (Session Manager) ustanawia i przerywa międzymodułowe sesje i sesje modułu z zaufanym serwerem. Zarządca zespołu zabezpieczeń 144 (Security Manager) obsługuje informacje bezpieczeństwa (na przykład, certyfikat modułu zaufanego agenta i listę modułów niezaufanego klienta) i ustanawia bezpieczną komunikację ze współpracującym modułem zaufanego agenta (przez główny procesor 124) i z lokalnym modułem pieniężnym 6 w tym samym urządzeniu do realizacji transakcji 122. Funkcje transakcyjne 146 dostarczają protokoły do realizacji transakcji. Funkcje transakcyjne dla klienta, sprzedawcy i odpowiedniej instytucji nadrzędnej są stosowane odpowiednio dla modułów CTA, MTA i ATA.

Na fig. 5B pokazano funkcje transakcyjne klienta. Funkcja kupna (Purchase) 158 wymienia płatności na noty 8 i elektroniczne reprezentacje obiektów. Funkcja komunikacji z głównym procesorem (To Host) 160 zapewnia interfejs do głównego procesora 124 urządzenia transakcyjnego. Funkcja wystawiania noty (Present Ticket) 164 przedstawia noty 8 do uzyskania odpowiednich informacji' lub usług. Funkcja nabywania wierzytelności (Acąuire Credential) 166 działa w celu uzyskania noty uwierzytelniającej. Funkcja rejestru transakcji (Tran Log) 162 obsługuje rejestr transakcji modułu zaufanego agenta. Zarówno moduł CTA 2, jak i moduł MTA 4 utrzymują rejestr transakcji, który przechowuje następujące informacje: typ transakcji (na przykład, typ noty), obraz noty przed transakcją, obraz noty po transakcji, informacja o sporze zawierająca datę sporu (odpowiednią dla każdego modułu zaufanego agenta w czasie sporu), status oraz postanowienie sprzedawcy (na przykład, zastąpienie, refundację, odrzucenie), informacja o ponownej certyfikacji (na przykład

180 151 data ponownej certyfikacji). Funkcja rozpoczęcia sporu (Initiate Dispute) wystawia elektroniczną reprezentację towaru, jeśli klient jest niezadowolony.

Na fig. 5C pokazano funkcje transakcyjne sprzedawcy. Funkcja kupna 170 wymienia notę 8 i elektroniczne obiekty za płatność. Funkcja łączności z głównym procesorem 172 zapewnia interfejs do głównego procesora 124 urządzenia transakcyjnego. Funkcja odbioru noty przetwarza odebraną notę 8, w celu dostarczenia odpowiedniej usługi lub informacji. Funkcja nabywania wierzytelności 177 odbiera uwierzytelnienie klienta. Funkcja rejestru transakcji 174 utrzymuje zapis transakcji modułu zaufanego agenta. Funkcja rozstrzygania sporu 178 (Resolve Dispute) odbiera noty 8 i elektroniczne obiekty, w celu rozstrzygnięcia zastrzeżeń klienta.

Na fig. 5D pokazano funkcje transakcyjne instytucji. Funkcja wystawiania wierzytelności 180 (Create Credential) konstruuje i dostarcza noty uwierzytelniające do jednostki żądającej. Funkcja łączności z głównym procesorem 182 zapewnia interfejs do głównego procesora 124 urządzenia transakcyjnego. Funkcja odbioru noty przetwarza odebraną notę 8, w celu zapewnienia odpowiedniej usługi lub informacji. Funkcja potwierdzenia wierzytelności 186 (Revalidate Credential) akceptuje bieżącą wierzytelność i ponownie wystawia wierzytelność z nową datą wygaśnięcia. Funkcja rejestru transakcji 183 utrzymuje zapis trans^ccji. Funkcja nabywania wierzytelności 185 otrzymuje uwierzytelnienie instytucji.

Nawiązując ponownie do fig.5A, funkcja łączności z modułem pieniężnym komunikuje się z modułem pieniężnym 6 w tym samym urządzeniu do realizacji transakcji 122 w celu dostarczenia płatności. Funkcja kryptograficzna 152 (Cryptography) dostarcza klucz publiczny i funkcje kryptograficzne z kluczem symetrycznym. Mogą być zastosowane dowolne znane techniki kryptograficzne z kluczem publicznym i symetrycznym, na przykład RSA i DES. Funkcja posiadacza noty 148 (Ticket Holder) tworzy noty 8 w module MTA 4 lub przechowuje i wyszukuje noty 8 w module CTA 2. Funkcja generatora liczb losowych 156 (Random Number Generator) generuje losowe liczby, w celu utworzenia kluczy kryptograficznych. Funkcja daty i czasu 154 (Date/Time) zarządza danymi daty i czasu dostarczanymi z głównego procesora 124, w celu datowania noty 8, oraz walidacji certyfikatu i wystawionych not. Informacja o bieżącym stanie zegara jest wprowadzana do modułu zaufanego agenta za każdym razem, gdy moduł zaufanego agenta jest otwierany (to znaczy, rejestrowany jako gotowy do użytku), oraz jest podtrzymywana aż do zamknięcia modułu zaufanego agenta.

Sprzęt komputerowy modułu zaufanego agenta i modułu pieniężnego składa się korzystnie z następujących elementów: mikrokontrolera (na przykład z rodziny Intel 196) do realizacji protokołów transakcji, pamięci ulotnej dużej prędkości (na przykład pamięci SRAM) do przechowywania systemu operacyjnego, części aplikacji, informacji kryptograficznych, i tym podobnych, w czasie ich pracy, pamięci nieulotnej (na przykład pamięć błyskowa) do przechowywania systemu operacyjnego aplikacji, not, elektronicznych pieniędzy, zapisów historii, i tym podobnych, zegarowego układu scalonego do dostarczania czasu odniesienia, baterii dla zegara, diody szumiącej, lub innego losowego źródła dla generatora liczb losowych.

Ogólna struktura systemu objaśniona zostanie w oparciu o fig. 6, na której przedstawiono ogólną architekturę sieci rozważanego systemu dla płatności handlowych. Urządzenie do realizacji transakcji klienta CTD 188 może komunikować się z systemem kont płatniczych klienta 189 (accounts payable system) przez sieć klienta 191. System kont płatniczych klienta tworzy zlecenie przelewu zawierające listę faktur do zapłacenia i wysyła tę informację do CTD 188.

Gdy urządzenie CTD 188 otrzyma zlecenie przelewu, sprawdza, czy moduł pieniężny 6 posiada wystarczającą ilość kapitału dla obsługi płatności, albo otrzymuje elektroniczną reprezentację pieniędzy z innego urządzenia do realizacji transakcji lub konta bankowego klienta. W przypadku opłaty przy wykorzystaniu kredytu, urządzenie CTD 188 musi mieć możliwość kredytowania na bieżąco, lub musi pobrać ten kredyt z banku.

Gdy urządzenie CTD 188 posiada zarówno zlecenie przelewu, jak i elektroniczne pieniądze, może połączyć się z siecią sprzedawcy 134 przez sieć przejściową 190. Sieć klienta

180 151 zapewnia komunikację z urządzeniem do realizacji transakcji sprzedawcy MTD 198 i z systemem kont odbiorczych sprzedawcy 193. System kont odbiorczych 193 jest używany do dopasowania nie uregulowanych faktur i odebranego zlecenia. System płatności handlowych według wynalazku umożliwia następnie klientowi wykonanie bezpiecznej płatności z modułu pieniężnego do sprzedawcy, oraz w odpowiedzi zapewnia odebranie noty płatności handlowej posiadającej podpisy z urządzenia MTD pod danymi zlecenia.

Schematy blokowe pokazane na figurach używają symboli A i B do oznaczenia dwóch współpracujących modułów zaufanego agenta. Te same oznaczenia A i B mogąbyć również zastosowane do głównego procesora 124 lub modułu pieniężnego 6 związanych z konkretnym modułem zaufanego agenta 120, to znaczy w tym samym urządzeniu do realizacji transakcji 122. Schematy blokowe ukazują główne komponenty funkcjonalne odpowiedzialne za wykonywanie danego zadania. Na przykład, termin zarządca zabezpieczeń A oznacza, że rozważane zadanie jest wykonywane przez funkcję zarządcy zabezpieczeń 144 (patrz fig. 5A) w module zaufanego agenta A.

W schematach blokowych mogą również występować procedury, z których niektóre mogą wykorzystywać oznaczenia parametrów X i Y. Na przykład, termin utwórz sesję A —> B jest wywołaniem procedury utworzenia sesji. Następujący dalej schemat blokowy procedury utworzenia sesji w całym swym przebiegu przyjmuje, że X=A, a Y=B.

Obecnie nastąpi objaśnienie zatwierdzenia i przerwania transakcji (Abort and Commit). Przy przetwarzaniu transakcji rozważanego typu pożądane jest przesyłanie elektronicznych pozycji, takich jak noty 8 i elektroniczne rachunki, pomiędzy dwiema jednostkami, przy zapewnieniu sumy zerowej (zero-sum gamę). Innymi słowy, duplikowanie elektronicznych pozycji jest niepożądane, ponieważ przy zakończeniu transakcji występuje podwójna ilość pozycji w porównaniu ze stanem sprzed transakcji. Podobnie, niepożądana jest utrata pozycji elektronicznych, tak że byłoby mniej pozycji po transakcji niż przed nią. Na przykład, jeśli na starcie transakcji A posiada elektroniczną notę 8 i chce przesłać ją do B, pożądane jest, by przy zakończeniu transakcji B posiadał tę elektroniczną notę 8, a A jej nie posiadał. Jednakże w świecie rzeczywistym w praktyce mogą zaistnieć dwie inne sytuacje, a mianowicie A i B mogą posiadać tę samą elektroniczną notę 8 (duplikacja), albo ani A ani B nie posiada elektronicznej noty 8 (utrata).

W celu minimalizacji prawdopodobieństwa duplikacji lub utraty, protokół transakcji musi wziąć pod uwagę możliwość, że w wyniku zdarzeń wynikających z naturalnego funkcjonowania systemu lub specjalnie wywołanych może nastąpić przerwanie typowego przebiegu transakcji. Typowe przerwanie polega na zerwaniu połączenia komunikacyjnego pomiędzy Ai 8 w czasie transakcji. W celu minimalizacji prawdopodobieństwa duplikacji lub utraty w przypadku takiego losowego zdarzenia należy jak najbardziej zmniejszyć zakres możliwości wystąpienia utraty lub duplikacji. W celu minimalizacji występowania umyślnych przerwań (tzw. jawny atak - overt attack) pożądane jest wyeliminowanie ekonomicznego bodźca dla takiego działania. Na przykład, gdyby przerywający mógł jedynie stracić noty lub pieniądze w wyniku usiłowania wywołania takiego przerwania, przesłanki ekonomiczne odradzałyby mu takie postępowanie.

Powyższe rozważania znajdują odbicie w wydajnych protokołach transakcji opisywanego systemu. W szczególności, pożądane jest zapewnienie zgodnych stanów porzucenia i zatwierdzenia pomiędzy dwoma dokonującymi transakcji modułami zaufanego agenta 120, lub modułami pieniężnymi 6. Na przykład, jeśli A zatwierdza transakcję, wówczas B również ją zatwierdza; z kolej jeśli A porzuca transakcję, to porzuca ją również B. W celu zapewnienia zgodności i minimalizacji prawdopodobieństwa duplikacji lub utraty, w przypadku wystąpienia niezgodności, protokoły transakcji biorą pod uwagę uporządkowanie i zależności czasowe dla A i B zatwierdzających daną transakcję.

Na fig. 7 pokazano dwie procedury, przerwania (abort) i zatwierdzenia (commit). Procedura przerwania jest wykonywana wewnątrz danego modułu zaufanego agenta 120, gdy transakcja, w którą jest zaangażowany nie udaje się. Procedura przerwania przywraca moduł zaufanego agenta 120 do stanu dokładnie takiego, jaki był przed rozpoczęciem przerwanej transakcji. Ponadto, jeśli moduł zaufanego agenta sprzedawcy przerywa transakcję po

180 151 autoryzacji, wówczas autoryzacja zostanie cofnięta. Analogicznie, transakcja przerwania jest wykonywana wewnętrznie w danym module zaufanego agenta 120, gdy transakcja w którą był zaangażowany ulega prawidłowemu zakończeniu. Moduł zaufanego agenta 120 zapisuje wówczas zakończoną transakcję w rejestrze transakcji i jest gotowy do obsługi nowej transakcji. Na przykład, w czasie transakcji przesłania noty, elektroniczna nota 8 jest przesyłana z modułu zaufanego agenta A do modułu zaufanego agenta B. Ponieważ w tym konkretnym momencie ani A ani B nie zaakceptowały ani nie porzuciły transakcji, A tymczasowo zatrzymuje notę 8, podczas gdy B również tymczasowo posiada tę notę 8. Jeśli zarówno A i B dokonają akceptacji, wówczas A kasuje notę 8, a posiadanie noty 8 przez B staje się trwałe. W przypadku, gdy A i B przerwą transakcję, A zatrzyma swą notę 8, a nota 8 przechowywana tymczasowo przez B zostanie skasowana w wyniku cofnięcia dotychczasowych rezultatów transakcji. Należy zauważyć, że operacja kasowania może być zaimplementowana na różne znane sposoby. Jak wspomniano powyżej, pożądana jest minimalizacja możliwości wystąpienia sytuacji, w której jeden z modułów zaufanego agenta 120 zatwierdzi transakcję, podczas gdy drugi moduł zaufanego agenta 120 ją przerwie, ponieważ może to prowadzić w pewnych określonych warunkach do wystąpienia duplikacji lub utraty pewnych elektronicznych pozycji.

Te same uwagi tyczą się modułów pieniężnych 6 wymieniających elektroniczne rachunki. W czasie transakcji kupna, elektroniczne rachunki są przesyłane z modułu pieniężnego A do modułu pieniężnego B, tak że A tymczasowo zmniejsza stan o przesyłaną wartość elektronicznych rachunków, podczas gdy B tymczasowo zwiększa swój stan o wartość odebranych elektronicznych rachunków. Jeśli A i B dokonają akceptacji, wówczas A zatrzyma rachunki w zmniejszonej odpowiednio sumie, a zwiększenie stanu B o wartość odebranych rachunków będzie trwałe.

Na fig. 7A pokazano procedurę zatwierdzenia. Funkcja rejestru transakcji X modyfikuje rejestr transakcji. Funkcja łączności z głównym procesorem X powiadamia główny procesor, że transakcja jest ukończona. Zarządca sesji X odnotowuje zakończenie sesji. (Kroki 230 - 234).

Na fig. 7B pokazano procedurę przerwania. Zarządca sesji X cofa zmiany i stwierdza, że moduł agenta dokonał przerwania transakcji. Zarządca sesji śledzi przebieg wszystkiego, co zostało wykonane od rozpoczęcia sesji i w przypadku anulowania transakcji cofa wszystkie zmiany. Funkcja łączności z głównym procesorem X wysyła komunikat do głównego komputera, że transakcja została przerwana. (Kroki 236 - 238).

Procedura przerwania może być wołana bezpośrednio w którymś z kroków przebiegu transakcji, na przykład gdy moduł zaufanego agenta 120 stwierdzi, że certyfikat nie jest ważny. Procedura przerwania może być również wywołana, gdy nie wystąpi spodziewana akcja. W szczególności, gdy dwa moduły zaufanego agenta 120 komunikują się ze sobą będą monitorować protokół przekroczenia czasu (time-out protocol). Na przykład, po wysłaniu przez pierwszy moduł zaufanego agenta 120 komunikatu do drugiego modułu zaufanego agenta 120, zarządca sesji pierwszego modułu zaufanego agenta (A) ustawi zegar na odpowiednią długość czasu, jaką może oczekiwać na odpowiedź. Zarządca sesji może również numerować wysłane komunikaty. Ten numer pojawiłby się w komunikacie z odpowiedzią którą przesyła zarządca sesji drugiego modułu zaufanego agenta (B).

Jeśli czas przydzielony zegarowi upłynie przed nadejściem komunikatu, zarządca sesji B stwierdza, czy transakcja wciąż biegnie w B. Jeśli B nie odpowie, zarządca sesji A porzuci transakcję. Jeśli zostanie odebrana odpowiedź, że transakcja jest w toku, wówczas zegar zostanie ponownie zainicjowany na nowy czas oczekiwania. Jeśli A zapyta B zadaną ilość razy bez otrzymania odpowiedzi na pierwotny komunikat, wówczas A porzuci transakcję. Podobna funkcja przekraczania przydzielonego czasu (time-out function) istnieje w modułach pieniężnych 6.

Obecnie opisane zostanie przeprowadzanie płatności handlowych przy pomocy modułów pieniężnych. Na fig. 8 przedstawiono schemat blokowy płatności handlowych dokonywanych przy pomocy modułów pieniężnych (commercial money module payment). Na początku, zlecenie przelewu z systemu kont płatniczych 189 jest wysyłane do głównej

180 151 aplikacji A sterującej transakcją HTA. Chociaż system kont płatniczych jest z korzyścią systemem zautomatyzowanym, opis niniejszego wynalazku odnosi się do ręcznie obsługiwanego systemu (na przykład gdzie dane przelewu są wstukiwane do aplikacji HTA). Następnie aplikacja HTA łączy się z główną aplikacją B sterującą transakcją HTB, z korzyścią przez sieć klienta 191, sieć przejściową 190, oraz sieć sprzedawcy 134 (krok 700), oraz klient podejmuje decyzję o wykonaniu płatności handlowej. Aplikacja HTA wysyła komunikat do związanego z nią modułu zaufanego agenta A w celu zapłaty płatności handlowej, a aplikacja HTB wysyła komunikat do swego modułu zaufanego agenta B w celu przyjęcia płatności handlowej.

Moduły zaufanego agenta klienta i sprzedawcy (A i B) następnie ustanawiają sesję, w znany sposób. W szczególności, procedura utworzenia sesji jest wywoływana w kroku 706 w celu ustanowienia kryptograficznie zabezpieczonego kanału komunikacyjnego pomiędzy modułem zaufanego agenta A i modułem zaufanego agenta B. Nawiązując do fig. 9, zarządca sesji modułu zaufanego agenta A wysyła żądanie i otrzymuje certyfikat A, który przyznaje zarządca zabezpieczeń (kroki 2962-98). Zarządca sesji A modułu zaufanego agenta wysyła certyfikat A, którego odbiorcą jest zarządca sesji modułu zaufanego agenta B, po czym otrzymuje go zarządca zabezpieczeń (kroki 300304).

Funkcja klucza publicznego (Public Key) modułu zaufanego agenta B sprawdza w znany sposób certyfikat A przy użyciu protokołów walidacji (kroki 306 - 308).

Jeśli certyfikat A nie jest ważny, zarządca sesji B stwierdza, że sesja jest kończona i powiadamia zarządcę sesji A, że transakcja jest odrzucona. Zarządca sesji A również stwierdza, że sesja jest kończona. (Kroki 310-312).

Jeśli A nie znajduje się na liście niezaufanych jednostek, generator liczb losowych B tworzy losową liczbę R(B), oraz komunikat weryfikacji B (krok 318). Losowa liczba R(B) może być użyta do utworzenia klucza sesyjnego. Komunikat weryfikacji B jest losową liczbą stosowaną przez B do ochrony przed powtarzaniem komunikatu. Następnie, zarządca sesji B zestawia R(B), komunikat weryfikacji B i certyfikat A (cert(TA)) w komunikat dla modułu zaufanego agenta A (krok 320). Klucz publiczny B koduje komunikat przy użyciu klucza publicznego modułu zaufanego agenta A (TA(PK)), który moduł zaufanego agenta B otrzymał z A od cert(TA) (krok 322). Zarządca sesji B wysyła zakodowany komunikat do zarządcy sesji A (kroki 324-326).

Funkcja klucza publicznego A dekoduje komunikat przy użyciu swego klucza prywatnego (odpowiadającego temu kluczowi publicznemu) i sprawdza ważność cert(TA) (kroki 328-330). Jeśli cert(TA) jest nieważny, wówczas zarządca sesji A uznaje sesję za zakończoną i wysyła komunikat o odmowie realizacji transakcji do B, którego zarządca sesji również odnotowuje sesję jako zakończoną (kroki 332-334). Jeśli cert(TA) jest ważny, wówczas zarządca zabezpieczeń A sprawdza, czy moduł zaufanego agenta B jest na liście niezaufanych jednostek (kroki 336-338). Jeśli moduł zaufanego agenta B jest na tej liście, sesja jest kończona (kroki 332-334).

Jeśli B nie znajduje się na liście niezaufanych jednostek, generator liczb losowych A generuje losową liczbę R(A) i komunikat weryfikacji A (na przykład, inną losową liczbę) (krok 340). Funkcja obsługi daty i czasu przesyła bieżącą datę i czas do zarządcy zabezpieczeń (krok 342). Następuje wymiana danych daty i czasu pomiędzy A i B w celu ich ewentualnego zapisania w ich rejestrach transakcji w momencie akceptacji. Następnie zarządca zespołu zabezpieczeń A tworzy i przechowuje klucz sesyjny (TA/TA) powstały w wyniku zastosowania funkcji logicznej XOR na losowych liczbach R(A) i R(B) (krok 344). Klucz sesyjny (TA/TA) jest używany do kodowania komunikacji pomiędzy dwoma modułami zaufanego agenta 120. Zarządca sesji A zestawia komunikat zawierający komunikaty weryfikacji A i B, dane daty i czasu, oraz R(A) (krok 344). Funkcja klucza publicznego A koduje ten komunikat przy użyciu klucza publicznego modułu zaufanego agenta B (otrzymanego przez A w cert(TA)) i wysyła zakodowany komunikat do zarządcy sesji modułu zaufanego agenta B (kroki 346-350).

Funkcja klucza publicznego B dekoduje otrzymany komunikat przy użyciu tajnego klucza (odpowiadającego jego kluczowi publicznemu) (krok 352). Zarządca sesji B spraw

180 151 dza, czy komunikat weryfikacji B otrzymany z A jest taki sam, jak komunikat weryfikacji B poprzednio wysłany do A (kroki 354-356). Jeśli nie jest on taki sam, wówczas sesja jest kończona (kroki 310-312). Jeśli natomiast jest on taki sam, wówczas zarządca sesji B odnotowuje początek sesji (krok 358).

Zarządca sesji B tworzy klucz sesyjny (TA/TA) poprzez zastosowanie operacji R(A) XOR R(B) i następnie przechowuje ten klucz sesyjny (krok 360). W tym momencie, A i B utworzyły i zapisały ten sam klucz sesyjny (to znaczy klucz sesyjny (TA/TA)), który jest używany przy wzajemnej komunikacji. Następnie, funkcja daty i czasu B wysyła swe bieżące dane daty i czasu do zarządcy zabezpieczeń B (krok 362). Zarządca zabezpieczeń B zestawia komunikat, który zawiera potwierdzenie dla A, komunikat weryfikacji A, oraz dane daty i czasu B (krok 364). Następnie, w kroku 366, jest wywoływana procedura wysłania komunikatu (send message), w celu przesłania komunikatu z A do B.

Nawiązując do fig. 10, funkcja klucza symetrycznego (symmetric key) modułu zaufanego agenta B koduje komunikat przy użyciu klucza sesyjnego (TA/TA) (krok 376). Następnie, funkcja interfejsu komunikatów (message interface) B formatuje komunikat i wysyła go do zarządcy komunikatów głównego procesora (krok 378). Zarządca komunikatów głównego procesora B przesyła je przy użyciu funkcji komunikacyjnych (Communications) do zarządcy komunikatów głównego procesora A w głównym procesorze modułu zaufanego agenta A (krok 380). Zarządca komunikatów głównego procesora A wysyła następnie komunikat do interfejsu komunikatów modułu zaufanego agenta A, który wydobywa zawartość z komunikatu (kroki 382-384). Funkcja klucza symetrycznego A dekoduje komunikat przy użyciu klucza sesyjnego (TA/TA), co kończy zabezpieczoną wymianę komunikatów pomiędzy modułami zaufanego agenta przy wykorzystaniu klucza sesyjnego (TA/TA) (krok 386).

Nawiązując ponownie do fig. 9, zarządca zabezpieczeń A odbiera potwierdzenie, komunikat weryfikacji A, oraz dane daty i czasu B (krok 368). Zarządca zabezpieczeń A sprawdza czy komunikat weryfikacji A jest taki sam, jak komunikat weryfikacji A poprzednio wysłany do B (kroki 370-372). Jeśli nie są one takie same, zarządca sesji A kończy sesję (kroki 332-334). W przeciwnym przypadku, zarządca sesji A odnotowuje początek sesji (krok 374).

Nawiązując ponownie do fig.8, po ustanowieniu sesji, moduł zaufanego agenta A żąda i sprawdza uwierzytelnienie sprzedawcy z modułu zaufanego agenta B, w znany sposób. Uszczegóławiając, nawiązując do fig. 11, wywoływana jest procedura sprawdzania wierzytelności (check credential) (krok 708). Wszystkie urządzenia sprzedawcy do realizacji transakcji MTD 198 posiadają uwierzytelnienie identyfikujące właściciela/sprzedawcę (na przykład ΝΥΝΕΧ, Ticketron i tym podobne). Takie uwierzytelnienie sprzedawcy może być na przykład wystawione przez organ identyfikujący sprzedawcę, kontrolowany przez zaufany organ. Jednocześnie, uwierzytelnienie klienta posiadane przez urządzenie klienta CTD 198 może obejmować numery prawa jazdy lub kart kredytowych w przypadku osób fizycznych lub uwierzytelnienie handlowe w przypadku osób prawnych, takie jak pole danych umieszczone w urządzeniu sprzedawcy MTD 198 zapełnione danymi z różnych organów identyfikujących. Nawiązując do fig. 11, funkcja zakupu A wysyła komunikat do funkcji zakupu B modułu zaufanego agenta B, żądając jego uwierzytelnienia handlowego (kroki 444-448). Funkcja posiadacza noty odczytuje swe uwierzytelnienie handlowe i wysyła je do A w celu walidacji (kroki 450-456).

Uwierzytelnienia lub inne typy not 8 są, poddawane walidacji w następujący sposób: sprawdzenie certyfikatu wystawcy i sprawdzenie podpisu wystawcy; sprawdzenie każdego transferu - dopasowanie identyfikatorów odbiorcy i nadawcy (to znaczy S_o = wystawca, Ro = pierwszy odbiorca, wówczas Rj = Sj+i dla i > 0); sprawdzenie certyfikatu i podpisu każdego nadawcy; sprawdzenie czy identyfikator ostatniego odbiorcy odpowiada identyfikatorowi (TA(id)) certyfikatu (cert(TA)) modułu zaufanego agenta w bieżącej sesji.

Jeśli uwierzytelnienie sprzedawcy nie jest ważne, wówczas transakcja jest przerwana poprzez wywołanie procedury przerwania transakcji (krok 458). Nawiązując do fig.12, moduł zaufanego agenta A wykonuje porzucenie (krok 388), a jego zarządca sesji wysyła ko

180 151 munikat do zarządcy sesji modułu zaufanego agenta B, informujący B, że A wykonał porzucenie (kroki 390-394). Następnie moduł zaufanego agenta wykonuje porzucenie (krok 396). Nawiązując ponownie do fig. 11, jeśli uwierzytelnienie sprzedawcy jest ważne, wówczas funkcja łączności z głównym procesorem a wysyła dane uwierzytelnienia do głównej aplikacji transferowej w celu zatwierdzenia, to znaczy potwierdzenia przez główny procesor danych identyfikacyjnych sprzedawcy w zleceniu przelewu (kroki 460-462).

Nawiązując ponownie do fig.8, kontynuowany jest przebieg płatności handlowej wykonywanej przez moduł pieniężny. Funkcja zakupu A wysyła komunikat do modułu zaufanego agenta B z zapytaniem, czy B wymaga uwierzytelnienia A (kroki 710-712). Następnie funkcja łączności z głównym procesorem B wysyła do aplikacji HTB komunikat z zapytaniem, czy wymagane jest uwierzytelnienie A (kroki 714-716). Jeśli uwierzytelnienie klienta jest wymagane do identyfikacji płatnika, wówczas wykonywana jest procedura sprawdzenia wierzytelności, po czym funkcja zakupu B wysyła komunikat do A, w celu rozpoczęcia wykonywania płatności (kroki 718-724). Jeśli nie jest wymagane żadne uwierzytelnienie, wówczas funkcja zakupu B wysyła komunikat, że uwierzytelnienie A nie jest wymagane (722-724). Komunikat modułu zaufanego agenta B jest odbierany przez funkcję zakupu A (krok 726), po czym funkcja łączności z głównym procesorem A żąda zlecenia przelewu z aplikacji HTA (krok 728). Następnie aplikacja HTA wysyła zlecenie przelewu do modułu zaufanego agenta A (krok 730), które jest przyjmowane przez funkcję łączności z głównym procesorem A i wysyłane do modułu zaufanego agenta B (kroki 732-734).

Funkcja zakupu B odbiera zlecenie przelewu i weryfikuje całkowitą sumę zlecenia przelewu, ze względu na sumę faktur pokrywaną tym zleceniem przelewu (krok 736). Jeśli ta całkowita suma jest nieprawidłowa, wówczas transakcja jest porzucana (kroki 738-740). W przeciwnym przypadku, funkcja klucza publicznego B cyfrowo podpisuje zlecenie przelewu i przesyła podpis do funkcji odbiorcy noty B (krok 742). Funkcja odbiorcy noty B tworzy notę płatności handlowej (krok 744) i wysyła te notę do A (kroki 746-748).

Funkcja zakupu A odbiera i weryfikuje notę (krok 750). Jeśli zostanie ona uznana za nieważną, wówczas transakcja jest porzucana (kroki 752-754). W przeciwnym przypadku, funkcja zakupu A wysyła tę notę do funkcji odbiorcy noty A i wysyła podpis pod zleceniem przelewu do weryfikacji (krok 756).

Funkcja klucza publicznego A weryfikuje cyfrowy podpis przy wykorzystaniu klucza publicznego sprzedawcy, który otrzymała wraz z uwierzytelnieniem sprzedawcy (krok 758). Jeśli podpis jest niepoprawny, wówczas transakcja jest przerwana (kroki 760, 754). Jeśli podpis jest poprawny, wykonywana jest płatność modułu pieniężnego (kroki 760-762).

Moduł zaufanego agenta A wykonuje następnie płatność modułu pieniężnego do modułu zaufanego agenta B, w znany sposób. Uszczegóławiając, wywoływana jest procedura płatności modułu pieniężnego (krok 762). Nawiązując do fig.13, generator liczb losowych A generuje liczbę R(1) (krok 520). Następnie funkcja zakupu A wysyła komunikat do modułu zaufanego agenta B wskazujący, że będzie realizowana płatność modułu pieniężnego, oraz zawierający ponadto R(l) (kroki 522-524). Funkcja zakupu B odbiera ten komunikat i wysyła R(l) do zarządcy zabezpieczeń B (kroki 526-528). Generator liczb losowych B generuje losową liczbę 2 i wysyłają do modułu zaufanego agenta A (kroki 530-532). Każdy z zarządców zabezpieczeń A i B tworzy klucz sesyjny (ΤΑ/MM) poprzez wykonanie operacji XOR na R (1) i R (2) (kroki 534-536).

Nawiązując do fig.14, pokazano cztery kanały kodowania utworzone w czasie transakcji. Kanał kodowania 436 pomiędzy dwoma modułami zaufanego agenta 120 przenosi komunikaty zakodowane kluczem sesyjnym (TA/TA). Kanały 438 i 440 pomiędzy modułem zaufanego agenta 120 i jego modułem pieniężnym 6 współdzielą klucz sesyjny (TA/MM). Kanał 442 pomiędzy modułem pieniężnym 6 i innymi urządzeniami do realizacji transakcji 122 wykorzystuje klucz sesyjny (MM/MM).

Klucz sesyjny (TA/MM) jest stosowany do kodowania komunikatów wysyłanych pomiędzy modułem zaufanego agenta 120 i związanym z nim modułem pieniężnym 6 przez kanały kodowania 438 i 440. W tym momencie przebiegu algorytmu jedynie dwa moduły zaufanego agenta 120 posiadają klucze sesyjne (TA/MM). Oba moduły pieniężne 6 w dal

180 151 szej części przebiegu będą posiadać kopie klucza sesyjnego (ΤΑ/MM), tak by umożliwiać kodowaną komunikację pomiędzy modułami zaufanego agenta 120 i ich modułami pieniężnymi 6.

Należy zauważyć, że zamiast realizacji modułu zaufanego agenta 120 i modułu pieniężnego 6 jako oddzielnych, zabezpieczonych przed niepowołanym dostępem, komponentów, można je wytwarzać w jednym, zabezpieczonym przed niepowołanym dostępem, module. W tym przypadku, nie byłoby konieczne ustanawianie zabezpieczonej sesji dla komunikacji pomiędzy modułem zaufanego agenta 120 i modułem pieniężnym 6 w tym samym urządzeniu do realizacji transakcji 122. Jednakże, zastosowanie oddzielnych modułów pieniężnych 6 i modułów zaufanego agenta 120 przynosi korzyść z większej elastyczności ich zastosowań.

Nawiązując ponownie do fig. 13, funkcja modułu pieniężnego A wysyła komunikat zrealizuj płatność i R(l) do związanego z nią modułu pieniężnego A. Podobnie, funkcja modułu pieniężnego B wysyła komunikat odbierz płatność i R(2) do związanego z nią modułu pieniężnego B (kroki 538-544).

Na tym etapie, moduł pieniężny A (wewnątrz CTA 2) i moduł pieniężny B (wewnątrz MTA 4) ustanawiają między sobą sesję, tak że każdy moduł pieniężny 6 otrzymuje nowy klucz sesyjny (MM/MM). Przy ustanawianiu tej sesji pomiędzy modułami pieniężnymi, moduły pieniężne wymieniają komunikaty poprzez wcześniej istniejącą sesję modułów zaufanego agenta. Nawiązując do fig. 14, klucz sesyjny dla kanału kodowania 442 jest formowany w wyniku wymiany komunikatów zakodowanych przez kanał 436. Po ustanowieniu sesji modułów pieniężnych, komunikaty wysyłane pomiędzy modułami pieniężnymi będą zakodowane podwójnie, przez klucz sesyjny (MM/MM) i przez klucz sesyjny (TA/TA), wraz z częścią toru komunikacyjnego pomiędzy modułami zaufanego agenta 120.

W korzystnym przykładzie realizacji, sesja modułu pieniężnego jest ustanawiana w sposób podobny do ustanawiania sesji modułów zaufanego agenta. W tym przypadku, moduły pieniężne 6 będą zachowywać swe własne certyfikaty zawierające ich klucze publiczne. Wymiana certyfikatów i losowych liczb (do wykonania funkcji XOR) umożliwia bezpieczne tworzenie kluczy sesyjnych. Protokół ustanawiania sesji stosowany przez moduły pieniężne jest znany i jest pokazany na fig. 15. Funkcja utrzymywania zabezpieczenia wysyła certyfikat modułu do zarządcy sesji, po czym zarządca sesji A odbiera ten certyfikat i sprawdza, czy moduł pieniężny A jest podłączony do sieci (kroki 1464-1466). Jeśli moduł pieniężny A nie jest podłączony do sieci, wówczas zarządca sesji A wysyła certyfikat otrzymany z funkcji utrzymywania zabezpieczenia A do miejsca przeznaczenia B (krok 1476).

Alternatywnie, jeśli moduł pieniężny A jest podłączony do sieci, funkcja klucza symetrycznego A koduje certyfikat przy użyciu K, a zarządca sesji A wysyła zakodowany certyfikat do serwera sieci (kroki 1468-1472). Serwer sieci dekoduje certyfikat przy użyciu K i wysyła go do miejsca przeznaczenia B.

Nie biorąc pod uwagę, czy certyfikat został wysłany przez serwer sieci, czy przez zarządcę sesji A, zarządca sesji B odbiera certyfikat i funkcja utrzymywania zabezpieczenia B (jeśli B jest serwerem zabezpieczającym wówczas ta funkcja jest wykonywana przez zarządcę sesji) wykonuje walidację certyfikatu (kroki 1480-1482). Jeśli certyfikat nie jest ważny, wówczas zarządca sesji B odnotowuje, że sesja jest zakończona i informuje o tym albo subskrybenta, albo bank (kroki 1486-1492) (jeśli B jest serwerem zabezpieczającym, wówczas odnotowuje jedynie zakończenie transakcji).

Jeśli certyfikat jest ważny, wówczas funkcja utrzymywania zabezpieczenia B sprawdza, czy A znajduje się na liście złych numerów identyfikacyjnych (kroki 1494-1496). Jeśli A znajduje się na tej liście, wówczas sesja ulega zakończeniu. W przeciwnym przypadku, generator liczb losowych B tworzy losową liczbę R(B) i komunikat weryfikacji B. Funkcja zegara/programatora czasowego B odczytuje czas i datę (krok 1500). Funkcja utrzymywania zabezpieczenia B zestawia R(B), komunikat weryfikacji B i dane daty i czasy w komunikat (krok 1502). Funkcja klucza publicznego B koduje komunikat kluczem publicznym A,

180 151 a zarządca sesji B dołącza certyfikat B do zakodowanego komunikatu i wysyła ten komunikat do A (kroki 1504-1506).

Zarządca sesji A odbiera komunikat, funkcja klucza publicznego A dekoduje zakodowaną część komunikatu, a funkcja utrzymywania zabezpieczenia A wykonuje walidację certyfikatu B (kroki 1508-1514). Jeśli certyfikat nie jest ważny, wówczas zarządca sesji A odnotowuje zakończenie sesji i informuje o tym subskrybenta lub bank (kroki 1516-1522). Jeśli certyfikat jest ważny, wówczas funkcja utrzymywania zabezpieczenia A sprawdza, czy B nie znajduje się na liście złych numerów identyfikacyjnych (kroki 1524-1526). Jeśli B znajduje się na tej liście, wówczas sesja jest kończona. W przeciwnym przypadku, funkcja utrzymywania zabezpieczenia A odczytuje datę i czas, i porównuje z datą i czasem B. Jeśli data i czas są spoza zakresu, wówczas sesja jest kończona.

Jeśli data i czas mieszczą się w odpowiednim przedziale, generator liczb losowych generuje losową liczbę R(A) i komunikat weryfikacji A (krok 1532). Funkcja utrzymywania zabezpieczeń A tworzy następnie klucz sesyjny poprzez wykonanie operacji R(A) XOR R(B) (krok 1534). Komunikat weryfikacji A, komunikat weryfikacji B, czas, data i R(A) są zestawiane w jeden komunikat i kodowane przy pomocy klucza publicznego B (krok 1538). Zarządca sesji B odbiera komunikat, funkcja klucza publicznego B dekoduje komunikat, a zarządca zespołu zabezpieczeń B sprawdza komunikat weryfikacji B (kroki 1540-1546). Jeśli komunikat weryfikacji B jest niepoprawny, sesja jest kończona. W przeciwnym przypadku, zarządca zabezpieczeń B tworzy klucz sesyjny poprzez wykonanie operacji R(A) XOR R(B) (krok 1548). Dane daty i czasu są odczytywane i porównywane z danymi daty i czasu A w celu sprawdzenia, czy mieszczą się w odpowiednim zakresie. Jeśli dane daty i czasu są spoza zakresu, zarządca sesji B odnotowuje początek sesji (krok 1552).

Zarządca sesji B wysyła następnie potwierdzenie i komunikat weryfikacji A do A (kroki 1554-1556). Zarządca sesji A odbiera komunikat i funkcja utrzymywania zabezpieczeń A sprawdza komunikat weryfikacji A (kroki 1554-1556). Zarządca sesji A sprawdza komunikat weryfikacji A (kroki 1558-1562). Jeśli weryfikacja komunikatu jest niepoprawna, sesja jest kończona. Jeśli weryfikacja jest poprawna, zarządca sesji A odnotowuje początek sesji (krok 1564).

System zabezpieczeń związany z modułami pieniężnymi może być zintegrowany z systemem zabezpieczeń dla modułów zaufanego agenta 120, lecz z korzyścią jest on od niego oddzielony w celu zwiększenia bezpieczeństwa i elastyczności systemu.

Nawiązując ponownie do fig. 13, moduł pieniężny A wysyła R(l) do modułu pieniężnego (B). Ta funkcja może być zainicjowana przez aplikację utrzymywania zabezpieczeń MM A funkcjonującą w module pieniężnym A (krok 548). Ta aplikacja i inne aplikacje modułu pieniężnego zawierają określenie MM i są opisane w amerykańskim opisie patentowym nr 5 453 601 wraz z późniejszymi modyfikacjami.

Losowa liczba R(l) jest wysyłana z modułu pieniężnego A do modułu pieniężnego B przez procedurę wysyłania skierowanego komunikatu (krok 550). Nawiązując do fig. 16, funkcja klucza symetrycznego MM A koduje komunikat (wraz z R(l)) przy pomocy klucza sesyjnego (MM/MM) (krok 640). Zarządca sesji MM A wysyła komunikat do zarządcy komunikatów głównego procesora A (Host Message Manager), który z kolei wysyła komunikat do interfejsu komunikatów A modułu zaufanego agenta A (kroki 642-646). Moduł zaufanego agenta A wysyła komunikat do interfejsu komunikatów B modułu zaufanego agenta B przy wykorzystaniu procedury wysyłania komunikatu (krok 648), która koduje i dekoduje komunikat kluczem sesyjnym (TA/TA) pomiędzy dwoma modułami zaufanego agenta. Interfejs komunikatów B wysyła następnie komunikat do zarządcy sesji MM B w module pieniężnym B przez zarządcę komunikatów głównego procesora B (kroki 650-654). W końcu, klucz symetryczny MM B dekoduje komunikat kluczem sesyjnym (MM/MM).

Nawiązując ponownie do fig. 13, funkcja utrzymywania zabezpieczeń MM B (w module pieniężnym B) tworzy klucz sesyjny (ΤΑ/MM) poprzez wykonanie operacji XOR na R(l) i R(2). Następnie moduł pieniężny wysyła R(2) do modułu pieniężnego A, który również tworzy klucz sesyjny (ΤΑ/MM) poprzez wykonanie operacji XOR na R(l) i R(2) (kroki

180 151

552-556). Nawiązując do fig. 14, na tym etapie występują trzy klucze sesyjne: (MM/MM), (MM/ΤΑ) i (TA/TA). Tak więc cztery kanały kodowania są wówczas już ustanowione.

Nawiązując do fig. 13, aplikacja do komunikacji z subskrybentem MM A zapytuje moduł zaufanego agenta A o sumę płatności w zależności od typu rachunku (na przykład w dolarach, jenach, funtach, itd.) (krok 558). Moduł pieniężny będzie zasadniczo stosował aplikację komunikacji z subskrybentem do komunikacji z właścicielem/posiadaczem modułu pieniężnego. Jednakże, w opisywanym przypadku aplikacja komunikacji z subskrybentem komunikuje się z modułem zaufanego agenta 120 w celu otrzymania różnych instrukcji. W tym przypadku, moduł zaufanego agenta 120 dostarcza sumę płatności i informację o typie rachunku (moduł zaufanego agenta A połączył się wcześniej z właścicielem/posiadaczem CTD 2 w celu wyznaczenia sumy).

Zapytanie z modułu pieniężnego 6 do modułu zaufanego agenta 120 jest wysyłane przez procedurę wysłania komunikatu zakodowanego przez MM/ΤΑ (krok 560). Nawiązując do fig. 17, funkcja klucza symetrycznego MM A koduje komunikat kluczem sesyjnym (TA/MM) (krok 658). Zarządca sesji MM A wysyła komunikat do modułu interfejsu komunikatów zaufanego agenta A przez zarządcę komunikatów głównego procesora A (kroki 660-664). Funkcja klucza symetrycznego A dekoduje komunikat przy pomocy klucza sesyjnego (ΤΑ/MM) (krok 666). Nawiązując ponownie do fig. 13, funkcja zakupu A modułu zaufanego agenta A wysyła kwotę (cenę wybranej grupy towarów) zależnie od typu rachunku do aplikacji zapłaty/wymiany MM A modułu pieniężnego A (kroki 562-566). Ten komunikat jest przesyłany przez procedurę wysyłania komunikatu zakodowanego przez TA/MM (krok 564). Nawiązując do fig. 18, funkcja klucza symetrycznego A koduje komunikat przy pomocy klucza sesyjnego (TA/MM) (krok 668). Interfejs komunikatów A wysyła komunikat do zarządcy sesji MM A modułu pieniężnego A przez zarządcę komunikatów głównego procesora A (kroki 670-674). W końcu, funkcja klucza symetrycznego MM A dekoduje komunikat przy pomocy klucza sesyjnego (TAZMM) (krok 676).

Nawiązując do fig. 13, funkcja skorowidzu, rachunków MM A (Notę Directory) sprawdza, czy moduł pieniężny 6 posiada wystarczające fundusze do pokrycia płatności (kroki 568-570). W przypadku, gdy nie są one wystarczające, moduły pieniężne A i B porzucają transakcję (krok 572-582).

Protokół porzucenia transakcji MM (krok 582) może być taki, jaki jest preferowany przez znany elektroniczny system finansowy i pokazany na fig. 19. Zarządca sesji X cofa zmiany i odnotowuje porzucenie transakcji (krok 1726). Zarządca sesji X sprawdza następnie, czy został wysłany komunikat gotowości do akceptacji (Ready-to-Commit) (kroki 1728-1730). Jeśli tak, wówczas X modyfikuje swój rejestr transakcji (krok 1732) poprzez zapis, że X dokonał akceptacji po wysłaniu komunikatu gotowości do akceptacji, oraz zapis identyfikatorów rachunku i sum każdego z rachunków pobranych w czasie wykonywania protokołu transfery rachunków (Transfer Notę). W takim przypadku, protokół porzucenia rejestruje informacje, gdy procedura porzucenia jest wywoływana w przypadku gdy nie powiodła się procedura akceptacji.

Jeśli X jest modułem pieniężnym do realizacji transakcji 1186, oraz został wysłany komunikat gotowości do akceptacji, wówczas funkcja komunikacji z subskrybentem X informuje swego subskrybenta, że transakcja została porzucona, oraz że mógł wystąpić błąd przelewu pieniężnego (kroki 1734-1738).

Jeśli X jest modułem pieniężnym kasjera 1188, wówczas funkcja łączności z bankiem X (To Bank) informuje bank, że powinien cofnąć swe operacje księgowe (poprzez zastosowanie odpowiednich debetów i kredytów) (kroki 1740-1742). Jeśli X jest modułem pieniężnym do realizacji transakcji 1186, oraz został wysłany komunikat gotowości do akceptacji, wówczas funkcja komunikacji z subskrybentem X informuje swego subskrybenta, że transakcja została przerwana (krok 1744).

W każdym przypadku, zarządca sesji X wysyła następnie do Y komunikat, że transakcja nie może być ukończona (kroki 1746-1748). Zarządca sesji Y cofa dokonane zmiany i odnotowuje transakcję jako przerwaną (kroki 1750). Następnie Y informuje swego

180 151 subskrybenta, że transakcja została przerwana (kroki 1752-1754) i informuje bank, by cofnął swe transakcje księgowe (kroki 1756-1758).

Jak opisano, jeśli transakcja jest przerwana w czasie realizacji protokołu akceptacji, możliwe jest by rachunki zostały utracone. Może dziać się tak w przypadku, gdy odbiorca przesyłki dokona przerwania, a przesyłający zaakceptuje transfer rachunków. W tym przypadku, moduł pieniężny odbiorcy zapisuje informację o rachunkach, które powinien odebrać i powiadamia subskrybenta, że występuje potencjalny problem (na przykład, nie otrzymał rachunków wysłanych przez A). Należy zauważyć, że w tych okolicznościach, jeśli chodzi o przesyłający moduł pieniężny, to poprawnie przesłał on rachunki.

Moduł pieniężny odbiorcy może wówczas zgłosić roszczenie otrzymania pieniędzy do agencji wystawiającej certyfikaty (Certification Agency). Informacja roszczenia będzie zawierać zapis w rejestrze nieudanej transakcji. Agencja wystawiająca certyfikaty może następnie sprawdzić w odpowiednich bankach, czy może nastąpić ugoda dotycząca rachunków. Po pewnym czasie, jeśli nie nastąpiła ugoda co do rachunków, subskrybent może ponownie zgłosić roszczenie do odzyskania swych pieniędzy.

Nawiązując ponownie do fig. 13, komunikaty pomiędzy modułem pieniężnym A i modułem pieniężnym B są przesyłane przez funkcję wysyłania zakodowanychskierowanych komunikatów (Send E-Routed Message), która wykorzystuje wszystkie trzy klucze sesyjne (MM/MM), (ΤΑ/MM) i (TA/TA). Nawiązując do fig. 20, funkcja klucza symetrycznego MM A koduje komunikat przy pomocy klucza sesyjnego (MM/MM) (krok 678). Komunikat jest następnie ponownie kodowany przez klucz sesyjny (MM/ΤΑ) zanim zostanie wysłany do modułu zaufanego agenta A. Po odebraniu tego komunikatu przez moduł zaufanego agenta A, komunikat jest dekodowany przy użyciu klucza sesyjnego (MM/ΤΑ) (krok 680). Interfejs komunikatów A wysyła następnie komunikat do interfejsu komunikatów B (kroki 682-684). Pomiędzy modułami zaufanego agenta 120, komunikat jest podwójnie zakodowany kluczem sesyjnym (TA/TA). W podobny sposób, interfejs komunikatów B wysyła komunikat do funkcji symetrycznego klucza MM B do ostatecznego zdekodowania (kroki 686-690). Na fig. 14 pokazano różne warstwy kodowania.

Nawiązując ponownie do fig. 13, w czasie wykonywania procedur porzucenia przez moduły A i B (krok 582), moduły te generują komunikat wysyłany do ich modułów zaufanego agenta, odpowiednio, A i B (kroki 584-586) w celu ich poinformowania o porzuceniu transakcji i w związku z tym o niepowodzeniu realizacji płatności. Zarządcy sesji A i B odnotowują, że realizacja płatności nie powiodła się i w rezultacie moduły zaufanego agenta A i B wykonują operację przerwania (kroki 588-598).

Jeżeli z jednej strony moduł pieniężny klienta 2 posiada wystarczające fundusze, wówczas aplikacja zapłaty/wymiany A wysyła komunikat do modułu pieniężnego sprzedawcy zawierający sumę pieniędzy, która ma być przetransferowana w ramach płatności, oraz typ rachunków (krok 600). Ten komunikat jest wysyłany przez procedurę wysłania zakodowanych-skierowanych komunikatów (krok 602).

Moduł pieniężny B odbiera komunikat zawierający kwotę płatności zależną od modułu pieniężnego A. Funkcja łączności z subskrybentem MM B wysyła następnie zapytanie do modułu zaufanego agenta B, w celu weryfikacji tej kwoty płatności (kroki 604-606). W związku z tym, funkcja zakupu B w module zaufanego agenta B sprawdza, czy kwota jest poprawna (kroki 608-610). Jeśli jest poprawna, wówczas moduł zaufanego agenta B wysyła komunikat poprawności kwoty do modułu pieniężnego B. Jeśli nie jest poprawna, wówczas moduł zaufanego agenta B wysyła komunikat niepoprawności kwoty (kroki 612616). W przypadku wystąpienia komunikatu o niepoprawności kwoty, moduł pieniężny B informuje o tym moduł pieniężny A, który z kolei żąda od swego modułu zaufanego agenta ponownego przesłania nowej kwoty lub w przeciwnym przypadku przerwania transakcji (kroki 618-622, 572-582). Przy płatnościach modułów pieniężnych realizowanych w przypadku zakupu elektronicznych reprezentacji towarów, moduł zaufanego agenta nie wyśle nowej kwoty i wówczas oba moduły pieniężne 6 i oba moduły zaufanego agenta 120 wykonają operację przerwania.

180 151

Jeśli w przeciwnym przypadku moduł pieniężny B odbierze komunikat poprawności kwoty ze swego modułu zaufanego agenta, wówczas moduł pieniężny B wysyła komunikat potwierdzenia z powrotem do modułu pieniężnego klienta (kroki 624-626). Gdy aplikacja zapłaty/wymiany MM A otrzyma komunikat potwierdzenia, wówczas przesyła kwotę do aplikacji pieniężnej A (Money Holder) (aplikacja, która zawiera i zarządza elektroniczną reprezentacją pieniędzy) (krok 628).

Należy zauważyć, że opisany powyżej inicjowany przez płatnika protokół może być zaimplementowany jako inicjowany przez odbiorcę, tak jak w protokole płatności POS. W takim protokole, moduł zaufanego agenta sprzedawcy powiadamia moduł pieniężny, jaką kwotę płatności spodziewa się otrzymać. Ta informacja o płatności jest przesyłana do modułu pieniężnego klienta, który prosi swój moduł zaufanego agenta o weryfikację, po czym, gdy kwota jest poprawna, moduł zaufanego agenta klienta przesyła informację do swojego modułu pieniężnego.

Nawiązując do fig. 13, moduł pieniężny klienta A przesyła następnie elektroniczne rachunki na określoną kwotę do modułu pieniężnego sprzedawcy 4 przez zakodowany - ukierunkowany tor komunikatów (E-Routed message path) (krok 630). Na fig. 21 pokazano znany protokół przesyłania rachunków. Aplikacja skorowidza X (Directory) wybiera rachunek (jeden lub wiele) i wartości do przesłania, modyfikuje kwotę (jedną lub wiele) rachunku i kolejny numer (jeden lub wiele), po czym wysyła komunikat do aplikacji rachunków (Notes) (krok 1566). Możliwymi przesłankami przy wyborze rachunków do przesłania mogą być na przykład, po pierwsze minimalizacja liczby cyfrowych podpisów (które są kosztowne z punktu widzenia czasu przetwarzania), po drugie minimalizacja rozmiaru pakietu, po trzecie maksymalna użyteczność elektronicznych rachunków pozostałych do przesłania subskrybentowi (to znaczy, przesyłanie rachunków z jak najkrótszym czasem pozostałym do ich wygaśnięcia). Powyższe cele mogąbyć osiągnięte przy pomocy następującego algorytmu przesyłania rachunków, po pierwsze wyznaczenie wszystkich możliwych kombinacji, które zawierają najmniejszą liczbę rachunków, po drugie wyznaczenie prostych kombinacji wymagających najmniejszej liczby przesłań, po trzecie jeśli pozostała jedna lub więcej możliwość po etapie drugim, wybór tej która posiada najmniejszą liczbę jednostek pieniądze/dni. Jednostki pieniądze/dni = pozostała wartość rachunku do przesłania pomnożona przez ilość dni pozostałych do wygaśnięcia rachunku, zsumowana dla wszystkich rachunków w pakiecie.

Aplikacja rachunków X po otrzymaniu komunikatu z aplikacji skorowidzu rachunków X kreuje transfer, który ma być dołączony do każdego przesyłanego rachunku (krok 1568). Funkcja klucza publicznego X tworzy podpisy pod rachunkiem (jednym lub wieloma) (krok 1570). Zarządca pakietów X (Packet Manager) zestawia wówczas rachunki wraz z ich nowymi transferami i podpisami w pakiet i wysyła ten pakiet do Y (kroki 1572-1574). Zarządca pakietów Y odbiera pakiet i rozkłada go na części (krok 1576).

Aplikacja weryfikacji Y dokonuje walidacji wszystkich certyfikatów w rachunku (jednym lub wielu) (na przykład certyfikat zarządcy pieniędzy i wszystkie certyfikaty transferów). Następnie, aplikacja weryfikacji Y sprawdza, czy numery identyfikacyjne grup transferów odpowiadają numerom identyfikacyjnym modułów certyfikatów w podpisie, oraz grupie certyfikatów zebranych w czasie całej historii elektronicznego rachunku. Podobnie, zgodność kwot transferów dla każdego rachunku jest poddawana walidacji poprzez zapewnienie, że przez całą historię elektronicznego rachunku kwota przesyłana w każdym kolejnym transferze jest mniejsza niż kwota w transferze bezpośrednio poprzednim. Ponadto sprawdzana jest całkowita transferowana kwota dla zapewnienia, że ta właśnie kwota jest spodziewana (kroki 1578-1580). Jeśli walidacja się nie powiedzie, wówczas transakcja jest porzucana (krok 1582).

Po pozytywnym przejściu walidacji i gdy Y jest modułem pieniężnym do realizacji transakcji, wówczas aplikacja weryfikacji Y sprawdza daty wygaśnięcia rachunku (jednego lub wielu) (kroki 1584-1588). Jeśli którykolwiek z tych rachunków utracił ważność, wówczas transakcja jest przerwana. W przeciwnym przypadku, aplikacja weryfikacji Y sprawdza każdy numer identyfikacji id z transferów rachunku, czy nie znajduje się na liście

180 151 złych id (kroki 1590-1592). Jeśli którykolwiek z tych id znajduje się na liście złych id, wówczas transakcja jest przerwana.

Jeśli żaden id transferu nie znajduje się na liście złych id lub Y nie jest modułem pieniężnym do realizacji transakcji), wówczas funkcja klucza publicznego Y sprawdza ważność podpisów pod rachunkiem (jednym lub wieloma) (kroki 1594-1596). Jeśli którykolwiek z tych podpisów nie jest ważny, wówczas transakcja jest przerwana. Jeśli wszystkie podpisy są ważne, wówczas funkcja weryfikacji Y sprawdza, czy zawartość rachunku(ów) odpowiada zawartościom, które są przechowywane przez aplikację rachunków lub umieszczone w rejestrze transakcji (1598-1600). Dla każdej zawartości rachunku, która jest odpowiednio dopasowana, tworzone jest drzewo transferu rachunku w celu wyznaczenia, czy nie nastąpiło żadne powielenie rachunku (kroki 1602-1604). Jeśli którykolwiek z rachunków został powielony, wówczas transakcja jest przerwana. To sprawdzenie duplikacji jest szczególnie skierowane i dostosowane do wyszukiwania osób, które usiłują kreować pieniądze przez przesyłanie rachunków w operacjach typu self-dealing przy użyciu przejściowych transakcyjnych modułów pieniężnych.

Jeśli nie występują żadne duplikacje lub gdy nie stwierdzono dopasowań zawartości rachunków, wówczas aplikacja rachunków Y umieszcza rachunek (jeden lub wiele) w aplikacji posiadacza pieniędzy (money holder) (krok 1606). W końcu, funkcja skorowidzu rachunków Y modyfikuje pozycję (jedną lub wiele) rachunku (jednego lub wielu) i kwotę (jedną lub wiele), oraz również inicjuje numer sekwencyjny (jeden lub wiele) (krok 1608).

Proces przesyłania rachunków zawiera etapy modyfikacji i inicjacji numerów sekwencyjnych, w celu ułatwienia uzgadniania rachunków, sprawdzania czy odbiorca któregokolwiek z rachunków nie znajduje się na liście złych id, oraz sprawdzania duplikacji rachunków. Te dodatkowe własności i kroki utrudniają ewentualnym przeciwnikom wprowadzanie i podtrzymywanie w obiegu zduplikowanych rachunków, co zwiększa zdolność do wykrywania pozostających w obiegu zduplikowanych rachunków.

Nawiązując ponownie do fig. 13, wywoływana jest procedura akceptacji MM (krok 632). Protokół akceptacji jest pokazany na fig. 22. Zarządca sesji X wysyła komunikat gotowości do akceptacji do Y (kroki 1702-1704). Zlecenie akceptacji jest następnie przesyłane do modułu przyjmującego komunikat. W klasycznym scenariuszu transferów pieniężnych, sposób polegający na tym, że strona obciążana dokonuje najpierw akceptacji, jest stosowany w celu zapewnienia, że strona przesyłająca pieniądze pierwsza dokona akceptacji, tak by wyeliminować możliwość duplikacji pieniędzy.

Zarządca sesji Y wysyła następnie potwierdzenie do X (kroki 1706-1708) i wykonuje akceptację wszystkich nieuregulowanych transakcji poprzez modyfikację ich rejestru transakcji (krok 1710). Podobnie, jeśli Y jest transakcyjnym modułem pieniężnym, wówczas funkcja łączności z subskrybentem Y powiadamia subskrybenta o prawidłowym zakończeniu transakcji (kroki 1712-1714). Zarządca sesji Y odnotowuje koniec sesji (krok 1716).

Funkcja rejestru transakcji X odbiera potwierdzenie z Y i modyfikuje jego rejestr transakcji, w wyniku czego akceptuje wszystkie nieuregulowane transakcje. X kończy swą akceptację w taki sam sposób jak Y (kroki 1718-1724).

Przebieg algorytmu jest kontynuowany, gdy moduły pieniężne 6 współpracują z modułami zaufanego agenta 120, przy założeniu, że funkcja wysyłania komunikatów jest tożsama z funkcją wysyłania zakodowanych-skierowany eh komunikatów, oraz że komunikaty funkcji łączności z subskrybentem są w rzeczywistości wysyłane w postaci zakodowanej do modułu zaufanego agenta 120. Mając powyższe założenia na uwadze, zarządca sesji modułu pieniężnego MM B wysyła komunikat gotowości do akceptacji do zarządcy sesji modułu pieniężnego MM A przez procedurę wysyłania zakodowanych-skierowanych komunikatów (kroki 1702-1704). Zarządca sesji MM A wysyła następnie komunikat potwierdzenia do modułu pieniężnego B, a moduł pieniężny A dokonuje akceptacji (kroki 1706-1716). Gdy moduł pieniężny B odbierze komunikat „potwierdzenia, również dokonuje akceptacji (kroki 1718-1724 ).

W czasie wykonywania procedur akceptacji przez moduły pieniężne A i B, moduły te generują komunikaty wysyłane do ich modułów zaufanego agenta, odpowiednio, A i B

180 151 (kroki 1714, 1722) informujące o tym, że transakcja została zaakceptowana i płatność została zrealizowana.

Nawiązując ponownie do fig. 13, oba moduły pieniężne wysyłają wspomniane komunikaty poprawnej realizacji płatności (Payment Successful) do swych modułów zaufanego agenta (kroki 584-586). Te komunikaty są kodowane przy użyciu klucza sesyjnego (ΤΑ/MM). Zarządca sesji A wykrywa, że płatność została zrealizowana poprawnie i aplikacja posiadacza noty A modyfikuje notę pokwitowania danymi płatności, takimi jak data transakcji (kroki 588, 592, 634). Moduł zaufanego agenta A dokonuje wówczas akceptacji (krok 636), tak że posiadanie przez niego noty nie ma już dalej charakteru tymczasowego. Podobnie, zarządca sesji B wykrywa poprawną realizację płatności (kroki 590, 594) i moduł zaufanego agenta B dokonuje akceptacji (krok 638). Transakcja jest wówczas zakończona.

Nawiązują ponownie do fig. 8, aplikacja posiadacza noty A wysyła notę płatności handlowej do aplikacji HTA (krok 764), która odbiera tę notę i wysyła ją, wraz ze zleceniem przelewu, do systemu kont płatniczych 189 jako dowód zapłaty (krok 766). Aplikacja posiadacza noty B wysyła notę płatności handlowej do aplikacji HTB (krok 768), która odbiera notę i wysyłają, wraz ze zleceniem przelewu, do systemu kont odbiorczych 193, w celu dopasowania do nieuregulowanych faktur. Alternatywnie, dopasowywanie może być wykonywane w czasie realizacji transakcji płatności.

Powyższy opis przedstawia jedynie korzystny przykład realizacji niniejszego wynalazku. Wynalazek może być poddawany różnym modyfikacjom i stosowany w różnych warunkach, nie wychodząc jednak poza określone tutaj ramy.

ZL£C£A/(E. Ą

180 151

48 49 i______________________________________________________I ..................................1

MOMĄCM ORUŁRCie	IWORptACTA 0 SPRZWKY	1 data PWWOŚU	Κ^οτΑ PŁATNOŚCI
	LISTA	FĄKJUR

I 50

FAKTURĄ

51-	nuher FAKTURY	HR MdJPU	DATĄ ptATNoba	KKOTA FMaUKY	KhfUFĄ ZMŻlAl	MĄ: Νεπο
	III II 52 53 54 55 56

180 151

Fig ₀ 3

180 151

120*3

Π2 ι

128

FUNKCJE ΚοΗϋΜίίέΑζ,ΎΙΜΕ (fifTERF^lS

132-

hO^UŁ

ZAUFANEGO A6sm

APLIKACJĄ- Iapl/AAC/A 7&WS/tfC7/W^^

APUKĄCJA ΊΊ^/SAicCJl ta

ZARZĄDCĄ .

KOHUA/f KĄFOW

134 ~130

-124

FUNKCJE 2^/CZASU L_?36

126

MOW-L,

Fig, 4

180 151

138

146

152

INTERFEJS KMUNIKĄTÓH
ZARZĄDCA SESJI
ZARZĄDCA ZA&EZPiECZ&Y
FUNKCJE TRA^KCYJNE TWKOE PC&AiACZA , .o WMCCTE EĄCIM2ŚCI NUTY 12« ZHODU{£H
FUNKCJE KRYFWiiAFICZNE
KZUCZ^ | M\/££JA· KLUCZA SYHETRYCZNE6O | W&JGfflfcO	6EA/HU&OR L/CZ& LOSOWYCH

140

142

144

150

154

156

160

162

158

ZAKUP	kĄGZiUOĆĆ z&tiómjyH PROc^sa^A	Rejestr TR/WS^CGJl
(jySTAK/APlE KOTY	K^fHAk£	RoSPOG^CiE sP6na

168

166

164

172

174

170

ZAKUP	ί&έύ^ι^Κ PPF>C£Sc^EH	PEJESIK. TRj^^KCJT
	Mtey^fie.
Μ)Γν	\j£Q3yYTUK^	sws

176

177 178 \ 5C

183

182

180-

UTHORZEWE	iA^^yść ζ&άλ $Ε7&^β jyy» PROC£S)^\ TRAffSĄKjCJt
D^&R<^IE WTY	WM/AAr i/A&rKAiylE KiERZYWYCÓCI [MEfgyWLMSC!

184

186

185

180 151

193

Fig ο

180 151

Fig. 7B

180 151

702

Fśg_o 8A

180 151

Fig, 8B

180 151

738

W

740

MS

ΡΟ^υέ

KIM P^BUCZ^ Q 1-742

SOPPiSĆ ŚL&CEME Ρ&Εί£EU Z ftyŚUJ WfaJiD PD— 5/aD/K^A ΜΧΥβ

744

PbS/AMCZ Μ>7> & uthóqz mtts pt&wśa

ΉΛΗΡΡΟΜΡΪ h/YSLir ΜΕΡξ jo Λ

746 ^ŚLQ KbmJMllcbT -748

-750 ⁷⁵² x/\ \7£ LMośĆ/

754

popsuć TP^^S^Cją

-756

K.DMEC hTYŚU7 7^J)O P^AfiCCJl

PPS^BACZA: LHYÓLIT iW(S ^C^/A Pi&EIJEW

j>la pERynitAor/

180 151

180 151 ^57 f X

I fyMJ C&ZTYF/KATU

-296

ZARZĄDCA ^e&^ie^-293

Wf5i.lT CESTYP/f<AT

DO ZARZĄDCY SS5J!

ZAmpCA SESJĘ X poo NYŚL17 C^Y^RArjo y

ZARZUCĄ ^szt y

Wfy£RZ CcRT/mAT

-302

WBfE&z cŁRryFfk^T qd żarłocy sesje ku/cz Ρϋβυοωγ y -306

ZHERYFfKUJ CERiyHKAT y

306

JJśC(E ME^FA WC/i

316

X JEST ^RZĄDCĄ 3£SJ/ y

-310

MWTltf s?

S7/_z M&UJ KOHJMKAT Zffi//A7J/^7W/SĄUCjf doy.

Fag o M

ISO 151

9B

180 151

340-

spRAhioJ: czy y 7fóTM UŚCIE M£ZWAlWCł1 338^ ?

'y

W-uśae^

Ltczg wso^ycft x utwórz iosmą uczRfr) / KD^MR^T ^mnKĄcj/ x

ZARZUCĄ SESJT X

-332

ODRbJiUd ZA&>/C>GLEUe $& I^ŚLIJ KOWMm R^RrRA/v&{ECJ7 JD y

-334 oda/djuj kw/ec

ÓW υτΗϋ& klucz

Ky]^R R(y) IRESTAR ^)KiMWi h/ERYlFfm Yl y ,^ε,^γ i G^SUiRR^) hnEP&y

346-	KLUCZ PUMICZNY X
ZĄZO0UJ ROKU^tRR-T KuycRtu pJdLicMH y
	i
348-
zAiio$oM&/y !O0M^(iCAl R>0 y

wieoz KoWMr

Fig _o 9C

180 151

180 151

370

374

KOfaJMiCĄT H&I.YFIIC&CU i

Of/YolUJ ^SJ/

Fig. 9E

180 151

FUg _o W

180 151

180 151

180 151

LiG& lOSOHYC^t X (ΛΗύ&ί LoS^ UdB^ PO)

-520 dC^kUP X________-522 w/ślu koWMKAT P/3^ ινοέα HObUW PlEM&WEĆG i ACl)

524 y

QD3/^ koM/MAT

-526

^e&^P/EC^ y	-528
Ob&i^ 8.0)

udSD^ycH y	-530
uryói^ UC^B^ LOSWĄ 8&) / MŚU? J)O y
$
H/śur koHU/y/K&T y-^x	-532

klucz

Fig. 13 A

180 151

13Β

180 151

558~W X ża&we *wry W7no5c/ ^JĄLpj^Cl GD ZW R4<^iCU

560- H/5^£ l^OhUMK· ΗΜ/ΓΑ X

562Z&iCUPX

KYŚLtJ KWTE WJALE^ft/c^tl DD ΎΜνΡΜΜ.,βΟ TdtD^P/e· L______________

564~ fayi&ME KOWMK. TA/Hh A

566~ ZAP&#tfN7MWA HM X

OJ) T/PG OACHUMOJ

570

568~ SkaW/DZ PACHUfiKÓH Wj* s?PAktó <^yHysTĄzcJi^

PGMDPSłE

600- ^y^i-Ą/VA uh?

^LIJ &PkOc/E QD Ί7ΡΟ PIACH UlDkU JO Hhy

ME ^UMDGGit _Λ, &y$łAME ZAtoDOHMEGO : 602-SKĆĄOł&WEGO KoHGNiK^b HM y ΜΗΎ

604ŻĄ^AI ZHERfflkoHAMĄ y ^al. dd rw

Fśg o 13C

180 151

614

612 zakup y

MŚUJ PohUMK^żE KfrUTA JEST PPANUltGPĄ zakup y

N7ŚU 7 KOWM PAr r M/εροΡRAW MOŚCI

620

13D

180 151

OJu (ZAKWOfijĄMF-^^ ńoW^iKAZyl

/KC&T^CJĄ HM -632

MHY hMX (^Hoj>Qf^E - 5Ηϊ&Μή/£

584-HYSiA^e kCMPhflK. HHfa* WSłANiP Κ&ΐΜ. HtyM Y -586

588- ^^^DCA-SSST/ X ^p^dcą- 5esJ( y 1-590

596

ΙΌΡΆ^^

592

Wćz^ai

634- ^Ty

594

638

/Y/£

I2OW,

CIU PbęwcŹCl

AKCEPTACJA y

636~ ^^T^CJĄ X

598 1

IFiig „ 13E

180 151

120

436

438 — moduł ZAUFANEGO agenta

442

120

-440

MODUŁ pieniężny

MM.

PlEMĘtHy

Fig. M

180 151

ο

15Α

180 151

1484

1494

JTl^YNMiE 3A8EtPtEGfóri & SPAAM CZY A ZNAJDUJE S(Ę Ml UŚCIE ZEYCK (0/0^

1498 J__

1496

TAK

ME

Ą JEST

NA UŚCIE

HO& Ł0SWCH3

UTWÓRZ UCZSĘ LOSONARU l KOM Ml KAT HERYEl'

KKCJl B /pRO&lAMTbK

V AWEZt^Y IGS45U*

ZN?^4PCA· S&SJ! £>_ -1486

Q!WTUJ ZAKOKlJZEME SESJI

1488

1490

NE

TAK

TOANSAKCJi eagcndsć zsueswpys. 3 kcfaWikĄT ^4^czeM/a tmsazcji PiNEŚLlJDD F.UTKZyM 1500

ZEST^! R(&) KOM.MERTWCACJt3 l DANE l CZASU N JEDEN KOHUMKAT

KONIEC

1492 ^CZMŚĆ Z βΑΜΟΕΜίΓ NYŚUT KOMU MKET

CZM/Ą TRAHSAKCJl

KONIEC

KUJCZ PU& LICZNYM

-1504

ZiKODl/J MW Ml WE KUA m W&UCZMM A

MKATU / NyŚLlJ w 4

15$

180 151

180 1S1

Fig. 15D

180 151

1550

TAK

SPXiĄ

KRESU

ME

ZARZĄDCA ^S3Y £ 1-/552

ZARZĄDCA- ^S7T & wyślij panmzsMF l KKAT HCW^ACJl ą DO A

-1554

WSWAfóz -_Ί556

-1558 tyMKĄT A

SiWu^ KoHUY HE&YHK

1562

-1564

WRÓn

Fsg. 15E

180 151

Fig.. 16

180 151

KWCZ MH K

ZWCOWJ KLUCZE/( ^S7JM Cwwi)

-658

T&Oty&A ttSJI HFt A -660

KVŚ(J1 łCCHyU. JO A. IW&& %

UŁÓhfAiy MGMCA t/n/tr-J, / X/ OOZ

MŚLZJ KOWMKĄF J®

IMEWEJSU KCFUMIK X

IM^FEJS ΚΟΚυΜKĄTKU X -664

MESZ ićO^//(KAT kwcx syMEjR,ycxA/y X ^DEKODUJ /CUKREM SESyJ^H fTA/MH]

666

Fig^ 17

180 151

180 151

-1726

CiFMJ M/MY i ODROb^f POiWCEME TPMSĄkCJI

ZARZfyPC-^ SESif X -1728

SPfWttó CZy kZHŻ ^DiZDŚa WAEćEPl^

1730

ME

REJESTR 'rREESMCJ! X AEWAUd^J iĆEJESnł. Tl^ffS kWMtZA

NystĄRy

-1732

1744 _1_______________ iĄ&MŻĆ Z SU&SkQ. X

M&rt KCfyJMKAT o FU o nZUCEMN TRMSĄKCJi

1734

ME

1736

ΜΕ

TMC hT/SEAM

TAK

1740

ME 'KESl^fl łtM^-—

TEK

C&FM7 OPERACJE iĄc^ożć z -1738

MŚUJ jrPA^~ kaA Zł^MWy POŻUhE RY^· DirUis: biej^AiJ TnJLAKccni)^u

1746llySuj^kM^r^yl' ŻE TRE^SAŁCTA ME fEŚE być ιζζο^ομχ

Fig o W A

180 151

\y V / '' / (SWJ

1754

1752

h/(E

WC

NSklCCJĄ

1756

W hh

MY&JJ kOHidA/^T D tsa^m.ch

Hg 19B

1758

180 151

180 151

k7566

ΝΎβίββΖ RĄGHUifElciKi) MAR^ŚCL pD ZAKTUALIZUJ WOTĘCY) PACHUNW 1 WHFRM

OdBlEU /(MM^-^68

TS^MSFFR M OAGHU^U

KLUCZ. PU&UC1NY X UFMÓiU PODPiSCy) J>IARPCHUNKU (^l)

I zarzuca fj^irróH P RĄCRUN&C(I),

-1570

-1572

WNSFER(y)_t POBPisCy) m

IźbtN PAKIET l MYŚLI! Do Y

NYMME ΚοΗυΜΙ&ςΊΌ-1574

ZARZĄDCA PARINTÓM / 1-1576 OD0lS2f Μ/£Τ/ΑαΖ^YFlfCACJĄ Y -1578

ZHLPNFIP^ wwTERY DLA ĆEPTYflK^ÓH^EObWŚĆ KHOT TRANSFERU J)IA KAŹ' i^GO T^CHUNKU ORAZ MkOmtą 1580

TAK

MlYE

ME

1582

PCRJYCEME TRANSAKCJI

KoMEC

180 151

180 151

1718 | 1708 AKTUALIZUJ REJESTR 7R. 1720 1722 _!__________1____________ W SU&SK^&EMTA X y7J PoW/AWd SUbS!CS.\2EMrĄ 0 ZAKOŃCZENIU ^/SMCGK ____________________________________ . ------------------------- ZARZĄDCA SESJI X -1724 j7Ί OWOWJ I&NEC TW&SAKCJI

1 1710 ,______________________2_________!____________ [ REJESTR. 'iRAMSAKCriy \aKJUĄuJUT SEJESiR ^MS- 1712^^^ - 4- co SUeSKRYdEMTA y scesKpyeEm- 0 TR^AECJl &- M^dcą S^jf y ObMJPJJ KDMfSO JRĄfMCJ/

Departament Wydawnictw UP RP. Nakład 70 egz. Cena 6,00 zł.

Claims (8)

1. Zastrzeżenia patentowe

   1. Sposób realizacji elektronicznych płatności handlowych, w którym przeprowadza się wymianę pieniędzy elektronicznych przy wykorzystaniu modułu zaufanego agenta klienta, pierwszego modułu finansowego, modułu zaufanego agenta sprzedawcy i drugiego modułu pieniężnego, z utworzeniem zabezpieczonego środowiska transakcyjnego, znamienny tym, że przesyła się dane zlecenia przelewu, za pomocą modułu zaufanego agenta klienta, do modułu zaufanego agenta sprzedawcy, tworzy się za pomocą modułu zaufanego agenta sprzedawcy notę płatności handlowej zawierającą, przynajmniej w części, dane zlecenia przelewu, przesyła się za pomocą modułu zaufanego agenta sprzedawcy notę płatności handlowej, do modułu zaufanego agenta klienta, który tymczasowo zatrzymuje tę notę, przesyła się za pomocą pierwszego modułu pieniężnego elektroniczną reprezentację pieniędzy, do drugiego modułu pieniężnego, który tymczasowo zatrzymuje tę elektroniczną reprezentację pieniędzy, dokonuje się zatwierdzenia za pomocą pierwszego modułu pieniężnego i bezpiecznie informuje się moduł zaufanego agenta klienta o prawidłowo zakończonym transferze pieniężnym, następnie dokonuje się zatwierdzenia za pomocą drugiego modułu pieniężnego, w wyniku czego zatrzymanie elektronicznych pieniędzy przestaje być tymczasowe i bezpiecznie informuje się moduł zaufanego agenta sprzedawcy o prawidłowo zakończonym odbiorze elektronicznych pieniędzy, następnie dokonuje się zatwierdzenia za pomocą modułu zaufanego agenta klienta, w wyniku czego zatrzymanie noty płatności handlowej przestaje być tymczasowe, a następnie dokonuje się zatwierdzenia za pomocą modułu zaufanego agenta sprzedawcy.
2. 2. Sposób według zastrz. 1, znamienny tym, że za pomocą modułu zaufanego agenta sprzedawcy tworzy się cyfrowy podpis pod danymi zlecenia przelewu i dołącza się ten podpis do noty płatności handlowej.
3. 3. Sposób według zastrz. 2, znamienny tym, że dodatkowo za pomocą modułu zaufanego agenta klienta weryfikuje się cyfrowy podpis przed rozpoczęciem transferu elektronicznych pieniędzy.
4. 4. Sposób realizacji elektronicznych płatności handlowych, w którym przeprowadza się wymianę pieniędzy elektronicznych przy wykorzystaniu pierwszego urządzenia transakcyjnego i drugiego urządzenia transakcyjnego, z utworzeniem zabezpieczonego środowiska transakcyjnego, znamienny tym, że za pomocą, pierwszego urządzenia transakcyjnego przesyła się dane zlecenia przelewu do drugiego urządzenia transakcyjnego, następnie za pomocą drugiego urządzenia transakcyjnego zestawia się notę płatności handlowej zawierającą dane klienta, dane sprzedawcy, dane płatności, kwotę płatności oraz cyfrowy podpis i za pomocą tego drugiego urządzenia transmisyjnego przesyła się notę płatności handlowej do pierwszego urządzenia transakcyjnego, a za pomocą pierwszego urządzenia transakcyjnego weryfikuje się tę notę płatności handlowej i przesyła się elektroniczną reprezentację pieniędzy do drugiego urządzenia transakcyjnego.
5. 5. Sposób według zastrz. 4, znamienny tym, że cyfrowy podpis jest cyfrowym podpisem pod danymi zlecenia przelewu.
6. 6. Sposób według zastrz. 5, znamienny tym, że podczas weryfikacji noty płatności handlowej sprawdza się ważność cyfrowego podpisu.
7. 7. Sposób według zastrz. 6, znamienny tym, że dane zlecenia przelewu obejmują dane klienta i sprzedawcy, numer odniesienia klienta, adres sieciowy sprzedawcy, kwotę do zapłaty, datę i listę faktur do zapłaty.
8. 8. Sposób według zastrz. 4, znamienny tym, że dodatkowo ustala się kryptograficznie zabezpieczony kanał za pomocą pierwszego urządzenia transakcyjnego i drugiego urządzenia transakcyjnego.

   180 151