DE102022000532A1 - Verfahren für anpassungsfähige, ausfallsichere Transaktionen von Wirtschaftsobjekten - Google Patents
Verfahren für anpassungsfähige, ausfallsichere Transaktionen von Wirtschaftsobjekten Download PDFInfo
- Publication number
- DE102022000532A1 DE102022000532A1 DE102022000532.8A DE102022000532A DE102022000532A1 DE 102022000532 A1 DE102022000532 A1 DE 102022000532A1 DE 102022000532 A DE102022000532 A DE 102022000532A DE 102022000532 A1 DE102022000532 A1 DE 102022000532A1
- Authority
- DE
- Germany
- Prior art keywords
- tan
- transaction
- trust server
- value
- emergency
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims description 13
- 230000003044 adaptive effect Effects 0.000 title 1
- 238000012790 confirmation Methods 0.000 claims 3
- 230000003993 interaction Effects 0.000 claims 2
- BUHVIAUBTBOHAG-FOYDDCNASA-N (2r,3r,4s,5r)-2-[6-[[2-(3,5-dimethoxyphenyl)-2-(2-methylphenyl)ethyl]amino]purin-9-yl]-5-(hydroxymethyl)oxolane-3,4-diol Chemical compound COC1=CC(OC)=CC(C(CNC=2C=3N=CN(C=3N=CN=2)[C@H]2[C@@H]([C@H](O)[C@@H](CO)O2)O)C=2C(=CC=CC=2)C)=C1 BUHVIAUBTBOHAG-FOYDDCNASA-N 0.000 description 1
- 206010037180 Psychiatric symptoms Diseases 0.000 description 1
- 206010038743 Restlessness Diseases 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000002045 lasting effect Effects 0.000 description 1
- 230000005923 long-lasting effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- 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/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Computer Security & Cryptography (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Computer Hardware Design (AREA)
- General Health & Medical Sciences (AREA)
- Bioethics (AREA)
- Health & Medical Sciences (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Die Figur 1 zeigt ein Ausführungsbeispiel der Erfindung.Bei Verfügbarkeit eines Netzwerks (9) werden für jedes Device(1),(2),(3) Abbildungen von Konten und Portfolios von Realtransaktionsservern (14) in einer Liste (8) auf einem Heimat-Trust-Server(7) auf Guthabenbasis geführt und ein Standort-Trust-Server(10) eingebunden. Gemäß bekanntem Guthabenwert werden TAN zur späteren Abrechnung mit (14) verwendet.Den Devices(1),(2),(3) werden ohne (9) oder Notfallnetz(12) von dem zugehörigen (7) eine eindeutige Identifikationsnummer und Schlüssel in einer Liste (4),(5),(6) zur Verfügung gestellt und mit Hardwaremerkmalen in einer Liste(8) eingetragen.Bei Erreichbarkeit von (7) wird gemäß (8) der nächste (10) gemäß Vorgaben (4),(5),(6) ermittelt und (7) ein Notfallwert mitgeteilt, in (8) als Maximalwert berücksichtigt.Von (7) generierte TAN mit Regeln von (8) plus ID von (7) werden an (10) für (11) und (1),(2) für (4),(5) gesendet.Je TAN in (4),(5) wird von (1) mit (2) eine Transaktion bei Plausibilität abgewickelt, in (8),(11) als blockiert eingetragen.Ist (7) nicht erreichbar, wird über (12) eine Verbindung zu (10) hergestellt, in (1),(2) ungenutzte TAN im Abgleich mit (10) verwendet oder von (10) TAN mit ID von (10) nach Regeln (11) generiert.Ist weder (7) noch (10) erreichbar, aber ein (3), so wird von (1) ein (3) als Kontroll-Device bestimmt. Transaktionen können über(12)mit Not-TAN oder ohne (3) notfalls direkt zwischen (1) und (2) mit NOT2-TAN durchgeführt werden.
Description
- Der Erfinder beschäftigt sich seit vielen Jahren mit einem Trusted WEB 4.0. Wesentliche Merkmale von Trusted WEB 4.0 sind Dezentralität und Anonymität. Unter
DE 102017005550.5 - Die Erfindung betrifft ein Verfahren entsprechend dem Oberbegriff des Anspruchs 1 bis 4.
- Die erfindungsgemäße Aufgabe besteht darin, eine bessere Verfügbarkeit von allen Transal<tionsarten auch bei Ausfällen des Stromnetzes oder des Internets zu gewährleisten. Dabei werden vorhandene Onlineportfolios und Bankkonten erfindungsgemäß ohne großen Aufwand integriert. Vorhandene Portfolios und Bankkonten werden gespiegelt oder treuhänderisch von dem Betreiber eines Heimat-Trust-Servers verwaltet betrieben und auf Guthabenbasis geführt.
- Nach dem Stand der Technik wird für ausfallsichere Transaktionen die Blockchain bevorzugt. Diese hat jedoch gegenüber der Erfindung den Nachteil, dass sie ein funktionierendes Internet erwartet. Auch besteht hier durch die aufeinander aufbauenden Blocks eine sichere Dokumentation für die Zukunft. Bei der Verwendung von Bargeld ist es aber eben meist nicht gewollt, dass zukünftige Generationen sich noch genau über die einzelnen Ausgaben ihrer Vorfahren informieren können. Dem Anspruch des anonymen Bezahlens kommt das erfindungsgemäße Verfahren wesentlich näher. Wobei wie bei
DE 102017005550.5 - Das erfindungsgemäße Verfahren passt sich auf verschiedenste Ausfallszenarien an. Nach dem Stand der Technik gibt es bei jedem Smartphone grundsätzlich eine Vielzahl von Möglichkeiten, wie über 5G, 4G, LTE, W-LAN, Bluetooth, NFC zu kommunizieren. Auch gibt es bereits mehrere Verfahren, um Ad-hoc Netze ohne Router direkt zwischen Smartphones aufzubauen. Bei einem Stromausfall ist es in der Regel möglich, das Smartphone zum Beispiel über eine Autobatterie noch aufzuladen. Erfindungsgemäß neu ist, dass innerhalb des Netzwerks verbindlich für alle Teilnehmer möglichst viele standardisierte Verfahren festgelegt werden und in Versuchen vom globalen Verbindungsaufbau im Internet bis herunter zum Aufbau zwischen zwei Devices von jedem Device versucht wird, in der festgelegten Reihenfolge eine Verbindung aufzubauen.
- Bei Verbindungseinschränkungen wird erfindungsgemäß zwischen mindestens 4 Status unterschieden. Entweder Status 1 das Internet funktioniert weltweit normal oder Status 2 das Internet funktioniert nur in einer Region oder Status 3 zwischen mehreren Devices kann eine Verbindung aufgebaut werden oder Status 4 zwischen den an der Transaktion beteiligten Devices kann eine Verbindung aufgebaut werden. Das Risiko für Betrug und Manipulation steigt bei jeder höheren Verbindungseinschränkung. Dementsprechend werden erfindungsgemäß durch einzelne Voreinstellungen und allgemeine Vorgaben die Transal<tionsmöglichkeiten reduziert und damit den Risiken bei jeder höheren Verbindungseinschränkung entgegengewirkt. Durch manuellen Eingriff in die Voreinstellung hat der Benutzer jedes Devices selbst die Möglichkeit , höhere Risiken einzugehen.
- Soweit zum Beispiel über einen Aktienwert aktuelle Informationen nötig sind, kann eine Transaktion schon ab Status 2 nicht oder nur gemäß einer für eine Ausnahmesituation hinterlegten Regel durchgeführt werden. Die Abwicklung des tatsächlichen Aktienverkaufs erfolgt erst, nachdem alle nötigen Verbindungen zu der entsprechenden Informationsquelle wiederhergestellt sind. So können zum Beispiel Wetten abgeschlossen werden, ob der Aktienkurs bei Verfügbarkeit einer Netzverbindung steigt oder fällt oder es gilt der letzte gespeicherte Aktienwert. Insofern sind bereits bei Status 2 Wertschwankungen unterworfene Transaktionen zumindest erschwert. Allerdings ist die Sicherheit der Transaktionen noch vergleichbar mit Status 1, wenn alle an der Transaktion beteiligten vor einem Ausfall des Internets ihrem Heimat-Trust-Server ihren aktuellen Standort mitgeteilt haben. Die eindeutige TAN und das Guthaben sind dann über einen Standort-Trust-Server überprüfbar. Im Notfall kann man zum Beispiel zu dem Wi-Fi Hotspotbereich des Standort-Trust-Servers hinlaufen.
- Steht gemäß Status 3 kein Standort-Trust-Server zur Verfügung, so ist im erfindungsgemäßen Verfahren vorgesehen, dass ein beliebiges drittes Device, welches Teil des Transaktionsnetzwerkes ist, die Funktion eines Kontroll-Devices übernimmt. Dieses Kontroll-Device ist vergleichbar einem Zeugen. Wenn das Internet wieder funktioniert, übermittelt dieses die Transaktion an seinen eigenen Heimat-Trust-Server, welcher die Information an die Heimat-Server der an der Transaktion beteiligten Devices weitergibt. Es ist technisch erfindungsgemäß sichergestellt, dass im Streitfall an allen Speicherorten forensische Beweise gesichert werden können.
Es ist auch eine Mischung zwischen Status 2 und Status 3 möglich, wenn sich nur einer der Transaktionspartner im Einzugsbereich seines Standort-Trust-Servers befindet. - Um in jeder denkbaren Situation eine Verfügbarkeit entsprechend dem Bargeld sicherzustellen, ist gemäß Status 4 auch eine Transaktion direkt zwischen zwei Devices möglich. Durch die Umstellung auf erneuerbare Energien werden selbst langanhaltende, flächendeckende Stromausfälle wahrscheinlicher. Das zufällig im Geldbeutel befindliche Bargeld wird meist nicht reichen, um einen mehrere Wochen andauernden Ausfall des Stroms und Internets zu bewältigen. Es ist davon auszugehen, dass durch eine Notstromversorgung das Mobilfunknetz auch bei einem solcher Ausfallgroßereignis noch einige Stunden funktioniert. In einem solchen Fall können gemäß Voreinstellung oder manuell ein Guthaben noch aufgefüllt und weitere Anweisungen an alle Standort-Trust-Server und Devices gesendet werden.
Für alle Beteiligten kann davon ausgegangen werden, dass die Schäden durch Vandalismus, wenn die Menschen kein Geld haben, um sich Essen zu kaufen, größer sind, als wenn jedem ein minimales Geld zur Verfügung gestellt wird. Erfindungsgemäß wird standardmäßig von dem Guthabenwert ein Teil für den Notfall als Notfallwert einbehalten. Dieser steht zur Verfügung, wenn das Guthaben aufgebraucht ist und keine Möglichkeit mehr besteht, auf andere Weise Transaktionen durchzuführen.
Ebenfalls besteht erfindungsgemäß die Möglichkeit, eine Anweisung zu hinterlegen, dass bei Eintreten einer bestimmten Verbindungsbeschränl<ung veränderte Regeln gelten. So kann zum Beispiel bei Status 4 nach Aufbrauchen des Notfallwerts die Regel hinterlegt sein, das Generieren weiterer TAN zuzulassen. Da die tatsächliche Abrechnung der Transaktion erst später erfolgt, könnte eine solche Regel sogar gesetzlich festgelegt werden. Schließlich stehen moderne Sozialsysteme in der Pflicht, den Grundunterhalt eines jeden Bürgers zu decken. Es geht also nur um einen Vorschuss, der später mit dem Grundunterhalt verrechnet wird. Die hohen Kosten von Unruhen, wenn die Wirtschaft und das öffentliche Leben ohne funktionierendes Transaktionssystem zusammenbrechen und der Vertrauensverlust in den Staat werden durch das erfindungsgemäße Verfahren auf ein Minimum reduziert. - ZITATE ENTHALTEN IN DER BESCHREIBUNG
- Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
- Zitierte Patentliteratur
-
- DE 1020170055505 [0001, 0004]
Claims (4)
- (Heimat-Trust-Server) dadurch gekennzeichnet, • dass mit mindestens einem weiteren Heimat-Trust-Server ein Netzwerk eingerichtet sein kann, • dass jedem Heimat-Trust-Server eine in dem Netzwerk einmalige, eindeutige Identifikationsnummer zugeordnet werden kann, • dass mindestens ein Device zugeordnet werden kann, • dass für mindestens ein Device eindeutige Hardwaremerkmale gespeichert werden können, • dass für mindestens ein Device ein auf mindestens einem Wertkonto eines Rechenzentrums verwalteter Guthabenwert gespiegelt und aktualisiert werden kann, • dass ein Wertkonto direkt ohne Zwischenschaltung eines Rechenzentrums verwaltet werden kann und das erfindungsgemäße Verfahren integriert werden kann, • dass für mindestens ein Device ein Notfallwert gespeichert werden kann, • dass für mindestens ein Device von mindestens einem Portfolio verschiedene Informationen zusätzlich zu einem Guthabenwert gespeichert werden können, • dass für mindestens ein Device nur bei Erlaubnis und in Höhe entsprechend einem hinterlegten Regelwerk je Portfolio der Guthabenwert eines Portfolios dem Guthabenwert eines Wertkontos zu einem zu verwendenden Maximalwert zugerechnet werden kann, • dass der Notfallwert von einem verwendeten Maximalwert abgezogen wird, • dass mindestens einem Device in einer Direktverbindung individuelle symmetrische Schlüssel und die eigene eindeutige Identifikationsnummer zur Verfügung gestellt werden können, • dass von mindestens einem Device zu einem definierten Anlass mindestens ein Standort abgefragt werden kann, • dass auf Basis einer von einem Device übermittelten Standortinformation der nächst gelegene Standort-Trust-Server ermittelt werden kann, • dass an mindestens einen Standort-Trust-Server für mindestens ein Device mehr als eine TAN, sowie ein Maximalwert, ein Notfallwert, Anweisungen für mindestens eine Stufe des Verbindungsausfalls, Portfolios mit hinterlegtem Regelwerk und Informationen gesendet und in Interaktion mit dem jeweiligen Device verwendet werden können, • dass für mindestens ein Device mindestens zwei TAN(Transaktionsnummern) auf Basis mindestens eines individuell vergebenen symmetrischen Schlüssels und mindestens eines gespeicherten Hardwaremerkmals vergeben werden kann, • dass für mindestens vier Stufen des Verbindungsausfalls von jedem zugeordneten Device gesendete Anweisungen gespeichert werden können, • dass die Anzahl der TAN abhängig von einem verwendeten Maximalwert und einem Wert sein kann, welcher sich aus den Erfahrungswerten von mindestens zwei erfolgreich durchgeführten Transaktionen ergibt, • dass die TAN auf die je Device ermittelten Standorte und Portfolios aufgeteilt werden können, • dass mindestens auf einem Device TAN und damit verknüpfte Zusatzinformationen gespeichert werden können, • dass je Transaktionsart und Art der Werte eigene Zusatzinformationen mindestens einem Device gespeichert werden können, • dass von einem Device gesendete Zusatzinformationen für einzelne Transaktionen gespeichert werden können, • dass der Maximalwert gemäß Regeln der Zusatzinformationen und Schwankungen von einzelnen Werten sich ändern kann, • dass von mindestens einem Device je TAN eine Transaktion gemeldet werden kann, • dass eine für ein Device gemeldete Lastschrift bereits vor einer Plausibilitätsprüfung vom Maximalwert abgezogen werden kann, • dass eine von einem Device gesendete, zur Endprüfung markierte TAN verknüpft mit der eigenen Identifikationsnummer auf Übereinstimmung mit einer dem Device zur Verfügung gestellten TAN überprüft werden kann, • dass bei einer zur Endprüfung markierten TAN erwarteten Gegenleistung, diese von dem entsprechenden Rechenzentrum angefordert und erst nach der Bestätigung der Leistungserbringung die Plausibilitätsprüfung abgeschlossen werden kann, es sei denn, das Erbringen einer Gegenleistung wurde als gesondert bestätigt zu einer TAN eingetragen, • dass, wenn eine von einem Device gesendete TAN, Not-TAN oder Not2-TAN eine fremde Identifikationsnummer enthält, der zugehörige Heimat-Trust-Server aus einer Liste ermittelt werden können und bei diesem die Überprüfung der Plausibilität angefordert werden kann, • dass, wenn eine TAN als Not-TAN gekennzeichnet ist, für eine erfolgreiche Plausibilitätsprüfung die Reihenfolge der Zeitstempel der als Notfall genutzt markierten Not-TAN der Reihenfolge einer als genutzt gespeicherten gleichlautenden TAN des betreffenden Devices entsprechen muss, • dass, wenn eine TAN als Not2-TAN markiert ist, für eine erfolgreiche Plausibilitätsprüfung die Reihenfolge der Zeitstempel der als Notfall genutzt markierten Not2-TAN der Reihenfolge der als genutzt gespeicherten gleichlautenden TAN des betreffenden Devices entsprechen muss, • dass, wenn die Plausibilitätsprüfung nicht erfolgreich ist, eine Warnmeldung an die entsprechenden Devices gesendet werden kann und bis zur Überprüfbarkeit und Überprüfung der Transaktion, diese nicht weiterverarbeitet werden kann, • dass erst nach erfolgreicher Plausibilitätsprüfung die eigentliche Transaktion bei dem entsprechenden Rechenzentrum angestoßen werden kann, • dass ein Maximalwert um die für ein Device gemeldete Gutschrift erst nach Rückmeldung der erfolgreichen Durchführung der eigentlichen Transaktion erhöht werden kann, es sei denn, die erfolgreich erbrachte Gegenleistung wurde als vom Lastschriftempfänger gesondert bestätigt eingetragen und ein Abgleich mit einem Rechenzentrum kann entfallen. • dass die betroffenen Devices über die erfolgreiche Transaktion der Rechenzentren und den angepassten Maximalwert informiert werden und zur Markierung der TAN als genutzt aufgefordert werden,
- (Standort-Trust-Server) dadurch gekennzeichnet, • dass gesendet von mindestens einem Heimat-Trust-Server für mindestens ein Device mehr als eine TAN, sowie ein Maximalwert, ein Notfallwert, Anweisungen für mindestens eine Stufe des Verbindungsausfalls, Portfolios mit hinterlegtem Regelwerk und Informationen gespeichert und in Interaktion mit dem jeweiligen Device verwendet werden können, • dass für mindestens ein Device mindestens zwei TAN auf Basis mindestens eines individuell vergebenen symmetrischen Schlüssels und mindestens eines von dem Device übermittelten eindeutigen Hardwaremerkmals vergeben werden können, sobald die vom Heimat-Trust-Server zur Verfügung gestellten TAN verbraucht sind, • dass die Anzahl der TAN abhängig von einem verwendeten Maximalwert und einem Wert ist, welcher sich aus den Erfahrungswerten von mindestens zwei erfolgreich durchgeführten Transaktionen ergeben, • dass von einem Device gesendete Zusatzinformationen für einzelne Transaktionen gespeichert werden können, • dass von mindestens einem Device maximal eine Transaktion je TAN gemeldet werden kann, • dass eine für ein Device gemeldete Lastschrift bereits vor einer Plausibilitätsprüfung vom Maximalwert abgezogen werden kann, • dass die von einem Device gesendete TAN verknüpft mit der eigenen Identifikationsnummer auf Übereinstimmung mit einer dem Device zur Verfügung gestellten TAN überprüft werden kann, • dass erst nach erfolgreicher Plausibilitätsprüfung die eigentliche Transaktion bei dem entsprechenden Rechenzentrum angestoßen werden kann, sobald die Heimat-Trust-Server der die Transaktion betreffenden Devices wieder erreichbar sind, • dass ein Maximalwert um die für ein Device gemeldete Gutschrift erst nach Rückmeldung der erfolgreichen Durchführung der eigentlichen Transaktion erhöht werden kann, es sei denn, die erfolgreich erbrachte Gegenleistung wurde als vom Lastschriftempfänger gesondert bestätigt eingetragen und ein Abgleich mit einem Rechenzentrum kann entfallen. • dass die Funktion eines Heimat-Trust-Servers (
Anspruch 1 ) übernommen werden kann, • dass ein Maximalwert um die für ein Device gemeldete Gutschrift erst nach Rückmeldung der Durchführung der eigentlichen Transaktion erhöht werden kann, es sei denn, die erfolgreich erbrachte Gegenleistung wurde vom Lastschriftempfänger gesondert bestätigt und ein Abgleich mit dem Heimat-Trust-Server kann entfallen. - (Device) dadurch gekennzeichnet, • dass alle die Anforderungen dieses Verfahrens erfüllende Devices über verfügbare Netzwerke und Verbindungen miteinander Transaktionen abwickeln können, • dass ohne Internetverbindung mehr als ein Schlüssel vom Heimat-Trust-Server übertragen werden kann, auf dessen Basis Einzelschlüssel für eine eindeutige Authentifizierung und Identifikation und zum Schutz von Informationen generiert werden können, • dass ohne Internetverbindung eine eindeutige Identifikationsnummer eines eindeutig zugeordneten gleichbleibenden Heimat-Trust-Servers übertragen werden kann, • dass mit mindestens einem Devices eine Transaktion abgewickelt werden kann, wenn hierfür allen von einer Transaktion betroffenen Device eine eindeutige, nicht genutzte TAN, Not-TAN oder Not2-TAN zur Verfügung steht, • dass bei der Verwendung von Portfolios oder durch manuellen Eintrag jede Transaktionsart verwendet werden kann, • dass manuell ergänzte Zusatzinformationen für einzelne Transaktionen gesendet werden können, • dass für mindestens vier Stufen des Verbindungsstatus Anweisungen auf jedem zugeordneten Device gespeichert und ausgeführt werden können, • dass Zusatzinformationen abhängig davon gelten, ob ein Netzwerk zwischen beliebigen Teilnehmern oder ein Notnetzwerk zwischen Devices und mindestens einem Standort-Trust-Server oder ein Notnetzwerk zwischen mindestens drei Devices oder eine Direktverbindung zwischen zwei Devices zustande kommt, • dass durch Auswahl oder Eingabe und Mitteilung an einen Heimat-Trust-Server mehrere Standorte hinterlegt werden können oder bei einem autorisierten automatischen Positionsabruf gemäß Voreinstellung eine automatische globale Positionsbestimmung ergänzt oder ersetzt werden kann, • dass ein standardmäßig hinterlegter Notfallwert über die Anweisung des Heimat-Trust-Server verändert werden kann, • dass die eigenen eindeutigen Hardwaremerkmale auf dem Heimat-Trust-Server gespeichert werden können, einem Standort-Trust-Server jedoch bei fehlender Erreichbarkeit des Heimat-Trust-Servers zur Vergabe von TAN zur Verfügung gestellt werden müssen, • dass die Gültigkeit einer TAN über den Abgleich der eigenen eindeutigen Hardwaremerkmale und von einem Trust-Server (definiert durch
Anspruch 1 oder2 ) zur Verfügung gestelltem Schlüssel ermittelt werden können, • dass eine verwendete TAN zum Schutz vor einer erneuten Verwendung gekennzeichnet und als blockiert gespeichert werden können, • dass eine Transaktion zur Plausibilitätsprüfung an einen Trust-Server gemeldet werden kann und bei Rückmeldung einer erfolgreichen Prüfung die Markierung der TAN von blockiert zu in Endprüfung verändert werden kann, • dass, solange ein Trust-Server erreichbar ist, der von diesem übermittelte Guthabenwert für eine Lastschrift verwendet und um den Lastschriftbetrag einer Transaktion reduziert werden kann, • dass bei jeder Transaktion die Deckung über einen Guthabenwert oder Notfallwert gewährleistet sein muss, • dass der hinterlegte Notfallwert als Guthaben für Lastschriften in Transaktionen verwendet werden kann, wenn kein Trust-Server erreichbar ist, • dass ein Guthabenwert oder ein Notfallwert um den Lastschriftbetrag einer Transaktion reduziert werden kann, • dass ein Guthabenwert oder Notfallwert um die für ein Device gemeldete Gutschrift erhöht werden kann, wenn die erfolgreich erbrachte Gegenleistung vom Lastschriftempfänger gesondert bestätigt wurde oder eine Freigabe über den zugehörigen Heimat-Trust-Server gemeldet wurde, • dass Teil der Anforderungen für den Verbindungsausfall eine verbindlich festgelegte Reihenfolge ist, über verschiedene Verbindungswege, Protokolle und Verfahren ein Ad-hoc- oder Notnetzwerk aufzubauen, um einen Heimat-Trust-Server oder Standort-Trust-Server erreichen zu können und wenn das nicht gelingt, direkt mit anderen Devices eine Verbindung aufzubauen, • dass, wenn von einem Trust-Server gesendete, nicht benutzte TAN gespeichert sind, aber kein Trust-Server erreichbar ist, diese ohne Plausibilitätsprüfung verwendet werden können, • dass wenn kein Trust-Server erreichbar ist, eine als genutzt gespeicherte TAN mit einer Kennzeichnung als Not-TAN oder Not2-TAN erneut verwendet werden kann, • dass für die erneute Vergabe einer TAN als Not-TAN oder Not2-TAN zusätzlich zur Kennzeichnung die Einhaltung genau der zeitlichen Reihenfolge erwartet wird, in der die TAN von dem für die Vergabe zuständigen Trust-Server als genutzt gemeldet wurde, • dass, wenn ein Kontroll-Device definiert wurde, die für die Transaktion benötigten Informationen mit einem für den jeweiligen Heimat-Trust-Server lesbarem Schlüssel verschlüsselt, sowie Identifikationsnummer, Markierung als Not-TAN, der Betrag der Gutschrift oder Lastschrift, der Notfallwert und der Zeitstempel unverschlüsselten an ein Kontroll-Device gesendet werden, • dass eine Not-TAN erst nach Freigabe durch ein Kontroll-Device für eine Transaktion verwendet werden kann, • dass, wenn kein Trust-Server und kein an der Transaktion nicht beteiligtes, weiteres Devices erreichbar sind, jedes an einer Transaktion beteiligte Device TAN ohne die Kontrolle Dritter generieren kann und als Not2-TAN kennzeichnet, • dass erneut überprüft wird, ob keine Verbindung zu einem Trust-Server oder einem dritten Device aufgebaut werden kann und erst dann die Transaktion freigegeben werden kann. - (Kontroll-Device) dadurch gekennzeichnet, 1. dass jedes Device als Kontroll-Device ausgesucht werden kann, welches die Anforderungen gemäß
Anspruch 3 erfüllt, 2. dass für die Transaktion benötigten Informationen mit einem für den jeweiligen Heimat-Trust-Server lesbarem Schlüssel verschlüsselt, sowie Identifikationsnummer, Markierung als Not-TAN, der Betrag der Gutschrift oder Lastschrift, der Notfallwert und der Zeitstempel unverschlüsselten von den an der Transaktion beteiligten Devices erhalten werden können, 3. dass überprüft werden kann, ob der gesendete Notfallwert zur Deckung einer Lastschrift ausreicht, 4. dass die Richtigkeit des Zeitstempels mit einer definierten Toleranz mit der Eingangszeit der Transaktionsdatei überprüft werden kann, 5. dass erneut überprüft werden kann, ob keine Verbindung zu einem Trust-Server aufgebaut werden kann und erst dann die Plausibilitätsprüfung abgeschlossen und die Transaktion an die betreffenden Devices freigegeben werden kann, 6. dass, wenn kein Trust-Server erreichbar ist, aber an der Transaktion nicht beteiligte, weitere Devices erreichbar sind, über einen Zufallsgenerator bei mehreren erreichbaren Devices, je Transaktion ein Device als Kontroll-Device definiert werden kann, 7. dass die verschlüsselten und nicht verschlüsselten Informationen gespeichert und zu dem eigenen Heimat-Trust-Server später gesendet werden können, sobald hierzu eine Verbindung besteht.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102022000532.8A DE102022000532A1 (de) | 2022-02-02 | 2022-02-02 | Verfahren für anpassungsfähige, ausfallsichere Transaktionen von Wirtschaftsobjekten |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102022000532.8A DE102022000532A1 (de) | 2022-02-02 | 2022-02-02 | Verfahren für anpassungsfähige, ausfallsichere Transaktionen von Wirtschaftsobjekten |
Publications (1)
Publication Number | Publication Date |
---|---|
DE102022000532A1 true DE102022000532A1 (de) | 2023-08-03 |
Family
ID=87160419
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE102022000532.8A Withdrawn DE102022000532A1 (de) | 2022-02-02 | 2022-02-02 | Verfahren für anpassungsfähige, ausfallsichere Transaktionen von Wirtschaftsobjekten |
Country Status (1)
Country | Link |
---|---|
DE (1) | DE102022000532A1 (de) |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102017005550A1 (de) | 2017-06-13 | 2018-12-13 | Olaf Berberich | Verfahren für ein persönliches digitales System(PDS) |
-
2022
- 2022-02-02 DE DE102022000532.8A patent/DE102022000532A1/de not_active Withdrawn
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102017005550A1 (de) | 2017-06-13 | 2018-12-13 | Olaf Berberich | Verfahren für ein persönliches digitales System(PDS) |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69633308T2 (de) | Elektronisches Zahlungssystem mit billigem Schema zum Ermitteln von illegalen Handlungen | |
WO2020212337A1 (de) | Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten sowie bezahlsystem | |
EP4111348B1 (de) | Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit | |
WO2020212331A1 (de) | Gerät zum direkten übertragen von elektronischen münzdatensätzen an ein anderes gerät sowie bezahlsystem | |
AT512070B1 (de) | Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen | |
DE112011100182T5 (de) | Transaktionsprüfung für Datensicherheitsvorrichtungen | |
EP3743844B1 (de) | Blockchain-basiertes identitätssystem | |
WO2012174579A1 (de) | Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen | |
WO2023011759A1 (de) | Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit | |
DE102021002329A1 (de) | Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt | |
DE112009001207T5 (de) | Kenntnisverteilung | |
DE102022000532A1 (de) | Verfahren für anpassungsfähige, ausfallsichere Transaktionen von Wirtschaftsobjekten | |
EP2399218B1 (de) | Verfahren zur erzeugung eines identifikators | |
WO2022194658A1 (de) | Verfahren zur autorisierung eines ersten teilnehmers in einem kommunikationsnetz, verarbeitungseinrichtung, kraftfahrzeug und infrastruktureinrichtung | |
DE4427039A1 (de) | Verfahren zur Bestimmung des aktuellen Geldbetrages in einem Datenträger und System zur Durchführung des Verfahrens | |
EP4072180A1 (de) | Verfahren zur autorisierung eines ladevorgangs an einem ladepunkt | |
EP2696319B1 (de) | Verfahren zur Freigabe einer Transaktion | |
EP1306820B1 (de) | Signatur eines Dokuments | |
EP1415285A2 (de) | Verfahren zum bezug einer über ein datennetz angebotenen leistung | |
DE102004058020A1 (de) | Verfahren zur Personalisierung von Chipkarten | |
DE102016106055A1 (de) | Alternative Zahlungsmittel und Zahlungsverfahren | |
EP3312753B1 (de) | Physisches sicherheitselement zum zurücksetzen eines passworts | |
DE102016111858A1 (de) | DLMS-Server, DLMS-Client und Verfahren für die DLMS-Kommunikationssicherheit | |
DE102021130943A1 (de) | Konsensalgorithmus für distributed-ledger-technologie | |
DE102005001107A1 (de) | Verfahren und Vorrichtung zum gesicherten Aufbauen einer Zugangsverbindung zu einem Netz eines Internetservice-Providers |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |