Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur Scheckeinreichung. Insbesondere betrifft die Erfindung eine Schnittstelle eines Selbstbedienungsautomaten zur Übertragung von Scheckdateninformationen, die eine sofortige Buchung erlaubt.

Gebiet der Erfindung:

Heute können Kundenschecks in Scheck Deposit Terminals (Selbstbedienungsautomaten SB-Automaten oder auch ATM genannt) deponiert werden. Die Schecks werden ohne Validierung verarbeitet und der Kunde bekommt eine Quittung, dass er den/die Scheck (s) deponiert hat. Bis es zu einer Betragbuchung bzw. Kontobewegung kommt, müssen die Schecks aus den Terminals zu sogenannten Clearing- Zentren geschickt werden. Das geschieht über den normalen Postweg. Das hat zur Folge, dass die Validierung und die endgültige Verbuchung des Scheckbetrages erst nach einigen Tagen oder Wochen erfolgt .

Die Druckschriften WO 99/11021 und die Eintrage unter Check 21 Act in Wikipedia beschreiben die Handhabung von Schecks als gescannte Daten. Eine exakte Implementierung in Bezug zu einem SB-Automaten wurde jedoch nicht offenbart. Im Bereich der Selbstbedienungsautomaten gibt es eine Vielzahl von Kommunikationsprotokollen, wie NDC, DDC, IFX usw. All diese Standardprotokolle enthalten nicht die notwendigen Definitionen für eine integrierte vollständige Bild-Uberprufung und Verarbeitung. Eine Erweiterung der Standardprotokolle ist aufgrund der Interessen der Vielzahl der Mitglieder sehr herausfordernd und schwierig. Somit bedarf es einer alternativen Losung, um die Erweiterung der SB-Automaten zu ermöglichen, so dass eine Überprüfung der Bilddaten, die in der Regel Schecks darstellen, ermöglicht wird .

Übersicht über die Erfindung:

Aufgabe der vorliegenden Erfindung ist die Bereitstellung eines Verfahrens und einer Vorrichtung, insbesondere eines Selbstbedienungsautomaten, der eine Erweiterung von SB- Automaten bereitstellt neben den bestehenden Protokollen, so das in einer möglichen Ausfuhrungsform, die Überprüfung von Bilddaten und deren Analyse erlaubt wird.

Gelost wird diese Aufgabe durch Merkmale der unabhängigen Ansprüche .

Um die Überprüfung eines Schecks in einem Selbstbedienungsautomaten zu erreichen, basiert auf die Erfindung auf den folgenden Elementen. Diese Elemente sind - eine eindeutige API (application programming interface) , um die Server/Hostfunktionalitat bereitzustellen, eine Implementierung der API in einer offenen Standardtechnologie als einen Web-Service.

Eine mögliche Erfindungsidee dahinter ist, dass SB Automaten und andere Uberprufungslesegerate, die Prüf- und Lesefunktionalitat von unterschiedlichen CPS (Cheque Processing System) durch ein einziges Web-Service-Interface integrieren können. Somit sind der Host und der Client unabhängig voneinander. Die Implementierung des Web-Services verbindet den Client mit dem spezifischen CPS-System in der individuellen Kundenumgebung. Client und Host Software müssen nicht verändert werden und sie sind weiterhin unabhängig voneinander.

Es gibt wahrscheinlich genauso viele Definitionen für Web- Services wie es Unternehmen gibt, die welche bereitstellen, aber den vielen Definitionen ist folgendes gemeinsam:

1. Web-Services stellen eine benutzbare Funktionalitat dem Benutzer über einen Standard Web-Protokoll zu Verfugung. In den meisten Fallen wird als Protokoll SOAP (Simple Object Access Protocol) verwendet. Es ist ein Netzwerkprotokoll, bei dem Daten zwischen Netzwerksystem über RPC (Remote Procedure Calls) ausgetauscht werden können.

2. Web Services stellen einen Weg zur Verfugung, der das Interface in einem ausreichenden Detaillierungsgrad beschreibt, so dass der Benutzer in der Lage ist, eine Client-Anwendung zu entwickeln, die mit dem Web-Service kommuniziert. Diese Beschreibung ist normalerweise in einem XML-Dokument beschrieben unter Verwendung z.B. der Web Services Description Language (WSDL) .

3. Web Services sind registriert, so dass potentielle Benutzer sie einfach finden können. Dies wird in der Regel erreicht mit der Universal Discovery Description and Integration (UDDI) .

Eine der primären Vorteile der Webarchitektur ist, dass sie erlaubt, dass Programme in unterschiedlichen Sprachen und auf unterschiedlichen Plattformen programmiert werden, die jedoch in standardisierter Weise miteinander kommunizieren und Informationen austauschen. So arbeiten sie mit Standardwebprotokollen wie XML, HTTP and TCP/IP. Eine signifikante Anzahl von Firmen hat bereits eine Webinfrastruktur und somit ist ein Wissen und eine Erfahrung auf diesem Gebiet gegeben, um diese Struktur aufrechtzuerhalten und zu verwalten. Somit sind die Kosten für einen Eintritt in den Bereich der Web-Services signifikant geringer als in vorhergehenden Technologien.

Dieser Ansatz erlaubt es dem Kunden, eine Multivendorstrategie (mehrere Verkaufer-Strategie) in beide Richtungen zu fahren. Web-Services sind eine fundamentale Technologie und stellen einen wichtigen evolutionären Schritt in Richtung des verteilten Rechnens dar. Offene Standards und der Focus auf Kommunikation und Zusammenarbeit zwischen Menschen und Anwendungen haben eine Umgebung geschaffen, in der Web-Services die Plattform für Anwendungs-Integration werden. Anwendungen werden entwickelt unter Verwendung mehrerer Web-Services von unterschiedlichen Quellen, die zusammenarbeiten unabhängig davon, wo sie sich befinden oder wie sie implementiert wurden.

Mit dieser Erfindung wird eine einheitliche Schnittstelle in Form eines WEB-Services geschaffen, in der Methoden enthalten sind, die den elektronischen Versand von Schecks oder Uberweisungsbelegen von einem Geldautomaten zu einem entfernten Scheckvalidierungs Server definiert. Gleichzeitig wird mit dieser Schnittstelle eine online (realtime) Validierung von einem Scheckvalidierungs Server ermöglicht. (Es sind auch Batch-Uberprufungen mit dieser Technologie denkbar) .

Ein wichtiger Aspekt ist die Definition von Funktionen und Parameter, die eine Schecktransaktion mit gleichzeitiger online (realtime) Buchung ermöglichen. Das heißt, die vom Kunden deponierten Schecks werden, wahrend die Kundentransaktion aktiv ist, elektronisch als Bilddaten (BMP, JPG oder TIF) zu einem entfernten Validierungsserver gesendet und sofort validiert. Der Kunde hat direkt die Möglichkeit, die Betragsbestätigung auszulösen, wobei die Beträge sofort auf die jeweiligen Konten gebucht werden können. Es gibt somit eine allgemein gültige Schnittstelle auf Basis der WEB-Service Technologie, die Server- und Client Provider ermöglichen, diese Schnittstelle zu benutzen, um für die online Scheckverarbeitung eine Kommunikationslogik zu entwickeln. Der Vorteil ist die Vorgabe von Funktionen und Datenfelder die lediglich mit vordefinierten Werten gefüllt werden müssen. Die feste Vorgabe der Funktionen und Datenfelder ermöglicht eine völlig unabhängige Entwicklung der Client und Server Anwendung.

Es ergeben sich somit eine Reihe von Vorteilen. So ist einer der Vorteile der bereits in Teilen erwähnt wurde, der hohe Grad an Unabhängigkeit. Sobald die Kunden die eindeutige Web- Service- API integriert haben, sind sie vom Hostsystem unabhängig. Auf der anderen Seite bedarf es keiner spezifischen Geräteintegrations Anstrengung. Wie bereits oben erwähnt wurde, hat der Kunde nun die Möglichkeit, eine Multivendorstrategie für Clienten zu wählen und ein CPS System.

Weiterhin hat man eine Möglichkeit der einfachen Integration in eine offene standardisierte Umgebung. Neben der einmaligen Integration eines Web-Service-Proxy auf dem Client ist die Hauptintegration darin zu sehen, den Web- Service selber zu implementieren. Die Web-Service- Implementierung realisiert die Verbindung zwischen dem eindeutigen Client API und dem individuellen CPS Hostsystem. Der Vorteil daran ist, dass die Web-Service Entwicklung in einer vollständig offenen Umgebung mit Standardtechnologien erfolgen kann.

Ferner bedarf es keines ATM Protokolls oder einer Erweiterung dessen. Die Erweiterung von bestehenden Protokollen hat gezeigt, dass dies ein oftmals langwieriger und schwieriger Prozess ist. Weiterhin wäre der der Aufwand sehr hoch, um spezifische CPS Losungen für jedes ATM Protokoll (. NDC, DDC, IFX etc.) durchzufuhren.

Weiterhin bedarf es keiner Installation von Scheck- Uberprufung und Lesesoftware auf dem Clienten (SB-Automat bzw. ATM) . Dies wurde in der Regel einen hohen Verwaltungsaufwand mit sich bringen, da die Software auf jedem Gerat installiert werden musste und kontinuierlich upgedated werden muss und synchronisiert werden muss. Ferner ist die Integration in ein ATM-Software sehr spezifisch.

Daraus ergibt sich im Umkehrschluss, dass die Wartung sehr einfach ist, dass die Hauptteile auf einem zentralen Server Web-Service-Server oder dem CPS-System oder einem anderen Host- System laufen. Ein weiterer Vorteil stellt die Skalierbarkeit und Flexibilität dar, die Web-Service-Losung macht es möglich, dass der Web-Service entweder auf dem Client (was nicht ratsam ist) oder auf einem separaten Server oder auf dem gleichen Server wie das CPS System lauft.

Als Software für die sichere Daten-Übertragung kann HTTPS verwendet werden was wohl bekannt ist. Durch diesen Ansatz ist es möglich, dass auch andere Bilderfassungssoftware das Interface verwenden kann, da es sich um einen offenen Standard handelt. Beschreibung der Figuren

Im Folgenden werden die Figuren kurz beschrieben, wobei die konkreten Ausfuhrungsformen nicht beschrankend aufzufassen sind, sondern lediglich dem Verständnis dienen sollen. Der Schutzumfang der Erfindung soll alleine durch die Ansprüche bestimmt werden:

Fig. 1 zeigt die eine Strukturubersicht der Erfindung mit unterschiedlichen Losungen von unterschiedlichen

Herstellern; Fig. 2 zeigt den Ablauf der Erfindung in einem

Flussdiagramm; Fig. 3 zeigt den Ablauf der Eingabe eines Schecks gemäß

Fig. 2 mit mehreren Korrekturen; Fig. 4. zeigt den Ablauf der Erfindung mit dem Entfernen eines Schecks;

Beschreibung einer Ausfuhrungsform:

Teile der folgenden Beschreibung der Web-Service API werden in WSDL Notation beschrieben (es wird darauf hingewiesen, dass eine Vielzahl von Programmiersprachen verwendet werden kann, die verwendete dient lediglich zum exemplarischen Verständnis) .

Wenn eine Nachricht zwischen den Geraten und dem Service gesendet wird, ist es möglich, dass sich der Inhalt bei der Übertragung im Netzwerk. Das kann dazu fuhren, dass die gleiche Nachricht beim Service zweimal ankommt. Das gleiche Verhalten ist möglich, wenn der Service eine Nachricht an das Endgerat sendet. Aus diesem Grunde wird eine Messageld verwendet, die sicherstellt dass die gleiche Nachricht nicht zweimal bearbeitet wird. Jedes Mal wenn eine Methode auf dem Service ausgeführt wird, erhalt die Methode einen Nachrichten-Identifizier (ID) . Dieser Nachrichtenidentifizierung muss eindeutig sein innerhalb des Service für alle Nachrichten, so dass das Gerat einen eindeutigen Identifizierer für jede Nachricht konstruieren muss. Der Service muss die Nachrichtenidentifizierer empfangen, um sicherzustellen dass diese eindeutig sind. Falls der gleiche Nachrichtenidentifizierer empfangen wird durch den Dienst für die gleiche Methode, dann muss der Service seine ursprungliche Antwort erneut übergeben. Falls der gleiche Nachrichtenidentifizierer in unterschiedlichen Methoden empfangen wird, dann muss der Service sicherstellen, dass es ein Problem gibt, und muss einen entsprechenden Fehlercode InvalidMessageld zurückgeben. Dies impliziert, dass der Service Kopien von allen Nachrichten, die er empfangt und sendet, vorhalten muss, so dass er die eingehenden Nachrichten validieren kann und die ausgehenden Nachrichten reproduzieren kann. Das Endgerat muss entsprechend alle Nachrichten, die es sendet, überwachen, so dass es keine doppelten Antworten erhalt. Doppelte Antworten können ignoriert werden.

Ein weiterer Ansatz der vorliegenden Erfindung liegt darin, dass jeder Methodenaufruf durch Übermittlung einer Versions-Information sicherstellen kann, dass die richtige Art von Service verwendet werden kann. Das Endgerat sollte normalerweise die gleichen Versionswerte in jeden Methodenaufruf integrieren, so dass der Server in der Lage ist, zu erkennen, welche Version der Methode verwendet wird. Die Version der Methode ist im Allgemeinen die gleiche, wie die Version der API selber. Der Server kann somit unterschiedliche Versionen von APIs unterstutzen. Er muss den Versionswert in jedem Methodenaufruf prüfen um sicherzustellen, dass die Version der Methode unterstutzt wird. Falls die Version nicht unterstutzt wird, dann muss der Service einen UnsupportedVersion error an das Gerat (SB/ATM) mitteilen. Der Hersteller des Endgerates (SB/ATM) muss berücksichtigen, dass dieser Fehler auf jeden individuellen Methoden-Aufruf angewendet werden kann, so dass das Endgerat diese Fehler entsprechend abarbeiten muss. So ist es zum Beispiel möglich, zwei unterschiedliche Scheckhmterlegungs-Services auf unterschiedlichen Servern bereitzustellen, die auf Methodenanfragen in einem Lastverteilungs-Szenario antworten. Falls zwei Methoden vom gleichen Gerat zu unterschiedlichen Servern geroutet werden, kann die Version für einen Server zulassig sein jedoch nicht für den anderen. Das Endgerat kann nicht davon ausgehen, dass alle Methoden einer Version immer zulassig sind, wenn lediglich ein Methodenaufruf einmal erfolgreich war. Eine individuelle Methode kann einen Versionswert haben, der unterschiedlich ist, von dem anderer Methodenaufrufe in der Version der API, auch wenn dies ein außergewöhnlicher Zustand ist, sollte dies berücksichtigt werden, jedoch auch möglichst vermieden werden. Die Versionsnummer wird aus Haupt- und Unterextensionselementen bestimmt. Auf der Basis dieser fein strukturierten Versionsnummern können Regeln festgelegt werden, die bestimmen, ob es sich um Größere oder kleinere Veränderungen bei den Versionen handelt .

Auf der Basis der Überlegungen kann bei einer Fehlermeldung des Dienstes mehrfach versucht werden, die Methode erneut auszufuhren oder es erfolgt ein Abbruch nach einer gewissen Anzahl von Versuchen. In einer alternativen Ausfuhrungsform kann der Dienst auch unmittelbar aufgeben, weitere Versuche zu senden. Mögliche Methoden werden in der folgenden Tabelle dargestellt .

So kann durch die Methode GetCapabilites vom Service erfragt werden, welche Sprachen unterstutzt werden, welche Bilddaten unterstutzt werden, welche Art von Transaktionen, wie viel Schecks übergeben können werden können und so weiter. Der Client beziehungsweise das SB System kann somit die Fähigkeiten des Services abfragen, um die folgenden Methodenaufrufe richtig zu Steuern. Details der genauen Art der Abfrage werden hier aus Gründen der Beliebigkeit und der Kurze weggelassen. Em Fachmann kann die Art der Aufrufe von den weiteren Beispielen, die folgen, ableiten. Die Methode StartTransaction erlaubt zum Beispiel die Übergabe folgender Parameter:

Das Endgerat beziehungsweise ATM/SB übermittelt mit dem Methodenaufruf startTransaction die oben aufgeführten Parameter an den Dienst/Service. Dabei berücksichtigt das Endgerat die Sprache des Benutzers und übergibt die oben aufgeführten Identifikationen einem Dienst. Weiterhin wird die Kontonummer übergeben, die in der Regel von einer Karte ermittelt wurde. Die weiteren Informationen die, übergeben werden, werden oftmals in einem Dialog mit dem Benutzer ermittelt .

Der Service wertet im Gegenzug die so übermittelten Daten aus und gibt gegebenenfalls Fehlermeldungen zurück, wenn er den Anforderungen wie Version, Sprache nicht gerecht werden kann. Wenn alle Daten berücksichtigt werden können, gibt er als Antwort StartTransaction zurück, auf deren Details hier nicht weiter eingegangen wird, da sie recht simple aufgebaut ist.

Im Folgenden wird auf die Methode Processltem eingegangen, durch die die Scheckdaten vom SB Gerat an den Service übermittelt wird.

Die Beschreibung der Tabelle ist so verstandlich, dass weitere Details hierzu sich erübrigen. Zu berücksichtigen ist, dass sowohl die Vorderseite als auch die Ruckseite als Bilddaten übertragen werden und einige Zusatzdaten wie Ubermittlungszeiten des Schecks.

Als Antwort erhalt der SB vom Service als Processltem Response

ProcessitemResponse

Auch diese Informationen sind sehr detailliert und lassen für den Fachmann einen eindeutigen Ruckschluss auf den Ablauf zu.

Die Figuren 2 bis 4 zeigen einen Konkreten Ablauf auf der Basis der Beschriebenen Methoden und deren Parametern .

Figur 2 zeigt, dass von einem SB-Automat, der lediglich Schecks annimmt, die Transaktion gestartet wird, indem der Benutzer einen entsprechenden Dialog ausfuhrt. Auf die Antwort des Web-Servi ce- Server wird der Benutzer aufgefordert den Scheck einzuführen. Nach dem Einfuhren des Schecks wird dieser verarbeitet und der Server übermittelt, dass die ubergebenen Daten korrekt sind. Nun werden in weiteren Schritten der Benutzer aufgefordert, weitere Schecks einzugeben, wobei sich beim zweiten Scheck herausstellt dass die Hohe des Schecks entweder fehlte oder nicht erkennbar war. Der Benutzer wird nun aufgefordert die Hohe des Schecks einzugeben, was wiederum dann an den Web- Service-Server übermittelt wird. Weiterhin ist erkennbar, dass der Benutzer den Wert des Schecks 1 andern mochte, da dieser durch den Server nicht korrekt erkannt wurde. Nachdem nun alle Daten abgebildet wurden, wird die Transaktion abgeschlossen und die Gutschrift erfolgt.

Die Figur 3 zeigt einen Ablauf bei dem mehrere Korrekturen bei der Eingabe vorgenommen werden müssen. Einerseits ist der Wert nicht erkennbar, so dass dieser manuell nachgefordert wird, andererseits ist die

Qualität des Bildes des Schecks nicht ausreichend, dass der angegebene Betrag mit den Daten des Schecks übereinstimmt. Aus diesem Grunde wird der SB Automat aufgefordert, die Bildqualität des Schecks 1 zu überprüfen und gegebenenfalls die Qualitätswerte erneut zu übertragen. Nachdem dies nun erfolgt ist, kann eine Gutschrift erfolgen.

Die Figur 4 zeigt den Ablauf eines Verfahrens, bei dem zwei Schecks eingegeben werden, wobei der zweite Scheck wieder aus dem SB-Automat entfernt werden soll und nicht gutgeschrieben werden soll.

Die Figur 1 zeigt den grundsätzlichen Aufbau des Web- Services, der von unterschiedlichen Anbietern wie IBM, Carreker, Alogent angeboten werden kann und mit unterschiedlichen SB Terminal s /ATM über ein Netzwerk kommunizieren kann, wobei ein Proxy, der auf dem SB Automaten installiert ist, für die Abbildung der Technik innerhalb der ATMs auf die des Web-Services eingesetzt wird.

Zur Implementierung eines Web-Services kann z.B. Apache-Axis, eingesetzt werden, wie auch JWSDP, .NET, et c .

Der Service kann das SOAP-RPC Kommunikations-Modell bereitstellen. Die API kann vollständig in einem WSDL- FiIe beschrieben sein, aus dem dann automatisch das Skelett bzw. der Rahmen des Services generiert wird, der dann mit durch entsprechende Programmierung mit Leben gefüllt werden muss.