-
Gebiet der Erfindung
-
Die vorliegende Erfindung betrifft Telekommunikationen. Insbesondere betrifft die Erfindung ein System zur Buchung einer Reservierung in einem Buchungssystem und zum Synchronisieren von Buchungen in mehreren Buchungssystemen, das umfasst: mindestens ein Buchungssystem; wobei mindestens ein Diensteanbieter eingeschlossen ist; einen Vermittlerdienst; einen Auftraggeber und mindestens ein Auftraggeberendgerät, das ein Mobilgerät sein kann und das einen Dialog umfasst. Zusätzlich umfasst das System Telekommunikationsverbindungen, die verwendet werden, um die Buchungssysteme, die Diensteanbieter, den Vermittler und das Auftraggeberendgerät zu verbinden.
-
Hintergrund der Erfindung
-
Dienste, die gebucht werden oder über das Internet genutzt werden, nehmen beständig zu. Das Internet ermöglicht, dass man mehrere Online-Dienste nutzt, wie z. B. Dienste, die mit Banken, Gesundheitsdiensten, Reisebüros, Fahrzeugwartung usw. verbunden sind.
-
Die zunehmende Popularität von mobilen Computer- und Kommunikationsgeräten führt neue Herausforderungen an Dienste auf dem Internet ein. Mobile Endstellen können Benutzern Information liefern, wenn sie benötigt wird und wo sie benötigt wird. Benutzer wünschen allgegenwärtigen Zugriff auf Information und Anwendungen von dem jeweiligen Gerät. Sie wünschen auch auf diese Information zuzugreifen und sie zu aktualisieren, wo auch immer sie sich gerade befinden.
-
Es ist jedoch wichtig, zu beachten, dass nicht sämtliche Endstellen mobil sein werden. Zukünftige Dienste müssen mit den verschiedensten Endgeräten kommunizieren können, sowohl mit denen, die mobil sind, als auch mit denen, die es nicht sind. Unterschiedliche Endgeräte haben sehr unterschiedliche Fähigkeiten.
-
Die Interoperabilität von verschiedenen Diensten und Endgeräten erfordert Standards auf mehreren Niveaus. Es reicht nicht aus, z. B. gemeinsame Kommunikationsprotokolle zu besitzen. Es würde sehr wichtig sein, gemeinsame Begriffe miteinander zu teilen und Einvernehmen darüber zu besitzen, was in einem gewissen Kontext ein gewisses Datum bedeutet. Jedoch ist es sehr schwierig gewesen, über diese Punkte Einigkeit zu erzielen, da es eine außerordentlich große Anzahl von Firmen, Organisationen und anderen Akteuren auf diesem Gebiet gibt.
-
Viele Dienste müssen Buchungen managen können. Sie umfassen zum Beispiel Buchungstermine für Gesundheitsdienste; eine Buchung von Reisereservierungen für Hotels, Fluggesellschaften und Leihwagen; eine Buchung von Tickets für Veranstaltungsorte; eine Buchung von Terminen zur Fahrzeugwartung; eine Buchung einer Wohnraumpflege; usw.. Es würde sehr nützlich sein, wenn diese Dienste Information voneinander erhalten könnten. Zum Beispiel könnte, wenn ein Kunde Tickets für ein Konzert bucht, er oder sie wünschen, auch einen Tisch in einem Restaurant zu buchen. Es hilft, wenn der Buchungsdienst des Restaurants eine Basisinformation, wie Datum und Name des Kunden, vom Buchungssystem des Theaters erhält. Unglücklicherweise hat es keine Techniken gegeben, um Information zwischen unterschiedlichen Arten von Buchungssystemen auszutauschen.
-
Es gibt viele Techniken, um Information zwischen Diensten auszutauschen. Wenn man von Diensten spricht, die Buchungs- oder Kalenderfunktionen umfassen, findet ein Informationsaustausch häufig als Synchronisieren von Buchungs- oder Kalendereinträgen statt. Zu diesem Zweck laufen im Augenblick mehrere wichtige Standardisierungsbemühungen. Zum Beispiel ist SyncML eine Industrieinitiative, um ein einziges gemeinsames Datensynchronisationsprotokoll zu entwickeln und zu fördern.
-
vCalendar ist ein Austauschformat zur persönlichen Terminierungsinformation. Es ist auf die verschiedensten Kalender- und Terminierungsprodukte anwendbar und ist beim Austauschen von Information über einen breiten Bereich von Transporttechniken nützlich. Eine Anzahl von Anbietern hat die Spezifikation übernommen, weil sie ermöglicht, dass ihre Produkte Kalender- und Terminierungsinformation austauschen. vCalendar ist eine offene Spezifikation auf Grundlage von Industriestandards, wie z. B. die x/Open- und XAPIA-Kalender- und Terminierungs-API (CSA), der internationale ISO-8601-Datums- und Zeitstandard und die verwandten MIME-eMail-Standards. Das vCalendarformat nutzt Daten, die normalerweise in einer Kalender- und Terminierungsanwendung gespeichert sind, wobei der plattformübergreifende Austausch von Information über Gegenstände, wie z. B. Ereignisse und durchzuführende Handlungen, erleichtert wird. Ein Ereignis ist eine Kalender- und Terminierungsentität, die eine bestimmte Zeitdauer auf einem Kalender darstellt. Eine durchzuführende Handlung ist eine Kalender- und Terminierungsentität, die einen Aktionsgegenstand oder eine Zuweisung darstellt. Zum Beispiel kann sie ein Arbeitsgegenstand sein, der einer Einzelperson zugewiesen ist.
-
vCard automatisiert den Austausch von persönlicher Information, die man typischerweise auf einer herkömmlichen Geschäftskarte findet. vCard wird bei Anwendungen wie z. B. Internetmail, Voicemail, Web-Browsern, Telefonanwendungen, Call-Centern, Videokonferenzen, PIMs (Personal Information Managers [persönliche Informationsmanager]), PDAs (Personal Data Assistants [Personaldatenassistenten]), Rufanlagen, Fax, Bürogeräten und Smartcards verwendet. Zusätzlich zum Text kann vCard-Information Elemente wie Bilder, Firmenlogos, Live-Web-Adressen usw. umfassen.
-
Wie diese Beispiele zeigen, hat es Unmengen an Bemühungen gegeben, um Systeme zu erstellen, die Buchungssysteme synchronisieren können. Ein übliches Problem bei all diesen vorhandenen Lösungen besteht darin, dass sie keine gemeinsame Semantik für unterschiedliche Systeme liefern. Wenn ein Eintrag vorläufig ist, können ihn zum Beispiel unterschiedliche Systeme auf unterschiedliche Weisen interpretieren.
-
Ein anderes Problem besteht darin, dass Buchungssysteme mehrere unterschiedliche und normalerweise ziemlich komplexe Benutzeroberflächen aufweisen. Wenn ein Kunde wünscht, sowohl einen Termin bei einem Zahnarzt zu vereinbaren als auch ein Taxi zu buchen, das ihn oder sie dorthin bringt, muss der Kunde die gesamte Buchungsinformation beiden Buchungssystemen auf unterschiedliche Weisen eingeben.
-
Noch ein Problem besteht darin, dass es zu einer Herausforderung wird, Auftraggeberantworten zu managen, wenn man einem Auftraggeber eine Anzahl von Fragen vorgelegt hat. Zum Beispiel ist es vernünftig, SMS-Textmitteilungen zu verwenden, um einen Auftraggeber zu fragen, welche Option er oder sie wählt, weil es in vielen Ländern, wie in Finnland, sehr üblich ist, mit SMS-Textmitteilungen zu kommunizieren, und sie für Bedienpersonen Einkommen erzeugen. Jedoch kann es, wenn ein Auftraggeber auf mehrere Anfragen durch Senden einer Anzahl von Textmitteilungen antwortet, mühselig sein, herauszufinden, welche Antwort einer gewissen Frage entspricht, weil die Antwort nicht automatisch einen Bezug auf die Frage beinhaltet. Wenn z. B. ein Dienst einen Auftraggeber fragt, ob er oder sie – zusätzlich zu einem Flugticket – auch wünscht, ein Taxi und ein Hotelzimmer zu reservieren und der Auftraggeber ”ja” auf eine Frage aber ”nein” auf die andere antwortet, dann weiß der Dienst nicht notwendigerweise, welches Angebot der Auftraggeber akzeptiert hat.
-
Ziel der Erfindung
-
Das Ziel der Erfindung besteht darin, die oben erwähnten Nachteile zu beseitigen oder sie zumindest signifikant zu verringern. Die Erfindung ermöglicht eine neue Art von wertschöpfenden Diensten, die insbesondere für mobile Dienste wesentlich sind.
-
Es ist ein weiteres Ziel der Erfindung, ein System bereitzustellen, das Transaktionen vom Buchungstyp vornehmen kann, das mindestens einen Diensteanbieter und eine Mehrzahl von Benutzern einschließt, die jeweils mit einem Mobiltelefon kommunizieren, das kurze Textmitteilungen empfangen und senden kann.
-
Es ist ein weiteres Ziel der Erfindung, ein System bereitzustellen, das Transaktionen vom Buchungstyp zwischen einer Mehrzahl von Diensteanbietern und einer Mehrzahl von Benutzern vornehmen kann, die jeweils mit einem Mobiltelefon kommunizieren, das kurze Textmitteilungen empfangen und senden kann.
-
Kurze Beschreibung der Zeichnungen
-
Im folgenden Abschnitt wird die Erfindung mit Hilfe einiger Beispiele ihrer Ausführungsformen in Einzelheit beschrieben.
-
1 stellt ein vorteilhaftes System gemäß der Erfindung dar;
-
2 stellt ein zweites vorteilhaftes System gemäß der Erfindung dar;
-
3 stellt ein drittes vorteilhaftes System gemäß der Erfindung dar;
-
4 ist ein vorteilhaftes Beispiel für ein Ablaufdiagramm, wobei Mitteilungen dargestellt sind, die in einem System gemäß der Erfindung übertragen werden;
-
5 ist ein zweites vorteilhaftes Beispiel für ein Ablaufdiagramm, wobei Mitteilungen dargestellt sind, die in einem System gemäß der Erfindung übertragen werden.
-
6 stellt ein Beispiel für die dynamische Dialogmatrix dar, die auf eine Frage und Antwort angewandt wird, gemäß der Erfindung.
-
7 stellt die Phasen des Buchungsprozesses in einer bevorzugten Ausführungsform der Erfindung dar.
-
8 stellt ein Matrixdiagramm entsprechend Beispiel 2 dar, gemäß einer bevorzugten Ausführungsform der Erfindung.
-
Beschreibung der Erfindung
-
Die Erfindung betrifft ein Austauschen und Synchronisieren von Information zwischen Buchungssystemen und Benutzerendgeräten. Die Dienste können z. B. sein: eine Buchung von Terminen für Gesundheitsdienste; eine Buchung von Reisereservierungen für Hotels, Fluggesellschaften und Leihwagen; eine Buchung von Tickets für Veranstaltungsorte; eine Buchung von Terminen zur Fahrzeugwartung; eine Buchung einer Wohnraumpflege; usw..
-
Das Buchungssystem gemäß der Erfindung umfasst mindestens ein Diensteanbieter-Buchungssystem; mindestens einen Diensteanbieter; einen Vermittler; einen Auftraggeber; mindestens ein Auftraggeberendgerät, das ein Mobilgerät sein kann, das Textmitteilungen empfangen kann und das einen Dialog enthält; und Telekommunikationsverbindungen, die verwendet werden, um die Diensteanbieter-Buchungssysteme, die Diensteanbieter, den Vermittler und das Auftraggeberendgerät miteinander zu verbinden.
-
Die Diensteanbieter sind diejenigen, mit denen Auftraggeber Termine, Reservierungen oder andere Buchungen vereinbaren wollen, und umfassen die Ressourcen, die dazu bestimmt sind, dass das Buchungssystem sie zuweist. Diensteanbieter führen ein Geschäft mittels Diensteanbieter-Buchungsdienste durch. Wie in dieser Anmeldung verwendet, ist der Vermittler ein netzwerkbasierter Dienst, der für die Diensteanbieter-Buchungsdienste über das Netzwerk verfügbar ist, der zusätzliche Semantik, Übersetzungs- und Synchronisations-Dienste bereitstellt, die zur Übermittlung der Information benötigt werden, die für einen Auftraggeber benötigt wird, um eine Transaktion mit einem Diensteanbieter zu vervollständigen. Die Diensteanbieter-Buchungsdienste und der Vermittler sind vorzugsweise Anwendungen, die auf Netzwerkservern laufen, wie z. B. das Internet oder ein privates Intranet. Im Allgemeinen umfasst ein System eine Mehrzahl von Diensteanbietern und Diensteanbieter-Buchungssystemen (die Diensteanbieter-Buchungsdienste implementieren), aber es ist möglich, dass man für nur einen Diensteanbieter ein einfaches Buchungssystem besitzt, in welchem Fall der Vermittler und Diensteanbieter in eine einzige Anwendung festintegriert sein könnten.
-
Auftraggeber umfassen vorzugsweise Auftraggeber, die auf Mobiltelefonen kommunizieren, die kurze Textmitteilungen empfangen können, wie z. B. Short Message Service [Kurznachrichtdienst] (SMS)-Mitteilungen. Natürlich wird ein System, das SMS-Mitteilungen handhaben kann, auch andere Auftraggeber mit größeren Fähigkeiten handhaben. Der Vermittler kommuniziert vorzugsweise mit Mobiltelefonauftraggebern mittels eines SMS-Gateways, wie sie z. B. durch Mobiltelefonanbieter betrieben werden und heutzutage wohlbekannt sind. Der Vermittler kommuniziert unter Verwendung von Dialogen mit Auftraggebern. Dialoge sind Kurzmitteilungen, die dem Auftraggeber Information darbieten und eine einfache Antwort ermöglichen. Dialoge stellen Benutzer vor einfache Wahlentscheidungen, wie z. B. ja/nein oder um eine Selektion aus einer geordneten Liste zu ermöglichen. Dialoge können auch Einwegdialoge sein, wie z. B. um eine Reservierung zu quittieren. Eine Transaktion kann typischerweise eine Folge von Dialogen beinhalten, die jeweils eine einfache Antwort einschließen. Dialoge umfassen eine asynchrone Kommunikation durch Mitteilungen. Das wie beschriebene System macht es möglich, Buchungen zwischen unterschiedlichen Diensteanbietersystemen abzustimmen, um einem Bedarf eines Auftraggebers zu entsprechen, z. B. eine Abstimmung einer Fluggesellschaftsbuchung mit einem Transport zum Flugplatz.
-
1 ist ein Diagramm des einfachsten Systems, das umfasst: ein einziges Diensteanbieter-Buchungssystem 100 für einen einzigen Diensteanbieter, einen Vermittler 102, der mit dem Diensteanbieter über ein Netzwerk kommuniziert, und einen Benutzer mit einem Mobiltelefon, das einen Dialog aufweist, der darauf eingegeben wird.
-
2 stellt eine Mehrzahl von Diensteanbieter-Buchungssystemen dar, die mit einem Vermittler über ein Netzwerk kommunizieren.
-
3 stellt einen Vermittler mit Namen BookIT dar, der mit verschiedenen Diensteanbietersystemen und Benutzern mit Telefongeräten kommuniziert, die Dialoge übertragen.
-
Ein auf Vernunft gegründeter Kundendialog ist vom Standpunkt des Auftraggebers eine wünschenswerte Verbesserung, weil Diensteanbieter ihre eigenen Dialoge in Verbindung mit jedem Buchungsereignis erzeugen können. Ein Dialog steht in enger Beziehung mit einer gewissen Buchungssituation. Er wird im richtigen Augenblick automatisch aktiv, oder der Auftraggeber kann den Dialog nach Bedarf aktivieren, oder eine andere Entität im System kann eine Mitteilung zum Dialog senden, um ihn zu aktivieren. Der Dialog sendet dann eine Anfrage zu einer anderen Entität im System oder informiert den Auftraggeber, und fragt möglicherweise Wahlentscheidungen eines Auftraggebers an. Mit Hilfe dieser Dialogart kann der Auftraggeber in mehreren Buchungssystemen unter Verwendung nur einer Benutzeroberfläche Reservierungen tätigen. Der Dialog stellt eine Verbindung zu entfernten Buchungssystemen her, z. B. durch das Internet oder selbst mobile Netzwerke.
-
Ein Vermittlerdienst kann Buchungsinformation zwischen Diensteanbieter-Buchungssystemen übertragen. Z. B. kann, nachdem eine Buchung in ein Fluggesellschafts-Buchungssystem eingegeben ist, ein Taxi-Buchungssystem dem Auftraggeber eine Mitfahrgelegenheit zum Flugplatz anbieten. In dieser Anwendung ist eine Buchung eine Zuweisung einer einzigen Ressource (entweder die Fluggesellschaftsbuchung oder das Taxi in dem vorhergehenden Beispiel), während eine Reservierung die Vereinigung der Buchungen für sämtliche Ressourcen für dasselbe Ereignis ist (die Fluggesellschaftsbuchung plus die Taxibuchung in dem vorhergehenden Beispiel). Der Dialog zwischen dem Auftraggeber, dem Vermittler und den Buchungssystemen sowie gespeicherte Kundenprofile gewährleisten, dass der Auftraggeber den auf Vernunft gegründeten Dienst, den er oder sie benötigt, nicht dagegen aufdringliche Werbung bekommt.
-
Ein Auftraggeber kann Reservierungen tätigen sowie sie unter Verwendung von vielen Arten von Kommunikationseinrichtungen, einschließlich aber nicht beschränkt auf das Internet, eMail und mobile Endstellen, bestätigen, ändern und stornieren. Der Auftraggeber kann auch einen Kalender, der durch den Vermittler oder einen Diensteanbieter bereitgestellt wird, mit einem Kalender in einem Endgerät synchronisieren, wobei Synchronisationsfunktionen des Vermittlers verwendet werden.
-
Ein Diensteanbieter kann Auftraggeber daran erinnern, Reservierungen auf einer regelmäßigen Basis vorzunehmen und folglich eine Kundenloyalität erhöhen. Ein Vermittler kann Diensteanbietern helfen, ihre Buchungssysteme zusammen zu bringen, um umfassendere Dienste bereitzustellen, ohne dass ihr Geschäft unnötig ausgeweitet wird. Wegen der Internationalisierung ist der Vermittler imstande, z. B. viele Sprachen, Zeitzonen, Währungen und Datenformate zu unterstützen.
-
Das System, das mindestens einen Dialog, einen Vermittler, einen Diensteanbieter und ein Diensteanbieter-Buchungssystem einschließt, kann sich auf einem der folgenden Niveaus befinden:
- 1. Es gibt einen vorbestimmten Satz von Dialogen im System. Ihr Inhalt und die möglichen Wahlentscheidungen werden im voraus festgelegt. Z. B. bietet, wenn ein Auftraggeber einen Flug bucht, ein Dialog immer gewisse andere Buchungen an. Frühere Aktionen des Auftraggebers werden nicht berücksichtigt.
- 2. Es gibt eine unbegrenzte Anzahl von dynamischen oder ”intelligenten” Dialogen, die z. B. basieren auf: einem Profil, das ein Auftraggeber oder eine Auftraggeberin selbst erzeugt hat, Aufzeichnungen über Benutzungen in der Vergangenheit und dem Ort des Auftraggebers. Eine einfache Logik unterstützt Entscheidungen. Es ist ein Expertensystem von niedrigem Niveau.
- 3. Das System kann Entscheidungen selbst fällen und kann eine Entscheidungsfindung des Auftraggebers unterstützen. Auf diesem Niveau kann ein Dialog ein Expertensystem von hohem Niveau umfassen. Es kann als ein Agent wirken und mit mehreren Diensteanbietern verhandeln, um das beste Angebot zu bekommen, ohne dass der Auftraggeber direkt einbezogen wird.
-
In einer bevorzugten Ausführungsform der Erfindung bucht ein Auftraggeber einen Dienst von einem Diensteanbieter. Die Buchung kann unter Verwendung einer Endstelle durchgeführt werden, die mit dem Vermittlerdienst verbunden ist. Zuerst stellt der Auftraggeber unter Verwendung eines Dialogs eine Verbindung mit dem Vermittlerdienst her. Der Auftraggeber gibt eine Reservierungsanfrage zum Dialog ein, der die Anfrage zum Vermittler sendet. Der Vermittler fragt unter Verwendung von Begriffen und einer Terminologie, die diese Dienste interpretieren können, mögliche Reservierungen vom Informationssystem des Diensteanbieters an. Die Anfrage beruht auf Präferenzen des Auftraggebers. Der Auftraggeber offenbart einige Präferenzen, die in Beziehung zu der spezifischen Buchung stehen, wenn er oder sie eine Reservierungsanfrage zum Dialog eingibt. Zusätzlich kann der Dialog und der Vermittlerdienst allgemeine Präferenzen des Auftraggebers gespeichert haben und sie verwenden, so dass der Auftraggeber nicht sämtliche Präferenzen jedes Mal eingeben muss.
-
Managen der Anfrage und der Buchungen beruht auf komplizierten Zustandsmodellen. Jede Buchung beinhaltet mehrere Phasen, die durch Zustände beschrieben werden, die ihren Status über ihre Lebensdauer verfolgen. Zum Beispiel weist, wenn sich der Vermittler über eine Reservierung von einem Diensteanbieter erkundigt hat, der entsprechende Eintrag in jedem System einen Zustand auf, dass die Buchung unerledigt, aber nicht bestätigt ist. Wenn die Systeme keine gemeinsame Übereinkunft darüber aufweisen, was ein gewisser Zustand bedeutet, übersetzt der Vermittler es ihnen. Ein bevorzugter Buchungsprozess, der die Phasen und Zustände einschließt, ist in Beispiel 1 beschrieben.
-
Zusätzlich zur Anfrage von Reservierungen von dem Diensteanbieter kann der Vermittler Buchungen in mehreren Systemen des Diensteanbieters synchronisieren. Die Synchronisation beruht auf Regeln, die in dem Vermittlerdienst spezifiziert sind. Z. B. kann eine Regel sein, dass ”wenn ein Auftraggeber eine Buchung für ein Fluggesellschaftsticket anfragt: frage auch Buchungen für Taxis zum Flugplatz an.” Deshalb kann eine Anfrage vom Auftraggeber im Vermittlerdienst vervielfacht werden, was zu einer Anzahl von Anfragen führt. Die Diensteanbieter antworten dem Vermittler, wenn sie imstande sind, einen angeforderten Dienst bereitzustellen, und sie können einige Zusatzinformation hinzufügen, wie über Sitze oder Zeitablauf. Der Vermittler vereinigt gesammelte Information und sendet sie zum Dialog, der dem Auftraggeber eine einfache Liste von Optionen zeigt. Z. B. kann der Dialog drei Optionen für einen Flug aufzeigen und fragen, ob der Auftraggeber auch wünscht, ein Taxi zu reservieren, das tatsächlich bereits vorläufig vom Vermittler gebucht ist. Der Auftraggeber fällt seine oder ihre Entscheidung, indem die Optionen aus der einfachen Liste von Alternativen gewählt werden. Der Dialog sendet Information über die Wahlentscheidung des Auftraggebers zum Vermittler, der die Buchungen in Übereinstimmung mit den Wahlentscheidungen des Auftraggebers bestätigt und die unnötigen Reservierungen storniert.
-
4 stellt ein Ablaufdiagramm einer Anfrage CINQ1 dar, die von einem Auftraggeber unter Verwendung eines zum Vermittler gesendeten Dialogs DINQ1 erzeugt wurde. Der Vermittler initiiert die Anfrage MINQ1, die CINQ1 und DINQ1 entspricht, zum Buchungssystem 1, einem Diensteanbieter-Buchungssystem. Schließlich kommt eine Antwort DANS1 zum Auftraggeber zurück, wobei eine Wahl angeboten wird, auf die mit einer Selektion CSEL1 reagiert wird, was zu einer Buchung durch den Auftraggeber auf dem Buchungssystem 1 führt. Der Vermittler erkennt den potenziellen Bedarf an einem komplementären Dienst vom Buchungsdienst 2 und initiiert eine Anfrage, MINQ2, zum Buchungssystem 2, die schließlich zu einem Vorschlag führt, der mehrere zum Auftraggeber rückgeführte Wahlentscheidungen, DANS2, einschließt, aus denen eine Selektion, CSEL2, vorgenommen wird, was zu einer komplementären Buchung auf dem Buchungssystem 2 führt.
-
Die Buchungen können ebenso auf andere Weisen getätigt werden, z. B. indem der Diensteanbieter telefonisch angerufen wird oder indem das Büro des Diensteanbieters vor Ort besucht wird. In diesem Fall kann der Diensteanbieter den Vermittler über Buchungen des Auftraggebers informieren, so dass der Vermittler den Auftraggeber über andere Optionen informieren kann. Zum Beispiel könnte ein Zahnarzt dem Vermittler erzählen, dass der Auftraggeber einen Termin gebucht hat, so dass der Vermittler anbieten kann, auch ein Taxi zu buchen.
-
Auch ist es möglich, eine Gedächtnisstütze zum Vermittlerdienst hinzuzufügen, so dass der Vermittler zu einer gewissen Zeit anfragt, ob der Auftraggeber eine neue Buchung zu machen wünscht. Zum Beispiel kann der Vermittler eine Anzeige zum Auftraggeber senden, dass es ein Jahr her ist, seit der Auftraggeber zum letzten Mal einen Termin bei seinem oder ihrem Zahnarzt hatte, und fragen, ob der Auftraggeber wünscht, einen neuen Termin zu vereinbaren. Diese Anzeige kann bereits einige Optionen für den Termin enthalten. Der Vermittler hat den Kalender des Auftraggebers überprüft, ob er oder sie dies ermöglicht hat, so dass die gegebenen Optionen für den Auftraggeber bequem sind. Der Dialog stellt die Optionen auf eine einfache und leicht zu handhabende Weise dar. Der Auftraggeber braucht bloß zu wählen, welche Option für ihn oder sie die beste ist, oder ob er oder sie wünscht, neue Optionen zu bekommen oder die Buchung aufzuschieben. 5 ist ein Zeitfolgediagramm für eine solche Situation, wo die ursprüngliche Anfrage, MINQ1, durch den Vermittler initiiert wurde.
-
Beispiel 1 – Ein bevorzugtes Buchungssystem
-
Ein bevorzugtes Buchungssystem gemäß der Erfindung wird hinsichtlich eines Systems mit Namen BookIT unten beschrieben.
-
BookIT ist so entworfen, dass es eine Schnittstelle zwischen Diensteanbieter-Buchungssystemen und anderen Parteien über ein Netzwerk, wie z. B. das Internet, und zu Endbenutzer-Auftraggebern bildet, die mit Mobiltelefonen ausgerüstet sind, die Textmitteilungen empfangen können. Das erstere wird vorzugsweise mit einer generischen XML-Schnittstelle erreicht. BookIT unterstützt vCard- und vCalendar-Standards, da sie von allen größeren Buchungs- und Kalender-Systemen verwendet werden.
-
BookIT kommuniziert mit Mobiltelefon-Benutzern unter Verwendung des Short Message Service [Kurznachrichtendienst] (SMS) über ein SMS-Gateway zur asynchronen Kommunikation. BookIT verwendet die neue dynamische Dialogmatrix (DDM) zur sicheren Übertragung und Abbildung der SMS-Mitteilungen. Die DDN wird unten weiter beschrieben.
-
Eine klare Unterscheidung muss zwischen einem Diensteanbieter-Buchungsprozess und BookIT-Prozess gemacht werden. Der erstere deckt nur die Standardbuchung mit Zeit- und Resource-Reservierung ab. Der letztere besteht aus Buchen, Bearbeitung und Finanzierung. Beide Prozesse endigen zum selben Punkt. Der BookIT-Prozess besteht aus sieben Phasen, wie folgt:
-
Phasen (Statushandhabung)
-
Die Phasen stellen eine Verbindung (Gummiband) zwischen den Ressourcen her. In jeder der Phasen des BookIT-Prozesses werden die mit dem Buchen in Zusammenhang stehenden Daten verbessert, um die Erfordernisse der fraglichen Phase widerzuspiegeln. Für die Status und Werte betrachte man bitte die untere Tabelle.
-
Die Phasen werden in der folgenden Erörterung in größerer Einzelheit beschrieben.
-
1. Anmelden
-
Anmelden bedeutet Initialisierung eines BookIT-Prozesses und eines Buchungsprozesses. Infolge der Initialisierung wird ein Eintrag in die Datenbank-w/Basisinformation eingefügt. Er erscheint nicht in einem Kalender, da es keine Terminierungsinformation gibt. Er kann in einer separaten Aufgabenliste des Besitzers als eine offene Aufgabe angezeigt werden.
-
2. Anfordern
-
In der Anforderungsphase wird eine Buchungsanforderung zu den Ressourcen gesandt, die für die zuvor angemeldete Aufgabe erforderlich sind. Da es kein Terminieren gibt, was in den meisten Fällen wesentlich sein wird, kann diese Phase zusammen mit der Terminierungsphase durchgeführt werden.
-
3. Terminieren
-
Dem Besitzer und den Ressourcen wird ein Terminplan gegeben. Als ein Teil und ein Ergebnis des Terminierens werden die folgenden Daten benötigt:
- a vorgeschlagener Anfangszeitpunt (ISO-Zeitstempel-w/Zeitzone)
- b vorgeschlagene Anfangsstelle (Koordinaten)
- c vorgeschlagener Endzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
- d vorgeschlagene Endstelle (Koordinaten)
-
4. Bestätigen
-
Zeit und Stelle, wie sie durch die Ressourcen akzeptiert sind, die akzeptiert haben. Daten, die mit dieser Phase in Zusammenhang stehen:
- a akzeptierter Anfangszeitpunkt (ISO-Zeitstempel-w/Zeitzone)
- b akzeptierte Anfangsstelle (Koordinaten)
- c akzeptierter Endzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
- d akzeptierte Endstelle (Koordinaten)
-
Standardmäßig werden die Daten aus der Planungsphase kopiert.
-
In der Praxis können, wenn die geplante Zeit nicht benötigt wird, dieselben Datenstrukturen dafür verwendet werden, und Status zeigt die aktuelle Bedeutung der Daten an.
-
5. Bearbeiten
-
Die Ressourcen führen die gebuchte Aufgabe durch. Mit dieser Phase in Zusammenhang stehende Daten bestehen aus unterschiedlichen Merkmalen und ihren Werten, die mit der aktuellen Aufgabe in Zusammenhang stehen. Zusätzlich werden die folgenden statischen Strukturen benötigt:
- a aktueller Startzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
- b aktuelle Startstelle (Koordinaten)
- c aktueller Endzeitpunkt (ISO-Zeitstempel-w/Zeitzone)
- d aktuelle Endstelle (Koordinaten)
- d Produkte, die verwendet werden, Extras, Kilometerleistung, ...
-
Standardmäßig werden die Daten aus der Bestätigungsphase kopiert.
-
6. Buchführen
-
An diesem Punkt werden alle Daten, die in den Datenstrukturen bei vorhergehende Phasen gespeichert wurden, analysiert und für Fakturierungszwecke verarbeitet.
-
Die mit dieser Phase in Zusammenhang stehende Daten: Buchführungsdaten. Getrennt zu definieren.
-
7. Beendigen
-
Die Aufgabe ist beendigt worden. Vom Standpunkt des gesamten BookIT-Prozesses ist es irrelevant, ob der Aufgabe ein Erfolg beschieden war oder nicht. Es ist relevant für die Buchführungsphase, in der die finanziellen Aktionen zum Organisator gehandhabt werden. In dieser Phase wird Systemverwaltung (Datenbankinhalte; temporäre Dateien, ...) ausgeführt, um den BookIT-Prozess zu beendigen.
-
Die folgende Tabelle zeigt Daten, die in jeder Phase verfügbar sind. Die Buchungsphase ist in Kursivschrift.
-
-
Phasenstatus, Werte und Übergänge
-
Die folgende Tabelle beschreibt die Phasen, ihre Status und Werte zusammen mit einem Übergang zur nächsten logischen Phase auf Grundlage der erhaltenen Werte. Zusätzlich sind entsprechende vCalendarstatus dargestellt, wenn zutreffend.
| Phase | Status | Nächste Phase | vEvent | vTodo |
| Anmelden | | Anfordern | | |
| Anfordern | | Terminieren | Gesendet | Gesendet |
| Terminieren | Unerledigt | Bestätigen | Benötigt Aktion | Benötigt Aktion |
| Terminieren | Terminiert | Bestätigen | Benötigt Aktion | Benötigt Aktion |
| Terminieren | Neuterminiert | Bestätigen | Benötigt Aktion | Benötigt Aktion |
| Bestätigen | Akzeptiert | Bearbeiten | Bestätigt | Akzeptiert |
| Bestätigen | Abgelehnt | Buchführen | Abgelehnt | Abgelehnt |
| Bestätigen | Vorläufig | Buchführen | Vorläufig | |
| Bestätigen | Delegiert | Anfordern | Delegiert | Delegiert |
| Bestätigen | Neuteminieren angefordert | Buchführen oder Terminieren | | |
| Bestätigen | Im Gange | Bearbeiten | | |
| Bearbeiten | Im Gange | Bearbeiten | | |
| Bearbeiten | Verzögert | Bearbeiten | | |
| Bearbeiten | Gestartet | Bearbeiten | | |
| Bearbeiten | n% fertig | Bearbeiten | | |
| Bearbeiten | Bereit | Buchführen | | |
| Buchführen | | Beendigen | | |
| Beendigen | <Kopiert von Phase vor Buchführen> | n/a | | |
-
Angehaltene, neugestartete und stornierte interne Phasen wirken für alle relevanten Phasen an einem beliebigen Punkt wie folgt:
| <Phase y> | Angehalten | <Status x> | | |
| <Phase y> | Neugestartet | <Status x> | | |
| <Phase y> | Storniert | Buchführung | | |
-
6 stellt die Arbeitsflussübergänge von Phase zu Phase dar. Für Bedingungen, siehe die obige Tabelle. Auch beachte man bitte, dass ein Storniert-Status immer zur Buchführung führt.
-
Bestätigen der (ganzen) Reservierung
-
Damit die ganze Reservierung erfolgreich ist, müssen alle Ressourcen, die die Reservierung akzeptierten, dieselbe Terminierung aufweisen. Zusätzlich gibt es Ressourcen in unterschiedlichen Funktionen, und mit der Bearbeitungsphase in Zusammenhang stehende Daten können selbst stark variieren.
-
Die unterschiedlichen Status der ganzen Reservierung sind:
- a ”Keine Antworten” (0) für ”Niemand hat auf die Anforderung, die vom Organisator gemacht wurde, geantwortet”
- b ”Keine Ablehnungen” (1) für ”Nicht alle Eingeladenen haben schon geantwortet. Diejenigen, die geantwortet haben, haben akzeptiert”
- c ”Alles Akzeptierungen” (2) für ”Alle Eingeladenen haben bestätigt”
- d ”Einige Ablehnungen” (3) für ”Einige der Eingeladenen haben abgelehnt”
- e ”Alles Ablehnungen” (4) für ”Sämtliche Eingeladenen haben abgelehnt”.
-
Die folgende Entscheidungstabelle hilft beim Auswerten des Status der ganzen Buchung. ”Vielleicht” bedeutet, dass diese Bedingung allein ein wahres oder falsches Ergebnis nicht unstreitig spezifiziert.
| Buchungsstatus\Bustätigungn | Niemand antwortete | Niemand akzeptierte | Einige akzeptierten | Alle akzeptierten | Niemand lehnte ab | Einige lehnten ab | Alle lehnten ab |
| Keine Antworten | Wahr | Vielleicht | | | Vielleicht | | |
| Keine Ablehnungen | Wahr | Vielleicht | Vielleicht | Wahr | Wahr | | |
| Keine Akzeptierungen | Wahr | Wahr | | | Vielleicht | Vielleicht | Wahr |
| Alles Akzeptierungen | | | Wahr | Wahr | Vielleicht | | |
| Einige Akzeptierungen | | | Wahr | Vielleicht | Vielleicht | Vielleicht | |
| Alles Ablehnungen | | Vielleicht | | | | | Wahr |
| Einige Ablehnungen | | Vielleicht | Vielleicht | | | Wahr | Vielleicht |
-
Auf Grundlage der Information und Entscheidungstabelle oben muss der Organisator/die Anwendung die Entscheidung darüber fällen, was mit der Reservierung zu machen ist. Dies kann eine automatische Entscheidung sein, die durch das System auf Grundlage von voreingestellten Regeln gefällt wird oder durch den Organisator von Hand vorgenommen wird.
-
Ein Hauptproblem, das durch die Erfindung gelöst wird, ist die Herausforderung, Auftraggeberantworten zu managen, wenn einem Auftraggeber eine Anzahl von Fragen aufgegeben worden ist und der Auftraggeber SMS-Textmitteilungen oder eine ähnliche Technologie verwendet, wobei eine Antwort nicht automatisch einen expliziten Bezug auf die Anfrage einschließt. Die Erfindung löst dieses Problem unter Verwendung von dynamischen Dialogmatrizen. Eine Anfrage schließt immer eine gewisse Art von Adresse oder Identifizierung des Empfängers ein. Im Fall der SMS-Textmitteilung ist dies die sogenannte B-Teilnehmernummer. Andererseits wird die A-Teilnehmernummer des Senders oder Calling Line Identity [A-Teilnehmeranzeige] (CLI) oder eine ähnliche Identifizierung ebenfalls an jede Textmitteilung angehängt. Deshalb kann der Auftraggeber oder B-Teilnehmer normalerweise leicht auf eine Mitteilung unter Verwendung der Erwiderungs- oder Antwort-Funktion des Mobilgeräts antworten.
-
Wenn ein Vermittlerdienst, der Anfragen zu einem Auftraggeber sendet, unterschiedliche A-Teilnehmernummern bei unterschiedlichen Anfragen verwendet, ist es möglich, zwischen Antworten zu unterscheiden, was darauf beruht, zu welcher Nummer der Auftraggeber Antworten sendet. Wenn ein Vermittler einem Auftraggeber eine Anfrage ”Benötigen sie auch ein Taxi?”, wobei eine A-Teilnehmernummer A1 verwendet wird, und dann Anfragen ”Benötigen Sie ein Hotelzimmer?” von der A-Teilnehmernummer A2 sendet, geht beispielsweise die Antwort des Auftraggebers auf die erste Frage an Nummer A1, und die zweite Antwort geht an Nummer A2. Unter Verwendung einer Dialogmatrix verfolgt ein Vermittler laufend Anfragen und Antworten. In der Matrix gibt es eine Spalte für jeden Auftraggeber und eine Reihe für jede A-Teilnehmernummer, die der Vermittler verwendet. Augenscheinlich könnte es eine Reihe für jeden Auftraggeber geben und entsprechend ebenso eine Spalte für jede A-Teilnehmernummer. Nach Senden einer Anfrage von einer gewissen A-Teilnehmernummer zu einem Auftraggeber wird der Status und die Antwort in der entsprechenden Schale der Matrix gespeichert. Infolgedessen kann der Vermittler herausfinden, ob der Auftraggeber auf eine gewisse Anfrage geantwortet hat und was die Antwort war. Auch ist es möglich, die Matrix zu verwenden, um Information über das Verhalten des Auftraggebers zu sammeln und sie zum Beispiel für Marketingzwecke zu verwenden. Ein Vermittler benötigt nur eine beschränkte Anzahl von A-Teilnehmernummern. Eine Dialogmatrix kann auch verwendet werden, um herauszufinden, welche A-Teilnehmernnummern verwendet werden können, wenn die nächste Anfrage zu einem gewissen Auftraggeber gesendet wird.
-
Die Verwendung der dynamischen Dialogmatrix wie oben beschrieben ist in 7 veranschaulicht.
-
Die dynamische Dialogmatrix ist auch ein starke, aber sehr einfache Sicherheitsmaßnahme zur Authentifizierung eines Mobiltelefonbenutzers, der nur die Fähigkeit aufweist, Mitteilungen zu senden und zu empfangen. Es besteht für einen Dienst das Problem, die Identität eines Senders zu bestätigen. Ein Weg zu versuchen, den Benutzer zu identifizieren, besteht darin, die Adresse des Senders zu überprüfen. Normalerweise weisen SMS, eMail und andere ähnliche Mitteilungen die Adresse des Senders angehängt auf. Diese Adresse kann zum Beispiel die A-Teilnehmernummer des Senders oder die Calling Line Identity [A-Teilnehmeranzeige] (CLI) sein oder die eMail-Adresse oder IP-Adresse. Jedoch ist es ziemlich leicht, eine Senderadresse zu fälschen. Aus der Sicht des Diensteanbieters ist die Abwärtsstrecke von einem Diensteanbieter zu einem Benutzer normalerweise verhältnismäßig zuverlässig, und es ist für andere schwierig, Mitteilungen abzufangen oder zu ändern, aber die Aufwärtsstrecke von einem Benutzer zu einem Diensteanbieter ist viel anfälliger, und es ist nicht allzu schwierig, eine falsche Senderadresse anzugeben. Eine wohlbekannte Lösung für das obige Problem besteht darin, Verschlüsselungstechnologien zu verwenden, um die Kommunikationen zu sichern, wobei Public-Key-Infrastrukturen (PKI) gute Beispiele sind. Z. B. kann ein Benutzergerät mit einem Mikrochip, beispielsweise einer sicheren SIM-Karte in GSM-Geräten, ausgerüstet sein, um Mitteilungen unter Verwendung des privaten Schlüssels des Benutzers zu verschlüsseln. Der Diensteanbieter kann dann sicher sein, dass die Mitteilung vom Benutzer stammt, wenn sie unter Verwendung des öffentlichen Schlüssels des Benutzers entschlüsselt werden kann. Jedoch erfordert diese Lösung spezielle Geräte, die bisher nicht sehr üblich, kostengünstig oder standardisiert sind. Wenn man auf eine solche Lösung angewiesen ist, wird die Anzahl von möglichen Benutzern signifikant beschränkt.
-
Eine Verwendung der DDM liefert eine neue Lösung. Wenn der Dienst eine Anforderung zum Mobiltelefonbenutzer sendet, enthält jede Anforderung eine unterschiedliche, vorzugsweise zufällig gewählte Antwortnummer. Folglich ist eine zulässige Antwort nur diejenige, die zu der richtigen Antwortadresse gesendet wird.
-
Beispiel 2 – Verwendung der dynamischen Dialogmatrix
-
Dieses einfache Beispiel befasst sich mit dem Sichern von Tickets bei einem Morgenflug am nächsten Tag. Das System sendet eine Reihe von Fragen als SMS-Mitteilungen, die eine kurze Antwort erfordern. Jede Mitteilung ist gekennzeichnet, so dass ihre Antwort identifiziert werden kann, damit die Mitteilungen nicht notwendigerweise in einer speziellen Folge gesendet oder beantwortet werden müssen, es sei denn, dass die Logik es so fordert (z. B. wenn die Antwort auf eine Frage den Inhalt der nächsten Frage beeinflusst).
-
Ein Benutzer, dessen Telefonnummer ID = 0418 979 813 ist, hat das Ticket angefordert. Das System sendet die folgenden Anforderungen als einzelne SMS-Mitteilungen:
-
Bitte wählen Sie eine der folgenden Abflugzeiten:
| 6:00 vormittags | , | Antwort A |
| 7:30 vormittags | , | Antwort B |
| 8:15 vormittags | , | Antwort C. |
Wenn keine von diesen OK ist, antworten Sie mit D.
Sender: +358440844 027
-
Bitte wählen Sie eine Ticketklasse:
| Erste Klasse | , | Antwort A |
| Businessclass | , | Antwort B |
| Economyclass | , | Antwort C |
| Preiswerteste verfügbare | , | Antwort D |
Sender: +358440844 011
-
Bitte wählen Sie:
| Fenstersitz | , | Antwort A |
| Gangsitz | , | Antwort C |
Sender: +358440844 034
-
Bitte wählen Sie die Mahlzeit aus:
| Vegetarier | , | Antwort A |
| Rindfleisch | , | Antwort B |
| Huhn | , | Antwort C |
Sender: +358440844 003
-
Die von dem Kunden empfangenen Antworten auf die vorhergehenden Fragen und mehrere andere waren wie folgt:
'A' auf die Frage mit Kennnummer +358 440 844 027
'D' auf die Frage mit Kennnummer +358 440 844 011
'A' auf die Frage mit Kennnummer +358 440 844 034
'B' auf die Frage mit Kennnummer +358 440 844 003
'D' auf die Frage mit Kennnummer +358 440 859 751
'A' auf die Frage mit Kennnummer +358 440 844 277
'C' auf die Frage mit Kennnummer +358 440 841 368
-
Hieraus kann der Diensteanbieter herausfinden, dass der Kunde wählte:
| – den ersten Morgenflug | (= A), |
| – das preiswerteste verfügbare Ticket | (= D), |
| – einen Fenstersitz | (= A), |
| – Rindfleisch für die Mahlzeit | (= B), |
und usw..
-
Es ist wichtig zu beachten, dass der Kunde mit der Matrix die Fragen in einer beliebigen Reihenfolge beantworten kann, und es ihm selbst misslingen kann, einige Fragen zu beantworten. Wenn diese relevant sind, kann das System dringend um eine Antwort bitten. Wenn nicht, kann das System ohne diese Information fortfahren.
-
Die obigen Antworten sind in 8 als eine dreidimensionale Matrix dargestellt, wobei Kundennummern auf der X-Achse aufgetragen sind, Antwortnummern auf der Y-Achse aufgetragen sind und Antworten auf der Z-Achse aufgetragen sind. Unser Benutzer mit der Telefonnummer 0418 979 813 ist der am weitesten links angeordnete Benutzer entlang der X-Achse. Die Antworten sind entlang der Z-Achse entsprechend den Antwortnummern auf der Y-Achse aufgetragen.
-
Zusätzliche Sicherheit kann unter Verwendung einer semantischen Analyse erreicht werden. In den Matrixschalen kann sich eine Information über die Anfrage und darüber, welche Arten von Antworten akzeptabel sind, befinden. Wenn eine Antwort den Kriterien nicht entspricht, wird sie zurückgewiesen. Wenn zum Beispiel der Diensteanbieter den Benutzer bittet, zu berichten, wie viele Gegenstände geordert sind, und der Benutzer antwortet ”ja”, dann wusste der Benutzer augenscheinlich nicht, was die Frage war, und die Mitteilung war keine Antwort auf die Anfrage.
-
Es ist auch möglich, dass der Diensteanbieter tatsächlich ein Vermittler ist und dass sich der ”echte” Diensteanbieter irgendwo sonst befindet. In diesem Fall muss der Vermittler bloß das matrixbasierte System besitzen, und der aktuelle Diensteanbieter kommuniziert mit dem Vermittler unter Verwendung entweder des Matrixsystems des Vermittlers oder anderer sicherer Einrichtungen, wie einem Verschlüsselungskanal. Zum Beispiel könnte ein Carsharing-System auf die folgende Weise implementiert sein: Wagen befinden sich zufällig verteilt überall in einer Stadt. Wenn ein Benutzer einen Wagen benötigt, sendet er oder sie eine Mitteilung an einen Vermittler, um zu fragen, wo sich der nächste Wagen befindet. Der Vermittler sendet eine Mitteilung, die die Stelle des Wagens berichtet. Diese Antwort kommt von einer Zufallsadresse y'. Wenn der Benutzer den Wagen erreicht, sendet er oder sie eine Mitteilung an y', die berichtet, dass die Leihperiode beginnt, und bittet den Vermittler um Fernfreigabe der Arretierungen des Wagens. Diese Mitteilung ist verhältnismäßig zuverlässig, weil sie an die Adresse gesendet ist, die nur der Benutzer kennt. Deshalb bildet sie einen stichhaltigen Grund, die Arretierungen freizugeben und mit der Inrechnungstellung zu beginnen. Die Kommunikation zwischen Vermittler und dem Wagen ist andererseits für den Benutzer und Außenstehende unsichtbar. Der Wagen kann mit speziellen Geräten ausgerüstet sein, und deshalb können Fernbefehle, die Arretierungen usw. freizugeben, verschlüsselt sein. Oder die Kommunikation zwischen dem Wagen und dem Vermittler könnte auch unter Verwendung von Matrizen implementiert sein. In jedem Fall arbeitet der Vermittler als eine ”Firewall” zwischen dem Benutzer und dem Wagen, wobei Außenstehende außer Stand gesetzt werden, eine unbefugte Verwendung vorzunehmen.
-
Obwohl die vorliegende Erfindung mit Bezug auf gewisse bevorzugte Versionen davon in beträchtlicher Einzelheit beschrieben worden ist, sind andere Versionen möglich. Deshalb sollte der Geist und Umfang der angefügten Ansprüche nicht auf die bevorzugten Versionen hierin beschränkt werden.
-
Weitere Aspekte und Ausführungsformen der vorliegenden Erfindung liefern Material, wie in den folgenden nummerierten Absätzen definiert:
-
Absatz 1. System eines Vermittlers, das eine Kommunikation mit einer Auftraggeberendstelle mit einer Auftraggeberkennungsadresse weiterführt, umfassend: a) Initialisieren einer Kommunikation mit der Auftraggeberendstelle, umfassend ein Zuordnen einer speziellen Antwortadresse, zu der eine Antwort zu einem Dialog gerichtet werden muss, umfassend ein Auswählen der speziellen Antwortadresse aus einer Vielzahl von Adressen, an denen der Vermittler Antworten empfängt; b) Initiieren eines Dialogs zu der Auftraggeberendstelle, der die spezielle Antwortadresse enthält; c) Empfangen einer Antwort an der speziellen Antwortadresse von der Auftraggeberendstelle, wobei die Antwort die Auftraggeberkennungsadresse enthält; und d) Auswerten der Antwort unter Verwendung der Auftraggeberkennungsadresse und der speziellen Antwortadresse, an der die Antwort empfangen wird.
-
Absatz 2. System nach Absatz 1, bei dem ein Auswerten der Antwort weiter ein Analysieren der Semantik der Antwort umfasst.
-
Absatz 3. System nach Absatz 1, bei dem die Kommunikation einen speziellen Diensteanbieter betrifft.
-
Absatz 4. System nach Absatz 1, bei dem ein Auswählen der speziellen Antwortadresse aus der Vielzahl von Adressen eine Zufallswahl ist.
-
Absatz 5. System nach Absatz 1, bei dem die Kommunikation eine Mehrzahl von Dialog- und Antwortaustauschvorgängen mit der Auftraggeberendstelle umfasst und ein Initiieren ein Verknüpfen von unterschiedlichen Antwortadressen mit unterschiedlichen Dialog- und Antwortaustauschvorgängen umfasst.
-
Absatz 6. System nach Absatz 5, bei dem ein Auswerten der Antwort selbst dann fortschreiten kann, wenn die unterschiedlichen Antworten in einer anderen Reihenfolge empfangen werden, als die Austauschvorgänge initiiert werden.
-
Absatz 7. System nach Absatz 3, bei dem ein Initialisieren einer Kommunikation auf eine Aufbauanforderung anspricht, die die Auftraggeberendstelle und den speziellen Diensteanbieter identifiziert.
-
Absatz 8. System nach Absatz 4, weiter umfassend ein Speichern der Antworten in einer Matrix mit einer ersten Achse, die Auftraggeberkennungsadressen entspricht, und einer zweiten Achse, die Antwortadressen entspricht.
-
Absatz 9. System nach Absatz 7, bei dem der Vermittler simultan mit einer Mehrzahl von anderen Auftraggeberendstellen kommuniziert, die jeweils eine unterschiedliche Auftraggeberkennungsadresse aufweisen, und wobei das System weiter ein Verfolgen davon umfasst, welche der Vielzahl von Adressen augenblicklich verfügbar ist.
-
Absatz 10. System nach Absatz 8, bei dem ein Initialisieren einer Kommunikation weiter ein Auswählen der speziellen Antwortadresse aus gegenwärtig verfügbaren Adressen umfasst.
-
Absatz 11. Vermittler, der Kommunikationen zwischen mindestens einem Diensteanbieter und einer Auftraggeberendstelle mit einer Auftraggeberkennungsadresse steuert, wobei der Vermittler umfasst: a) eine Vielzahl von Adressen, an denen der Vermittler Mitteilungen von der Auftraggeberendstelle empfangen kann; b) Logik und Ressourcen, die angepasst sind, um i) eine Kommunikation mit der Auftraggeberendstelle zu initialisieren, die einen speziellen Diensteanbieter betrifft, umfassend ein Zuordnen einer speziellen Antwortadresse, zu der eine Antwort zu einem Dialog gerichtet werden muss, wobei die spezielle Antwortadresse aus der Vielzahl von Adressen ausgewählt ist; ii) Initiieren eines Dialogs zu der Auftraggeberendstelle, der die spezielle Antwortadresse enthält; iii) Empfangen einer Antwort an der speziellen Antwortadresse; und iv) Auswerten der Antwort unter Verwendung der Auftraggeberkennungsadresse und der speziellen Antwortadresse, an der die Antwort empfangen ist.
-
Absatz 12. Vermittler nach Absatz 11, bei dem die Logik und Ressourcen zur Auswertung der Antwort weiter die Semantik der Antwort analysieren.
-
Absatz 13. Vermittler nach Absatz 11, bei dem die Kommunikation eine Mehrzahl von Dialog- und Antwortaustauschvorgängen mit der Auftraggeberendstelle umfasst, und unterschiedliche Antwortadressen mit unterschiedlichen Dialog- und Antwortaustauschvorgängen verknüpft sind.
-
Absatz 14. Vermittler nach Absatz 13, bei dem die Logik und Ressourcen angepasst sind, um Antworten zu Dialogen zu verarbeiten, selbst wenn die unterschiedlichen Antworten nicht in der, von den unterschiedlichen Fragen aus gesehen, richtigen Reihenfolge empfangen werden.
-
Absatz 15. Vermittler nach Absatz 11, bei dem die Logik und Ressourcen, die angepasst sind, um die Kommunikation zu initialisieren, eine Matrix mit einer ersten Achse, die einer Auftraggeberkennungsadresse entspricht, und einer zweiten Achse, die einer Antwortadresse entspricht, umfasst.
-
Absatz 16. Vermittler nach Absatz 11, bei dem die Logik und Ressourcen, um die Kommunikation zu initialisieren, angepasst sind, um auf eine Aufbauanforderung anzusprechen, die die Auftraggeberendstelle und den speziellen Diensteanbieter identifiziert.
-
Absatz 17. Vermittler nach Absatz 11, bei dem die Logik und Ressourcen, um die spezielle Antwortadresse aus der Vielzahl von Adressen auszuwählen, die Selektion zufällig wählen.
-
Absatz 18. Vermittler nach Absatz 11, bei dem die Auftraggeberkennungsadresse aus der Gruppe ausgewählt ist, die aus einer A-Teilnehmernummer eines Auftraggebers, A-Teilnehmeranzeige, e-Mail-Adresse und IP-Adresse besteht.
-
Absatz 19. Vermittler zum Steuern eines Buchungssystems mit mindestens einem Diensteanbieter und einem Auftraggeberendgerät zur Verwendung durch einen Auftraggeber mit einer Auftraggeberkennungsadresse, wobei der Vermittler umfasst: a) eine Vielzahl von Adressen, an denen der Vermittler von der Auftraggeberendstelle Mitteilungen empfangen kann, b) Logik und Ressourcen, die angepasst sind, um: mindestens einen Dialog vorzubereiten, ansprechend auf eine Anfrage, die den Diensteanbieter betrifft, eine spezielle Antwortadresse zu jedem Dialog zuzuordnen, wobei die spezielle Antwortadresse aus der Vielzahl von Adressen ausgewählt ist, den mindestens einen Dialog zu der Auftraggeberendstelle zu senden, eine Antwort an der speziellen Antwortadresse von dem Auftraggeberendgerät einschließlich der Auftraggeberkennungsadresse zu empfangen; und die Antwort unter Verwendung der Auftraggeberkennungsadresse und der speziellen Antwortadresse auszuwerten, an der die Antwort empfangen ist.
-
Absatz 20. Vermittler nach Absatz 19, bei dem die Logik und Ressourcen eine Matrix umfassen, die eine erste Achse enthält, die durch eine Auftraggeberkennungsadresse indexiert ist, und eine zweite Achse, die durch eine Antwortadresse indexiert ist.
-
Absatz 21. Vermittler nach Absatz 19, bei dem die Auftraggeberkennungsadresse eine Kennung umfasst, die aus der Gruppe ausgewählt ist, die aus einer A-Teilnehmernummer eines Auftraggebers, A-Teilnehmeranzeige, e-Mail-Adresse und IP-Adresse besteht.
-
Absatz 22. Vermittler nach Absatz 19, bei dem die Logik und Ressourcen zur Auswertung der Antwort weiter die Semantik der Antwort analysieren.
-
Absatz 23. Vermittler nach Absatz 19, bei dem die Anfrage auf eine Diensteanforderung anspricht, die das Auftraggeberendgerät identifiziert.
-
Absatz 24. Vermittler nach Absatz 19, bei dem eine Mehrzahl von Dialogen vorbereitet ist, ansprechend auf die Anfrage, und bei dem die Logik und Ressourcen, die angepasst sind, um eine spezielle Antwortadresse zuzuordnen, angepasst sind, um eine unterschiedliche spezielle Antwortadresse zur Verknüpfung mit jedem Dialog auszuwählen, wodurch die Logik und Ressourcen angepasst sind, um Antworten selbst dann auszuwerten, wenn unterschiedliche Antworten in einer von unterschiedlichen Dialogen verschiedenen Reihenfolge erhalten werden.
-
Absatz 25. Vermittler nach Absatz 24, bei dem die Logik und Ressourcen Logik und Ressourcen umfassen, um diejenigen Adressen der Vielzahl von unterschiedlichen Adressen zu verfolgen, die augenblicklich verfügbar sind, und um die spezielle Antwortadresse zufällig aus denjenigen Adressen zuzuweisen, die augenblicklich verfügbar sind.
-
Absatz 26. Vermittler nach Absatz 24, bei dem der mindestens eine Dialog eine Frage ist, die beantwortet werden kann, indem eine Selektion von einem Gegenstand aus einer geordneten Auswahlliste vorgenommen wird, wobei jede Wahl eine Ordinalposition aufweist.
-
Absatz 27. Vermittler nach Absatz 26, bei dem die Matrix weiter einen dritten Achsenindex zum Speichern der Ordinalposition der Selektion enthält.
-
Absatz 28. System eines Vermittlers, der Ressourcen für einen Auftraggeber von einem Diensteanbieter bucht, wobei der Auftraggeber eine Auftraggeberkennungsadresse aufweist und ein Auftraggeberendgerät verwendet, um mit dem Vermittler zu kommunizieren, wobei der Vermittler Handlungen durchführt, umfassend: a) Vorbereiten mindestens eines Dialogs, ansprechend auf eine Anfrage; b) Zuordnen einer speziellen Antwortadresse zu jedem Dialog, wobei die spezielle Antwortadresse aus einer Vielzahl von Adressen ausgewählt ist, die zum Empfangen von Mitteilungen von einem Auftraggeberendgerät verfügbar sind; c) Senden des mindestens einen Dialogs zu dem Auftraggeberendgerät; d) Empfangen einer Antwort zu dem mindestens einen Dialog von dem Auftraggeberendgerät, wobei die Antwort die Auftraggeberkennungsadresse enthält; und e) Auswerten der Antwort zu dem mindestens einen Dialog unter Verwendung der Auftraggeberkennungsadresse und der speziellen Antwortadresse.
-
Absatz 29. System nach Absatz 28, bei dem die Handlung eines Auswertens der Antwort weiter umfasst: Analysieren der Semantik der Antwort.
-
Absatz 30. System nach Absatz 28, weiter umfassend: Speichern der Antwort zu dem mindestens einen Dialog in einer Matrix, die eine erste Achse enthält, die durch eine Auftraggeberkennung indexiert ist, und eine zweite Achse, die durch eine Antwortadresse indexiert ist.
-
Absatz 31. System nach Absatz 28, bei dem die Handlung eines Zuordnens einer speziellen Antwortadresse zu jedem Dialog so ausgeführt wird, dass die spezielle Antwortadresse zufällig ausgewählt wird.
-
Absatz 32. System nach Absatz 28, bei dem die Anfrage auf eine Diensteanforderung von dem Auftraggeberendgerät anspricht.
-
Absatz 33. System nach Absatz 28, bei dem die Auftraggeberkennungsadresse eine Kennung umfasst, die aus der Gruppe ausgewählt ist, die aus einer A-Teilnehmernummer eines Auftraggebers, A-Teilnehmeranzeige, e-Mail-Adresse und IS-Adresse besteht.
-
Absatz 34. System nach Absatz 28, bei dem die Handlung eines Vorbereitens des mindestens einen Dialogs weiter umfasst: Vorbereiten des mindestens einen Dialogs in eine Form, die beantwortet werden kann, indem eine Selektion aus einer geordneten Auswahlliste vorgenommen wird, wobei jede Wahl eine Ordinalposition in der Auswahlliste aufweist.
-
Absatz 35. System nach Absatz 28, bei dem der mindestens eine Dialog eine Mehrzahl von Dialogen umfasst, so dass eine unterschiedliche spezielle Antwortadresse mit jedem Dialog verknüpft ist, wodurch ein Auswerten der Antwort selbst dann fortschreiten kann, wenn Antworten in einer anderen Reihenfolge empfangen werden, als Dialoge gesendet werden.
-
Absatz 36. System nach Absatz 34, bei dem die Matrix eine dritte Achse enthält, die zum Speichern der Ordinalposition von Selektionen indexiert ist, und wobei das System weiter umfasst: Speichern der Selektion zu der mindestens einen Antwort entlang der dritten Achse.
-
Absatz 37. System nach Absatz 34, bei dem das Auftraggeberendgerät ein Mobiltelefongerät umfasst und die Dialoge SMS-Mitteilungen umfassen.
-
Absatz 38. Netzwerkserver, der als ein Vermittler programmiert ist, um das System nach Absatz 28 auszuführen.
-
Absatz 39. Netzwerkserver, der als ein Vermittler programmiert ist, um das System nach Absatz 34 auszuführen.
-
Absatz 40. System eines Vermittlers, das einen Auftrageber authentifiziert, wobei der Auftraggeber ein Mobiltelefongerät verwendet, das SMS-Mitteilungen senden und empfangen kann und eine A-Teilnehmerkennungsnummer eines Auftraggebers aufweist, wobei der Vermittler Handlungen ausführt, umfassend: a) Zuweisen einer eindeutigen Antwortadresse zu einem SMS-Dialog aus einer Vielzahl von verfügbaren Antwortadressen; b) Senden des SMS-Dialogs zu dem Auftraggeber an die A-Teilnehmerkennungsnummer des Auftraggebers; und c) Authentifizieren des Auftraggebers, wenn eine Antwort zu dem SMS-Dialog an der eindeutigen Antwortadresse empfangen wird.
-
Absatz 41. System nach Absatz 40, bei dem die eindeutige Antwortadresse zufällig aus der Vielzahl von verfügbaren Antwortadressen zugewiesen wird.
-
Absatz 42. System nach Absatz 40, bei dem der Vermittler einen Netzwerkserver umfasst, der programmiert ist, um die Erfindung auszuführen, und wobei das System weiter umfasst: Speichern der Antwort in einer Matrix, die eine erste Achse enthält, die durch eine Auftraggeber-A-Teilnehmerkennungsnummer indexiert ist, und eine zweite Achse, die durch eine Antwortadresse indexiert ist.
-
Absatz 43. System nach Absatz 40, bei dem die Authentifizierungshandlung weiter umfasst: Analysieren der Semantik der Antwort.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
