-
Erfindungsgebiet
-
Die
vorliegende Erfindung betrifft allgemein Kommunikationssysteme und
insbesondere drahtlose mobile Kommunikationssysteme.
-
Hintergrund
der Erfindung
-
Es
gibt eine große
Vielfalt an im Stand der Technik bekannten Werbetechniken einschließlich Radio- und
Fernseh-Werbespots,
Zeitungsreklamen und direktem Marketing, z. B. Telemarketing. Da
diese Reklamen verwendet werden, um eine Information an soviele
Personen wie möglich
zu befördern,
können
sie relativ teuer und ineffizient sein. Im allgemeinen bemühen sich
Verkäufer
von Waren und Diensten um die Maximierung ihres Gewinns in Bezug
auf Reklameausgaben. Verkäufer
wünschen,
das Kennen ihrer Produkte an soviele mögliche Verbraucher wie möglich zu
befördern.
Vor allem Verkäufer
von verschiedenen Waren und Diensten wünschen, die Verbraucher zu
erreichen, die einen Wunsch oder Bedarf an den vom Verkäufer bereitgestellten Waren
und Diensten haben.
-
Jedoch
ist es schwierig und teuer, jene Verbraucher zu identifizieren,
die ein Interesse an einem besonderen Produkt oder Dienst haben,
die von einem speziellen Verkäufer
angeboten werden. Und selbst wenn diese Verbraucher identifiziert
werden können,
kann es relativ schwierig sein, den Verbraucher dazu zu bringen,
sich auf eine Werbung zu konzentrieren. Zusätzlich haben Verbraucher für gewöhnlich keine
Motivation, sich selbst als an einer besonderen Art an Artikel oder
Dienst interessiert zu identifizieren.
-
WO-97/17774
offenbart ein Verfahren und System für das Ausstrahlen einer Werbung
oder eines Inhalts an ein spezifisches Publikum, in dem ein Benutzerprofil
auf die empfangende Vorrichtung eines Benutzers heruntergeladen
wird, das mit einem Ziel-Profil verglichen wird, das in der ausgestrahlten
Werbung und im ausgestrahlten Inhalt eingeschlossen ist.
-
Es
wäre daher
wünschenswert,
Nachrichten von Verkäufern
an Verbraucher zu senden, die einen Wunsch oder Bedarf an Waren
und Diensten ausgedrückt
haben, die die gewünschten
Waren und Dienste zur Verfügung
stellen. Es wäre
weiterhin wünschenswert,
Nachrichten für
Mobilfunkbenutzer bereitzustellen, wenn sich diese in der Nähe des Verkäufers befinden,
in Bezug auf den der Benutzer eine Information empfangen möchte.
-
Zusammenfassung
der Erfindung
-
Die
vorliegende Erfindung stellt ein lokalisiertes Auf-Nachfrage-Multicast-Kommunikationssystem
für ein
mobiles Netz bereit, das den Benutzern des mobilen Netzes Nachrichten
bereitstellt. Dies wird durch ein Verfahren nach Anspruch 1 erreicht.
Indem unter vom Benutzer bestimmten Bedingungen dem Benutzern des mobilen
Netzes Nachrichten bereitgestellt werden, ist der Benutzer in Bezug
auf die übertragenen
Nachrichten relativ empfänglich.
Obwohl die Erfindung vorrangig in Verbindung mit einem Mobilfunktelefonnetz
gezeigt und beschrieben wird, das kommerzielle Werbenachrichten überträgt, ist
es verständlich,
dass die Erfindung auf andere Nachrichtentypen und andere Netztypen
angewandt werden kann, in denen es wünschenswert ist, Auf-Nachfrage-Nachrichten
bereitzustellen.
-
In
einem Aspekt der Erfindung schließt ein mobiles Kommunikationssystem
einen Profil-Proxy-Server ein, der an mehrere Nachrichtenserver
gekoppelt ist. Benutzer stellen einem lokalen Nachrichtenserver über den
Profil-Proxy-Server eine Profilinformation zur Verfügung. Die
Profilinformation kann vom Benutzer festgelegte Vorzüge einschließen, die
die Kategorien bestimmen, für
die der Benutzer Nachrichten empfangen möchte, und die Bedingungen,
z. B. Tageszeit, maximale Nachrichtenanzahl und Standort, unter
denen die Nachrichten akzeptiert werden, bestim men. Verkäufer können ebenfalls
eine Profilinformation bereitstellen, die die Geschäftskategorie
des Verkäufers
und die Bedingungen, z. B. Zeiteinstellung, Werbeumfang und Zahl
der interessierten Benutzer, unter denen die Nachrichten ausgestrahlt
werden sollten, identifiziert.
-
Die
Benutzerprofilinformation kann vom lokalen Nachrichtenserver verwendet
werden, um einen Dienst-ID-Pool für den Benutzer zu bestimmen,
der an den Benutzer heruntergeladen wird. Der Dienst-ID-Pool erlaubt
dem Benutzer zu bestimmen, welche Multicastnachrichten die im Profil
des Benutzers festgelegten Vorzüge
erfüllen.
Die Multicastnachrichten können
von allen Benutzern empfangen werden, für die die Profilbedingungen
und Benutzer- und Verkäuferbedingungen
erfüllt
sind. Multicastnachrichten schließen die Kategorieinformation
für den
Verkäufer
zusammen mit einem einmaligen Bezeichner für den Verkäufer ein. Die Multicastnachrichten
können
eine Information einschließen,
die den Benutzern erlaubt, den Verkäufer zu besuchen oder auf andere
Weise zu kontaktieren.
-
In
einer Ausführungsform
schließt
der Benutzer-Dienst-ID-Pool
Paare von Dienst-IDs und ID-Masken auf der Grundlage der im Benutzerprofil
bestimmten Vorlieben ein. Felder im Dienst-ID-Pool werden mit entsprechenden Feldern
in einer Multicastnachricht verglichen, um zu bestimmen, ob der
Benutzer die Nachricht verarbeiten sollte. In einer beispielhaften
Ausführungsform
werden die ID-Masken logisch mit der Multicastnachricht UND-verknüpft und
das Ergebnis mit der Dienst-ID verglichen. Wenn das Ergebnis der
logischen UND-Verknüpfung
mit der Dienst-ID übereinstimmt,
dann sollte die Nachricht verarbeitet werden.
-
Diese
Anordnung erlaubt den Verkäufern,
die Information zu senden, die die Waren und/oder den Dienst betrifft,
die sie den Benutzern zur Verfügung
stellen, die einen Wunsch zum Empfangen der Nachrichten von Verkäufern geäußert haben,
die die bestimmte Ware und/oder den bestimmten Dienst bereitstellen.
-
Vor
der Ausstrahlung der Nachrichten an Mobilnetzbenutzer, wartet das
Auf-Nachfrage-Kommunikations-Multicast-Kommunikationssystem auf
ein mit den Benutzern des Systems verknüpftes Ereignis. In einer Ausführungsform
schließen
die Ereignisse Registrationsereignisse, Ent-Registrationsereignisse,
Standortaktualisierungsereignisse und aktive Nachfrageereignisse
ein. Im allgemeinen empfängt
ein Nachrichtenserver die Ereignisinformation, bestimmt die Ereignisart
und verarbeitet das Ereignis.
-
Registrationsereignisse
erfolgen, wenn sich ein Mobilbenutzer einschaltet und den Benutzer
dem Mobilnetz kennzeichnet. Das Auf-Nachfrage-Kommunikationssystem
erlangt das Benutzerprofil wieder und erzeugt einen gewünschten
Dienst-ID-Pool für
den Benutzer, der dann an den Benutzer heruntergeladen wird. Der
gewünschte
Dienst-ID-Pool wird vom Benutzer verwendet, um jene Multicastnachrichten
zu identifizieren, die vom Benutzer verarbeitet werden sollten.
Ent-Registrationsereignisse erfolgen, wenn ein Benutzer das Mobilnetz
verläßt, wie
beispielsweise beim Ausschalten.
-
Aktive
Nachfrageereignisse erfolgen, wenn ein Benutzer aktiv die Verkäuferinformation
für eine
oder mehrere Verkaufskategorien verlangt. Zum Beispiel kann ein
Benutzer eine Nachfrage zum Empfangen von Nachrichten von umliegenden
Restaurants einreichen. Multicastnachrichten, die die Verkäuferinformation
bereitstellen, können,
wenn Benutzer- und Verkäuferbedingungen
erfüllt
sind, an den Benutzer gesendet werden.
-
Standortaktualisierungsereignisse
werden durch die Bewegung des Benutzers im Mobilnetz ausgelöst. Im allgemeinen
informiert das Mobilnetz das Auf-Nachfrage-Kommunikationsnetz darüber, wann
sich ein Benutzer von einer Zelle zur anderen bewegt. Das Kommunikationsnetz
informiert dann einen Nachrichtenserver, der die neue Zelle des
Benutzerstandorts abdeckt.
-
Kurze Beschreibung der
Zeichnungen
-
Die
Erfindung wird in Zusammenhang mit der folgenden detaillierten Beschreibung
verständlicher,
die in Verbindung mit den begleitenden Zeichnungen gemacht wird,
in denen:
-
1 ein
Blockdiagramm eines beispielhaften drahtlosen Auf-Nachfrage-Kommunikationssystems
in Übereinstimmung
mit der vorliegenden Erfindung ist;
-
2 ein
weiteres Blockdiagramm eines beispielhaften drahtlosen Auf-Nachfrage-Kommunikationssystems
in Übereinstimmung
mit der vorliegenden Erfindung ist;
-
3 ein
Blockdiagramm einer besonderen Ausführungsform eines drahtlosen
Auf-Nachfrage-Kommunikationssystems in Übereinstimmung mit der vorliegenden
Erfindung ist;
-
4 eine
bildhafte Darstellung eines drahtlosen Auf-Nachfrage-Kommunikationssystems in Übereinstimmung
mit der vorliegenden Erfindung ist, die die Benutzerbewegung zeigt;
-
5 ein
Blockdiagramm eines beispielhaften Nachrichtenservers ist, der in Übereinstimmung
mit der vorliegenden Erfindung einen Teil einer Nachricht-Auf-Nachfrage-Systems
bildet;
-
6 ein
Blockdiagramm eines beispielhaften Formats für einen gewünschten Dienst-ID-Pool ist,
der in Übereinstimmung
mit der vorliegenden Erfindung von einem Auf-Nachfrage-Kommunikationssystem
gebildet wird;
-
7 ein
beispielhaftes Format für
eine Auf-Nachfrage-Multicastnachricht
in Übereinstimmung
mit der vorliegenden Erfindung ist;
-
8 eine
beispielhafte Schrittfolge zum Antworten auf Ereignisse in einem
Nachricht-Auf-Nachfrage-System in Übereinstimmung mit der vorliegenden
Erfindung zeigt;
-
9 eine
beispielhafte Schrittfolge zum Abwickeln von Registrationsereignissen
in einem Auf-Nachfrage-Kommunikationssystem in Übereinstimmung mit der vorliegenden
Erfindung zeigt;
-
10 eine
beispielhafte Schrittfolge zum Abwickeln von Ent-Registrationsereignissen
in einem Auf-Nachfrage-Kommunikationssystem
in Übereinstimmung
mit der vorliegenden Erfindung zeigt;
-
die 11a und 11b eine
beispielhafte Schrittfolge zum Abwickeln von Standortaktualisierungsereignissen
in einem Auf-Nachfrage-Kommunikationssystem
in Übereinstimmung
mit der vorliegenden Erfindung zeigen; und
-
die 12a und 12b eine
beispielhafte Schrittfolge zum Abwickeln aktiver Nachfrageereignisse in
einem Auf-Nachfrage-Kommunikationssystem
in Übereinstimmung
mit der vorliegenden Erfindung zeigen.
-
Detaillierte
Beschreibung der Erfindung
-
Die 1–2 zeigen
in Übereinstimmung
mit der vorliegenden Erfindung ein drahtloses mobiles Kommunikationssystem 100,
das über
eine Auf-Nachfrage-Benachrichtigung verfügt. Im allgemeinen sendet das
System Verkäuferinformation
enthaltende Nachrichten auf der Grundlage des Benutzerstandorts
und der von den Benutzern und den Verkäufern festgelegten Bedingungen
an die Mobilbenutzer. Diese Anordnung sorgt für einen effizienten Mechanismus
für Lieferanten
von Waren und Diensten, d. h. Verkäufern, um Mobilbenutzer zu
kontaktieren, die wünschen,
Nachrichten zu empfangen, die eine Information zu den vom Benutzer
gewünschten
Waren und Diensten enthalten.
-
In
einer Ausführungsform
schließt
das mobile Kommunikationssystem 100 mehrere Zellen 102a–d ein, die
auf eine dem durchschnittlichen Fachmann auf dem Gebiet gut bekannte
Weise von einer jeweiligen Basisstation 104a–d bedient
werden. Jede Basisstation 104a–d kann mit dem jeweiligen
Nachrichtenserver 106a–d
verbunden werden, um, wie detailliert unten beschrieben, die Basisstation
mit Kommunikationsanweisungen zu versorgen. Die Nachrichtenserver 106 können über ein
Netz 110 wie beispielsweise Internet oder Intranet mit
einem Profil-Proxy-Server (PPS) 108 verbunden werden. Mehrere
Benutzer 112a–N
und Verkäufer 114a–M (2)
können
z. B. über
Internet 110 mit dem Profil-Proxy-Server 108 kommunizieren.
Der Profil-Proxy-Server 108 kann die bereitgestellte Information
zum Speichern in einer Datenbank an einen Nachrichtenserver 16 senden,
der für
den Benutzer lokal ist.
-
Die
Benutzer 112 des Systems stellen dem Profil-Proxy-Server 108 eine
Information bereit, um die Bedingungen zu bestimmen, unter denen
sie bereit sind, die Nachrichten von den Verkäufern 114 zu akzeptieren. Es
ist klar, dass die Motivation für
die Benutzer, diese Information zur Verfügung gestellt zu bekommen,
variieren kann. Zum Beispiel kann der Benutzer Rabatte auf die in
Zusammenhang mit der Verwendung des Netzes verknüpften Gebühren, z. B. montatliche Mobilfunktelefonrechnungen,
empfangen. Der Benutzer kann auch elektronische Coupons empfan gen,
wenn er einen Verkäufer
als Reaktion auf eine Nachricht besucht.
-
3 zeigt
in Übereinstimmung
mit der vorliegenden Erfindung eine besondere Ausführungsform
eines Auf-Nachfrage-Kommunikationssystems 120, das an ein
General Packet Radio Service(GPRS)-Netz 150 gekoppelt ist.
Das Auf-Nachfrage-Kommunikationssystem 120 schließt einen
mit einem Nachrichtenserver 106 und einer Profildatenbank 107 verbundenen
Profil-Proxy-Server 108 ein, der ebenfalls mit dem Nachrichtenserver
verbunden wird. Wie unten beschrieben, kann die Profildatenbank 107 Profildaten
für die
mit dem Mobilnetz verknüpften
Benutzer und Verkäufer
speichern. Der Profil-Proxy-Server 108 wird über ein
herkömmliches
Gateway 111 mit Internet 110 verbunden. In einer
Ausführungsform
kann der Profil-Proxy-Server 108 über das Auf-Nachfrage-Kommunikationssystem
mehrere Nachrichtenserver 106 unterstützen.
-
Das
GPRS-Netz 150 schließt
einen mit einem lokalen Nachrichtenserver 106 und einem
Gateway-GPRS-Unterstützungsknoten
(GGSN) 154 verbundenen Dienst-GPRS-Unterstützungsknoten
(SGSN) 152 ein. Der SGSN 152 steht mit einer Basisstation 104 in
Verbindung, die die lokale Zelle 102 abdeckt, um Benutzern 112 innerhalb
der Zelle einen Mobildienst zur Verfügung zu stellen. Der Nachrichtenserver 106 stellt dem
lokalen SGSN 152 eine Nachrichteninformation zur Übertragung
durch die verbundene Basisstation 104 zur Verfügung.
-
Wie
in 4 gezeigt, bewegen sich Mobilbenutzer 112 innerhalb
des Netzes in und außerhalb
von verschiedenen Zellen 102. Verkäufer 116a–P wollen
mögliche
Benutzer 112 kontaktieren, die einen Wunsch nach ihren
Waren- oder Dienstarten geäußert haben.
Im allgemeinen möchten
Verkäufer 116 Benutzer
in der Nähe ihres
Standorts identifizieren, um die Wahrscheinlichkeit zu erhöhen, dass
ein Benutzer den Verkäufer
besuchen wird. Wie unten beschrieben, kann das Auf-Nachfrage-Kommunikationssystem
der vorliegenden Erfindung Multicastnachrichten übertragen, die von Benutzern 112 in
der Nähe
eines speziellen Verkäufers
verarbeitet werden, vorausgesetzt dass die Profilbedingungen, z.
B. Warenart, Zeit, Standort, durch die Nachricht erfüllt werden.
Die Nachricht kann die Verkäufer
identifizieren und dem Benutzer erlauben, den/die Verkäufer zu
lokalisieren und/oder kontaktieren. Die Verkäufer können Bedingungen, z. B. Benutzerstandort,
Zeit, Zahl der Benutzer, unter denen die Nachrichten gesendet werden
sollten, wie unten beschrieben, bestimmen.
-
Wie
oben in Verbindung mit den 1–3 beschrieben,
können
Benutzer 112 unter der Steuerung des Profil-Proxy-Servers 108 einem
lokalen Nachrichtenserver 106 eine Profilinformation zur
Verfügung
stellen. In einer Ausführungsform
kann der Benutzer 112 die Profilinformation über Internet 110 bereitstellen,
um die Benutzerannehmlichkeit zu maximieren. Der Profil-Proxy-Server 108 gewährleistet,
dass die Profilinformation in einer Profil-Datenbank 107 gespeichert
wird, die mit einem Nachrichtenserver 106 verknüpft ist,
der für die
Basisstation des Benutzers, z. B. Hausadresse, lokal ist. Wie detailliert
unten beschrieben, sendet die Basisstation 104, die den
aktuellen Standort des Benutzers abdeckt, Multicastnachrichten,
die von ausgesuchten Mobilbenutzern verarbeitet werden.
-
Im
allgemeinen werden die Benutzer die Profilinformation bestimmen,
die die Bedingungen eingrenzen, unter denen sie automatisch Nachrichten
empfangen. Eine darstellende Liste von Profilbedingungen umfasst
eine vorbestimmte Nachrichtengrenzzahl je Zeiteinheit, z. B. nicht
mehr als drei Nachrichten pro Stunde, eine vorbestimmte Zeitdauer,
z. B. zwischen 3 und 6 Uhr nachmittags, ausgesuchte Tage der Woche,
die Verkäuferkategorie,
z. B. Restaurants, und die Verkäufernähe, z. B.
innerhalb von 5 Meilen. Es wird ohne weiteres ersichtlich sein,
dass viele weitere Bedingungen vom Benutzer festgelegt werden können. Die
Bedingungen für
den Benutzer können
in einem in einer Datenbank enthaltenen Benutzerprofil gespeichert
werden. Tabelle 1 unten zeigt ein beispielhaftes Benutzerprofil,
das darstellende Bedingungen für
das Empfangen von Nachrichten enthält.
-
-
-
Verkäufer können auch
die Bedingungen zur Ausstrahlung ihrer Nachrichten bestimmen. Beispielhafte Bedingungen
schließen
das Multicasten ihrer Nachrichten nur dann ein, wenn sich eine vorstimmte
Benutzerzahl zu bestimmten Tageszeiten und an bestimmten Wochentagen
in einer festgelegten Nähe
zum Verkäufer befinden.
Zusätzlich
kann das Verkäuferprofil
die Fahrtrichtung zum Verkäufer,
die Geschäftskategorie,
z. B. Restaurant, und Unterkategorien, z. B. Art des Essens und
duchfahren (Drivethru), enthalten. Das Verkäuferprofil kann weiterhin Zeiträume, die
für die
Nachrichtenausstrahlung erwünscht
sind, den Benutzerentfernungsbereich, die Art der Aktion, z. B.
das Senden einer vorbestimmten Nachricht bzw. elektronische Coupons,
und den Schwellwert der Benutzerzahl in einem lokalen Gebiet vor
dem Senden der Nachrichten einschließen. Die Verkäuferbedingungen
können
in einer Verkäuferprofil-Datenbank
gespeichert werden, die mit einem für den Verkäufer lokalen Nachrichtenserver
verknüpft
ist.
-
In
einer Ausführungsform
kann ein Verkäufer
manuell die Zahl der Benutzer innerhalb des lokalen Gebiets des
Verkäufers
bestimmen, die die Kategorie des Verkäufers bestimmt haben, indem
er sich mit dem Proxy-Server verbindet. Zum Beispiel kann ein Verkäufer mit
einem lokalen Nachrichtenserver kommunizieren, der dem Verkäufer die
Benutzerinformation bereitstellt. Der Verkäufer kann dann manuell Nachrichten
an die Benutzer senden.
-
Die
Benutzer-Privacy kann beibehalten werden, indem die eigentliche
Identität
des Benutzers geschützt
wird.
-
Es
ist klar, dass der Begriff "Benutzer", wie hierin verwendet,
weitestgehend eine Person mit einem mobilen Telefon betrifft. Es
ist weiterhin verständlich,
dass die von einem Benutzer durchgeführte Verarbeitung die Verarbeitung
betrifft, die vom Telefon des Benutzers gemacht wird.
-
5 zeigt
in Übereinstimmung
mit der vorliegenden Erfindung eine beispielhafte Ausführungsform eines
Nachrichtenservers wie beispielsweise des Nachrichtenservers 106 der 1 und 2,
der einen Teil eines mobilen Auf-Nachfrage-Kommunikationsservers bildet. In einer
Ausführungsform
schließt
der Nachrichtenserver 106 einen Server 180 für die sofortige
Nachrichtenübermittlung
ein, um als Reaktion auf eine aktive Nachfrage nach einer Information
von einem Benutzer sofortige Nachrichten für einen Benutzer zu erzeugen. Der
Server 150 für
die sofortige Nachrichtenübermittlung
kann auch den Benutzer in einer Gruppe von Benutzern einschließen, um
als Reaktion auf eine Nachforschung automatisch erzeugte Nachrichten
zu empfangen.
-
Der
Nachrichtenserver 106 kann weiterhin einen Benutzerstandort-Monitor 182 einschließen, um
den Standort der Mobilnetzbenutzer zu überwachen. Wie vollständiger unten
beschrieben, kann der Standort des Benutzers verwendet werden, um
die vom Benutzer verlangte Information zu senden. Für die sogenannte zweite
Generation bzw. 2G-Art an drahtlosen Netzen kann der Benutzerstandort-Monitor 152 mit
einer Funkvermittlungsstelle (MSC) verbunden werden. Für drahtlose
3G-Systeme kann der Benutzerstandort-Monitor 152 mit einem
Serving GPRS(General Packet Radio Service (Universalpaket-Funkdienst))-Unterstützungsknoten(SGSN)
verbunden werden.
-
Ein
Multicastnachrichten-Gateway 184 gibt, wie vollständiger unten
beschrieben, Nachrichten über
ein GPRS-Netz in einem Multicastformat an eine ausgewählte Benutzergruppe
ab. Alter- nativ dazu können
die Nachrichten mittels Verwendung von herkömmlichen Kurznachrichtdienst-(SMS)
oder Mobilfunk-Digitalpaketdaten (CDPD) gesendet werde, die auf
einen Email-Dienst basieren.
-
Der
Nachrichtenserver 106 kann weiterhin eine Profildatenbank 186 zum
Speichern der Benutzer- und Verkäuferprofile
einschließen.
Benutzer und Verkäufer
können
ihre Profilinformation mithilfe des Profil-Proxy-Servers 108 durch
Internet modifizieren.
-
In
einer Ausführungsform
werden die Benutzer- und Verkäuferprofile
im Nachrichtenserver 106 gespeichert, der für den jeweiligen
Benutzer oder Verkäufer
lokal ist. Der Profil-Proxy-Server 108 kann
einen Benutzer-Nachricht-Server-Index enthalten. Mit dieser Anordnung
kann im Fall, in dem sich ein Benutzer nicht im Bereich befindet,
der vom Nachrichtenserver bedient wird, der das Profil vom Benutzer
enthält,
der Profil-Proxy-Server
vom Nachrichtenserver infragegestellt werden, in dem sich der Benutzer
gerade befindet, um, wie vollständiger
unten beschrieben, das Profil des Benutzers zu erhalten.
-
Wenn
sich ein Benutzer mit dem drahtlosen Netz registriert, bildet der
lokale Nachrichtenserver allgemein auf der Grundlage der im Profil
des Benutzers festgelegten Geschäftskategorie-
und Unterkategorievorlieben einen gewünschten Dienst-ID-Pool für den Benutzer.
Der Dienst-ID-Pool schließt,
wie unten beschrieben, die gewünschte
Kategorieinformation und entsprechende Masken-Information ein. Der Dienst-ID-Pool
für den
Benutzer kann auch die Bedingungsinformation vom Benutzerprofil
enthalten. Der gewünschte
ID-Pool kann, wie unten beschrieben, an den Benutzer heruntergeladen
werden, um dem Benutzer zu erlauben, Multicastnachrichten von den
Verkäufern
innerhalb der gewünschten
Kategorien und Bedingungen zu verarbeiten bzw. "empfangen".
-
6 zeigt
eine beispielhafte Ausführungsform
eines Dienst-ID-190- und ID-Masken-192-Paars, das eine Dienst-ID-Gruppe bereitstellt.
Mehrere Dienst-ID-Gruppen können
einen vom Benutzer gewünschten Dienst-ID-Pool
für einen
Benutzer bilden. Ein Abschnitt einer Multicastnachricht 194 wird
ebenfalls gezeigt. Es wird ohne weiteres ersichtlich sein, dass
die im gewünschten
Dienst-ID-Pool gezeigte Größe und Anzahl
der Felder in Übereinstimmung
mit den Erfordernissen einer besonderen Applikation variieren kann.
-
Die
Dienst-ID schließt
Felder für
den Kategoriewert 195a, den ersten Unterkategoriewert 195b,
den zweiten Kategoriewert 195c und die Verkäufer-ID 195d ein.
Jedes Feld, für
das der Benutzer im Benutzerprofil eine Vorliebe festgelegt hat,
enthält
einen besonderen Wert. Zum Beispiel kann die Restaurantkategorie 50H (hexadezimale
Bezeichnung) entsprechen. Felder, für die der Benutzer keinen Wert
bestimmt hat, werden auf einen Standartwert gesetzt, wie beispielsweise
alles Binär-Einsen.
-
Die
ID-Maske 192 schließt
einen Kategorie-Filter 196a, einen ersten Unterkategorie-Filter 196b,
einen zweiten Kategoriefilter 196c und einen Verkäuferfilter 196d ein.
In einer Ausführungsform
werden die Filter 196 auf einen ersten vorbestimmten Wert
gesetzt, wenn eine Vorliebe für
die entsprechende Kategorie, Unterkategorie oder einen Verkäufer bestimmt
wird, und auf einen zweiten vorbestimmten Wert gesetzt, wenn ein
Vorzug nicht bestimmt wird. In einer besonderen Ausführungsform
werden die Filter 196 in dem Fall sämtlich auf Binär-Einsen
gesetzt, wenn ein Vorzug von Benutzer festgelegt wird, und sämtlich auf
Binär-Nullen
gesetzt, wenn eine Vorliebe nicht festgelegt wird.
-
Die
Multicastnachricht-Ausstrahlung durch eine Basisstation kann eine
Vielfalt an Formaten haben, die eine Identifikationsinformation,
Daten und die Verkäuferkategorie-Information 197a–d enthalten. 7 zeigt
in Übereinstimmung
mit der vorliegenden Erfindung eine beispielhafte Multicastnachricht.
Die Nachricht schließt eine
Kategorie-ID 197a, eine erste Unterkategorie-ID 197b und
eine Fall- bzw. Verkäufer-ID 197d und
einen Inhalt 197e ein.
-
Der
Benutzer extrahiert die Information von der Multicastnachricht,
um die Werte der Kategorie 197a, ersten Unterkategorie 197b,
zweiten Unterkategorie 197c und Verkäufer-ID197d in die Dienst-Instanz-ID
des Verkäufers
zu füllen.
Es ist verständlich,
dass jedes Feld 197 einen vorbestimmte Wert hat, der der
besonderen Kategorie und Unterkategorie entspricht, zu denen der
Verkäufer
gehört.
Der Verkäufer-ID-Wert 197d ist
ein Wert, der jeden Verkäufer
eindeutig identifiziert.
-
Allgemein
wird vom Benutzer der gewünschte
Dienst-ID-Pool des Benutzers verwendet, um zu bestimmen, welche
Multicastnachrichten vom Benutzer verarbeitet oder "empfangen" werden sollten.
Es ist klar, dass das Bestimmmen von wenigeren Vorlieben zu einem
Benutzer führt,
der mehr Nachrichten empfängt. Zum
Beispiel kann ein Benutzer, der nur eine Vorliebe für eine Kategorie 195a und
eine erste Unterkategorie 195b bestimmt, alle Nachrichten
von Verkäufern
empfangen kann, die die festgelegten Vorlieben erfüllen. Ein Benutzer,
der eine Vorliebe für
die Kategorie 195a, eine erste Unterkategorie 195b,
eine zweite Unterkategorie 195c und einen Verkäufer 195d bestimmt,
beschränkt
die Nachrichten auf Verkäufer,
die die Kategorie-, Unterkategorie- und Verkäuferkriterien erfüllen.
-
In
einer beispielhaften Ausführungsform
UND-verknüpft
der Benutzer die Verkäufer-Dienst-Instanz-ID 194 von
einer Multicastnachricht und die ID-Maske 192 beim Empfangen
der Multicastnachricht. ID-Maskenfilterwerte 196, die alle
Einsen haben, führen
zum Nachrichtenwert, der durch den Filter geht. Zum Beispiel dringt
der Kategoriewert 197a in der Verkäufer-Dienst-Instanz-ID durch einen Kategoriefilter 196a,
der sämtlich aus
Einsen besteht. Ein zweiter Unterkategoriewert 195c sowie
der zweite Kategoriefilter 196c in der Benutzerdienst-ID
sind sämtlich
Nullen, wenn der Benutzer für
die zweite Unterkategorie in der Geschäftskategorie keine Vorliebe
festgelegt hat.
-
Das
Ergebnis der logischen UND-Verknüpfung
der Dienst-Instanz-ID 194 von
der Multicastnachricht und der ID-Maske 192 wird dann mit
der Dienst-ID 190 verglichen. Wenn sie übereinstimmen, dann wird die Multicastnachricht "empfangen" und vom Benutzer
verarbeitet. Solchermaßen
müssen
ungefilterte Dienst-ID-Werte 195 mit
den Werten in der Verkäufer-Dienst-Instanz-ID 197 übereinstimmen.
Gefilterte Werte werden als übereinstimmend
angesehen, da unbestimmte Dienst-ID-Werte Binär-Nullen sind. Das bedeutet, dass
keine unbestimmte Kategorieinformation arbeitet, um zu verhindern,
dass der Benutzer Nachrichten empfängt.
-
Die
empfangenen oder verarbeiteten Nachrichten können vielerlei Formen annehmen.
Beispielhafte Nachrichtentypen schließen eine dem Web zugrundeliegende
Hyper-Text-Beschreibungssprache (HTML), eine einem drahtlosen Applikationsprotokoll(WAP)
zugrun deliegende drahtlose Beschreibungssprache (WML), einen ASCII-Text und andere geeignete
Formate ein, die von einem mobilen Telefon abgewickelt werden können. Weitere
Formate einschließlich
jener, die in der Zukunft entwickelt werden können, werden dem durchschnittlichen
Fachmann auf dem Gebiet sofort ersichtlich sein.
-
Die
Nachrichten können
aktiv sein, d. h. das Telefon des Benutzer klingeln lassen, oder
passiv sein, d. h. still im Telefon des Benutzers gespeichert werden.
Passive Nachrichten werden angezeigt, wenn der Benutzer das Telefon
beispielsweise durch das Drücken
einer Taste betätigt.
In einer Ausführungsform
kann der Verkäufer
beispielsweise im Verkäuferprofil
bestimmen, ob die Nachrichten aktiv oder passiv sein sollten. Der Benutzer
kann aktive Nachrichten so unbrauchbar machen, dass sie wie passive
Nachrichten behandelt, d. h. still gespeichert werden.
-
8 zeigt
in Verbindung mit den 1-3 in Übereinstimmung
mit der vorliegenden Erfindung eine beispielhafte Schrittfolge zum
Senden von Auf-Nachfrage-Multicastnachrichten. Allgemein empfängt ein lokaler
Nachrichtenserver ein zu einem Benutzer gehörendes Ereignis. In einer Ausführungsform
schließen
Ereignisarten Registrationsereignisse, Ent-Registrationsereignisse,
Standortaktualisierungsereignisse und aktive Nachfrageereignisse
ein.
-
Im
Schritt 200 wird bestimmt, ob der Nachrichtenserver 106 ein
Ereignis empfangen hat. Im Schritt 202 wird bestimmt, ob
das empfangene Ereignis ein Registrationsereignis ist. Ein Registrationsereignis
erfolgt, wenn als erstes ein Benutzer vom mobilen Kommunikationssystem,
beispielsweise durch Einschalten, erkannt wird. In einer Ausführungsform
wird eine lokale MSC auf den Benutzer aufmerksam und sendet einen
Hinweis an den mit der MSC verknüpften
lokalen Kommunikationsserver 106.
-
Im
Schritt 204 wird ein Registrationsverfahren, das detailliert
in 9 beschrieben wird, abgespielt, um das Registrationsereignis
zu verarbeiten. Wenn das Ereignis kein Registrationsereignis war,
bestimmt der Nachrichtenserver 106 im Schritt 206,
ob das empfangene Ereignis ein Ent-Registrationsereignis ist. Ein Ent-Registrationsereignis
erfolgt, wenn die MSC einen Hinweis dazu an den Kommunikationsserver 106 sendet,
dass ein Benutzer nicht länger
mit dem mobilen Netz registriert ist, z. B. Ausschalten. Im Schritt 208 wird für die Ent-Registrationsereignisse
ein Ent-Registrationsverfahren (s. 10) abgespielt.
Auf ähnliche
Weise bestimmen die Schritte 210 und 214, ob die
empfangenen Ereignisse jeweils Standortaktualisierungs- oder aktive
Nachfrageereignisse sind. Im Schritt 212 wird für Standortaktualisierungsereignisse
ein Standortaktualisierungs-verfahren (s. 11)
abgespielt, und im Schritt 216 wird für aktive Nachfrageereignisse
ein aktives Nachfrageverfahren (s. 12)
abgespielt.
-
8 zeigt
in Verbindung mit den 1–3 eine beispielhafte
Schrittfolge zum Verarbeiten eines Registrationsereignisses. Im
Schritt 300 wird die Benutzer-ID wie beispielsweise die
Mobil-Teilnehmer-Identität (MSID)
aus der Ereignisnachricht gezogen. Der Nachrichtenserver 106 bestimmt
im Schritt 302, ob die Benutzer-ID in der mit dem Nachrichtenserver 106 verknüpften lokalen
Benutzerprofil-Datenbank enthalten ist. Wenn die Benutzer-ID in
der lokalen Benutzerprofil-Datenbank gefunden wird, wird im Schritt 304 das
Benutzerprofil aus der Datenbank wiedererlangt. Im Schritt 306 bestimmt
der lokale Nachrichtenserver 106, ob der Benutzer ein vagabundierender
Benutzer ist; wenn dem so ist, aktualisiert er im Schritt 308 in
der Profildatenbank eine Ablaufzeit für den Benutzer. Wenn der Benutzer
kein vagabundierender Benutzer ist, wird im Schritt 310,
der vollständiger
unten beschrieben wird, ein gewünschter
Dienst-ID-Pool gebildet.
-
Wenn
sich die Benutzer-ID nicht in der lokalen Profil-Datenbank befand (Schritt 302),
fordert der lokale Nachrichtenserver 106 den Profil-Proxy-Server 108 im
Schritt 312 nach der Internetprotokoll-(IP)-Adresse des Benutzers
auf. Im Schritt 314 empfängt der lokale Nachrichtenserver 106 die
IP-Adresse eines mit dem Benutzer verknüpften Nachrichtenservers, und
im Schritt 316 wiedererlangt er das Benutzerprofil aus
dementfernten Nachrichtenserver. Das empfangene Benutzerprofil wird
dann im Schritt 318 in der lokalen Nachrichtenserver-Profildatenbank gesichert.
-
Im
Schritt 310 bildet der lokale Nachrichtenserver 106 auf
der Grundlage der im Benutzerprofil festgelegten Waren und/oder
Dienste, wie oben beschrieben, einen gewünschten Dienst-ID-Pool für den Benutzer. Allgemein
wird der gewünschte
Dienst-ID-Pool aus der im Benutzerprofil gewünschten Kategorie- und Bedingungsinformation
vom lokalen Nachrichtenserver 106 gebildet. Im Schritt 312 wird
die gewünschte Dienst-Pool-ID
an den Benutzer gesendet und im mobilen Telefon des Benutzers gespeichert.
-
Zum
Beispiel können
die vier Bytes einer Benutzer-Dienst-ID 190 (6)
wie folgt bereitgestellt werden: (B4: Kategorie; B3: erste Unterkategorie;
B2: zweite Kategorie; B1: besonderer Verkäufer). Ein Benutzer kann Vorlieben
zum Empfangen der Nachrichten von Fast Burger auf folgende Weise
bestimmen: (B4: Abendessen; B3: Fast-Food; B2: Drive-thru; B1: Fast
Burger). Es ist klar, dass jedes Byte einem vorbestimmten Wert entspricht.
Es ist weiterhin klar, dass "Fast
Burger" ein imaginäres Fast-Food-Restaurant ist,
das für
die Zwecke dieses Beispiels verwendet wird. Die entsprechende Maske
(in hexadezimale Bezeichnung) kann wie folgt sein: (B4 : FF; B3:
FF; B2: FF; B1 : FF). Da der Benutzer eine Vorliebe für einen
besonderen Verkäufer
festgelegt hat, enthält
die Maske, wie unten beschrieben, Binärcodes, um die gesamte Multicastnachricht
weiterzugeben.
-
Ein
Benutzer kann auch eine allgemeinere Vorliebe zum Empfangen aller
Fast-Food-Verkäufer
mit der folgenden Dienst-ID festlegen: (Abendessen; Fast-Food; keine
Vorliebe; keine Vorliebe). Die entsprechende Maske für die Dienst-ID
lautet (in hexadezimaler Bezeichnung) (FF; FF; 00; 00).
-
Eine
Multicastnachricht enthält
vier Bytes, die die Identität
des Verkäufers
und die Kategorieinformation anzeigen. Eine Multicastnachricht kann
z. B. ein Format haben, das der Benutzer-Dienst-ID wie folgt ähnelt: (B4:
Kategorie; B3: erste Unterkategorie; B2: zweite Unterkategorie;
B1: Verkäufer-ID).
Die Multicastnachricht wird mit der ID-Maske des Benutzers logisch
UND-verknüpft.
Zum Beispiel kann eine Nachricht von Fast Burger wie folgt bereitgestellt
werden: (B4: Restaurant; B3: Fast Food; B2: Drive-Thru; B1: Fast
Burger ID).
-
Wenn
der Benutzer angezeigt hat, dass Nachrichten von Fast Burger empfangen
werden sollten, wird die Multicast-Nachricht logisch sämtlich mit
Einsen UND-verknüpft.
Solchermaßen
wird die Multicastnachricht nicht geändert, d. h. nicht gefiltert.
Das UND-Ergebnis wird dann mit der Benutzer-Dienst-ID verglichen.
Wenn die Kategorie (B4), erste Unterkategorie (B3), zweite Unterkategorie
(B2) und die Verkäufer-ID
(B4) übereinstimmen,
wird die Nachricht vom mobilen Telefon des Benutzers empfangen.
-
Wie
man sehen kann, arbeiten Felder, z. B. die Verkäufer-ID, für die der Benutzer keine Vorliebe
bestimmt hat, nicht, um Nachrichten von irgendeinem Verkäufer im
Feld zu blockieren. D. h.: eine Nachricht wird nicht auf der Grundlage
des in der Nachricht identifizierten Verkäufers gesperrt, wenn der Benutzer
keine Vorliebe für
einen speziellen Verkäufer
bestimmt hat.
-
Zusätzlich werden
die Benutzerbedingungen für
das Empfangen der Nachricht auch mit der Information in der Multicastnachricht
verglichen. Der Nachrichtenserver bestimmt, ob die Benutzerbedingungen
erfüllt sind.
Wenn ein Nachrichtenserver ein mit dem Benutzer verknüpftes Ereignis,
z. B. das Wechseln von einer Zelle zur anderen Zelle, empfängt, bestimmt
der Nachrichtenserver zunächst,
ob die im Benutzerprofil festgelegten Bedingungen zutreffen. Wenn
sie nicht zutreffen, wird das Ereignis ignoriert. Wenn die Bedingungen
zutreffen, wird eine Zahl möglicher
Verkäufer,
die die Bedingungen des Benutzers erfüllen, erhöht. Wenn die Zahl einen vorbestimmten
Schwellwert übersteigt,
der vom Verkäufer
festgelegt werden kann, beginnt der Nachrichtenserver mit einer-
vorbestimmten Aktion wie beispielsweise dem Senden einer Multicastnachricht.
-
Es
ist verständlich,
dass dem durchschnittlichen Fachmann auf dem Gebiet weitere Techniken
zum Verarbeiten der Multicastnachrichten ohne weiteres ersichtlich
sein werden und im Schutzumfang der vorliegenden Erfindung liegen.
-
10 zeigt
ein beispielhaftes Verfahren zum Abwickeln eines Ent-Registrationsereignisses.
Allgemein wird der Benutzer aus der Verkäufer-Kandidaten-Liste beseitigt.
Im Schritt 400 extrahiert der lokale Nachrichtenserver
die Benutzer-ID und bestimmt im Schritt 402, ob sich die
Benutzer-ID in der lokalen Benutzerprofil-Datenbank befindet. Die
Verarbeitung ist beendet, wenn sich die Benutzer-ID nicht in der
lokalen Benutzerprofil-Datenbank
befindet. Wenn sich die Benutzer-ID in der lokalen Benutzerprofil-Datenbank
befindet, wird im Schritt 404 das Benutzerprofil wiedererlangt
und im Schritt 406 eine gewünschte Dienst-ID für den Benutzer gebildet.
-
Im
Schritt 408 findet der lokale Nachrichtenserver 106 eine
Verkäufer-ID,
die mit einer gewünschten Dienst-ID
im Pool übereinstimmt.
Im Schritt 410 findet der Nachrichtenserver eine Verkäufer-ID,
die mit einer ID im gewünschten
Dienst-ID-Pool des Benutzers übereinstimmt.
Die Verkäuferprofil-Kandidaten-Liste,
die unten beschrieben wird, wird im Schritt 412 überprüft, um zu
bestimmen, ob die Benutzer-ID in der Verkäufer-Kandidaten-Liste enthalten
ist. Wenn die Benutzer-ID gefunden wird, wird im Schritt 414 die
Benutzer-ID aus der Verkäufer-Kandidaten-Liste
entfernt. Wenn die Benutzer-ID nicht in der Verkäufer-Kandidaten-Liste gefunden wird, wird
im Schritt 416 bestimmt, ob es zusätzliche Verkäufer-IDs
gibt, um den vom Benutzer gewünschten
Dienst-ID-Pool zu prüfen.
-
11 zeigt eine beispielhafte Schrittfolge
zum Bedienen eines Standortaktualisierungsereignisses. Im Schritt 500 extrahiert
der lokale Nachrichtenserver 106 die Benutzer-ID und bestimmt
im Schritt 502, ob das Ereignis ein Eintreffereignis ist.
Im Schritt 504 spielt der lokale Nachrichtenserver 106 das
oben in Verbindung mit 10 beschriebene Ent-Registrationsverfahren
ab, wenn das Ereignis kein Eintreffereignis, sondern z. B. ein Abfahrereignis
ist.
-
Im
Schritt 506 bestimmt der lokale Nachrichtenserver, ob sich
das Benutzerprofil in der lokalen Benutzerprofil-Datenbank befindet.
Die Schritte 508–514 und 520–524 ähneln jeweils
den oben in Verbindung mit dem Registrationsverfahren (9)
beschriebenen Schritten 312–318 und 304–308 und
werden nicht weiter beschrieben. Im Schritt 516 ordnet
der lokale Nachrichtenserver 106 dem Benutzerprofil eine
Ablaufzeit zu. Ein gewünschter
Dienst-ID-Pool für
den Benutzer wird im Schritt 518 gebildet.
-
Im
Schritt 526 wird die Verkäufer-ID für den gewünschten Dienst-ID-Pool des
Benutzers aus der lokalen Profildatenbank wiedererlangt. Im Schritt 528 bestimmt
der lokale Nachrichtenserver, ob die Benutzerbedingungen und die
Verkäuferbedingungen
beide erfüllt
sind. Beispielhafte Benutzer- und Verkäuferbedingungen werden oben
geschildert. Wenn die Bedingungen nicht erfüllt sind, wird im Schritt 530 bestimmt,
ob zusätzliche
Verkäufer-IDs
mit den IDs im gewünschten
Dienst-ID-Pool des Benutzers übereinstimmen.
Wenn die Bedingungen erfüllt
sind, bestimmt der lokale Nachrichtenserver im Schritt 532,
ob der Benutzer bereits die Nachrichten vom Verkäufer empfangen hat. Wenn keine
vorherigen Nachrichten empfangen wurden, wird die Benutzer-ID im
Schritt 534 in eine Kandidaten-Liste für das Verkäuferprofil gesetzt. Im Schritt 536 wird
dem Benutzerprofil eine Ablaufzeit zugeordnet.
-
Im
Schritt 538 bestimmt der lokale Nachrichtenserver 106,
ob die Zahl der Benutzer in der Kandidaten-Liste des Verkäufers einen
vorbestimmten Schwellwert übersteigt.
Falls nicht, werden im Schritt 530 weitere Verkäufer-IDs
geprüft.
Wenn der Schwellwert überstiegen
wird, wird im Schritt 540 eine Multicastnachricht durch
die mit dem Nachrichtenserver verbundene Basisstation übertragen.
Die Multicastnachricht wird, wie detailliert oben beschrieben, durch
die Dienst-Instanz-ID des Verkäufers
identifiziert.
-
Die 12A–B
zeigen eine beispielhafte Schrittfolge für das aktive Nachfrageverfahren.
Allgemein geht eine aktive Nachfrage ein, wenn ein Benutzer eine
Information zu Waren/Diensten innerhalb einer Kategorie oder Unterkategorie
verlangt. Es ist klar, dass der Benutzer auf vielfache Weise eine
Nachfrage machen kann. Zum Beispiel kann ein vorbestimmtes lokales
Informationsmenü auf
das Telefon des Benutzers heruntergeladen werden. Im Menü kann der "1"-Knopf am Telefon einer Abendessen-Kategorie,
der "2"-Knopf einer Unterhaltungskategorie,
usw., entsprechen. Wenn der Benutzer eine Information zu lokalen
Restaurants haben möchte,
wird der "1"-Knopf gedrückt. Im
Tausch antwortet der Nachrichtenserver mit einer Liste an Verkäufern innerhalb
der Kategorie der Benutzernachfrage, die im Telefon angezeigt werden.
Zusätzlich
kann der Nachrichtenserver weiterhin dieses Ereignis verarbeiten,
um zu bestimmen, ob vorab bestimmte Handelsnachrichten ausgelöst und an
Benutzer in der Nähe
gesendet werden können.
-
Die
Schritte 600–618 gleichen
den Schritten 300–318 aus 9 und
werden nicht weiter beschrieben. Nachdem der gewünschte Dienst-ID-Pool des Benutzers
gebildet ist, bestimmt der lokale Nachrichtenserver 106 im
Schritt 620 einen lokalen Verkäufer, der eine Dienst-Instanz-ID
hat, die mit der Kategorie oder Unterkategorie übereinstimmt, aus der der Benutzer
die verlangte Information bezieht, und die mit einer ID innerhalb des
gewünschten
Dienst-ID-Pools des Benutzers übereinstimmt.
Im Schritt 622 wird die Liste der übereinstimmenden lokalen Verkäufer an
den Benutzer übertragen.
-
Im
Schritt 624 bestimmt der lokale Nachrichtenserver, ob die
Kunden- und Verkäuferbedingungen
erfüllt
sind. Wenn die Bedingungen erfüllt
sind und der Benutzer zuvor keine Nachrichten vom Verkäufer empfangen
hat, wie im Schritt 626 bestimmt, wird die Benutzer-ID
im Schritt 628 in eine Kandidaten-Liste im Verkäuferprofil
gesetzt. Im Schritt 630 wird der Benutzer-ID eine Ablaufzeit
zugeordnet. Im Schritt 632 vergleicht der lokale Nachrichtenserver
die Zahl der Benutzer mit einem vorbestimmten Schwellwert. Wenn
der Schwellwert überstiegen
wird, wird im Schritt 634 eine Multicastnachricht übertragen,
die von der Dienst-Instanz-ID des Verkäufers identifiziert wird. Und
im Schritt 636 wird bestimmt, ob es weitere zu prüfende Verkäufer-IDs gibt.
-
Wenn
die Benutzer- und Verkäuferbedingungen
nicht erfüllt
sind (Schritt 624) oder der Benutzer bereits Nachrichten
vom Verkäufer
empfangen hat (Schritt 626), dann wird im Schritt 636 bestimmt,
ob es zusätzliche
zu prüfende
Verkäufer-IDs
gibt.
-
Ein
Fachmann auf dem Gebiet wird weitere Merkmale und Vorteile der Erfindung
auf der Grundlage der oben beschriebenen Ausführungsformen würdigen.
Entsprechend ist die Erfindung nicht dadurch eingeschränkt, was
speziell gezeigt und beschrieben wurde, mit Ausnahme von dem, was
in den anliegenden Ansprüchen
gezeigt wurde.