-
Technisches Gebiet
-
Die vorliegende Erfindung betrifft allgemein Auftragsverwaltungssysteme und Verfahren für im Fahrzeug in Auftrag gegebene Dienstleistungen bzw. Drive-in-Dienstleistungen. Ausführungsformen betreffen auch Erfassungseinrichtungen und Techniken. Ausführungsformen betreffen weiterhin die signaturbasierte Auftragsüberwachung in einer Dienstleistungsumgebung für aus einem Fahrzeug in Auftrag gegebene Dienstleistungen bzw. Drive-in-Dienstleistungen.
-
Hintergrund der Erfindung
-
Eine „Drive-in-Dienstleistung bzw. eine im Fahrzeug beauftragte und im Fahrzeug erfüllte Dienstleistung” ist eine Art von Dienstleistung, die von einem Unternehmen bereitgestellt wird, beispielsweise von Schnellimbissrestaurants, Banken, Apotheken, Cafehäusern, wobei ein Kunde in der Lage ist, ein Produkt zu kaufen, ohne dass er sein Fahrzeug verlässt. Derartige Drive-in-Dienstleistungen bzw. fahrzeuggestützte Dienstleistungen bieten dem Kunden eine schnelle und bequeme Dienstleistung, wobei auch die Anzahl der Kunden vergrößert werden kann, die im Vergleich zu konventionellen Aktivitäten mit persönlichem Eintreten bedient werden können. Aufträge können generell aufgegeben werden, indem ein Mikrophon verwendet wird und diese Aufträge werden von einer Person an einem Fenster entgegengenommen. Wenn der Auftrag aufgegeben ist, gibt ein Auftragsentgegennehmer die Auftragsinformation in ein Auftragsverwaltungssystem ein. Die Auftragsinformation kann an einer Anzeige dargestellt werden, so dass der Auftrag an einen Boten weitergeleitet werden kann.
-
Konventioneller Weise wird in üblichen Auftragsannahmeabläufen eine Vorgehensweise mit einer einzelnen Warteschlange angewendet, was dazu führt, dass Kunden mit kleinen schnellen Aufträgen hinter Kunden warten müssen, die große komplexe Aufträge aufgeben. Das Problem mit einer derartigen Vorgehensweise besteht darin, dass die Fahrzeuge nicht mehr die Reihenfolge einhalten zwischen dem Zeitpunkt, an welchem der Auftrag abgegeben wurde, und dem Zeitpunkt, an welchem das Fahrzeug das Produkt erhält. Ferner stellt eine derartige konventionelle Vorgehensweise nicht sicher, dass das richtige Produkt an dasjenige Fahrzeuge ausgeliefert wird, das den Auftrag aufgegeben hat, wodurch die Auftragsgenauigkeit und Effizienz weiter verringert werden. Derartige Probleme werden noch verstärkt in stark frequentierten Orten, in denen mehrere Spuren für die Auftragserteilung für jedes Auftragsverarbeitungsfenster vorhanden sind, was zu einer reduzierten Kundenzufriedenheit und zu einem ausgeprägten Verlust an Betriebseinnahmen führt.
-
Auf Grund der zuvor dargestellten Situation ist es eine Aufgabe, ein verbessertes System und ein Verfahren bereitzustellen, um eine signaturbasierte Auftragsüberwachung bzw. Verfolgung für Drive-in-Dienstleistungen vorzusehen, wie dies nachfolgend detaillierter beschrieben ist.
-
Kurzer Überblick
-
Es werden ein System und ein Verfahren zur Bereitstellung einer signaturbasierten Auftragsverfolgung bzw. Überwachung für Drive-in-Dienstleistungen bzw. fahrzeugbasierte Dienstleistungen bereitgestellt. Es wird ein Bild in Bezug auf ein Fahrzeug an einer POS-(Ort des Verkaufs)Einheit an einem Ort des Auftrags und an einem Ort des Auslieferns bzw. des Erfüllens der Dienstleistung (beispielsweise dem Ort des Bezahlens oder dem Ort des Aufnehmens des Auftrags) aufgenommen, wobei eine Bildaufnahmeeinheit verwendet wird, indem die Anwesenheit des Fahrzeuges an jedem Ort unter Verwendung eines Fahrzeuganwesenheitssensors erfasst wird. Das aufgenommene Bild wird dann verarbeitet, um ein kleines interessierendes Gebiet (beispielsweise das Fahrzeugkennzeichen) zu extrahieren und um das Bild zu einer einzigartigen Signatur zu reduzieren. Die extrahierte Signatur des Fahrzeugs am Ort des Auftrages wird in einer Datenbank zusammen mit dem zugehörigen Auftrag und dem Fahrzeugbild gespeichert. Die am Ort des Auslieferns extrahierte Signatur wird mit der in der Datenbank gespeicherten Signatur abgeglichen bzw. verglichen. Wenn eine Übereinstimmung erkannt wird, wird der Auftrag, der mit dem Fahrzeug im Zusammenhang steht, zusammen mit den Bildern, die an dem Ort des Auslieferns und dem Ort des Auftrags aufgenommen wurden, in einer Anwenderschnittstelle am Ort des Auslieferns angezeigt, so dass sichergestellt ist, dass der richtige Auftrag für einen Kunden bearbeitet ist.
-
In einem Extrahiermodus wird das interessierende Gebiet ermittelt und die Signatur des Fahrzeuges an dem Ort des Auftrages wird extrahiert und in der Datenbank gespeichert. Das ROI (interessierende Gebiet) in Bezug auf das Fahrzeugbild wird extrahiert, indem eine automatisierte Fahrzeugkennzeichenerkennungstechnik (beispielsweise eine mathematische morphologisch basierte Erkennungstechnik) angewendet wird, um die Signatur zu ermitteln. Die Signatur kann beispielsweise die Nummer des Kennzeichnens sein, die mittels einer optischen Zeichenerkennungstechnik gewonnen wird, oder diese kann eine Bildpunktkarte bzw. Bit-Map des ROI sein und/oder die Signaturen können andere Bildmerkmale sein (beispielsweise skalen-invariante Merkmalstransformations-(SIFT)Eigenschaften). Die Signatur wird dann in der Datenbank zusammen mit dem zugehörigen Auftrag und dem Fahrzeugbild gespeichert.
-
In einem Abgleichmodus wird die Signatur des Fahrzeuges am Punkt des Bezahlens und dem Punkt des Auftragentgegennehmens extrahiert und mit den Signaturen abgeglichen bzw. verglichen, die in der Datenbank gespeichert sind. Wenn die Signatur die Nummer des Kennzeichens ist, kann der Abgleich durch einen einfachen Vergleich der Zeichen ausgeführt werden. Wenn die Signatur die Bildpunktkarte bzw. Bit-Map ist, kann eine zweidimensionale korrelationsartige Abgleichtechnik eingesetzt werden. Eine Übereinstimmung von SIFT-Merkmalen kann durch die übereinstimmenden Merkmale auf der Grundlage eines euklidischen Abstandes der Merkmalsvektoren erreicht werden. Der mit dem aktuellen Fahrzeug verknüpfte Auftrag wird in der Anwenderschnittstelle dargestellt, wobei dies zusammen mit den Bildern erfolgt, die an dem Ort des Auslieferns und dem Ort des Auftraggebens aufgenommen wurden. Die Signatur wird automatisch zusammen mit dem Bild und dem Auftrag aus der Datenbank gelöscht, nachdem das Produkt des Auftrags an den Kunden ausgegeben bzw. der Auftrag erfüllt ist. Eine derartige Vorgehensweise kann effizient für eine Fülle von fahrzeugbasierten Dienstleistungsumgebungen bzw. Drive-in-Dienstleistungsumgebungen eingesetzt werden, um sicherzustellen, dass entsprechende Aufträge zusammengestellt wurden und bereit sind, dass sie bzw. die dazugehörigen Produkte an den Kunden ausgegeben werden.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt eine schematische Ansicht eines Computersystems gemäß den offenbarten Ausführungsformen;
-
2 zeigt eine schematische Ansicht eines Softwaresystems mit einem Fahrzeug und einem Auftragsüberwachungsmodul, einem Betriebssystem und einer Anwenderschnittstelle gemäß den offenbarten Ausführungsformen;
-
3 zeigt eine Blockansicht eines signaturbasierten Auftragsüberwachungssystems gemäß den offenbarten Ausführungsformen;
-
4 zeigt eine perspektivische Ansicht des signaturbasierten Auftragsüberwachungssystems in einer fahrzeugbasierten Dienstleistungsumgebung bzw. einer Drive-in-Dienstleistungsumgebung gemäß den offenbarten Ausführungsformen;
-
5 zeigt eine graphische Darstellung eines Auftragsüberwachungsfensters gemäß den offenbarten Ausführungsformen; und
-
6 zeigt ein Flussdiagramm auf höherer Ebene von Aktivitäten, in denen die logischen Arbeitsschritte des Verfahrens zum Überwachen bzw. Verfolgen des Auftrags auf der Grundlage einer Signatur in Bezug auf ein Fahrzeug gemäß den offenbarten Ausführungsformen dargestellt sind.
-
Detaillierte Beschreibung
-
Wie der Fachmann erkennt, kann die vorliegende Erfindung als ein Verfahren, ein Datenverarbeitungssystem oder ein Computerprogrammprodukt implementiert werden. Folglich kann die vorliegende Erfindung in Form einer vollständig in Hardware vorliegenden Ausführungsform, einer vollständigen in Software vorliegenden Ausführungsform oder einer Ausführungsform implementiert sein, in der Software und Hardwareaspekte kombiniert sind, wobei dies hierin allgemein als eine „Schaltung” oder „Modul” bezeichnet wird. Ferner kann die vorliegende Erfindung die Form eines Computerprogrammprodukts auf einem computernutzbaren Speichermedium annehmen, das eine computernutzbare Programmiercodierung aufweist, die in dem Medium integriert ist. Es kann ein beliebiges geeignetes computerlesbares Medium verwendet werden, wozu Festplatten, USB-Flash-Speicher, DVD’s, CD-ROM’s, optische Speichereinrichtungen, magnetische Speichereinrichtungen, etc. gehören.
-
Eine Computerprogrammcodierung für das Ausführen von Arbeitsschritten der vorliegenden Erfindung kann in einer objektorientierten Programmsprache (beispielsweise Java, C++, etc.) geschrieben sein. Die Computerprogrammcodierung zum Ausführen der Arbeitsabläufe der vorliegenden Erfindung kann aber auch in konventionellen auf Prozeduren basierenden Programmsprachen geschrieben sein, etwa in der Programmiersprache „C”, oder in einer visuell orientierten Programmierumgebung, etwa beispielsweise VisualBasic.
-
Die Programmcodierung kann vollständig auf dem Computer eines Anwenders ausgeführt werden, kann aber auch teilweise auf dem Computer des Anwender ausgeführt werden, als ein autarkes Softwarepaket, oder diese Codierung kann teilweise auf dem Computer des Anwenders und teilweise auf einem entfernten Computer oder kann auch vollständig auf dem entfernten Computer ausgeführt werden. In dem zuletzt genannten Szenario wird der entfernte Computer mit dem Computer des Anwenders über ein lokales Netzwerk (LAN) oder ein Weitbereichsnetzwerk (WAN), über ein drahtloses Datennetzwerk, beispielsweise Wimax, 802.xx oder ein Funknetzwerk verbunden, oder die Verbindung mit einem externen Computer kann über Netzwerke, die von einer dritten Partei bereitgestellt werden, hergestellt werden (beispielsweise über das Internet unter Anwendung eines Internetdienstleistungsanbieters).
-
Die Ausführungsformen sind zumindest teilweise hierin mit Bezug zu Flussdiagrammdarstellungen und/oder Blockdiagrammen von Verfahren, Systemen und Computerprogrammprodukten und Datenstrukturen gemäß den Ausführungsformen der vorliegenden Erfindung dargestellt. Es ist zu beachten, dass jeder Block der Darstellungen und Kombinationen von Blöcken durch Computerprogrammbefehle implementiert werden können. Diese Computerprogrammbefehle werden einem Prozessor eines Computers für Allgemeinzwecke, eines Computers für spezielle Zwecke, oder einer anderen programmierbaren Datenverarbeitungseinrichtung zur Verfügung gestellt, so dass ein Gerät bereitgestellt wird, derart, dass die Befehle, die über den Prozessor des Computers oder über eine andere programmierbare Datenverarbeitungseinrichtung abgearbeitet werden, Mittel bereitstellen, um die Funktionen/Aktivitäten zu implementieren, die in dem Block oder in den Blöcken spezifiziert sind.
-
Diese Computerbefehle können auch auf einem computerlesbaren Speicher gespeichert werden, der einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung veranlasst, in einer speziellen Weise zu funktionieren derart, dass die in dem Computer lesbaren Speicher gespeicherten Befehle ein hergestelltes Produkt ergeben, das Befehlseinrichtungen aufweist, die die Funktion/Aktivität, die in dem Block oder den Blöcken spezifiziert sind, implementieren.
-
Die Computerprogrammbefehle können auch in einen Computer oder eine andere programmierbare Datenverarbeitungseinrichtung eingeladen werden, so dass das Ausführen einer Reihe von Arbeitsschritten auf dem Computer oder einer anderen programmierbaren Einrichtung bewirkt wird, so dass ein Computer implementierter Prozess derart erzeugt wird, dass die Befehle, die auf dem Computer oder einer anderen programmierbaren Einrichtung abgearbeitet werden, Schritte zum Implementieren der Funktionen/Aktivitäten bereitstellen, die in dem Block oder in den Blöcken spezifiziert sind.
-
Die 1 bis 2 werden als beispielhafte Ansichten von Datenverarbeitungsumgebungen bereitgestellt, in denen Ausführungsformen der vorliegenden Erfindung implementiert sind. Es sollte beachtet werden, dass die 1 bis 2 lediglich anschaulicher Natur sind und nicht eine Beschränkung im Hinblick auf die Umgebungen auferlegen sollen, in denen Aspekte oder Ausführungsformen offenbarten Erfindung eingerichtet werden. Es können viele Modifizierungen an den dargestellten Umgebungen durchgeführt werden, ohne von dem Grundgedanken und dem Schutzbereich der offenbarten Ausführungsformen abzuweichen.
-
Wie in 1 gezeigt ist, werden die offenbarten Ausführungsformen im Rahmen eines Datenverarbeitungssystems 100 implementiert, das beispielsweise einen zentralen Prozessor 101, einen Hauptspeicher 102, eine Eingabe/Ausgabe-Steuerung 103, eine Tastatur 104, eine Eingabeeinrichtung 105 (beispielsweise ein Zeigergerät, etwa eine Maus, einen Spurball oder einen Stift, und dergleichen), eine Anzeigeeinrichtung 106, einen Massenspeicher 107 (beispielsweise eine Festplatte) und eine USB-(universeller serieller Bus)Peripherieverbindung 111 aufweist. Weitere Eingabe/Ausgabe-Einrichtungen, etwa eine Bildaufnahmeeinheit 108 (beispielsweise eine Kamera etc.) stehen mit dem Datenverarbeitungssystem 100 nach Bedarf in Verbindung. Wie gezeigt, können die diversen Komponenten des Datenverarbeitungssystems 100 elektronisch über einen Systembus 110 oder eine ähnliche Architektur miteinander in Verbindung treten. Der Systembus 110 ist beispielsweise ein Subsystem, das Daten beispielsweise zwischen Computerkomponenten innerhalb des Datenverarbeitungssystems 100 überträgt oder Daten zu und von anderen Datenverarbeitungseinrichtungen, Komponenten, Computern, etc. überträgt.
-
2 zeigt ein Computersoftwaresystem 150 zur Steuerung des Betriebs des Datenverarbeitungssystems 100, das in 1 gezeigt ist. Eine Softwareanwendung 152, die in dem Hauptspeicher 102 oder dem Massenspeicher 107 abgelegt ist, erzeugt generell einen Kernel oder ein Betriebssystem 151 und eine Peripherie- bzw. Schnittstelle 153. Ein oder mehrere Anwendungsprogramme, etwa eine Softwareanwendung 152, werden „eingeladen” (d. h. von dem Massenspeicher 107 in dem Hauptspeicher 102 übertragen), um von dem Datenverarbeitungssystem 100 ausgeführt zu werden. Das Datenverarbeitungssystem 100 empfängt Anwenderbefehle und Daten über eine Anwenderschnittstelle 153; diese Eingaben werden dann von dem Datenverarbeitungssystem 100 entsprechend den Befehlen von dem Betriebssystemmodul 151 und/oder der Softwareanwendung 154 verarbeitet.
-
Die folgende Erläuterung soll eine kurze generelle Beschreibung geeigneter Rechenumgebungen angeben, in denen das System und das Verfahren eingerichtet werden können. Obwohl dies nicht erforderlich ist, werden die offenbarten Ausführungsformen im allgemeinen Zusammenhang von computerausführbaren Befehlen, etwa Programmmodulen, beschrieben, die von einem einzelnen Computer ausgeführt werden können. In den meisten Fällen entspricht ein „Modul” einer Softwareanwendung.
-
Generell enthalten Programmmodule, ohne einschränkend zu sein, Routinen, Unterroutinen, Softwareanwendungen, Programme, Objekte, Komponenten, Datenstrukturen, etc., die spezielle Aufgaben ausführen oder spezielle abstrakte Datentypen und Befehle implementieren. Ferner erkennt der Fachmann, dass das erfindungsgemäße Verfahren und das System mit anderen Computersystemkonfigurationen umgesetzt werden können, etwa beispielsweise durch tragbare Geräte, Systeme mit mehreren Prozessoren, Datennetzwerke, mikroprozessorbasierten oder programmierbaren Konsumelektronikgeräten, mit PC’s, die mit einem Netzwerk verbunden sind, Minicomputern, größeren Computern, Dienstleistungsrechnern bzw. Servern, und dergleichen.
-
Zu beachten ist, dass der hierin verwendete Begriff Modul eine Ansammlung aus Routinen und Datenstrukturen bezeichnen kann, die eine spezielle Aufgabe ausführen oder einen speziellen abstrakten Datentyp implementieren. Module sind aus zwei Teilen zusammengesetzt: einer Schnittstelle, die die konstanten Datentypen, Variablen und Routinen, auf die durch andere Module oder Routinen zugegriffen werden kann, enthält, und eine Implementierung, die typischerweise privat ist (nur von diesem Modul abgerufen werden kann) und die eine Quellencodierung aufweist, die die Routinen in dem Modul tatsächlich implementiert. Der Begriff Modul kann auch einfach eine Anwendung bezeichnen, etwa ein Computerprogramm, das so gestaltet ist, dass es beim Ausfüllen einer speziellen Aufgabe unterstützend wirkt, etwa bei der Textverarbeitung, der Buchführung, bei der Bestandsverwaltung, etc.
-
Die Schnittstelle 153, die vorzugsweise eine graphische Anwenderschnittstelle (GUI) ist, kann dazu dienen, dass Ergebnisse dargestellt werden, woraufhin ein Anwender eine zusätzliche Eingabe bereitstellen oder eine spezielle Sitzung beenden kann. In einigen Ausführungsformen werden das Betriebssystem 151 und die Schnittstelle 153 im Zusammenhang eines „Fenstersystems” implementiert. Zu beachten ist, dass selbstverständlich andere Arten von Systemen möglich sind. Anstelle eines traditionellen „Fenstersystems” können etwa andere Betriebssysteme, etwa beispielsweise ein Echtzeitbetriebssystem (RTOS), das häufiger in kabellosen Systemen eingesetzt wird, angewendet werden zur Bereitstellung des Betriebssystems 151 und der Schnittstelle 153. Die Softwareanwendung 152 umfasst beispielsweise ein Auftragsüberwachungs- bzw. Verfolgungsmodul 154, um einen Auftrag auf der Grundlage einer Signatur in Bezug auf ein Fahrzeug zu verwalten. Das Fahrzeug- und Auftragsüberwachungsmodul 154 enthält Befehle, etwa jene des Verfahrens 500, das nachfolgend mit Bezug zu 6 erläutert ist.
-
Die 1 bis 2 sollen daher als ein Beispiel und nicht als eine Beschränkung der Architektur im Hinblick auf die speziellen Ausführungsformen dienen. Derartige Ausführungsformen sind jedoch nicht auf eine spezielle Anwendung oder eine spezielle Rechen- oder Datenverarbeitungsumgebung eingeschränkt. Stattdessen erkennt der Fachmann, dass das offenbarte System und das Verfahren vorteilhaft auf eine Vielzahl von System- und Anwendungssoftwaresystemen angewendet werden können. Ferner kann die vorliegende Erfindung in einer Vielzahl unterschiedlicher Rechenplattformen implementiert werden, wozu Macintosh, UNIX, LINUX und dergleichen gehören.
-
3 zeigt eine Blockansicht eines Ortes-des-Verkaufs-(POS)Systems zum Verfolgen bzw. Überwachen eines Auftrags 240 in Bezug auf ein Fahrzeug 205 gemäß den offenbarten Ausführungsformen. Zu beachten ist, dass in den 1 bis 6 identische oder ähnliche Blöcke generell durch identische Bezugszeichen benannt sind. Das POS-System 200 kann effizient in einer weiten Fülle an Dienstleistungsumgebungen für Dienstleistungen, die von einem Fahrzeug aus in Auftrag gegeben werden bzw. in Drive-in-Dienstleistungsumgebungen eingesetzt werden, um eine effiziente Auslieferung bzw. Erfüllung für eine gehobene Qualität der Dienstleistung in Bezug auf einen mobilen Kunden mit sehr begrenztem Zeitbudget sicherzustellen. Das System 200 enthält generell eine Auftragsverarbeitungseinheit 210, einen oder mehrere Orte des Auslieferns bzw. der Erfüllung der Dienstleistung, etwa eine Bezahlungsverarbeitungseinheit 260 und eine Auftragsaufnahmeverarbeitungseinheit 275, und eine zentralisierte Überwachungsbearbeitungseinheit 290 mit dem Auftragsüberwachungsmodul 154, die alle funktionsmäßig mit dem Netzwerk 245 verbunden sind.
-
Zu beachten ist, dass das Netzwerk 245 eine Internetverbindung sein kann, die eine weltumspannende Ansammlung von Netzwerken und Zugangsportalen darstellt, die das Übertragungssteuerprotokoll/Internetprotokoll (TCP/IP) verwenden, um miteinander zu kommunizieren. Dem Internet liegt ein Gerüst aus Hochgeschwindigkeitsdatenkommunikationsleitungen zwischen Hauptknoten oder Hauptrechnern zugrunde, die aus tausenden von kommerziellen, öffentlichen, zur Bildung dienenden oder anderen Computersystemen aufgebaut sind, die Daten und Nachrichten übermitteln. Selbstverständlich kann das Netzwerk 245 auch als eine Anzahl unterschiedlicher Arten von Netzwerken implementiert werden.
-
Die Auftragsverarbeitungseinheit 210 des POS-Systems 200 nimmt ein Bild 254 in Bezug auf das Fahrzeug 205 auf, wobei eine Auftragsort-Bildaufnahmeeinheit 212 verwendet wird, indem die Anwesenheit des Fahrzeugs 205 unter Anwendung eines Auftragsort-Fahrzeuganwesenheitssensors 230 erfasst wird. Die Auftragsverarbeitungseinheit 210 umfasst ferner eine Auftragsort-Anwenderschnittstelle 235, um den Auftrag 240 in Bezug auf den Kunden bereitzustellen. In ähnlicher Weise enthalten Bezahlungsverarbeitungseinheit 260 und die Aufnahmeverarbeitungseinheit 275 des POS-Systems 200 separate Bildverarbeitungseinheiten, etwa eine Bezahlungsort-Bildaufnahmeinheit 262 und eine Auftragsaufnahmeort-Bildaufnahmeeinheit 276 zum Aufnehmen der Bilder 254 in Bezug auf das Fahrzeug 205, indem die Anwesenheit des Fahrzeugs 205 über entsprechende Fahrzeuganwesenheitssensoren 270 bzw. 280 erfasst wird.
-
Zu beachten ist, dass die Bildaufnahmeeinheiten 212, 262, die detaillierter hierin beschrieben sind, analog oder ähnlich zu der Bildaufnahmeeinheit 108 des Datenverarbeitungssystems 100 sein können, das in 1 gezeigt ist. Die Bildaufnahmeeinheit enthält ggf. eingebaute integrierte Funktionen, etwa die Bildverarbeitung, Datenformatierung und die Datenkomprimierung. Ferner umfasst die Einheit eine Positioniereinrichtung, eine Bereichserkennung und ein Blitzlicht.
-
Das Auftragsüberwachungsmodul 154 des zentralisierten Dienstleistungsrechners 290 verarbeitet die aufgenommenen Bilder 254 in dem POS-System 200, um ein kleines interessierendes Gebiet (ROI) 220 zu extrahieren, beispielsweise in Form eines Fahrzeugkennzeichens. Ein interessierendes Gebiet, das häufig als ROI abgekürzt wird, ist eine ausgewählte Teilgruppe aus Elementen innerhalb eines Datensatzes, der für einen speziellen Zweck ermittelt wurde. Das interessierende Gebiet 220 in Bezug auf das Fahrzeug 205 kann ferner auf eine einzigartige Signatur 252 in der Auftragsverarbeitungseinheit 210 reduziert und in einer Datenbank 250 zusammen mit dem entsprechenden Auftrag 240 und dem Fahrzeugbild 254 gespeichert werden. Eine Abgleichanwendung bzw. Vergleichsanwendung 265, die in der Bezahlverarbeitungseinheit 260 und der Auftragsaufnahmeverarbeitungseinheit 275 eingerichtet ist, vergleicht die Signaturen 252, die in der Bezahlungsverarbeitungseinheit 260 und der Auftragsaufnahmeverarbeitungseinheit 275 extrahiert wurden, mit der Signatur 252, die in der Datenbank 250 gespeichert ist.
-
Die Abgleichanwendung 265 zeigt ferner den Auftrag 240, der mit dem Fahrzeug 205 verknüpft ist, zusammen mit den Bildern 254, die an dem Auslieferungsorten 260 und 275 von der Auftragsverarbeitungseinheit 210 aufgenommen wurden, in den Anwenderschnittstellen 272 und 285 an, um sicherzustellen, dass der richtige Auftrag 240 dem Kunden zugeordnet ist. Die Bezahlungsort-Anwenderschnittstelle 272 liefert eine Bestätigung der Bezahlung in Bezug auf den Auftrag 240, der an der Auftragsverarbeitungseinheit 210 des POS-Systems 200 aufgegeben wurde. In ähnlicher Weise zeigt die Auftragsaufnahmeort-Anwenderschnittstelle 285 die ausgelieferten bzw. bearbeiteten Aufträge 240 in Bezug auf das Fahrzeug 205 an.
-
4 zeigt eine Perspektive des Ort-des-Verkaufs-(POS)Systems 200 in einer Dienstleistungsumgebung für fahrzeuggestützte Dienstleistungen bzw. für Drive-in-Dienstleistungen 320. Das System 200 ist mit einem Laden bzw. einem Lager 310 mit einer Aufbewahrstelle 320 versehen, um die Aufträge 240 in dem Laden bzw. Lager 310 zu verarbeiten und zu verwalten. Die Aufbewahrstellen 320 können anhängige Aufträge 240 in dem POS-System 200 halten. Das System 200 kann in einem Extrahiermodus aktiviert werden, um die Signaturen 252 zu extrahieren und zu speichern, und das System kann auch in einem Abgleichmodus eingesetzt werden, um die Signaturen 352 des Fahrzeugs 205 abzugleichen bzw. miteinander zu vergleichen. In dem Extrahiermodus wird das interessierende Gebiet 220 in Bezug auf das Bild 254 des Fahrzeugs 205 positioniert und die Signatur 252 des Fahrzeugs 205 wird extrahiert und in der Datenbank 250 gespeichert. Zu beachten ist, dass das interessierende Gebiet (ROI) 220 ein Teil des Bildes 240 sein kann, das ein Anwender filtern kann oder auf das eine andere Operation angewendet werden kann. Manchmal ist es günstig, ein einzelnes Teilgebiet des Bildes 240 zu verarbeiten, wobei andere Gebiete unverändert bleiben. Das interessierende Gebiet 220 in Bezug auf das Fahrzeugbild 254 wird etwa ermittelt oder extrahiert, indem ein automatisierter Fahrzeugkennzeichenerkennungsalgorithmus angewendet wird, beispielsweise eine mathematische morphologisch basierte Erkennungstechnik, um die Signatur 252 zu ermitteln. Die Signatur 252 weist beispielsweise die Nummer eines Fahrzeugkennzeichens, die mittels einer optischen Zeichenerkennungstechnik ermittelt wird, eine Bildpunktkarte bzw. Bit-Map des interessierenden Gebiets 220, oder andere Bildmerkmale, beispielsweise eine skaleninvariante Merkmalstransformation, auf.
-
Im Abgleichmodus werden die Signaturen 252 des Fahrzeugs 205 an der Bezahlungsverarbeitungseinheit 260 und der Auftragsaufnahmeverarbeitungseinheit 275 extrahiert und mit den in der Datenbank 250 gespeicherten Signaturen 252 abgeglichen bzw. verglichen. Wenn die Signatur 252 die Nummer des Fahrzeugkennzeichnens ist, kann der Abgleich durch einen einfachen Zeichenvergleich ausgeführt werden. Wenn die Signatur die Bildpunktkarte bzw. die Bit-Map ist, kann ein zweidimensionaler korrelationsartiger Vergleich verwendet werden. Ein Abgleich von SIFT-Merkmalen kann durch den Vergleich von Merkmalen auf der Grundlage eines euklidischen Abstands der Merkmalsvektoren bewerkstelligt werden. Die Signaturen 252 in Bezug auf das Fahrzeug 205 können auch extrahiert werden, indem eine große Fülle an anderen Erkennungstechniken angewendet wird, etwa Unterstützungsvektormaschinenverfahren, Musterklassifizierung, Bayes-Entscheidungsverfahren, neuronale Netzwerkklassifizierer, eine Fuzzy-Logikentscheidungsfindung und genetische algorithmusbasierte Optimierer etc. Derartige Signaturen 252 können ferner eingesetzt werden, um die Aufträge 240 in Bezug auf den Kunden in der Drive-in-Umgebung 230 in wirksamer Weise zusammen zu stellen. Die Signatur 252 wird in der Datenbank 250 zusammen mit dem zugehörigen Auftrag 240 und dem Fahrzeugbild 254 gespeichert. Die Signaturen 252 können dann automatisch zusammen mit dem Bild 254 und dem Auftrag 240 aus der Datenbank 250 gelöscht werden, nachdem die Dienstleistung bzw. deren Ergebnis gemäß dem Auftrag 240 an den Kunden ausgeliefert bzw. erfüllt ist.
-
5 zeigt eine graphische Darstellung eines Auftragsüberwachungsfensters 400 in Bezug auf die Auslieferungsorte bzw. Erfüllungsorte Systems 200 gemäß den offenbarten Ausführungsformen. Das graphische Fenster 400 ist generell im Rahmen eines GUI-„Fensters” implementiert. Zu beachten ist, dass beim Berechnen ein GUI-„Fenster” generell ein visueller Bereich ist, der eine gewisse Art an Anwenderschnittstelle enthält. Ein derartiges „Fenster” besitzt für gewöhnlich (aber nicht immer) eine rechteckige Form und zeigt das Ergebnis eines oder mehrerer Prozesse und erlaubt auch möglicherweise eine Eingabe zu einem oder mehreren Prozessen. Derartige Fenster sind im Wesentlichen mit graphischen Anzeigen verknüpft, die mittels eines Mauszeigers manipuliert werden können, beispielsweise mit der Eingabeeinrichtung 105, die in 1 gezeigt ist. Eine GUI unter Anwendung von „Fenstern” als eine ihrer wesentlichen „Metapher” wird häufig als ein Fenster basiertes System bezeichnet.
-
Die Anwenderschnittstellen 272 und 285 in Bezug auf die Auslieferungsorte 260 und 275 zeigen die Bilder 410 und 420 an, die an dem Auftragsverarbeitungsort 210 und den Auslieferungsorten bzw. Erfüllungsorten 260 und 275 aufgenommen wurden, um die Nummer des Auftrags, die Fahrzeugerkennung und andere Details in Bezug auf den Auftrag 240 abzugleichen, der in der Drive-in-Umgebung 330 aufgegeben wurde. Zu beachten ist, dass die Drive-in-Umgebung bzw. die fahrzeuggestützte Umgebung 330, wie sie hierin offenbart ist, typischerweise einen breiten Bereich an Geschäftsanwendungen umfasst, beispielsweise Schnellimbissrestaurants, Banken, Apotheken und Cafehäuser. Das POS-System 200 im Zusammenhang mit den Dienstleistungen, die im Fahrzeug in Auftrag gegeben werden, bzw. im Zusammenhang mit den Drive-in-Dienstleistungen 330 bietet eine schnelle und bequeme Dienstleistung, wobei auch die Anzahl der Kunden vergrößert werden kann, die im Vergleich zu konventionellen Aktivitäten mit persönlichem Zutritt in ein Geschäft bedient werden können.
-
6 zeigt ein Flussdiagramm auf höherer Ebene von Aktivitäten, die logische Arbeitsschritte des Verfahrens 500 zeigen, um Aufträge auf der Grundlage der Signatur 252 in Bezug auf das Fahrzeug 205 gemäß den offenbarten Ausführungsformen zu überwachen. Zu beachten ist, dass das Verfahren 500 auch im Zusammenhang eines computernutzbaren Mediums implementiert werden kann, das ein Programmprodukt enthält, das wiederum beispielsweise ein Modul oder eine Gruppe aus Modulen enthält, Wiederum sei daran erinnert, dass in den 1 bis 6 identische oder ähnliche Blöcke generell durch die gleichen Bezugszeichen benannt sind. Die Anwesenheit des Fahrzeugs 205 in der Drive-in-Umgebung 330 kann über die Fahrzeuganwesenheitssensoren 230, 270 und 280, die mit dem POS-System 200 in Verbindung stehen, erkannt werden, wie dies im Block 510 dargestellt ist. Das Bild 254 in Bezug auf das Fahrzeug 205 kann an jedem Punkt bzw. Ort 210, 260 und 275 aufgenommen werden, wobei die Bildaufnahmeeinheiten 212, 262 bzw. 272 Verwendung finden, wie dies im Block 520 dargestellt ist.
-
Das Bild 254, das an der Auftragsverarbeitungseinheit 210 aufgenommen wurde, kann verarbeitet werden, um das kleine interessierende Gebiet 220 über den zentralisierten Dienstleistungsrechner 290 zu extrahieren, und das Bild kann zu einzigartigen Signaturen 252 reduziert werden, wie dies im Block 530 dargestellt ist. Die extrahierten Signaturen 252 des Fahrzeugs 205 in der Auftragsverarbeitungseinheit 210 werden in der Datenbank 250 zusammen mit dem entsprechenden Auftrag 240 und dem Fahrzeugbild 254 gespeichert, wie dies im Block 540 gezeigt ist. Die an den Auslieferungsorten 260 und 275 extrahierte Signatur 252 wird mit der Signatur 252, die in der Datenbank 250 gespeichert ist, verglichen, wie dies im Block 550 gezeigt ist.
-
Wenn eine Übereinstimmung ermittelt wird, wird der Auftrag 240, der mit dem Fahrzeug 205 im Zusammenhang steht, zusammen mit den Bildern 254, die an den Auslieferungsorten 260 und 275 und an der Auftragsverarbeitungseinheit 210 aufgenommen wurden, weiter an den Anwenderschnittstellen 272 und 285 der Auslieferungsorte 260 und 275 angezeigt, wie dies im Block 560 gezeigt ist. Schließlich wird der geeignete Auftrag 240 in Bezug auf den Kunden abgeschlossen bzw. das zugehörige Produkt auf der Grundlage der übereinstimmenden Signaturen 252 in der Dienstleistungsumgebung für fahrzeugbasierte Dienstleistungen 330 ausgeliefert, wie im Block 570 gezeigt ist. Ein derartiges System und ein Verfahren können effizient in einer Vielzahl von Drive-in-Dienstleistungsumgebungen bzw. Umgebungen mit Dienstleistungen, die im Fahrzeug beauftragt werden und deren Ergebnis darin entgegengenommen wird, verwendet werden, um sicherzustellen, dass entsprechende Aufträge zusammengestellt wurden und fertig sind, so dass deren Ergebnis an den Kunden ausgeliefert wird oder die Dienstleistung erfüllt wird.
