AT521646A1

AT521646A1 - System zum Verarbeiten von Anfragen mobiler Geräte

Info

Publication number: AT521646A1
Application number: ATA50728/2018A
Authority: AT
Original assignee: Res Industrial Systems Engineering Rise Forschungs Entwicklungs Und Grossprojektberatung Gmbh
Priority date: 2018-08-24
Filing date: 2018-08-24
Publication date: 2020-03-15
Also published as: US20210248582A1; WO2020037344A1

Abstract

System (1; 21) zum Verarbeiten zumindest einer Anfrage zumindest eines mobilen Geräts (6; 17) mit zumindest einer ersten Verarbeitungseinrichtung (9; 18) und einer Endverarbeitungseinrichtung (4; 19) des Systems (1; 21), wobei das mobile Gerät (6; 17) zur Abarbeitung einer Anfrageapplikation ausgebildet ist, mit der durch eine Anfragekenninformation (7) gekennzeichnete Anfrageinformationen (8) und Statusinformationen über den Fortschritt der Abarbeitung der Anfrage zwischen dem mobilen Gerät (6; 17) und der ersten Verarbeitungseinrichtung (9; 18) kommuniziert werden und an einem Display (12) des mobilen Geräts (6; 17) anzeigbar sind und, wobei die erste Verarbeitungseinrichtung (9; 18) zur Vorverarbeitung der Anfrageinformationen (8) und zur Weiterleitung, direkt oder über weitere Verarbeitungseinrichtungen (13, 14), an die Endverarbeitungseinrichtung (4; 19) ausgebildet ist und, wobei die Endverarbeitungseinrichtung (4; 19) zum Speichern von einen Anwender des Systems (1; 21) und/oder dessen mobilen Gerät (6; 17) eindeutig identifizierende Identitätskenninformationen (5) ausgebildet ist, wobei eine Informationssammeleinrichtung (15; 22) vorgesehen ist die, um die aktuellen Statusinformationen jeder Anfrage jedes mobilen Geräts (6; 17) zu ermitteln, zum Zuordnen der von den Verarbeitungseinrichtungen (4, 9, 13, 14; 18, 19) oder von dem mobilen Gerät (6; 17) des Systems (1; 21) empfangenen Informationen zu den jeweiligen Anfragen der mobilen Geräte (6; 17) ausgebildet ist, wofür im Falle des Fehlens der für eine eindeutige Zuordnung notwendigen Anfragekenninformation (7) und/oder Identitätskenninformation (5) eine bestmögliche Zuordnung anhand der weiteren in der Anfrageinformation (8) enthaltenen Informationen durchgeführt wird und, dass die Informationssammeleinrichtung (15; 22) zur Übermittlung der ermittelten aktuellen Statusinformation der jeweiligen Anfrage an das jeweilige mobile Gerät (6; 17) ausgebildet ist.

Description

System zum Verarbeiten von Anfragen mobiler Geräte

Die Erfindung betrifft ein System zum Verarbeiten zumindest einer Anfrage zumindest eines mobilen Geräts mit zumindest einer ersten Verarbeitungseinrichtung und einer Endverarbeitungseinrichtung des Systems nach dem Oberbegriff des Anspruchs 1.

Dem Fachmann sind Systeme bekannt, bei denen Anfrageinformationen eines mobilen Geräts, wie beispielsweise eines Mobiltelefons, von einer oder mehreren Verarbeitungseinrichtungen verarbeitet werden, um letztendlich eine Antwortinformation an das Mobiltelefon zu senden. Die Verarbeitungseinrichtungen können zeitversetzt ihren Teil der Verarbeitung der Anfrage durchführen und Teilergebnisse beziehungsweise Teilantworten der jeweils nachfolgenden Verarbeitungseinrichtung als Eingabewert für deren Verarbeitung bereitstellen oder auch bereits an Vorgänger-Verarbeitungseinrichtungen oder das Mobiltelefon übermitteln. Der Status der Verarbeitung der Anfrage und die Antwort auf die Anfrage kann sich somit je nach Teilantwort verändern und es besteht ein großes Interesse in dem Mobiltelefon jeweils den aktuellen Status der Anfrage und/oder bereits eine möglichst richtige Antwort auf die Anfrage für den Benutzer des Mobiltelefons bereitzustellen.

So eine Anfrage kann sich beispielsweise darauf beziehen, ob der Benutzer des Mobiltelefons einen bestimmten Raum eines Gebäudekomplexes, also beispielsweise einen Reinraum eines Labors, mit bestimmten mitgeführten Materialien betreten und nutzen darf. Diese Anfrage muss beispielsweise durch verschiedene Verarbeitungseinrichtungen inhaltlich geprüft werden. So kann eine vorgelagerte Sicherheitseinrichtung die Anfrage auf Plausibilität und richtige Verschlüsselung prüfen, ein Gebäudeverwaltungsserver kann die Anfrage auf ihre Durchführbarkeit prüfen, da der Reinraum ja gerade zur Reinigung gesperrt oder durch einen anderen Benutzer gebucht sein könnte, und ein von der Außenwelt abgeschirmter Sicherheitsserver kann die Anfrage auf die Zutrittsberechtigung der anfragenden Person zu dem Reinraum und deren Sicherheitsfreigabestufe prüfen. Es ist vorteilhaft, wenn in dem Mobiltelefon der jeweils aktuelle Stand zu der Anfrage, also der Status und die voraussichtliche Antwort auf die Anfrage an einem Display des Mobiltelefons, angezeigt werden kann.

Bei bekannten Systemen hat sich jedoch als Nachteil erwiesen, dass Teilantworten von Verarbeitungseinrichtungen nicht immer den zugehörigen Anfragen der zugehörigen Mobiltelefone zugeordnet werden konnten, weshalb die am Display des Mobiltelefons angezeigten Informationen zu der Anfrage nicht aktuell oder gar falsch waren. Weiters gibt / 29

23666-AT es Anwendungsbeispiele im Stand der Technik, bei denen die Anfragen von dem Mobiltelefon über einen lokalen Datenübertragungskanal, wie eine Bluetooth oder RFIDFunkverbindung, an eine erste Verarbeitungseinrichtung gestellt werden. Sobald sich das Mobiltelefon aus der Empfangsreichweite des lokalen Datenübertragungskanals entfernt ist bei vielen solcher Systeme die Übermittlung von Antworten oder aktualisierten Statusinformationen von einer oder allen Verarbeitungseinrichtungen des Systems an das Mobiltelefon nicht mehr möglich, weshalb das Mobiltelefon keine aktuellen Informationen zu der Anfrage anzeigen kann.

Bei anderen bekannten Systemen hat sich als Nachteil erwiesen, dass die Zuordnung der Ergebnisse der einzelnen Verarbeitungseinrichtungen, also die Zuordnung der Teilantworten auf die Anfrage, zu der Anfrage und dem anfragenden mobilen Gerät nicht immer möglich waren. Durch die fehlende Zuordnung konnte die Teilantwort zur Ermittlung der finalen Antwort auf die Anfrage nicht mitberücksichtigt werden, was zu fehlerhaften Antworten oder falschen Statusinformationen geführt hat.

Es ist die Aufgabe der vorliegenden Erfindung ein System zu schaffen, um mit dem mobilen Gerät bestmögliche und aktuelle Informationen über den Status und die Antwort auf die Anfrage anzeigen zu können.

Erfindungsgemäß wird die vorliegende Aufgabe durch ein System mit einer Informationssammeleinrichtung mit den Merkmalen des kennzeichnenden Teils des Anspruchs 1 und ein Verfahren gemäß dem Anspruch 7 gelöst. Bevorzugte Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.

Die Verarbeitungseinrichtungen des erfindungsgemäßen Systems, also die erste Verarbeitungseinrichtung, gegebenenfalls weitere Verarbeitungseinrichtungen und die Endverarbeitungseinrichtung, übermitteln die Ergebnisse ihrer Verarbeitung als Teilantworten direkt oder indirekt an die Informationssammeleinrichtung, die die Teilantworten den unterschiedlichen Anfragen der mobilen Geräte im System zuordnet. Da jede neue Anfrage durch eine Anfragekenninformation gekennzeichnet ist und jeder Anwender des Systems und/oder dessen mobilen Gerät durch eine Identitätskenninformation gekennzeichnet ist, kann zumindest eine dieser Kenninformationen oder können beide dieser Kenninformationen von der Informationssammeleinrichtung zum sicheren Zuordnen der von den Verarbeitungseinrichtungen empfangenen Informationen beziehungsweise Teilantworten verwendet werden, wenn diese Kenninformationen im Rahmen der der Teilantwort mitgesendet werden. Nach der Zuordnung der Teilantwort zu der Anfrage des / 29

23666-AT mobilen Geräts aktualisiert die Informationssammeleinrichtung den Status der Verarbeitung der Anfrage und/oder die voraussichtliche oder endgültige Antwort auf die Anfrage. Die so aktualisierte Statusinformation und die voraussichtliche oder endgültige Antwort werden dann von der Informationssammeleinrichtung an das mobile Gerät übermittelt, wodurch sich der Benutzer des mobilen Geräts jederzeit aktuelle Informationen zu seiner Anfrage am Display des mobilen Geräts anzeigen lassen kann.

Die erfindungsgemäße Informationssammeleinrichtung ist nunmehr dazu ausgebildet im Falle des Fehlens der für eine eindeutige Zuordnung der Teilantwort notwendigen Kenninformationen eine bestmögliche Zuordnung anhand der weiteren in der Anfrageinformation und der Teilantwort enthaltenen Informationen durchzuführen. Kenninformationen können aus den unterschiedlichsten Gründen, je nach Anwendungsfall, in der Teilantwort fehlen. Beispielsweise kann ein Übertragungsfehler in der Information von der Verarbeitungseinrichtung zur Informationssammeleinrichtung dazu führen, oder die Kenninformationen können aus Datenschutzgründen nicht mitverarbeitet und übermittelt werden. Auch wäre es möglich, dass einzelne Verarbeitungseinrichtungen nicht zur Verarbeitung der Kenninformationen ausgebildet sind, da beispielsweise die veraltete Anwendungsapplikation des Gebäudeverwaltungsservers diese Kenninformationen nicht verarbeiten kann. Vorteilhafterweise wird durch die erfindungsgemäße auf allen vorliegenden Informationen basierende bestmögliche Zuordnung von Teilantworten zu Anfragen mobiler Geräte eine deutliche Verbesserung der Qualität und Zuverlässigkeit der mit dem mobilen Gerät anzeigbaren Statusinformation und Antwortinformation ermöglicht.

Der durch die technischen Maßnahmen der erfindungsgemäßen Informationssammeleinrichtung erzielte technische Effekt ist je nach Ausführungsbeispiel eine höhere Zuverlässigkeit beziehungsweise Qualität der Statusinformation und der Antwort auf die Anfrage durch das mobile Gerät. Hierauf wird anhand der in den Figuren und der Figurenbeschreibung angegebenen Ausführungsbeispiele noch detaillierter eingegangen.

Figur 1 zeigt ein Zutrittskontrollsystem für ein Labor gemäß einem ersten Ausführungsbeispiel der Erfindung.

Figur 2 zeigt ein weiteres Ausführungsbeispiel der Erfindung, bei dem mit einem mobilen Endgerät an einem Kassen-Terminal eine Ware gemäß dem europäischen Bezahlsystem EMV bezahlt werden kann.

Figur 3 zeigt ein Flussdiagramm zur eindeutigen Zuordnung von Events aus einer beispielhaften Verarbeitungseinrichtung (Issuer-Events) in dem System gemäß Figur 2.

/ 29

23666-AT

Figur 4 zeigt ein Flussdiagramm zu dem Standard-Matching in dem System gemäß Figur 2. Figur 5 zeigt ein Flussdiagramm zu dem Best-Effort-Matching in dem System gemäß Figur 2, für den Fall, dass das Standard-Matching kein Ergebnis liefert.

Figur 1 zeigt Zutrittskontrollsystem 1 für ein Forschungsinstitut 2 für gefährliche Viren höchster Sicherheitsstufe mit einem spezialisierten Laborraum 3 und anderen unterschiedlichen Räumen gemäß einem ersten Ausführungsbeispiel der Erfindung. Das Zutrittskontrollsystem 1 ermöglicht Anwendern des Zutrittskontrollsystems 1 den spezialisierten Laborraum 3 und andere spezialisierte Räume für bestimmte Versuche zu buchen und zu betreten. Für jeden Anwender des Zutrittskontrollsystems 1 sind in einem abgesicherten dezentralen Kennserver 4, der eine Endverarbeitungseinrichtung bildet, Identitätskenninformationen 5 gespeichert, die den Anwender durch seinen Namen, seine Passnummer und seinen Fingerabdruck identifiziert. Der Anwender kann sich in dem Zutrittskontrollsystem 1 mit seinem mobilen Gerät, also beispielsweise seinem Mobiltelefon 6 identifizierenden, weshalb in dem Kennserver 4 als Identitätskenninformation 5 weiters eine eindeutige Seriennummer eines im Mobiltelefon 6 vorhandenen Secure Elements gespeichert ist.

Das Mobiltelefon 6 ist zur Abarbeitung einer Anfrageapplikation ausgebildet, mit der durch eine Anfragekenninformation 7 gekennzeichnete Anfrageinformationen 8 an einem RFIDReader 9 im Empfangsbereich des Forschungsinstituts 2 abgegeben werden können. Der RFID-Reader 9 bildet hierbei eine erste Verarbeitungseinrichtung und kann durch einen handelsüblichen kontaktlosen Reader gebildet sein, der beispielsweise gemäß dem NFCStandard mit dem Mobiltelefon 6 kommuniziert. Das Mobiltelefon 6 muss zum Abgeben der Anfrage, ob der Laborraum 3 gebucht und die Zutrittsberechtigung erteilt werden kann, in die unmittelbare Nähe des RFID-Readers 9 gehalten werden.

Als Anfrageinformation 8 könnte beispielsweise die Anfrage übermittelt werden, ob Herr Franz Müller am 20. August 2018 von 13h bis 19h den Laborraum 3 zur Analyse von in einem Spezialkoffer mitgebrachten Pockenviren benutzen kann. Diese manuell von Herrn Müller mit dem Mobiltelefon 6 eingegebenen Anfrageinformationen 8 werden von dem Mobiltelefon 6 gemeinsam mit der Identitätskenninformation 5 des Mobiltelefons 6 übermittelt. Der RFID-Reader 9 prüft bei einer Vorverarbeitung der Anfrage, ob die übermittelte Anfrageinformation 8 und Identitätskenninformation 5 eine plausible Datenstruktur aufweisen und gemäß der für solche Anfragen vorgesehenen Verschlüsselung übermittelt wurden. Wenn dies der Fall ist, dann sendet der RFID-Reader 9 als Bestätigung / 29

23666-AT die im Zutrittskontrollsystem 1 eindeutige Anfragekenninformation 7 für die Anfrage an das Mobiltelefon 6 zurück, wobei die Anfragekenninformation 7 durch eine laufende Nummer für jede Anfrage des Mobiltelefons 6 in dem Zutrittskontrollsystem 1 verknüpft mit der Identitätskenninformation 5 gebildet sein kann. Weiters übermittelt der RFID-Reader 9 eine Statusinformation 11, die an einem Display 12 des Mobiltelefons 6 angezeigt werden kann, dass die Anfrage zur weiteren Verarbeitung angenommen wurde. Nachdem Herr Müller diese Statusinformation 11 erhalten hat kann er das Forschungsinstitut 2 verlassen, da die Abarbeitung seiner Anfrage einige Minuten, aber auch Stunden dauern kann, zum Beispiel weil eine manuelle Freigabe durch das Aufsichtspersonal notwendig ist.

Das Zutrittskontrollsystem 1 weist weiters einen Gebäudeverwaltungsserver 13 auf, der eine zweite Verarbeitungseinrichtung bildet und in dem zu jedem Raum des Forschungsinstituts 2 Informationen gespeichert sind. Einerseits wird zu jedem Raum gespeichert von wann bis wann er von wem gebucht wurde, aber es werden auch in dem Raum vorhandene Einrichtungen und für den Raum geltende Einschränkungen, welche Personengruppe welcher Sicherheitsstufe den Raum nutzen darf, gespeichert. In dem Gebäudeverwaltungsserver 13 wird die Anfrage von Herrn Müller geprüft und festgestellt, dass der Laborraum 3 zu dem gewünschten Zeitpunkt verwendbar ist.

Das Zutrittskontrollsystem 1 weist weiters einen Gefährdungsserver 14 auf, der eine dritte Verarbeitungseinrichtung bildet und prüft, ob die in der Anfrageinformation 8 angegebenen Pockenviren in das Forschungsinstitut 2 gebracht werden dürfen und, ob der Laborraum 3 für Versuche mit den Pockenviren freigegeben ist.

In dem abgesicherten dezentralen Kennserver 4 wird weiters geprüft, ob die Identitätskenninformation 5 von dem Mobiltelefon 6 des Herrn Müller gespeichert ist und, ob Herr Müller der Sicherheitsstufe zugeordnet ist, die mit Pockenviren forschen darf.

Das Zutrittskontrollsystem 1 weist nunmehr einen eine Informationssammeleinrichtung bildenden Antwortserver 15 auf der, um die aktuellen Statusinformationen jeder Anfrage jedes Mobiltelefons 6 zu ermitteln, zum Zuordnen der von dem RFID-Reader 9, dem Gebäudeverwaltungsserver 13, dem Gefährdungsserver 14 und dem Kennserver 4 oder von dem Mobiltelefon 6 des Zutrittskontrollsystems 1 empfangenen Informationen zu den jeweiligen Anfragen der Mobiltelefone 6 ausgebildet ist. Hierfür prüft der Antwortserver 15 die von den Verarbeitungseinrichtungen empfangenen Informationen dahingehend, ob diese in einem Teilbereich durch die Identitätskenninformation 5 eines Mobiltelefons 6 und/oder durch eine bekannte Anfragekenninformation 7 des Zutrittskontrollsystems 1 gekennzeichnet / 29

23666-AT ist. Wenn ja, dann ist eine eindeutige Zuordnung der von der jeweiligen Verarbeitungseinrichtung empfangenen Information zu einer konkreten Anfrage eines Mobiltelefons 6 möglich. Die einer bestimmten Anfrage zugeordnete Information kann somit zur Änderung der Statusinformation der Anfrage und zur Konkretisierung der Antwort verwendet werden. Wenn also beispielsweise die Prüfung des Gefährdungsservers 14 ergibt, dass Pockenviren in dem Forschungsinstitut 2 nicht verwendet werden dürfen, dann kann eine Statusinformation 10 „Anfragebearbeitung abgeschlossen“ und eine Antwortinformation 16 für Herrn Müller als „Zutritt abgelehnt, aufgrund nicht zugelassener Materialien“ erzeugt werden. Diese Statusinformation 10 und Antwortinformation 16 kann von dem Antwortserver 15 über das normale Telefonnetz oder das Internet NET als Daten an die Anfrageapplikation des Mobiltelefons 6 übermittelt und dort gespeichert werden. Hierdurch ist der Vorteil erhalten, dass Herr Müller unmittelbar nach Abschluss der Prüfung seiner Anfrage die aktuelle Statusinformation 10 und Antwortinformation 16 auf dem Display 12 des Mobiltelefons 6 angezeigt erhält.

Der Gebäudeverwaltungsserver 13 ist nunmehr so aufgebaut, dass er auf Anfragen bezüglich bestimmter Räume zwar mit einer Information antwortet, ob beispielsweise der Laborraum 3 zu der gewünschten Zeit verfügbar und buchbar ist, diese Information enthält aber keinen Teilbereich mit einer Identitätskenninformation 5 und/oder einer Anfragekenninformation 7, weshalb eine unmittelbare und eindeutige Zuordnung der vom Antwortserver 15 empfangenen Information zu einer Anfrage bei dem Zutrittskontrollsystem 1 nicht möglich ist. Zur Lösung dieses technischen Problems ist der Antwortserver 15 dazu ausgebildet eine bestmögliche Zuordnung anhand der weiteren in der Anfrageinformation 8 enthaltenen Informationen durchzuführen. Gemäß dem vorstehenden Beispiel enthält die Anfrageinformation 8 von Herrn Müller die Anfrage, ob der Laborraum 3 am 20. August 2018 von 13h bis 19h gebucht werden kann, wobei die von dem Gebäudeverwaltungsserver 13 an den Antwortserver 15 übermittelte Information nur die Information „Laborraum 3 wurde am 20. August 2018 von 13h bis 19h für Sie gebucht“ enthält. Da keine andere im Zutrittskontrollsystem 1 gerade bearbeitete oder noch gültige Anfrage sich auf den Laborraum 3 für die Zeit von 13h bis 19h am 20. August 2018 bezieht, kann der Antwortserver 15 mit großer Wahrscheinlichkeit davon ausgehen, dass die erfolgte Buchung für die Anfrage von Herrn Müller gilt und kann somit die Statusinformation und voraussichtliche Antwort auf die Anfrage im Antwortserver 15 aktualisieren. Hierdurch ist der Vorteil erhalten, dass eine besonders hohe Zuverlässigkeit des Zutrittskontrollsystems 1 gegeben ist auch, wenn einzelne der Verarbeitungseinrichtungen des Zutrittskontrollsystems 1 nur mangelhafte Informationen liefern. Es kann folglich sichergestellt werden, dass nur für / 29

23666-AT den Zutritt berechtigte Personen in die jeweiligen Räume eingelassen werden und auch umgehend über ihre Zutrittsberechtigung informiert werden.

Der Antwortserver 15 ist weiters dazu ausgebildet zeitversetzt und parallel von den Verarbeitungseinrichtungen 4, 9, 13 und 14 oder über das Mobiltelefon 6 empfangene Informationen kontinuierlich zu verarbeiten, um die ermittelte aktuelle Statusinformation 10 und Antwortinformation 16 dem tatsächlichen Verarbeitungsstand der Verarbeitung der Anfrageinformationen 8 in den Verarbeitungseinrichtungen 4, 9, 13 und 14 aktuell zu halten. Dies ist insbesondere deshalb von Vorteil, weil die einzelnen Verarbeitungseinrichtungen 4, 9, 13 und 14 unterschiedlich schnell und teilweise abhängig von einander Teilantworten liefern, weshalb nur eine kontinuierliche Verarbeitung der empfangenen Informationen durch den Antwortserver 15 größtmögliche Aktualität der Statusinformation 10 und Antwortinformation 16 sicherstellt.

Der Antwortserver 15 ist weiters dazu ausgebildet die von dem RFID-Reader 9 als Informationsquelle nacheinander zu einer Anfrage erhaltenen Informationen gemeinsam zu verarbeiten, um daraus Rückschlüsse für die aktuelle Statusinformation 10 und Antwortinformation 16 zu ermitteln.

Der Antwortserver 15 ist weiters dazu ausgebildet die von den unterschiedlichen Verarbeitungseinrichtungen 4, 9, 13 und 14 und dem Mobiltelefon 6, als jeweils unterschiedliche weitere Informationsquellen, erhaltenen Informationen quellintern zu verarbeiten. Der Antwortserver 15 ist weiters dazu ausgebildet, die Informationen der quellinternen Verarbeitung für die quellenübergreifende Aktualisierung des Anfragestatus zu verarbeiten. Durch diese Arbeitsweise ist sichergestellt, dass aktuelle Statusinformationen 10 und aktuelle Antwortinformationen 16 mit größter Zuverlässigkeit ermittelt werden können.

Figur 2 zeigt ein weiteres Ausführungsbeispiel der Erfindung, bei dem mit einem mobilen Endgerät 17 an einem Kassen- oder POS-Terminal 18 eine Ware gemäß dem europäischen Bezahlsystem EMV bezahlt werden kann. EMV bezeichnet einen Standard für Bezahlkarten mit Chiptechnik und den zugehörigen Chipkartengeräten (z.B. POS NFC Terminals oder Bankomaten). Aus Endkundensicht durchläuft eine herkömmliche EMV-Transaktion mit einer physischen Bezahlkarte (z.B. Bankomatkarte in Österreich) folgende Phasen:

• EMV-Start: Der Kunde steht an dem Kassen-Terminal 18 und startet eine EMVTransaktion mit dem Kassen-Terminal 18, um ein Produkt zu kaufen. Dazu werden / 29

23666-AT

Daten zwischen der Bezahlkarte beziehungsweise dem die Funktion der Bezahlkarte simulierenden mobilen Endgerät 17 und dem Kassen-Terminal 18 ausgetauscht.

• Autorisierung: Das Kassa-Terminal 18 entscheidet, gegebenenfalls unter zur Hilfenahme eines Issuers 19 und der Bank des Kunden (wo das Konto hinterlegt ist), ob die Transaktionen autorisiert wird (z.B. durch technische Prüfung der Echtheit der Karte und Prüfung der Kontodeckung). Nach erfolgter Prüfung wird die Transaktion am Kassen-Terminal 18 mit dem Prüfungsergebnis angezeigt. Aus Kundensicht ist die Transaktion an der Stelle durchgeführt worden, und eine Erfolgsmeldung wird angezeigt.

• Presentment oder Transaktions-Einreichung: In Folge wird die Transaktion von nachgelagerten Händlersystemen weiterverarbeitet. Mit dem Presentment wird der tatsächlich bezahlte Transaktions-Betrag vom Bank-Konto des Kunden eingezogen. Die Transaktion ist an der Stelle abgeschlossen.

• Reversal oder Stornierung: Wenn nach erfolgreicher Autorisierung, aber vor dem Presentment, ein Abbruch erfolgt, dann wird ein Reversal an den Issuer 19 geschickt, um den zuvor reservierten Betrag wieder freizugeben. Die Transaktion ist an der Stelle abgeschlossen.

Daraus ergeben sich folgende Zustände einer EMV-Transaktion:

• Gestartet: Der Kunde hat die EMV Transaktion am Kassen-Terminal 18 gestartet.

• Autorisiert: Die Autorisierung wurde vom Issuer 19 bestätigt.

• Abgelehnt: Die Autorisierung wurde vom Issuer 19 abgelehnt (z.B. wegen ungenügender Kontodeckung, Kartensperre).

• Gebucht: Das Presentment wurde vom Issuer 19 verarbeitet.

• Storniert: Das Reversal wurde vom Issuer 19 verarbeitet.

Die Statusübergänge zwischen den Phasen werden durch Nachrichten hervorgerufen, die das Kassen-Terminal 18 über ein Bezahl-Netzwerk 20 an den Issuer 19 sendet. Diese Nachrichten bezeichnet man in der Technik als Transaktions-Events, welche einen Statusübergang der Gesamttransaktion veranlassen und somit die gesicherten Informationen der Gesamttransaktion beim Issuer 19 aktualisieren.

Bei kontaktlosen NFC-basierten EMV-Bezahlvorgängen am Kassen-Terminal 18 über das mobile Endgerät 17 (z.B. Smartphone, Smart Watch) werden der am mobilen Endgerät 17 installierten Bezahlapplikation vom Kassen-Terminal 18 Transaktionsinformationen über die gerade durchgeführte Transaktion mitgeteilt (mittels „EMV-Event“). Diese Information wird zugestellt, sobald die Kommunikation zwischen Kassen-Terminal 18 und mobilem Endgerät 17 abgeschlossen ist - aber bevor noch gesichert ist, dass die Transaktion auch wirklich erfolgreich durchgelaufen ist. Weitere Informationen wie z.B. Transaktionszustand, / 29

23666-AT tatsächlich verbuchter Betrag (z.B. bei Transaktionen in Fremdwährung), bleiben dem Endkunden daher in der Bezahlapplikation zu dieser Zeit noch verborgen. Diese werden erst im Nachgang durch den Issuer 19 selbst ermittelt und an den Kunden bereitgestellt.

Das System 21 gemäß Figur 2 zur Abwicklung der Transaktion weist nunmehr eine Informationssammeleinrichtung 22 auf, um die Transaktionsinformationen der EMVInformation mit Daten aus externen Daten-Quellen zu verknüpfen und, um dem Endkunden eine vollumfassende Darstellung der Transaktionsinformation am mobilen Endgerät 17 zu ermöglichen. Als externe Quelle kann hier beispielsweise der Issuer 19 angebunden werden, welcher gesicherte Informationen über den Status einer Transaktion als „Issuer-Event“ weiterleitet. Der Issuer 19 bildet eine Endverarbeitungseinrichtung, der beispielsweise die endgültige Währungsumrechnung einer Fremdwährungszahlung durchführt. Ein vom mobilen Endgerät 17 bezahlter Betrag von 20$ wird beim Issuer 19 in den tatsächlich vom Euro-Konto der Bank abzubuchenden Betrag von 17,45€ gemäß dem Tageskurs umgerechnet. Die Informationssammeleinrichtung 22 erhält diese Information des abzubuchenden Betrags von dem Issuer 19 und stellt sie dem mobilen Endgerät 17 zur Anzeige zur Verfügung.

Eine triviale Verknüpfung der Daten ist jedoch aufgrund der unterschiedlichen Informationen aus den verschiedenen Quellen eines bestehenden EMV-Ökosystems nicht immer möglich. Es kann des Weiteren aufgrund technischer Faktoren nicht sichergestellt werden, dass alle Statusübergänge als „Issuer-Event“ für eine Transaktion überhaupt oder in der richtigen Reihenfolge übermittelt werden.

Folgende für die Verknüpfung relevante Transaktionsinformationen sind im bestehenden EMV-Ökosystem vorhanden:

Quelle: EMV-Event:

• EMV_CARD_NR: Eine pro Issuer 19 eindeutige Identifikationsnummer einer Bezahlkarte beziehungsweise eines Secure Elements des mobilen Endgeräts 17 und bildet eine Identitätskenninformation.

• EMV_ATC: Eine pro Transaktion (in Kombination mit der EMV CARD NR) eindeutige Identifikationsnummer und bildet gemeinsam mit der EMV_CARD_NR eine Anfragekenninformation.

• EMV_DATE_TIME: Transaktionsdatum am Ort der Transaktionsdurchführung und bildet einen Teil der Anfrageinformation.

/ 29

23666-AT • EMV_BETRAG: Der zwischen Kassen-Terminal 18 und Karte beziehungsweise mobilem Endgerät 17 ausgetauschte Zahlungsbetrag bildet einen Teil der Anfrageinformation.

• EMV_WÄHRUNG: Die Währung des zwischen Kassen-Terminal 18 und Karte beziehungsweise mobilem Endgerät 17 ausgetauschten Zahlungsbetrags und bildet einen Teil der Anfrageinformation.

Über den Issuer 19 werden folgende gesicherte Informationen bereitgestellt:

Quelle: Issuer-Event • I_CARD_NR: Eine pro Issuer 19 eindeutige Identifikationsnummer einer Bezahlkarte beziehungsweise eines Secure Elements des mobilen Endgeräts 17 und bildet eine Identitätskenninformation.

• I_ATC: Eine pro Transaktion (in Kombination mit I_CARD_NR) eindeutige Identifikationsnummer und bildet gemeinsam mit der I_CARD_NR eine Anfragekenninformation. Diese Information ist optional und es kann nicht gewährleistet werden, dass diese vorhanden oder korrekt ist.

• I_EVENT_TYPE: Typ des Issuer-Events (Autorisierung, Reversal, Presentment) und bildet einen Teil der Anfrageinformation.

• I_EVENT_ID: Eindeutige Identifikationsnummer pro Event_Type und bildet einen Teil der Anfragekenninformation.

• I_REFERENZ_ID: Verweis von Presentment auf Autorisierungs Event-Id und bildet einen Teil der Anfragekenninformation. Ist nur dann für ein Presentment vorhanden, wenn die zugehörige Autorisierung online (d.h. über den Issuer) erfolgt ist.

• I_BERTAG_AUTORISIERT: Autorisierter Betrag in Originalwährung, d.h. in der Landeswährung des Terminals vor jeglicher Kursumrechnung und bildet einen Teil der Anfrageinformation. Nur bei Autorisierung vorhanden.

• I_WÄHRUNG_AUTORISIERT: Die Währung des autorisierten Betrags und bildet einen Teil der Anfrageinformation. Nur bei Autorisierung vorhanden.

• I_BETRAG_VERRECHNET: Verrechneter Betrag in Originalwährung, d.h. in der Landeswährung des Terminals vor jeglicher Kursumrechnung und bildet einen Teil der Anfrageinformation. Nur bei Presentment und Reversal vorhanden.

• I_ WÄHRUNG_VERRECHNET: Die Währung des verrechneten Betrags und bildet einen Teil der Anfrageinformation. Nur bei Presentment und Reversal vorhanden.

• I_DATE_TIME: Transaktionsdatum und lokale Zeit am Ort der Transaktionsdurchführung und bildet einen Teil der Anfrageinformation.

Transaktions-Matching-Algorithmus:

/ 29

666-AT

Um die Transaktionsdaten aus unterschiedlichen Quellen (Events) zu einem Gesamttransaktionsdatensatz in der Informationssammeleinrichtung 22 zusammenzuführen und somit eine Verknüpfung der Transaktionsdaten zu ermöglichen, müssen die Events miteinander verglichen und zueinander verbunden („gematcht“) werden. Dabei gilt es zum einen ein quelleinternes Matching zu definieren (verknüpfen und zusammenführen von Events aus einer Quelle) und zum anderen ein quellenübergreifende Matching festzulegen (Verknüpfen und Zusammenführen von Events aus verschiedenen Quellen), um die gewünschte Verknüpfung zu erziehen. Die nachstehend beschriebene technische Realisierung dieses Matchings in der Informationssammeleinrichtung 22 ermöglicht eine fehlertolerante Verknüpfung von externen und internen Transaktionsdaten für eine vollumfassende Darstellung der Transaktionsinformation. Quellenintemes Matching wird im Folgenden für Issuer-Events definiert und quellenübergreifendes Matching für die Verknüpfung von EMV-Events mit Issuer-Events.

Verknüpfung von Issuer-Events untereinander:

Im System 21 ist nicht sichergestellt, dass weitergeleitete Issuer-Events vollständig und chronologisch zugestellt werden. Das heißt es ist beispielsweise möglich, dass ein Presentment-Event vor einem Autorisierungs-Event zugestellt wird, oder ein AutorisierungsEvent gar nicht erst zugestellt wird (z.B., wenn die Autorisierung offline abgewickelt wird). Weiters enthalten verschiedene Issuer-Event Typen unterschiedliche Informationen. Es ist daher notwendig Issuer-Events, die zu einer Gesamttransaktion beziehungsweise zu einer Anfrage gehören, geeignet in der Informationssammeleinrichtung 22 zusammenzuführen.

Issuer-Events können mit Hilfe der Folgenden technischen Abfragen zusammengeführt und eindeutig zugeordnet werden:

• Autorisierung können mit Presentments eindeutig über IREFERENZID = IEVENTID der Autorisierung verknüpft werden.

• Autorisierung können mit Reversals eindeutig über I REFERENZ ID =

I EVENT ID der Autorisierung verknüpft werden.

Figur 3 zeigt ein Flussdiagramm 23 zur eindeutigen Zuordnung, das in folgender Table 1 näher erläutert ist.

Table 1: Schritte des Issuer-Event Matchings

Schritt	Beschreibung
1.	I EVENT ID prüfen Gibt es bereits ein Issuer-Event h für das gilt:

12/29

23666-AT

	• I EVENT ID = Ii.I EVENT ID
2.	Event verwerfen: Das Event ist dem System 21 bereits bekannt und kann verworfen werden.
3.	Matching über I_EVENT_ID Suche in allen Issuer-Events vom Typ Presentment oder Reversal (PR), nach solchen, für die gilt: • IEVENTID = PR.IREFERENZID
4.	Matching über I_REFERENZ_ID Suche in allen Issuer-Events vom Typ Autorisierung (A), nach solchen, für die gilt: • IREFERENZID = A.IEVENTID
5.	Verknüpfung erstellen Es handelt sich nicht um das erste Issuer-Event dieser Gesamt-Transaktion. Verknüpfe die Issuer-Events und führe die Daten zusammen. Fahre dann mit dem Standard-Matching (siehe Table 2) fort.
6.	Event persistieren Es handelt sich um das erste Issuer-Event für die Gesamt-Transaktion. Speichere das Event und fahre dann mit dem Standard-Matching fort.

Verknüpfung von EMV-Event und Issuer-Event:

Im Folgenden ist das mehrstufige Matching zwischen EMV-Event und Issuer-Event erläutert, wobei vorerst bei einem Standard-Matching versucht wird eine eindeutige Zuordnung und, wenn dies nicht möglich ist, bei einem Best-Effort-Matching eine bestmögliche Zuordnung der von dem Kassen-Terminal 18 oder dem Issuer 19 oder von dem mobilen Endgerät 17 in der Informationssammeleinrichtung 22 empfangenen Informationen zu den jeweiligen Transaktionen der mobilen Endgeräte 17 im System 21 zu ermöglichen.

Standard-Matching:

Das Standard-Matching stellt den Normalfall des Matchings dar. In diesem Fall ist eine 1:1 Zuordnung der beiden Events durch Zuordnung der jeweiligen IDs möglich. EMVTransaktion können mit Autorisierungen eindeutig über • EMVCARDNR = I CARD NR und • EMV_ATC = IATC / 29

666-AT gematcht werden, sofern der I ATC vorhanden ist. Wird auf diesem Weg ein Match gefunden so gilt dieses als verlässlich. Eventuell bestehende Verknüpfungen des Events, die durch ein vorangehendes Event über das Best-Effort-Matching (siehe Table 3) erstellt wurden, können als fehlerhaft angesehen und korrigiert werden.

Figur 4 zeigt ein Flussdiagramm 24 zu dem Standard-Matching in Form eines SequenzDiagramms in UML-Notation. Eine Beschreibung des Algorithmus ist in folgender Tabelle 2 zu finden.

Table 2: Schritte des Standard-Matchings

Schritt	Beschreibung
1.	I_ATC prüfen Ist das Feld I ATC gesetzt und existiert ein EMV-Event, für das gilt: • EMVCARD NR = I CARD NR und • RMN_ATC = IATC
2.	Verknüpfung vorhanden Prüfen ob das gefundene EMV-Event bereits mit einem Issuer-Event verknüpft ist.
3.	Verknüpfung korrigieren Die bestehende Verknüpfung des gefundenen EMV-Events wurde durch Best-Effort-Matching erstellt und ist fehlerhaft. Das Standard-Matching hat ein verlässliches Match gefunden, wodurch die Verknüpfung korrigiert werden kann. Das gefundene EMV-Event wird mit dem neuen Issuer-Event verknüpft.
4.	Verknüpfung erstellen Verknüpfe das ausgewählte EMV-Event mit dem Issuer-Event
5.	Best-Effort-Matching Standard-Matching kann nicht durchgeführt werden. Starte Best-Effort- Matching

Best-Effort-Matching:

Die erfindungsgemäße Informationssammeleinrichtung 22 ist nunmehr dazu ausgebildet, sollte es durch Standard-Matching nicht möglich sein, ein EMV-Event zu einem Issuer

14/29

23666-AT

Event eindeutig zuzuordnen, ein tolerantes Best-Effort-Matching zur bestmöglichen Zuordnung durchzuführen. Bei diesem werden bei mehreren technischen Abfragen gemäß einem Flussdiagramm 25 in Figur 5 die folgenden Felder verglichen:

• EMVCARDNR = ICARDNR und • EMVDATETIME = IDATETIME und • EMVBETRAG = I BERTAG AUTORISIERT (bei Autorisierungen) bzw. IBETRAG-VERRECHNET (bei Presentments, Reversals) und • EMV WÄHRUNG = I_WÄHRUNG_AUTORISIERT(bei Autorisierungen) bzw.

I WÄHRUNG VERRECHNET' (bei Presentments, Reversals)

Die vorstehenden die beim Best-Effort-Matching verglichenen Informationen sind weitere in der Anfrageinformation enthaltene und/oder im Zuge der Verarbeitung der Anfrageinformation zu dieser Transaktion erzeugte Informationen, die eine Zuordnung eines EMV-Events zu einem Issuer-Event mit großer beziehungsweise größtmöglicher Wahrscheinlichkeit ermöglichen. Da entsprechende Daten beziehungsweise Informationen nicht immer verlässlich übermittelt werden, können fehlerhafte Verknüpfungen zustande kommen. Diese werden jedoch im Zuge des Standard-Matchings (wie vorstehend beschrieben) wieder korrigiert.

Das in Figur 5 dargestellte Flussdiagramm 25 zum Best-Effort-Matching ist im Zuge eines Sequenz-Diagramms in UML-Notation dargestellt. Eine Beschreibung des Flussdiagramms 25 ist in folgender Tabelle 3 zu finden.

/ 29

666-AT

Schritt	Beschreibung
1.	Eventauswahl Prüfen ob das Issuer-Event vom Typ Autorisation ist (I EVENT TYPE = AU TH)
2.	Matching über Betrag für das Autorisierungs-Event Suche in allen noch nicht verlinkten EMV-Events, nach solchen, für die gilt: • EMVCARDNR = I CARD NR und • EMV BETRAG = I BERTAG AUTORISIERTund • EMVWÄHRUNG = I WÄHRUNG_A UTORISIERT Wird kein passendes Event gefunden kann keine Verlinkung hergestellt werden. Der Prozess endet, das Event wird jedoch gespeichert.
3.	Matching über Betrag für das Presentment- oder Reversal-Event Suche in allen noch nicht verlinkten EMV-Events, nach solchen, für die gilt: • EMV CARD NR = I CARD NR und • EMV BETRAG =1 BETRAG VERRECHNETE • EMV WÄHRUNG = I WÄHRUNG VERRECHNET
4.	Matching von Zero-Value-Transaktionen“ für das Presentment- oder Reversal-Event Suche in allen noch nicht verlinkten EMV-Events, nach solchen, für die gilt: • EMV CARD NR = I CARD NR und • Tag aus EMV DATE TIME = Tag aus I DATE TIME und • EMV BETRAG = 0
5.	Selektion des Events Aus allen gefundenen EMV-Events, wähle jenes, dessen Uhrzeit aus EMV DATE TIME der Uhrzeit aus I DATE TIME am nächsten ist
6.	Verknüpfung Verknüpfe das ausgewählte EMV-Event mit dem Issuer-Event

Table 3: Schritte des Best-Effort-Matching

Einbindung ins EMV-Ökosystem:

Im Folgenden ist anhand des in Figur 2 dargestellten Systems 21 das Verfahren zur Abarbeitung der Anfrage zur Bezahlung einer Ware erläutert, wie das System 21 die Informationssammeleinrichtung 22 in dem Bezahlprozess im EMV-Ökosystem nutzt.

16/29

23666-AT • Schritt 26: Der Kunde (nicht im Diagramm enthalten) startet über sein mobiles Endgerät 17 eine kontaktlose Bezahl-Transaktion, wobei das mobile Endgerät 17 für den Bezahlvorgang relevante Daten beziehungsweise Anfrageinformationen und Anfragekenninformationen mit dem Kassen-Terminal 18 austauscht.

• Schritt 27: Das Kassen-Terminal 18 kommuniziert mit dem Bezahl-Netzwerk 20.

• Schritt 28: Das Bezahl-Netzwerk 20 leitet die Zahlungsdaten an eine externe Quelle (z.B. Issuer 19, Bank) weiter, welche die Echtheit der Bezahlkarte, die ausreichende Kontodeckung, die Kreditwürdigkeit des Zahlers, etc. prüft und, sofern alle Voraussetzungen gegeben sind, die Zahlung autorisiert und sich um weitere Schritte (Presentment oder Reversal im Falle einer negativen Autorisierung) kümmert.

• Schritt 29: Zeitlich parallel zu den Schritten 26 bis 28 übermittelt das mobile Endgerät 17 die vom Kassen-Terminal 18 erhaltenen EMV-Zahlungsdaten („EMV-Events“) an die Informationssammeleinrichtung 22.

• Schritt 30: Der Issuer 19 leitet Informationen über Statusänderungen inklusive Datenupdates der Transaktion („Issuer-Events“) an die Informationssammeleinrichtung 22 weiter.

• Schritt 31: Bei jedem Eintreffen eines Events ordnet die Informationssammeleinrichtung 22 gemäß den in den Figuren 3 bis 5 angegebenen Matching der jeweiligen Transaktion des jeweiligen mobilen Endgeräts 17 eindeutig oder bestmöglich zu. Werden durch diese Aktualisierung Änderungen an den gespeicherten Transaktions-Daten vorgenommen, werden diese neuen Informationen an das mobile Endgerät 17 weitergeleitet.

Durch das vorstehend beschriebene Verfahren zur Zuordnung der empfangenen Informationen in der Informationssammeleinrichtung 22 des Systems 21 ist der Vorteil erhalten, dass die am mobilen Endgerät 17 für den Benutzer anzeigbaren Informationen über die Transaktion immer aktuell und richtig sind. Auch wäre es vorteilhaft möglich, dass von der Informationssammeleinrichtung 22 ermittelte aktuelle Informationen von weiteren Einrichtungen, beispielsweise für ein Loyalty-System, verwendet werden können.

Es kann erwähnt werden, dass auch jene Informationen, die im Zuge der Verarbeitung der ursprünglich von dem mobilen Gerät abgegebenen Anfrageinformationen durch die Verarbeitungseinrichtungen gewonnenen verarbeiteten Anfrageinformationen als / 29

23666-AT

Anfrageinformationen zu verstehen sind und folglich auch zur bestmöglichen Zuordnung von der Informationssammeleinrichtung genutzt werden können.

Es ist weiters vorteilhaft, wenn die Informationssammeleinrichtung durch einen Server gebildet ist, der ständig online ist und somit laufend Informationen von Verarbeitungseinrichtungen des Systems empfangen und verarbeiten kann. Wenn ein mobiles Gerät seine Anfrage mittels eines lokalen Funknetzes (z.B. Bluetooth oder RFID) gestellt hat und sich unmittelbar danach nichtmehr in dem lokalen Funknetz befindet, dann werden die aktuellen Statusinformationen zu der Anfrage und die voraussichtliche Antwort trotzdem ständig in der Informationssammeleinrichtung aktualisiert. Diese aktualisierten Informationen könnten von dem mobilen Gerät über eine Datenverbindung jederzeit von der Informationssammeleinrichtung abgeholt werden oder gemäß einem weiteren Ausführungsbeispiel auch aktiv von der Informationssammeleinrichtung an das mobile Gerät übertragen werden.

Es kann erwähnt werden, dass ein Benutzer mit seinem Mobiltelefon auch eine Anfrage in dem Zutrittskontrollsystem 1 bezüglich des Zutritts zu einem Raum des Forschungsinstituts 2 stellen könnte und in zwei Geschäften mit seinem Mobiltelefon Waren bezahlen könnte, deren Abwicklung gemäß dem System 21 erfolgen würde. Das Mobiltelefon würde dann über die über das Internet bestehende Datenverbindung laufend oder in bestimmten Zeitabständen aktuelle Informationen zu diesen drei Transaktionen von den jeweiligen Informationssammeleinrichtungen abholen und am Display anzeigen. Ebenso ist es möglich, dass ein Benutzer mehrere mobile Endgeräte (z.B. ein Mobiltelefon, ein Tablet und einen Laptop) hat, mit denen er sich die aktuellen Informationen von Anfragen bzw. Transaktionen anzeigen lassen kann.

Die anhand von den in den Figuren beschriebenen Systeme und Verfahren, um eine bestmögliche Zuordnung mittels eines Best-Effort-Matching Algorithmus durchzuführen, können auch in anderen als den beschriebenen Anwendungsbeispielen vorteilhaft angewandt werden. So könnte beispielsweise bei in unterschiedlichen Geräten geführten Adressbüchern, welche zusammengeführt werden sollen, die Zusammenführung dieser Stammdaten oder eine Duplikats-Erkennung notwendig sein. Ein Benutzer könnten in seinem Mobiltelefon die Adresse und das Geburtsdatum einer Person und in seinem Computer die Telefonnummer und das Geburtsdatum derselben Person gespeichert haben. Da die Datensätze in den Adressbüchern des Mobiltelefons und des Computers eine unterschiedliche Datensatznummer aufweisen, ist eine eindeutige Zuordnung nicht gegeben. Durch das BestEffort-Matching kann anhand der Übereinstimmung des Namens und des Geburtsdatums in / 29

23666-AT beiden Datensätzen eine bestmögliche Zuordnung und somit eine Zusammenführung der beiden Datensätze mit allen zu dieser Person bekannten Daten erfolgen, was vorteilhaft ist.

Ebenso wäre die Anwendung dieses Best-Effort-Matchings bei der Ermittlung einer konkreten Bewegungs-Route möglich, wenn GPS-Daten zu einer konkreten Bewegungsverfolgung, sowie GPS-Daten zu möglichen Routen (z.B. Straßen, im Gegensatz zu nicht passierbaren Wegen) vorhanden sind. Man möchte nun statt der GPS-Daten aus der Bewegungsverfolgung den tatsächlichen beschrittenen Weg auf der Straße darstellen. Da GPS-Daten aus der Bewegungsverfolgung variieren, und nicht immer genau auf einer bestimmten Route bzw. Straße liegen, ist ein Best-Effort-Matching notwendig, welches die entsprechende Entfernung der GPS-Daten zu den vordefinierten Routen bzw. Straßen analysiert. Bei entsprechender Übereinstimmung wird davon ausgegangen, dass der Benutzer diese Straße tatsächlich genommen hat, und der Weg auf der Landkarte kann visuell realistischer dargestellt werden. Konkret könnte der Schulweg eines Kindes, das ein Mobiltelefon mit sich trägt, mittels eines Mobiltelefons der Eltern nachverfolgt werden. Eine Routen-ID könnte die Anfragekenninformation und die Telefonnummer oder Kennung des Mobiltelefons des Kindes bzw. der Eltern könnte die Identitätskenninformation bilden. Die vom Mobiltelefon des Kindes abgegebenen GPS-Daten könnten in einem eine Endverarbeitungseinrichtung bildenden Server mit Zugriff auf Kartendaten verarbeitet und gemäß dem Best-Effort-Matching zugeordnet werden. Die jeweils auf dem letzten Stand befindlichen Daten der Bewegungsverfolgung des tatsächlich von dem Kind beschrittenen Weges könnten durch das Mobiltelefon der Eltern mittels einer Anfrageinformation von der Informationssammeleinrichtung abgefragt werden. Weitere Anwendungsbeispiele ergeben sich für den Fachmann anhand dieser exemplarischen Ausführungsbeispiele.

Claims

1. System (1; 21) zum Verarbeiten zumindest einer Anfrage zumindest eines mobilen Geräts (6; 17) mit zumindest einer ersten Verarbeitungseinrichtung (9; 18) und einer Endverarbeitungseinrichtung (4; 19) des Systems (1; 21), wobei das mobile Gerät (6; 17) zur Abarbeitung einer Anfrageapplikation ausgebildet ist, mit der durch eine Anfragekenninformation (7) gekennzeichnete Anfrageinformationen (8) und Statusinformationen über den Fortschritt der Abarbeitung der Anfrage zwischen dem mobilen Gerät (6; 17) und der ersten Verarbeitungseinrichtung (9; 18) kommuniziert werden und an einem Display (12) des mobilen Geräts (6; 17) anzeigbar sind und, wobei die erste Verarbeitungseinrichtung (9; 18) zur Vorverarbeitung der Anfrageinformationen (8) und zur Weiterleitung, direkt oder über weitere Verarbeitungseinrichtungen (13, 14), an die Endverarbeitungseinrichtung (4; 19) ausgebildet ist und, wobei die Endverarbeitungseinrichtung (4; 19) zum Speichern von einen Anwender des Systems (1;

21) und/oder dessen mobiles Gerät (6; 17) eindeutig identifizierende Identitätskenninformationen (5) ausgebildet ist, dadurch gekennzeichnet, dass eine Informationssammeleinrichtung (15; 22) vorgesehen ist die, um die aktuellen Statusinformationen jeder Anfrage jedes mobilen Geräts (6; 17) zu ermitteln, zum Zuordnen der von den Verarbeitungseinrichtungen (4, 9, 13, 14; 18, 19) oder von dem mobilen Gerät (6; 17) des Systems (1; 21) empfangenen Informationen zu den jeweiligen Anfragen der mobilen Geräte (6; 17) ausgebildet ist, wofür im Falle des Fehlens der für eine eindeutige Zuordnung notwendigen Anfragekenninformation (7) und/oder Identitätskenninformation (5) eine bestmögliche Zuordnung anhand der weiteren in der Anfrageinformation (8) enthaltenen Informationen durchgeführt wird und, dass die Informationssammeleinrichtung (15; 22) zur Übermittlung der ermittelten aktuellen Statusinformation der jeweiligen Anfrage an das jeweilige mobile Gerät (6; 17) ausgebildet ist.

2. System (1; 21) nach Anspruch 1, dadurch gekennzeichnet, dass die Informationssammeleinrichtung (15; 22) zeitversetzt und parallel von den Verarbeitungseinrichtungen (4, 9, 13, 14; 18, 19) oder von dem mobilen Gerät (6; 17) empfangenen Informationen kontinuierlich verarbeitet, um die ermittelte aktuelle Statusinformation dem tatsächlichen Verarbeitungsstand der Verarbeitung der Anfrageinformationen (8) in den Verarbeitungseinrichtungen (4, 9, 13, 14; 18, 19) in der Informationssammeleinrichtung (15; 22) aktuell zu halten.

3. System (1; 21) nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Informationssammeleinrichtung (15; 22) zum Ermitteln der bestmöglichen Zuordnung die

20 / 29

23666-AT von den jeweiligen Verarbeitungseinrichtungen (4, 9, 13, 14; 18, 19) oder von dem mobilen Gerät (6; 17) als Informationsquellen erhaltenen Anfrageinformationen in einem quellinternen Zuordnungsschritt getrennt voneinander geprüft werden und in einem quellübergreifenden Zuordnungsschritt auch gemeinsam geprüft werden, um anhand der Ergebnisse beider Zuordnungsschritte die aktuelle Statusinformation der Anfrageinformationen zu ermitteln.

4. System (1; 21) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Informationssammeleinrichtung (15; 22) bei Vorliegen der für eine eindeutige Zuordnung notwendigen Anfragekenninformation (7) und/oder Identitätskenninformation (5) zum Korrigieren der Zuordnung der zuvor bei einer bestmöglichen Zuordnung durchgeführten fehlerhaften Zuordnung der empfangenen Informationen zu den jeweiligen Anfragen der mobilen Geräte (6; 17) ausgebildet ist.

5. System (1) nach Anspruch 1 bis 4, dadurch gekennzeichnet, dass mit dem System (1) die Zugangsberechtigung des Anwenders des Systems (1) zu einem Gebäude (2) geprüft wird, wobei die erste Verarbeitungseinrichtung durch einen RFID-Reader (9), die weitere Verarbeitungseinrichtung durch einen Gebäudeverwaltungsserver (13) und/oder durch einen Gefährdungsserver (14) und die Endverarbeitungseinrichtung durch einen Kennserver (4) gebildet sind.

6. System (21) nach Anspruch 1 bis 4, dadurch gekennzeichnet, dass mit dem System (21) eine Bezahltransaktion des Anwenders des Systems (21) durchgeführt wird, wobei die erste Verarbeitungseinrichtung durch ein Kassen-Terminal (18) und die Endverarbeitungseinrichtung durch einen Kartenserver eines Kartenherausgebers beziehungsweise Issuers (19) gebildet sind.

7. Verfahren zum Verarbeiten zumindest einer durch eine Anfragekenninformation (7) gekennzeichnete Anfrage zumindest eines mobilen Geräts (6; 17) mit zumindest einer ersten Verarbeitungseinrichtung (9; 18) und einer Endverarbeitungseinrichtung (4; 19) eines Systems (1; 21) gemäß den Ansprüchen 1 bis 6, wobei folgende Verfahrensschritte durchgeführt werden:

Anzeigen von Anfrageinformationen und Statusinformationen über den Fortschritt der Abarbeitung der Anfrage an dem mobilen Gerät (6; 17);

Verarbeiten der Anfrageinformation in zumindest der ersten Verarbeitungseinrichtung (9;

18) und der Endverarbeitungseinrichtung (4; 19), wobei in der Endverarbeitungseinrichtung

21 / 29

23666-AT (4; 19) eine den Anwender des Systems (1; 21) und/oder dessen mobilen Gerät (6; 17) eindeutig identifizierende Identitätskenninformationen (5) gespeichert wird,

Zuordnen der von den Verarbeitungseinrichtungen (4, 9, 13, 14; 18, 19) oder von dem mobilen Gerät (6; 17) des Systems (1; 21) empfangenen Informationen zu den jeweiligen Anfragen der mobilen Geräte (6; 17) in einer Informationssammeleinrichtung (15; 22), um die aktuellen Statusinformationen jeder Anfrage jedes mobilen Geräts (6; 17) zu ermitteln; Durchführen einer bestmöglichen Zuordnung anhand der weiteren in der Anfrageinformation enthaltenen Informationen, wenn die für eine eindeutige Zuordnung notwendige Anfragekenninformation (7) und/oder Identitätskenninformation (5) nicht vorliegt; Übermittlung der in der Informationssammeleinrichtung (15; 22) ermittelten aktuellen Statusinformation der jeweiligen Anfrage an das jeweilige mobile Gerät (6; 17).