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 es Anwendungsbeispiele im Stand der Technik, bei denen die Anfragen von dem

Mobiltelefon über einen lokalen Datenübertragungskanal, wie eine Bluetooth oder RFID- Funkverbindung, 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 Informationssammel einrichtung, 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 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 äudeverwaltungs Servers 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.

Eine bestmögliche oder auch erste Zuordnung wird also erfindungsgemäß immer dann durchgeführt, wenn eine eindeutige Zuordnung anhand der die Anfrage kennzeichnende Anfragekenninformation oder die den Anwender des Systems oder dessen mobiles Gerät eindeutig identifizierende Identitätskenninformation der Informationssammeleinrichtung nicht zur Verfügung steht. Die bestmögliche oder erste Zuordnung zu einem bestimmten Zeitpunkt ist eine möglichst exakte Zuordnung mittels ein oder mehreren von der

Informationssammeleinrichtung empfangenen Informationen beziehungsweise Parametern, welche zwar für sich genommen noch keine eindeutige Zuordnung ermöglichen, aber unter Anwendung eines Zuordnungs- oder Matching- Algorithmus zu diesem Zeitpunkt mit den vorhandenen Informationen eine erste oder bestmögliche Zuordnung ermöglichen. Wenn zu einem späteren Zeitpunkt die die Anfrage kennzeichnende Anfragekenninformation oder die den Anwender des Systems oder dessen mobiles Gerät eindeutig identifizierende

Identitätskenninformation vorliegt, dann kann die zuvor erfolgte bestmögliche oder erste Zuordnung durch die eindeutige Zuordnung ersetzt oder bestätigt werden. Der durch die technischen Maßnahmen der erfindungsgemäßen

Informationssammel einrichtung 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 Zutrittskontroll System 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. 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 Zutrittskontroll System 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 Zutrittskontroll System 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 Zutrittskontroll System 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 RFID- Reader 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 NFC- Standard 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 l9h 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 die im Zutrittskontroll System 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 Zutrittskontroll System 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 Zutrittskontroll System 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 Zutrittskontroll System 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 Zutrittskontroll System 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 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 Zutrittskontroll System 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 l3h bis l9h 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 Zutrittskontroll System 1 gerade bearbeitete oder noch gültige Anfrage sich auf den

Laborraum 3 für die Zeit von 13h bis l9h 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 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 Verarb ei tungs stand 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 quellintem 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 EMV- Transaktion mit dem Kassen-Terminal 18, um ein Produkt zu kaufen. Dazu werden 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 EM V-Bezahl Vorgä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-Evenf‘). 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, 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 EMV- Information 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-Evenf‘ 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,456 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-Evenf‘ für eine Transaktion überhaupt oder in der richtigen Reihenfolge übermittelt werden. Folgende für die Verknüpfung relevante Transaktionsinformationen sind im bestehenden

EMV-Ökosy stem 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.

• 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 A UTORISIERT: 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:

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 („gematchf‘) 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üher greif ende 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 Autorisierungs- Event 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 I REFERENZ ID = I EVENT ID 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.

T ble 1 : Sehritte des Issuer-Event Matchings

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 Informationssammel einrichtung 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. EMV- Transaktion können mit Autorisierungen eindeutig über

• EMV CARD NR = I CARD NR und

• EMN_ATC = I ATC gematcht werden, sofern der 1 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 Sequenz- Diagramms in EIML-Notation. Eine Beschreibung des Algorithmus ist in folgender Tabelle 2 zu finden.

Table 2t Sehritte des Sri dard-MatciiMgs

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- 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:

_• EMV CARD NR = I CARD NR und

_• EMV DA TE TIME = I DA TE TIME und

_• EMV BETRAG = I BERTAG A UTORISIERT (bei Autorisierungen) bzw.

I BETRAG ^VERRECHNET (bei Presentments, Reversais) und

_• EMV _ WÄHR UN G = 1 WÄHRUNG _A UTORISIERT (bei Autorisierungen) bzw.

I WÄHRUNG VERRECHNET (bei Presentments, Reversais)

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 EIML-Notation dargestellt. Eine Beschreibung des Flussdiagramms 25 ist in folgender Tabelle 3 zu finden.

Tabie 3; Schritte des Best-Effort-Matching

Einbindung ins EMV-Ökosvstem:

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. • 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 Informationssammel einrichtung 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 Informationssammel einrichtung 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 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 Zutrittskontroll System 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 Best- Effort-Matching kann anhand der Übereinstimmung des Namens und des Geburtsdatums in 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 ab gefragt werden. Weitere Anwendungsbeispiele ergeben sich für den Fachmann anhand dieser exemplarischen Ausführungsbeispiele.