[go: up one dir, main page]

DE60128486T2 - Nachrichtensystem mit drahtloser kommunikation und verfahren dafür - Google Patents

Nachrichtensystem mit drahtloser kommunikation und verfahren dafür Download PDF

Info

Publication number
DE60128486T2
DE60128486T2 DE60128486T DE60128486T DE60128486T2 DE 60128486 T2 DE60128486 T2 DE 60128486T2 DE 60128486 T DE60128486 T DE 60128486T DE 60128486 T DE60128486 T DE 60128486T DE 60128486 T2 DE60128486 T2 DE 60128486T2
Authority
DE
Germany
Prior art keywords
message
client
host server
identification number
address
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60128486T
Other languages
English (en)
Other versions
DE60128486D1 (de
Inventor
Dennis New York MENDIOLA
Samuel S. Montecastro
Joseph Michael Garrovillo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chikka Pte Ltd
Original Assignee
Chikka Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Chikka Pte Ltd filed Critical Chikka Pte Ltd
Application granted granted Critical
Publication of DE60128486D1 publication Critical patent/DE60128486D1/de
Publication of DE60128486T2 publication Critical patent/DE60128486T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/53—Centralised arrangements for recording incoming messages, i.e. mailbox systems
    • H04M3/5322—Centralised arrangements for recording incoming messages, i.e. mailbox systems for recording text messages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/10—Aspects of automatic or semi-automatic exchanges related to the purpose or context of the telephonic communication
    • H04M2203/105—Financial transactions and auctions, e.g. bidding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/45—Aspects of automatic or semi-automatic exchanges related to voicemail messaging
    • H04M2203/4536—Voicemail combined with text-based messaging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/38—Graded-service arrangements, i.e. some subscribers prevented from establishing certain connections
    • H04M3/382—Graded-service arrangements, i.e. some subscribers prevented from establishing certain connections using authorisation codes or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/26—Network addressing or numbering for mobility support

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Game Theory and Decision Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Radio Relay Systems (AREA)

Description

  • BEREICH DER ERFINDUNG
  • Die vorliegende Erfindung betrifft ein Nachrichtensystem, das die Übermittlung von Nachrichten zwischen mehreren Benutzern und einem Host-Server beinhaltet, wobei das Medium zwischen einem der Benutzer und dem Host drahtlose Kommunikationen beinhaltet, sowie ein Verfahren dafür. Benutzer, die sich mit drahtloser Kommunikation befassen, in der die Erfindung besonders, aber nicht ausschließlich zum Einsatz kommt, sind Clients in Form von digitalen Funkvorrichtungen, insbesondere Mobilfunktelefonen, Pagern oder anderen solchen Kommunikationsvorrichtungen.
  • Die vorliegende Erfindung ist besonders, aber nicht ausschließlich, nützlich für Client-Anwendungen auf SMS-(Short Message Service)-Basis sowie für GSM-(Global System for Mobile Communications)-Geräte wie z.B. Mobiltelefone.
  • In der gesamten Beschreibung ist, wenn der Kontext nichts anderes verlangt, das Wort „umfasst" oder Variationen wie „umfassend" so zu verstehen, dass es eine angegebene ganze Zahl oder Gruppe von ganzen Zahlen impliziert, aber dabei keine andere ganze Zahl oder Gruppe von ganzen Zahlen ausschließt.
  • TECHNISCHER HINTERGRUND
  • Nachrichtensysteme sind mit der zunehmenden Verwendung von Personal Computern (PCs) und der Entwicklung von Computernetzwerken immer populärer geworden, die diese verknüpfen, um Kommunikationen dazwischen zu ermöglichen. So werden beispielsweise elektronische Bulletin Board Systeme (BBS) bereitgestellt, um elektronische Nachrichten und andere Dateien in einer analogen Weise gemeinsam zu nutzen und auszutauschen, in der Bulletin-Boards vor dem Auftreten von elektronischer Kommunikation zum Posten von Nachrichten verwendet wurden, die von großen Personenzahlen gepostet, gelesen und beantwortet werden konnten. BBSs waren ursprünglich vom Internet unabhängig, aber heute haben viele – wenn nicht sogar die meisten – ihre eigenen Websites und Nachrichten und Dateien werden mit dem Internet zum Zugreifen auf das Bulletin Board gepostet und gelesen. Typischerweise werden BBSs benutzt, damit Personen mit gemeinsamen Hobbys und Interessen Ideen austauschen können usw. BBSs werden auch als Mittel zum Verkaufen von Produkten verwendet.
  • Das Internet hat Zugängigkeit und Funktionalität des BBS-Konzepts erweitert, um ihm eine eigene Echtzeit-Nachrichtenübermittlungsmöglichkeit zu geben. Diese werden gewöhnlich in im Allgemeinen so genannten Sofortnachrichtensystemen (Instant Messaging Systems) und Chatrooms ausgeführt.
  • Instant-Messaging-Systeme bieten ein Medium, das das Internet und einen Dienstanbieter oder Transaktionsserver benutzt, über den eine Reihe verschiedener Typen von Benutzern oder Clients Nachrichten direkt zu- und voneinander senden und empfangen können. Es können spezieller Nachrichtengruppen von ,Buddies' gebildet werden, so dass Nachrichten gruppenweit gesendet und empfangen werden können. Der Direktheitscharakter dieses Nachrichtenübermittlungstyps ist der Email über das Internet ähnlich, kann aber unterschiedliche Client-Typen beinhalten. Dabei entfallt das Posten von Nachrichten auf einem virtuellen oder elektronischen Bulletin-Board und Nachrichten werden stattdessen direkt von einem Client zu einem/r beabsichtigten Empfänger oder Empfängergruppe übertragen. Somit ist das Instant-Messaging-System mehr benutzerspezifisch und wirkt durch den Antrieb individueller Benutzer und des Wunsches eines Benutzers, eine Nachricht zu einem anderen Benutzer oder einer Gruppe von Buddy-Benutzern zu senden, die einander im Allgemeinen kennen.
  • Chatrooms neigen dazu, das Bulletin-Board-Konzept zu behalten, indem ein virtuelles Bulletin-Board bereitgestellt wird, bei dem Nachrichten zwischengespeichert und auf den Chatroom zugreifenden Clients sequentiell angezeigt werden. Dabei werden weiterhin Nachrichten zu Clients heruntergeladen, die auf den Chatroom zugreifen, und in diesem Sinne findet eine mehr oder weniger sofortige Nachrichtenübermittlung statt. Chatrooms neigen jedoch dazu, eher gegenstandsspezifisch zu sein, und benutzen ein Format des Bulletin-Board-Typs, das eher geeignet ist, Informationen über einen bestimmten Gegenstand zu einer Reibe von interessierten Benutzern oder Clients zu übertragen, die auf den Chatroom zugreifen. Der Zugang kann für jedermann offen sein, der auf den den Chatroom hostenden Server zugreift, oder kann so beschränkt sein, dass für den Zugriff eine Mitgliedschaft und ein Passwort erforderlich sind. Die Gegenstandstypen sind grenzenlos, wobei spezielle Chatrooms für Ausbildungszwecke, persönliche Zwecke sowie E-Commerce jeglicher Art eingerichtet werden können.
  • So kann beispielsweise ein Chatroom speziell als Dating- oder Personenverkupplungsdienst für Mitglieder oder Clients eingerichtet sein, die auf den Chatroom zugreifen. Ein Chatroom kann auch speziell zum Diskutieren oder Bereitstellen von Informationen über ein bestimmtes Thema von Interesse für auf die Session zugreifende Personen betrieben werden, z.B. Teenager-Probleme oder Patentschutz für gewerbliche Methoden.
  • Die Idee eines Chatrooms kann auch erweitert werden, um Handel zu ermöglichen, wie z.B. ein Forum zum Kaufen und Verkaufen von Produkten unter Personen, die auf die Session zugreifen, wobei Artikel oder Produkte versteigert oder anderweitig gehandelt werden.
  • Für Nachrichtensysteme auf Internet-Basis, wie z.B. Instant-Messaging-Systeme, BBSs, Chatrooms, Auction-Rooms usw., muss sich ein Benutzer bei dem das Event hostenden Server einloggen, um teilnehmen zu können. Dies erfordert gewöhnlich die Eingabe einer Email-Adresse und eines Passwortes. Die Email-Adressen sind besonders dann erforderlich, wenn der Zugang beschränkt ist und/oder eine Form von gewerblicher Aktivität beinhaltet, so dass Authentifizierungsanweisungen und Alarmierungen zum Teilnehmer gesendet werden können (z.B. weil jemand eine Antwort auf seine Nachricht gepostet hat), und das Passwort dient zum Verifizieren der Identität des Teilnehmers.
  • Alle diese Nachrichtensysteme unterliegen denselben Beschränkungen. Ein Benutzer benötigt vornehmlich zuerst einmal Internet-Zugang, um eine Mitgliedschaft oder Zugangsgenehmigung zu dem den Nachrichtendienst hostenden Server zu erlangen, um Nachrichten zu lesen und zu posten. Bei BBSs muss ein Teilnehmer, wenn er wissen möchte, ob jemand auf seine Nachricht geantwortet hat, oder wenn er andere auf das BBS gepostete Nachrichten/Dateien lesen möchte, auf eine Email-Alarmierung warten (die auch verlangt, dass er sich bei seinem Internet Service Provider einloggt), oder muss das BBS regelmäßig besuchen, um den Status der Nachrichten auf dem BBS zu prüfen. Dies ist zeitaufwändig und umständlich. Wo das BBS für Handel oder für Versteigerungen eingerichtet ist, da kann sich die Zeitverzögerung zwischen dem Vorlegen eines (An)gebots, der Annahme dieses (An)gebots, und die Zeitverzögerung zwischen dem Stellen einer Frage über das Produkt und der Antwort auf eine solche Frage als für Käufer und Verkäufer sehr frustrierend erweisen.
  • Es ist jetzt für die Benutzer von mobilen Geräten wie z.B. Mobilfunktelefonen möglich, mit dem Wireless Application Protocol (WAP) auf das Internet zuzugreifen, typischerweise dann, wenn die Website auch in Wireless Markup Language (WML) gehostet wird. Benutzer können sich in so genannte „WAP Internet Gateways" einwählen und auf das Internet durch einen mit ihrem Mobilgerät bereitgestellten Web-Browser zugreifen. Der Benutzer kann daher Zugang zu BBSs mittels seines Mobilgerätes erlangen, aber dieselben Probleme entstehen wie bei Internet-Zugang mit anderen Geräten wie z.B. Personal Computern (PCs). Um das WAP zu benutzen, braucht ein Benutzer ein WAP-fähiges Gerät. Es ist nicht möglich, mit älteren Mobilgeräten auf WML-Websites zuzugreifen. Es ist gewöhnlich auch teurer, mit WAP-Geräten auf das Internet zuzugreifen als mit herkömmlichen PCs. Momentan kann nicht auf alle Websites über WAP-Geräte zugegriffen werden, da nicht viele Websites WML-Gegenstücke haben.
  • Eine weitere Alternative zu WAP-Inhaltszugriff, BBS, Chatrooms oder anderweitig ist die Verwendung von Sim Tool Kits oder STKs sowie Befehlen oder Schlüsselwörtern, die in die SMS-Nachricht selbst eingebettet sind. So ermöglichen es STKs, mit GSM-Geräten auf eine Weise ähnlich wie beim WAP-Zugriff auf Inhalt zuzugreifen, d.h. durch menügesteuerte Navigation. Der eigentliche Inhalt, auf den zugegriffen wird, kann vom Internet oder von einer beliebigen anderen elektronischen Quelle kommen. STKs vermitteln ein ,ähnliches Gefühl' wie WAP, da sich ein Benutzer in einem Optionsmenü mit seinem GSM-Gerät umherbewegen kann. STKs arbeiten mit SMS als Träger und STK als primäre Benutzeroberfläche auf dem Mobilgerät. STKs können zwar auf den meisten Legacy-GSM-Geräten arbeiten, d.h. denen, die nicht WAP-fähig sind, aber sie verlangen, dass der Benutzer die SIM-Karte seines Mobilgeräts austauscht. Ein weiterer Nachteil von STKs ist, dass der Menübaum in die SIM-Karten ,eingebrannt' werden muss. Nach dem Einbrennen ist die Baumstruktur des Menüs nicht mehr veränderbar.
  • In der anderen Praxis müssen Benutzer auf Inhalt auf SMS-Basis mittels Schlüsselwörtern zugreifen. Die meisten Benutzer finden das System bestenfalls unintuitiv. Ohne die Hilfe von Bedienungshandbüchern werden Schlüsselwörter fast immer vergessen, und wenn man sich erinnert, dann werden sie häufig falsch benutzt. Daher werden erhebliche Mengen an SMS-Inhaltsverkehr falsch zu den beabsichtigten Inhaltsanbietern geleitet.
  • Im Wesentlichen lassen sich Befehle des Menütyps nur schwer zwischen einem GSM-Gerät und einem Host-Server führen, wo der Träger der Befehle SMS ist. Die Schwierigkeit entsteht, weil ein Host-Server sich die vorherige Aktion oder Auswahl des Benutzers „merken" muss, um wissen zu können, wohin er im Baum als Nächstes geht. Da Interaktionen auf SMS-Basis zwischen GSM-Geräten und einem Host-Server im sessionlosen Format erfolgen, ist es nicht ohne weiteres offensichtlich, wie der Host-Server genau alle vorherigen Aktionen des Benutzen nachvollziehen kann. Eine Session bezieht sich auf Interaktionen zwischen einem Client und einem Server, wobei eine vorübergehende elektronische Verbindung zwischen dem Client und dem Server für den Echtzeitinformationsaustausch geöffnet wird. Die Session wird beendet, sobald sich der Client abmeldet oder die elektronische Verbindung aus irgendeinem Grund unterbrochen wird.
  • Wie in den mitanhängigen internationalen Patentanmeldungen PCT/SG00/00068 , PCT/SG00/00069 und PCT/SG00/00070 der Anmelderin beschrieben, können Instant-Messaging-Systeme bereitgestellt werden, die vom Client-Typ effektiv unabhängig sind und die Verknüpfbarkeit mit einem Server über das Internet oder ein anderes Computernetzwerk beinhalten. Diese Systeme können in der Tat Verknüpfbarkeit mit zellularen Mobilfunktelefonen bieten, die gemäß dem GSM-System arbeiten und SMS verwenden. Wie beschrieben, bietet bei SMS ein SMSC (Short Messaging Service Centre) ein Server- System, durch das alle SMS-Nachrichten gehandhabt werden, die von Client-Subscribern gesendet und empfangen werden. Die Nachrichten sind kurz, typischerweise auf eine Länge von 160 Zeichen begrenzt, und werden zwischen Subscribern des GSM-Netzes gesendet, wobei das SMSC-Server-System die Nachrichten zur Zuführung zum richtigen Zielort mit der GSM-Mobilnummer des beabsichtigten Empfängers verarbeitet. Unter dem SMS-Protokoll wird die Textnachricht vom Sender zunächst unter Verwendung des Mobiltelefonnetzes zum SMSC-Server-System gesendet. Das SMSC-Server-System speichert die Nachricht dann und weist sie dem beabsichtigten Empfänger zum Herunterladen mit dem normalen GSM-Protokoll zu, wenn der Empfänger als in einer Zelle aktiv identifiziert wird. Somit wird die SMS-Nachrichtenübermittlung typischerweise als eine beschrieben, die mit einem „Speichern und Weiterleiten"-Schema arbeitet.
  • Diese Anmeldungen beschreiben, wie eine Internetverbindung mit einem bestimmten Protokoll, dank des SMSC-Server-Systems, in Abhängigkeit vom jeweiligen GSM-Telefon- und -Netzwerkhersteller möglich ist. So verwendet beispielsweise NokiaTM das Computer Interface Message Distribution Protokoll Version zwei (CIMD2).
  • Wie in der mitanhängigen internationalen Anmeldung PCT/SG00/00092 der Anmelderin beschrieben, können WAP- und SMS-Technik bekanntlich im Tandembetrieb benutzt werden. Wapit.comTM stellt ein BBS bereit, bei dem Nachrichten über WAP gepostet und Teilnehmer per SMS informiert werden, sobald eine Antwort gepostet wurde. In diesem Fall erfolgen Antworten per SMS mittels in die SMS-Nachricht selbst eingebetteten Befehlen.
  • Alle früheren Anmeldungen der Anmelderin erleichtern Instant-Messaging auf eine Weise, die leicht an Kommunikationen mit einem GSM-Client angepasst werden kann. Dies kann in einer Reihe verschiedener Umgebungen in der Weise erfolgen, die in der mitanhängigen internationalen Anmeldung PCT/SG00/00127 der Anmelderin beschrieben ist.
  • In einer ähnlichen Weise, in der das in den oben erwähnten Anmeldungen beschriebene Instant-Messaging-System der Anmelderin effiziente und praktische Kommunikationen mit GSM-Geräten ermöglicht, ist es Ziel der vorliegenden Erfindung, diese Nutzung auf Nachrichtensysteme an sich auszuweiten, die die Verwendung von elektronischen BBSs, Chatrooms, Handelsforen oder anderen Funktionalitätstypen beinhalten, wo Informationen von einem Benutzer oder Client zu einem anderen zu einem beliebigen Zweck übertragen werden können.
  • In einem anderen Aspekt der Erfindung demonstriert die Anmelderin ein Verfahren zum Navigieren durch Inhalt vom Internet oder einer beliebigen elektronischen Quelle unter Verwendung von SMS als Träger zum Einholen von Informationen beispielsweise darüber, wie das System zu benutzen ist oder wie auf bestimmte Funktionen zugegriffen werden kann. Ein solches Verfahren vermittelt weiter das Gefühl eines Menü-„Baums", ohne dass WAP-Zugang oder STKs notwendig wäre(n).
  • Die US-A-5113442 offenbart ein Verfahren oder ein Betriebssystem zum Steuern der Zugriffsrechte für mehrere Benutzer auf mehrere sichere Objekte.
  • Es ist eine Aufgabe der Erfindung, eine effiziente und praktische Kommunikation von Nachrichten zwischen Benutzern oder Clients und einem Host-Server zu ermöglichen, wo das Medium zwischen einem der Benutzer und dem Austauschserver drahtlose Kommunikationen beinhaltet.
  • Die Erfindung stellt ein Nachrichtensystem zum Übermitteln von Nachrichten zwischen einem Host-Server und einem Client bereit, der Teil eines drahtlosen Kommunikationsnetzwerks mit einer Mehrzahl von drahtlosen Clients ist, mit einem Nachrichtendienst zum drahtlosen Übermitteln von Nachrichten dazwischen mit einem Nachrichtendienst-Server, wobei mit jedem drahtlosen Client eine Netzwerkidentifikationsnummer assoziiert ist, um den Client innerhalb des drahtlosen Kommunikationsnetzwerks eindeutig zu identifizieren, und wobei jede Nachricht ein Nachrichtenpaket mit der Adresse eines beabsichtigten Empfängers des Nachrichtenpakets und der Adresse des Senders der Nachricht beinhaltet; wobei das Nachrichtensystem Folgendes umfasst: einen Host-Server, mit dem mehrere Clients selektiv geschaltet werden können, um Nachrichten dazwischen zu übertragen, wobei mit jedem der Clients eine Client-Identifikationsnummer assoziiert ist, um den Client dem Host-Server eindeutig zu identifizieren; wobei der Host-Server und der Nachrichtendienst-Server zwecks Kommunikation dazwischen verbunden sind; wobei einer der Clients des Host-Servers ein drahtloser Client ist und die Client-Identifikationsnummer hat, die dessen Netzwerkidentifikationsnummer entspricht; wobei der Host-Server einen Zugangscode, um den Host-Server dem Nachrichtendienst-Server eindeutig zu identifizieren, und eine eindeutige Identifikationsnummer hat, die (a) einer vorgeschriebenen, vom Host-Server ausgeführten Aktion und (b) einer Entität, die Gegenstand der vorgeschriebenen Aktion ist, zugeordnet ist; wobei zwischen dem Host-Server und dem einen Client in Verbindung mit einer bestimmten vorgeschriebenen Aktion und Entität gesendete Nachrichten Folgendes beinhalten: (i) eine Kombination aus Zugangscode und eindeutiger Identifikationsnummer, die der jeweiligen Aktion und Entität als die Adresse des Host-Servers in Nachrichtenpaketen zugeordnet wurden, die zu oder von dem einen Client jeweils als der Sender bzw. der beabsichtigte Empfänger gesendet wurden, und (ii) die Netzwerkidentifikationsnummer als die Adresse des einen Clients in Nachrichtenpaketen, die zu und von dem Host-Server jeweils als der Sender oder der beabsichtigte Empfänger gesendet wurden; und wobei der Nachrichtendienst-Server den Zugangscode in der Adresse des beabsichtigten Empfängers oder des Senders zum Erkennen von zu oder von dem Host-Server gesendeten oder empfangenen Nachrichten verwendet und Nachrichten entsprechend leitet.
  • Der Host-Server kann ein Verarbeitungsmittel haben, um: (i) eine Client-Identifikationsnummer anhand der Adresse des Senders eines von einem Client empfangenen Nachrichtenpakets zu validieren; (ii) die eindeutige Identifikationsnummer anhand der Adresse des Empfängers in dem Nachrichtenpaket, das eine damit assoziierte gültige Client-Identifikationsnummer hat, zu verarbeiten; und (iii) die vorgeschriebene Aktion mit der durch die eindeutige Identifikationsnummer vorgegebenen Entität unter Berücksichtigung in dem Nachrichtenpaket enthaltener Begleitnachrichten auszuführen.
  • Der Host-Server kann ein Nachrichtenkompilationsmittel zum Kompilieren einer Nachricht und zum Senden derselben zu einem Client unter Verwendung seiner Client-Identifikationsnummer als die Adresse des beabsichtigten Empfängers oder ein Nachrichtenübertragungsmittel zum Übertragen einer davon von einem Client empfangenen Nachricht und zum Senden derselben zu einem anderen Client unter Verwendung seiner Client-Identifikationsnummer als die Adresse des beabsichtigten Empfängers haben, gemäß der vorgeschriebenen Aktion und Entität, die durch eine davon verarbeitete eindeutige Identifikationsnummer vorgegeben ist.
  • Der Host-Server kann ein Identifikationsmittel zum Identifizieren einer Netzwerkidentifikationsnummer anhand einer Client-Identifikationsnummer in der Adresse eines beabsichtigten Empfängers einer Nachricht haben, die entweder von dem Nachrichtenkompilationsmittel kompiliert oder von dem Nachrichtenübertragungsmittel empfangen wurde, sowie Übertragungsmittel zum Übermitteln der für einen drahtlosen Client beabsichtigten Nachricht zum Nachrichtendienst-Server dieses drahtlosen Client.
  • Der Nachrichtendienst-Server kann ein Verarbeitungsmittel haben, um die Adresse des beabsichtigten Empfängers einer vom Host-Server empfangenen Nachricht als die Netzwerkidentifikationsnummer eines drahtlosen Client des drahtlosen Kommunikationsnetzes davon zu verarbeiten und die Nachricht drahtlos zu dem drahtlosen Client, der der Netzwerkidentifikationsnummer entspricht, zu übertragen.
  • Die vorgeschriebene Aktion kann das Aufrufen einer Routine auf dem Host-Server umfassen, die mit dem Zugriff auf ein elektronisches Bulletin-Board assoziiert ist, und die Entität der Gegenstand oder das Thema ist, auf den/das sich das Bulletin-Board bezieht.
  • Die Nachricht kann sich auf das Lesen, Posten oder Antworten auf eine(r) Nachricht auf dem Bulletin-Board beziehen.
  • Die vorgeschriebene Aktion kann das Aufrufen einer Routine auf dem Host-Server in Verbindung mit der Teilnahme an einer kommerziellen Transaktion umfassen und die Entität ist ein Produkt oder ein Dienst, das/der der Gegenstand der Transaktion ist. Die kommerzielle Transaktion kann eine Aktion sein, die Entität ist ein auktioniertes/r Produkt oder Artikel und die Nachricht betrifft ein Gebot bei der Auktion in Bezug auf ein(en) spezielle/n Produkt oder Artikel.
  • Die vorgeschriebene Aktion kann das Aufrufen einer Routine auf dem Host-Server in Verbindung mit persönlichen Diensten umfassen und die Entität ist der jeweilige Typ des persönlichen Dienstes.
  • Die vorgeschriebene Aktion kann das Aufrufen einer Routine auf dem Host-Server in Verbindung mit einem Chatroom umfassen und die Entität ist der/das jeweilige Gegenstand oder Thema des Chatrooms.
  • Die vorgeschriebene Aktion kann das Aufrufen einer Routine auf dem Host-Server in Verbindung mit dem Übertragen der Nachricht direkt zu einem anderen Client oder einer Gruppe von Clients des Host-Servers gemäß Vorgabe im Nachrichtenpaket umfassen und die Entität ist der/die betroffene spezielle Client oder Clientgruppe.
  • Die Gruppe von Clients kann diejenigen sein, die als Buddies des Client entsprechend gespeichert sind, der die Nachricht zu einer Datenbank des Host-Servers sendet.
  • In dem erfindungsgemäßen Nachrichtensystem können Informationen über den Gebrauch des Nachrichtensystems vom Host-Server zum Client als Reaktion auf eine Anforderung vom Client gesendet werden, wobei die Anforderung ein Nachrichtenpaket umfasst, das einen Zugangscode und Daten umfasst, die die angeforderten Informationen anzeigen, wobei der Zugangscode den Host-Server dem Nachrichtenserver eindeutig identifiziert, wobei der Host-Server die Aufgabe hat, ein Informationsnachrichtenpaket als Reaktion auf das Anforderungsnachrichtenpaket zum Client zurückzusenden, wobei das Informationsnachrichtenpaket die vom Client angeforderten Informationen und einen Zugangscode umfasst, der vom Client als Anforderungsnachricht-Zugangscode als Reaktion auf das Informationsnachrichtenpaket zu verwenden ist, wobei der Anforderungsnachrichten-Zugangscode den Host-Server identifiziert und einen Teil beinhaltet, der durch die in dem Informationsnachrichtenpaket enthaltenen Informationen bestimmt wird.
  • Das anfängliche Anforderungsnachrichtenpaket kann einen Grundzugangscode plus die angeforderten Informationen anzeigenden Daten umfassen. Die Daten können ein Schlüsselwort aus alphanumerischen oder alphabetischen Zeichen umfassen. Nachfolgende Anforderungsnachrichtenpaket-Zugangscodes können den Grundzugangscode plus zusätzliche Indexe umfassen.
  • Der Host-Server kann Verarbeitungsmittel haben, um: (i) die Client-Identifikationsnummer anhand der Adresse des Senders eines von einem Client empfangenen Anforderungsnachrichtenpakets zu validieren; (ii) den Zugangscode anhand der Adresse des Empfängen im Nachrichtenpaket mit einer damit assoziierten gültigen Client-Identifikationsnummer zu verarbeiten; und (iii) das Informationsnachrichtenpaket als Reaktion auf eine empfangene Anforderungsnachricht mittels des Anforderungsnachrichtenpaket-Zugangscodes als die Senderadresse im Informationsnachrichtenpaket zu erzeugen.
  • Die Erfindung stellt auch ein Verfahren zum Übermitteln von Nachrichten zwischen einem Host-Server bereit, mit dem mehrere Clients selektiv verbunden werden können, um Nachrichten dazwischen zu übermitteln, und einem Client, der Teil eines drahtlosen Kommunikationsnetzwerks mit einer Mehrzahl von drahtlosen Clients ist, mit einem Nachrichtendienst, um Nachrichten drahtlos dazwischen mit einem Nachrichtendienst-Server zu übermitteln, wobei mit jedem drahtlosen Client eine Netzwerkidentifikationsnummer assoziiert ist, um den Client innerhalb des drahtlosen Kommunikationsnetzwerks eindeutig zu identifizieren, und wobei jede Nachricht ein Nachrichtenpaket mit der Adresse eines beabsichtigten Empfängers des Nachrichtenpakets und der Adresse des Senders der Nachricht umfasst; wobei das Verfahren die folgenden Schritte umfasst: Zuordnen einer Client-Identifikationsnummer zu jedem Client des Host-Servers, um den Client dem Host-Server eindeutig zu identifizieren, so dass die Client-Identifikationsnummer für den Client, der Teil des drahtlosen Kommunikationsnetzwerks ist, eine Client-Identifikationsnummer hat, die der Netzwerkidentifikationsnummer davon entspricht; Zuordnen eines Zugangscodes zum Host-Server, um den Host-Server dem Nachrichtendienst-Server eindeutig zu identifizieren, und einer eindeutigen Identifikationsnummer, die Folgendes anzeigt: (a) eine vorgeschriebene Aktion, die vom Host-Server auszuführen ist, und (b) eine Entität, die Gegenstand der vorgeschriebenen Aktion ist; Kompilieren von Nachrichten, die zwischen dem Host-Server und dem Client des drahtlosen Kommunikationsnetzwerks in Verbindung mit einer bestimmten vorgeschriebenen Aktion und Entität gesendet wurden, die Folgendes einschließen: (i) eine Kombination am dem Zugangscode und der der jeweiligen Aktion und Entität zugeordneten eindeutigen Identifikationsnummer als die Adresse des Host-Servers in Nachrichtenpaketen, die zu und von dem einen Client als Sender bzw. beabsichtigter Empfänger gesendet wurden, und (ii) die Netzwerkidentifikationsnummer als die Adresse des einen Client in Nachrichtenpaketen, die zu und von dem Host-Server als der Sender oder der beabsichtigte Empfänger gesendet wurden; und Leiten von Nachrichten durch den Nachrichtendienst-Server unter Verwendung des Zugangscodes in der Adresse des beabsichtigten Empfängers oder Senders, um Nachrichten zu erkennen, die zu dem Host-Server gesendet oder davon empfangen wurden.
  • Das Verfahren kann das Verbergen der Client-Identifikationsnummer eines bestimmten Client vor anderen Clients beinhalten, die Nachrichten von dem jeweiligen Client empfangen oder Nachrichten dorthin senden, wobei der bestimmte Client ebenfalls ein drahtloser Client ist.
  • Das Verfahren kann auch die folgenden Schritte umfassen: Kompilieren und Senden eines Anforderungsnachrichtenpakets vom Client zum Host-Server, wobei die Anforderung ein Nachrichtenpaket umfasst, das einen Zugangscode und die angeforderten Informationen anzeigende Daten umfasst, wobei der Zugangscode den Host-Server dem Nachrichtenserver eindeutig identifiziert, Zurücksenden eines Informationsnachrichtenpakets zum Client vom Host-Server als Reaktion auf das Anforderungsnachrichtenpaket, wobei das Informationsnachrichtenpaket die vom Client angeforderten Informationen und einen Zugangscode umfasst, der vom Client als Anforderungsnachricht-Zugangscode als Reaktion auf das Informationsnachrichtenpaket verwendet werden soll, wobei der Anforderungsnachricht-Zugangscode den Host-Server identifiziert und einen Teil beinhaltet, der von den im Informationsnachrichtenpaket enthaltenen Informationen bestimmt wird.
  • Das Verfahren kann auch die folgenden Schritte beinhalten: Validieren der Client-Identifikationsnummer anhand der Adresse des Senders eines von einem Client empfangenen Anforderungsnachrichtenpakets; Verarbeiten des Zugangscodes anhand der Adresse des Empfängers in dem Nachrichtenpaket mit einer damit assoziierten gültigen Client-Identifikationsnummer; und Erzeugen des Informationsnachrichtenpakets als Reaktion auf eine empfangene Anforderungsnachricht mittels des Anforderungsnachrichtenpaket-Zugangscodes als die Senderadresse in dem Informationsnachrichtenpaket.
  • Das Verfahren kann ferner das Austauschen einer Reihe von Anforderungs- und Informationsnachrichtenpaketen beinhalten, wobei sich jeder Austausch auf die Auswahl einer Option und das Bereitstellen einer Reibe weiterer Optionen in Bezug auf frühere Wahlen bezieht.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Die Erfindung wird im Hinblick auf die nachfolgende Beschreibung einer bestimmten Ausgestaltung davon besser verständlich. Die Beschreibung nimmt auf die Begleitzeichnungen Bezug. Dabei zeigt:
  • 1 ein schematisches Blockdiagramm, das die allgemeine Anordnung des Nachrichtensystems mit unterschiedlichen mit dem Host-Server verbundenen Client-Typen zeigt;
  • 2 ein schematisches Blockdiagramm der Ausgestaltung des Nachrichtensystems, das für eine Instant-Messaging-Anwendung mit dem Host-Server verbundenen Client-Typen auf PC-Basis und mit GSM-Geräten geeignet ist;
  • 3 ein schematisches Diagramm, das zeigt, wie eine Nachricht von einem GSM-Gerät-Client-Typ zum Host-Server gesendet wird;
  • 4 ein schematisches Blockdiagramm, das zeigt, wie eine Nachricht von einem GSM-Gerät-Client-Typ vom Host-Server empfangen wird;
  • 5 bis 7 schematische Diagramme, die allgemein zeigen, wie sich ein Benutzer bei der Handels- und Auktionsdienstanwendung registrieren kann;
  • 8 ein schematisches Diagramm, das allgemein zeigt, wie ein Benutzer Avisierungen über seine Gebote empfangen und weitere Gebote in der Handels- und Auktionsdienstanmeldung vorlegen kann;
  • 9 ein Beispiel für ein Diskussions-Board für einen Auktionsformatdienst;
  • 10 ein Fließschema des Diskussionsablaufs mit drahtlosen Clients, die mit dem Auktionsdienstformat assoziiert sind;
  • 11 ein schematisches Diagramm des Nachrichtensystems und der Interaktion von drahtlosen Clients mit dem Host-Server im Auktionsdienstformat;
  • 12 ein Beispiel für ein Diskussions-Board für einen persönlichen Dienst in Verbindung mit „Suche einen Freund", der drahtlose Clients und Clients auf PC-Basis beinhaltet;
  • 13 ein Beispiel für ein Diskussions-Board für einen Chatroom, der mit einem Thema in Verbindung mit „Teenager-Problemen" assoziiert ist; und
  • 14 ein Beispiel für einen Menübaum zum Illustrieren des Zugriffs auf Informationen durch einen GSM-Client von einem Host-Server.
  • BESTE ART DER AUSFÜHRUNG DER ERFINDUNG
  • Die bevorzugte Ausgestaltung des besten Modus der Erfindung betrifft ein Nachrichtensystem und ein Instant-Messaging-Verfahren, das die Übermittlung von Nachrichten in Verbindung mit einem oder mehreren Diensten beinhaltet, die zwischen einem Host-Server und einer Reihe von Benutzern bereitgestellt werden, die beim Host-Server registriert sind, wobei wenigstens einer der Benutzer ein Client eines drahtlosen Kommunikationsnetzes ist, das seinen eigenen Nachrichtendienst hat.
  • In der vorliegenden Ausgestaltung ist das drahtlose Kommunikationsnetzwerk ein GSM-Netzwerk und der Nachrichtendienst ist SMS.
  • Wie in 1 der Zeichnungen gezeigt, umfasst das Nachrichtensystem 11 der Ausgestaltung im Wesentlichen mehrere Clients 13 desselben Typs oder unterschiedlicher Typen 13a, 13b, 13c und 13d, sowie einen Host-Server 15. Der Host-Server 15 umfasst mehrere Gateway-Server 15a bis 15d und eine Benutzerinformationsdatenbank 17. Die Gateway-Server werden selektiv mit jedem der Clients 13 über ein Computernetz verbunden, das in der vorliegenden Ausgestaltung das Internet 19 ist, um Nachrichten und Befehle zu senden und zu empfangen, wie durch den Pfeil 21 in Verbindung mit einem vom Host-Server 15 zu den Benutzern bereitgestellten Dienst angedeutet wird.
  • Die Clients 13 werden bei Bedarf selektiv über das Internet 19 mit dem Host-Server 15 verbunden, um einen bestimmten Dienst mittels beliebiger oder aller der folgenden Teminals oder Geräte zu nutzen:
    • – einen über eine GSM-Cell-Site 23 und das SMSC-Server-System 25 verbundenen mobilen GSM-Client 13a, wobei SMS-Nachrichten 27 zwischen einem GSM-Gerät 29 des Client, wie z.B. ein Mobiltelefon, und dem SMSC-Server-System 25 übertragen werden,
    • – einen über einen Internet Service Provider („ISP") 31 verbundenen Client 13b auf PC-Basis, wobei Nachrichtenpakete 33 zwischen der PC-Client-Anwendung des Client und dem ISP 31 übermittelt werden,
    • – einen Internet-Browser-Client 13c über einen ISP 35, wobei HTML-Nachrichtenpakete 37 zwischen dem Browser-Client 13c und dem ISP 35 übermittelt werden, und
    • – einen Email-Client 13d über einen ISP 37, wobei Email-Nachrichtenpakete 39 zwischen dem Email-Client 13d und dem ISP 37 übermittelt werden.
  • Eine Client-Identifikationsnummer identifiziert jeden Client dem Host-Server 15 eindeutig. Diese Nummer wird auf die tatsächliche Adresse des Client abgebildet und in der Benutzerinformationsdatenbank 17 des Host-Servers gespeichert.
  • Drahtlose Clients, die Teil eines drahtlosen Kommunikationsnetzes sind, wie z.B. mobile GSM-Clients 13a, haben ebenfalls eine Netzwerkidentifikationsnummer, um den drahtlosen Client dem drahtlosen Kommunikationsnetz eindeutig zu identifizieren, in diesem Fall das GSM-Netzwerk, zu dem der mobile Client 13a gehört. Diese Nummer wird im GSM-Netzwerk gespeichert und von mobilen Clients benutzt, um beabsichtigte Empfänger von durch mobile Clients gesendeten SMS-Nachrichten und die Adresse des Senders solcher Nachrichten dem SMSC-Server-System eindeutig zu identifizieren, damit die Nachrichten übertragen werden. In der vorliegenden Ausgestaltung ist die Netzwerkidentifikationsnummer einfach die GSM-Telefonnummer des GSM-Gerätes des mobilen Client 13a.
  • Das SMSC-Serversystem 25 steuert und verwaltet die Übertragung aller SMS-Nachrichten zwischen seinen drahtlosen Client-Subscribern. Das SMSC-Server-System 25 beinhaltet eine Datenbank, in der die Netzwerkidentifikationsnummern aller SMS-Subscriber zusammen mit SMS-Nachrichtenpaketen 27 gespeichert werden, die von einem drahtlosen Client-Subscriber zu angepeilten Empfängern gesendet werden, die zur Zeit des Sendens mit dem zellularen Netzwerk verbunden oder für dieses verfügbar sein können oder auch nicht. Diese Nachrichtenpakete werden nachfolgend automatisch für angepeilte Empfänger heruntergeladen, wenn das GSM-Gerät eines Empfängers eingeschaltet wird, und ist zum Empfangen von Nachrichten innerhalb einer Cellsite angeschlossen oder anderweitig verfügbar.
  • Wie erwähnt, ist der Host-Server 15 über das Internet 19 direkt mit dem SMSC-Server-System 25 verbunden. In alternativen Ausgestaltungen kann das SMSC-Server-System jedoch über eine direkte elektronische Verbindung zugeschaltet sein. Auf diese Weise können Nachrichten oder Kurznachrichten über direkte elektronische oder Datenleitungen durch das Internet vom Host-Server 15 zum SMSC-Server-System 25 zur nachfolgenden Zuführung zu Subscribern von SMS auf dem GSM-Netzwerk gesendet werden. Kurznachrichten werden zwischen dem Host-Server 15 und dem SMSC-Server-System 25 mit dem Nachrichtenprotokoll des GSM-Netzwerks gesendet und empfangen. In der vorliegenden Ausgestaltung ist das verwendete Protokoll CIMD2 ein System, das von GSM-Mobiltelefon- und -Netzwerkherstellern wie Nokia und Ericsson verwendet wird. Das System kann jedoch auch andere Protokolle wie SMPP (Short Message Peer-to-Peer Protocol) verwenden.
  • Ein wichtiges Prinzip des Nachrichtensystems ist, dass der Host-Server 15 die Netzwerkidentifikationsnummer eines drahtlosen Client als die Client-Identifikationsnummer des Nachrichtensystems zuordnet. Auf diese Weise ist der Host-Server 15 mit dem SMSC-Server-System 25 bei seiner Identifikation und Adressierung von drahtlosen Clients kompatibel, um die Übertragung von Nachrichten zwischen dem Host-Server und einem drahtlosen Client über das SMSC-Server-System zu erleichtern.
  • Auch ein Zugangscode wird dem Host-Server 15 zugeordnet, um ihn dem SMSC-Server-System 25 eindeutig zu identifizieren. Der Zugangscode wird in Nachrichten verwendet, die zwischen drahtlosen Clients 13a und dem Host-Server 15 gesendet werden, so dass das SMSC-Server-System 25 SMS-Nachrichten von einem drahtlosen Client, die zum Host-Server 15 gesendet werden sollen, von anderen SMS-Nachrichten unterscheiden kann, die vom SMSC-Server-System gehandhabt werden, die mit dem von ihm bereitgestellten SMS-Nachrichtendienst assoziiert sind und nicht zum Host-Server gesendet werden sollen.
  • Dieser Zugangscode bildet von der Perspektive des SMSC-Server-Systems 25 aus effektiv die Adresse des Host-Servers 15. In der vorliegenden Ausgestaltung ist das SMSC-Server-System 25 besonders konfiguriert, um den Zugangscode von den ersten Stellen einer Netzwerkidentifikationsnummer zu decodieren, die die Zieladresse oder GSM-Telefonnummer eines beabsichtigten Empfängers einer SMS-Nachricht repräsentiert, die von einem drahtlosen Client auf dem GSM-Netzwerk gesendet wird. Das SMSC-Server-System 25 wird mit der geeigneten Routing-Software ausgestattet, um jede von ihm empfangene Nachricht zum Host-Server zu leiten, sobald der Zugangscode von der Netzwerkidentifikationsnummer decodiert ist, in der vorliegenden Ausgestaltung über das Internet.
  • Eine eindeutige Identifikationsnummer („UIN") wird verschiedenen Diensten zugeordnet, die vom Host-Server 15 für seine Clients bereitgestellt werden. Die UIN zeigt Folgendes an: (a) eine vorgeschriebene Aktion, die vom Host-Server für einen Client ausgeführt werden soll, und (b) eine Entität, die der Gegenstand der vorgeschriebenen Aktion ist.
  • In der vorliegenden Ausgestaltung beinhalten die vorgeschriebenen Aktionen, die vom Host-Server 15 ausgeführt werden, Folgende:
    • – Aufrufen einer Routine auf dem Host-Server, die mit dem Zugreifen auf ein elektronisches Bulletin-Board assoziiert ist;
    • – Aufrufen einer Routine auf dem Host-Server, die mit der Teilnahme an einer kommerziellen Transaktion assoziiert ist;
    • – Aufrufen einer Routine auf dem Host-Server, die mit persönlichen Diensten assoziiert ist;
    • – Aufrufen einer Routine auf dem Host-Server, die mit einem Chatroom assoziiert ist;
    • – Aufrufen einer Routine auf dem Host-Server, die mit der Übertragung der Nachricht direkt zu einem/r anderen Client oder Clientgruppe des Host-Servers gemäß Vorgabe im Nachrichtenpaket assoziiert ist, die nachfolgend als die Instant-Messaging-Anwendung bezeichnet wird.
  • Die Entitäten, die jeweils der Gegenstand der vorgeschriebenen Aktionen sind, lauten:
    • – der Gegenstand oder das Thema, auf den/das sich das Bulletin-Board bezieht;
    • – ein Produkt oder ein Dienst, der der Gegenstand der kommerziellen Transaktion ist;
    • – ein bestimmter Typ von persönlichem Dienst;
    • – ein bestimmter Gegenstand oder ein bestimmtes Thema des Chatrooms;
    • – ein(e) spezielle(r) Client oder Clientgruppe, der/die mit dem Empfang der Nachricht befasst ist.
  • Demgemäß werden unterschiedliche UINs für unterschiedliche vorgeschriebene Aktionen und unterschiedliche Entitäten zugeordnet, die mit der vorgeschriebenen Aktion assoziiert sind.
  • Ein wichtiger Aspekt der vorliegenden Ausgestaltung ist, dass im Falle eines drahtlosen Client die UIN einer vorgeschriebenen Aktion und Entität, auf die sich eine Nachricht bezieht, mit dem Zugangscode des Host-Servers kombiniert wird, um die Adresse des Host-Servers 15 zu bilden. Darüber hinaus ist, was das GSM-Netzwerk betrifft, diese Kombination aus Zugangscode und UIN die Netzwerkidentifikationsnummer für den Host-Server und wird als die Adresse oder effektive GSM-Nummer des beabsichtigten Empfängers in einer SMS-Nachricht verwendet, die von einem drahtlosen Client zum Host-Server gesendet werden soll. Sie wird ebenfalls als die Adresse des Senders für jede Nachricht verwendet, die vom Host-Server zu einem drahtlosen Client in Verbindung mit einem beliebigen Dienst gesendet wird, der dem drahtlosen Client vom Host-Server bereitgestellt wird.
  • Konfiguration und Betrieb des Host-Servers 15 und seiner Clients 13 werden nun mit besonderer Bezugnahme auf die davon ausgeführten verschiedenen Dienste beschrieben, wie durch die oben erwähnten vorgeschriebenen Aktionen und Entitäten umrissen wurde. Der Host-Server 15 ist so konfiguriert, dass er eine(n) bestimmte(n) Charakter und Funktion je nach dem von ihm bereitgestellten besonderen Dienst annimmt. Diese Konfiguration ist in Software ausgestaltet, daher konzentriert sich die Beschreibung auf die besonderen Funktionen zum Ausführen der bestimmten vorgeschriebenen Aktionen in Verbindung mit den Entitäten, die Gegenstand der Aktion sind, in einer genügenden Ausführlichkeit, damit ein Software-Programmierer, der über übliche allgemeine Kenntnisse der verfügbaren Programmentwicklungstools verfügt, die Software schreiben kann, die zum Implementieren der Funktionalität des Host-Servers nötig ist.
  • INSTANT-MESSAGING-ANWENDUNG
  • Wenn die UIN in einem von einem Client empfangenen Nachrichtenpaket anzeigt, dass eine Instant-Messaging-Funktion vom Host-Server 15 ausgeführt werden soll, dann führt der Host-Server die folgenden Grundaktionen für den Benutzer durch: (i) Senden und (ii) Empfangen von Sofortnachrichten, und (iii) Erfassen von Benutzern, die „online", d.h. die am Internet angeschlossen oder auf andere Weise für Sofortnachrichten erreichbar sind, genau oder etwa zu dem jeweiligen Zeitpunkt. Benutzer werden auch im Instant-Messaging-(„IM")-Szenario als „Buddies" bezeichnet.
  • Es gibt keinerlei absolute Gewährleistung dafür, dass ein Benutzer tatsächlich online oder zu einem bestimmten Zeitpunkt für Sofortnachrichten erreichbar ist, aufgrund der imperfekten Stabilität des Internets und von GSM-Netzwerken, der Mobilität des GSM-Subscribers usw. Die vorliegende Ausgestaltung macht jedoch eine sinnvolle Annahme in Bezug darauf, ob ein Benutzer zu einem bestimmten Augenblick wahrscheinlich erreichbar ist oder nicht, aufgrund bestimmter Aktivitäten, die vom Host-Server 15 durchgeführt werden, die nachfolgend ausführlicher beschrieben werden.
  • Der Host-Server 15 ist speziell so programmiert, dass er beliebige der oben erwähnten Grundaktionen ausführt, wenn er von einem auf den Host-Server zugreifenden Client dazu getriggert oder angewiesen wird. Diese Triggerung erfolgt dann, wenn der Client eine(n) elektronische(n) Aufforderung oder Befehl in einem zum Host-Server gesendeten Nachrichtenpaket sendet. Zum Beispiel, ein GSM-Gerät tut dies, indem es eine SMS-Nachricht zum Host-Server sendet, ein Email-Client tut dies, indem er eine Email zum Host-Sender sendet, ein Browser-Client tut dies, indem er Anweisungen oder Befehle zum Host-Server über das Web sendet, und eine Anwendung auf PC-Basis tut dies, indem sie Befehle über eine elektronische oder Internet-Verbindung zum Host-Server sendet.
  • Das Format der zugeführten Information, wie z.B. die tatsächliche Nachricht oder Avisierung, wer online ist, hängt unbedingt vom Gerätetyp ab. So wird das Format beispielsweise bei einem GSM-Gerät das SMS-Format sein, bei einer Email wird es ein Email-Format sein, und bei einem Browser-Client wird dies das HTML-(HyperText Markup Language)-Format sein.
  • Da die Erfindung vornehmlich die Instant-Messaging-Anwendung betrifft, da sie sich auf drahtlose Clients bezieht, werden die Grundfunktionen des Host-Servers 15 und des Client 13 in Bezug auf Sofortnachrichten im Zusammenhang damit beschrieben, wie sie in Bezug auf einen GSM-Client und einen Client auf PC-Basis ablaufen, wie in 2 der Zeichnungen dargestellt ist. Es wird nunmehr in Bezug auf eine Beschreibung davon, wie die Grundfunktionen mit anderen Client-Typen funktionieren, auf die mitanhängige internationale Anmeldung PCT/SG00/00068 der Anmelderin verwiesen.
  • Befassen wir uns zunächst mit Instant-Messaging mittels einer Client-Anwendung auf PC-Basis. Wie in 2 der Zeichnungen gezeigt, befindet sich eine internetgestützte PC-Anwendung 41 eines IM-Benutzers als Programm auf dem PC des Benutzers. Das Programm liefert die verschiedenen Funktionen zum Senden und Empfangen einer Nachricht und zum Avisieren von Buddies, die online sind, über zwei separate „Pop-up"-Fenster, ein Nachrichtensende- und -empfangsfenster 43 und ein Buddy-online-Fenster 45.
  • Das Nachrichtensende- und -empfangsfenster 43 hat einen „Von"-Header 47 zum Identifizieren der Client-Identifikationsnummer (CIN) des Urheber-Client der Nachricht, einen „Zu"-Header 49 zum Identifizieren der CIN des Client, für den die Nachricht bestimmt ist, und einen Nachrichteninhaltsraum 51 zum Anzeigen des Texts der zu sendenden oder zu empfangenden Sofortnachricht. In der eigentlichen PC-Anmeldung kann die Erzeugung dieser Nachricht in der Tat automatisiert sein, wobei die CIN des Senders und die CIN des Empfängen automatisch in die Nachricht einbezogen werden, wenn das Computer-Icon des Namens des Empfängers (des Buddy) auf der Client-Anwendung 41 auf PC-Basis doppelgeklickt wird.
  • Damit eine Nachrichtenübermittlung stattfinden kann, beinhaltet ein Host-Server 15 eine IM-Server-Anwendung 53, auf der sich die Enabling-Funktionen befinden, und eine Benutzerstatusdatenbank 55, die Einzelheiten von Benutzern speichert, unter denen Sofortnachrichten gesendet werden, sowie Statusdetails der Enabling-Funktionen, die kontinuierlich aktualisiert werden. Demgemäß erfolgen Kommunikationen zwischen PC-Anwendungen 45 von verschiedenen IM-Benutzern und dem Host-Server 15 über das Internet 19 und dem Internet Service Provider („ISP") 31 der Benutzer.
  • Das Senden von Nachrichten von der Client-Anwendung auf PC-Basis verlangt zunächst, dass der Benutzer 41 über den ISP 31 des Benutzers mit dem Internet 19 online geschaltet wird, und dass er eine „Nachricht senden"-Option aus einem Menü auf der Client-Anwendung des Benutzers auswählt, die die verfügbaren Funktionen der Anwendung angibt. Der Benutzer muss dann die Nachricht in den Nachrichteninhaltsraum 51 eingeben, der im Nachrichtensende- und -empfangsfenster 43 vorgesehen ist, und den Zielempfänger über die CIN des Zielempfängers oder eine Proxy dafür (wie z.B. seinen „Buddy"- Namen) im „Zu"-Header 49 angeben. Das Programm ist so ausgelegt, dass es automatisch die CIN im „Von"-Header 47 anzeigt, aufgrund der Tatsache, dass der Benutzer, weil er die „Nachricht senden"-Option gewählt hat, für den Sender gehalten wird.
  • Das Programm ist so ausgelegt, dass es dem Benutzer eine visuelle Avisierung gibt, dass eine Nachricht empfangen wurde, und diese kann somit vom Benutzer gelesen werden, indem dieser eine „Nachricht lesen"-Option im Menü wählt. Nach dem Wählen der Option erscheint das Nachrichtensende- und -empfangsfenster 43, in dem der „Von"-Header die CIN des Senders der Nachricht und der „Zu"-Header die CIN des Empfängers anzeigt, der der Benutzer ist.
  • Das Buddy-Online-Avisierungsfenster 45 hat zwei Hälften, eine obere Hälfte 57 und eine untere Hälfte 59. Die obere Hälfte 57 hat einen mit „online" beschrifteten Header 57a und einen Raum 57b, in dem alle CINs von Buddies, die online sind, wie zuvor definiert, aufgeführt sind. Die untere Hälfte 59 hat einen mit „offline" beschrifteten Header 59a und einen Raum 59b, in dem alle übrigen CINs von Buddies des Benutzen aufgeführt sind, die offline wären. Die tatsächliche Darstellung dieser Informationen kann in der PC-Anwendung je nach Benutzerpräferenz und dem sich ständig ändernden Design der grafischen Benutzeroberfläche („GUI") der Anwendung geringfügig variieren. Die gegebenen Grundinformationen bleiben jedoch gleich.
  • Die Bereitstellung solcher Funktionen und das Design von Fenstern in einer IM-Client-Anwendung auf PC-Basis sind in der Technik gut bekannt. Demgemäß können alternative Modi der Erfindung dieselben Grundfunktionen mit anderen Typen von visuellen Avisierungen erzielen, wie z.B. Ändern von Farben oder Pop-up-Listen von Icons, die bestimmte Benutzer oder Buddies identifizieren.
  • In Bezug auf die Bereitstellung dieser selben Funktionen in einem Client auf GSM-Basis wird eine notwendigerweise andere Anordnung bereitgestellt, bei der das bei GSM-Netzwerken verwendete existierende SMS-System benutzt wird. Im Client auf GSM-Basis ist ein GSM-Gerät 61 wie z.B. ein Mobiltelefon das Terminal oder Gerät und der Benutzer dieses Gerätes bedient es als Subscriber des GSM-Netzwerks, wobei Telekommunikationen zwischen Subscriber drahtlos durch GSM-Zellularsites 63 übertragen werden, die zum Schaffen eines Zellularnetzwerks angeordnet sind.
  • Eine SMS-Nachricht von Subscriber zu Subscriber auf einem GSM-Netzwerk beinhaltet ein Nachrichtenpaket 65, das eine Netzwerkidentifikationsnummer (NIN) des Senders (die GSM-Mobiltelefonnummer des Senders) 67, die NIN des Zielempfängers (gewöhnlich die GSM-Mobiltelefonnummer des Empfängers) 69, die GSM-Mobilnummer des SMSC-Server-Systems 25, das die Nachricht 71 verarbeitet, und eine Nachricht 73 mit einer Länge von 160 Zeichen umfasst.
  • Das Senden von Nachrichten vom GSM-Mobilgerät 61 zu einem anderen Benutzer des Nachrichtensystems 11 erfolgt durch Eingeben einer SMS-Nachricht 73 in das GSM-Gerät und durch Angeben der NIN des Zielempfängers in der „Zu"-Adresse 69. Die tatsächlichen Eingabeschritte sind für den GSM-Gerätehersteller spezifisch.
  • Von Bedeutung ist, dass die NIN-Adresse des Empfängers eine Kombination aus dem numerischen Zugangscode (gemäß Definition durch den GSM-Carrier) und der CIN des Zielempfängers ist. Wie zuvor beschrieben, ist der Zugangscode für den GSM-Carrier spezifisch und wird benutzt, um dem SMSC-Server-System 25 anzuzeigen, dass die SMS zum Host-Server 15 weitergeleitet werden soll.
  • Das GSM-Gerät 61 empfängt Sofortnachrichten über das Nachrichtensystem 11 genauso, wie es typische SMS-Nachrichten vom SMSC-Server-System 25 des GSM-Netzwerks empfangen würde. Von einem GSM-Client empfangene Sofortnachrichten vom Host-Server 15 würden eine CIN in der „Von" oder „Antwort an"-Adresse 67 anzeigen, die die Kombination aus Zugangscode plus CIN des Benutzers umfasst.
  • In der vorliegenden Ausgestaltung ist es wichtig zu bemerken, dass die CIN des Benutzers in der Instant-Messaging-Anwendung tatsächlich die UIN bildet, die vom Host-Server decodiert wird, um die notwendige vorgeschriebene Aktion mit der geeigneten Entität zu bestimmen – in diesem Fall das Senden des Nachrichtenpakets als Sofortnachricht zum angegebenen Empfänger.
  • Die IM-Server-Anwendung 53 ist so ausgelegt, dass sie eine Buddy-Online-Avisierung zu GSM-Clients über SMS-Nachrichten bereitstellt, die Online-Buddy-Informationen enthalten. Die IM-Server-Anwendung 53 sendet diese Nachrichten zum GSM-Client 61 nach Triggerung durch einen GSM-Client. Der Trigger für eine solche Nachricht kann automatisch oder manuell sein, je nach Spezifikation des Benutzers.
  • Wie in 2 gezeigt, werden manuelle Trigger von einem Benutzer eines GSM-Gerätes 61 ausgeführt, der eine SMS-Nachricht 75 sendet, die eine UIN enthält, die einen vorgeschriebenen SMS-Befehl zum Host-Server 15 designiert. So enthält beispielsweise das Nachrichtenpaket für diese SMS-Nachricht 75 den Zugangscode des Host-Servers 15, kombiniert mit der UIN für den vorgeschriebenen „Wer-ist-online-Befehl" als die NIN in der „Zu"-Adresse 77. Der Host-Server 15 ist mit einem Verarbeitungsmittel ausgestattet, so dass er dann, wenn er diese, den „Wer-ist-online-Befehl" enthaltende SMS-Nachricht vom SMSC-Server-System 25 empfängt, die UIN decodiert, um festzustellen, ob sie eine Instant-Messaging-Anwendung ist, und dann die IM-Server-Anwendung 53 zum Ausführen der vorgeschriebenen Aktion aufruft. Im vorliegenden Beispiel einer manuellen Triggerung würde dies das Zurücksenden einer SMS-Nachricht oder einer Serie von SMS-Nachrichten 81 zum Sender der Nachricht beinhalten, die die CINs und ggf. Pseudonyme derjenigen Buddies des Senders avisiert oder aufführt, die online sind. Alternativ kann das Nachrichtenpaket für diese SMS-Nachricht 81 die CIN 83 eines bestimmten GSM-Client-Benutzers und eine Nachricht 85 enthalten, die anzeigt, dass er oder sie online ist, oder eine andere Nachricht.
  • Im Falle einer automatischen Triggerung ist die IM-Server-Anwendung 53 so ausgelegt, dass sie eine SMS-Avisierung zum jeweiligen GSM-Client sendet, dass ein(e) bestimmte(r) Benutzer oder Benutzergruppe (Buddies) online ist oder nicht, wenn die IM-Server-Anwendung ihre Online-Anwesenheit oder eine Änderung derselben erkennt. Demgemäß wird bei automatischer Triggerung keine Aufforderung durch den GSM-Benutzer benötigt.
  • Die Instant-Messaging-Anwendung der vorliegenden Ausgestaltung arbeitet nach dem Prinzip der Verwendung einer einzigen CIN/UIN, um einen Benutzer unabhängig von seinem Client-Typ zu identifizieren, und der Anpassung dieser einen UIN an alle Client-Typen dieses Benutzers, die vom Host-Server gehandhabt werden können. Somit erlaubt es die IM-Server-Anwendung 53, dass der Benutzer auf sein Konto mit beliebigen der folgenden Client-Typen zugreift: Client-Anwendung auf PC-Basis, GSM-Client, Internet-Browser-Client und Email-Client. Unabhängig vom Client-Typ kann die IM-Server-Anwendung 53 den Benutzer erkennen und ihn entsprechend an seine jeweilige CIN/UIN anpassen. Von diesem Zeitpunkt an hat der Benutzer Zugang zu den Grundfunktionen des IM-Systems, wie z.B. Senden von Nachrichten, Antworten auf Nachrichten, Empfangen von Nachrichten und Prüfen, wer online ist, unter anderen IM-Grundfunktionalitäten.
  • Die Art und Weise, in der diese Anpassung von CIN/UINs an Geräte und Benutzer durch die IM-Server-Anwendung 53 abläuft, wird nun für den GSM-Geräte-Client-Typ mit Bezug auf die 3 und 4 beschrieben. Die Art und Weise, in der dies für andere Client-Typen abläuft, ist in der mitanhängigen internationalen Anmeldung PCT/SG00/00068 der Anmelderin beschrieben.
  • Mit Bezug auf eine von einem GSM-Gerät 85 bereitgestellte GSM-Client-Anwendung, die IM-Server-Anwendung 53, die in der Praxis unter den mehreren Gateway-Servern 15a bis 15e läuft, ist über das Internet 19 mit dem SMSC-Server-System 25 verbunden. Das SMSC-Server-System 25 kommuniziert wiederum drahtlos mit verschiedenen GSM-Zellularsites 87, um Kommunikationen mit dem GSM-Gerät 85 des Mobilbenutzers herzustellen.
  • Falls eine Sofortnachricht vom GSM-Gerät 85 zum Host-Server 15 gesendet wird, wie in 3 gezeigt, empfängt das SMSC-Server-System 25 zunächst das Nachrichtenpaket 89 vom GSM-Gerät 85 und sendet, nach dem Decodieren des Zugangscodes der Empfängeradresse im „Zu"-Adressfeld 91, das Nachrichtenpaket weiter über das Internet 19 zum Host-Server 15. Wie zuvor erwähnt, kann der GSM-Client-Benutzer Nachrichten in Nachrichtenpaketen 89 zu Clients des Host-Servers mittels seines lokalen SMS senden, wobei die Adresse durch Anhängen eines Zugangscodes (gemäß Definition durch den GSM-Carrier) an die Empfänger-CIN gebildet wird. Avisierungen von Buddies, die online sind, erfolgen ebenfalls durch SMS-Nachrichten, die vom Host-Server zum GSM-Client des Benutzers zurückgesandt werden.
  • Der Host-Server 15 benutzt dann nach dem Empfang des Nachrichtenpakets 89, wie durch den Pfeil 93 angedeutet ist, sein Verarbeitungsmittel zum Anpassen der (eindeutigen) CIN des Benutzers, in diesem Fall die GSM-Mobiltelefonnummer des Benutzers, im „Von"-Adressfeld 95 an die gespeicherte CIN von registrierten Benutzern des Host-Servers in der Benutzerinformationsdatenbank 17, um die CIN des Senders des Nachrichtenpakets zu validieren und dann die aus dem „Zu"-Adressfeld 91 extrahierte UIN zu verarbeiten, um die benötigte Routine zum Ausführen der vorgeschriebenen Aktion aufzurufen, in diesem Fall die Instant-Messaging-Anwendung, mit der vorgegebenen Entität. Der Host-Server benutzt in der vorliegenden Ausgestaltung (Landeskennzahl) + (Bereichskennzahl oder GSM-Carrier-Code) + (Mobiltelefonnummer), um die CIN des GSM-Benutzers zu bilden, wenn sich der Benutzer zum ersten Mal mit seinem GSM-Gerät registriert. Hier ist das Anpassen eine einfache Sache, da alle SMS-Nachrichtenpakete die GSM-Mobiltelefonnummer des Senders im „Von"-Adressfeld 95 enthalten.
  • Nach dem Aufrufen der Instant-Messaging-Anwendung ermittelt die IM-Server-Anwendung 53 den Benutzerstatus des Zielempfängers der Nachricht gemäß Vorgabe in der aus dem „Zu"-Adressfeld 91 extrahierten UIN durch Zugreifen auf die Benutzerinformationsdatenbank 17. Die IM-Serveranwendung 53 stellt auch die Client-Typen, auf die für den Zielempfänger zugegriffen werden kann, auf der Basis der in der Benutzerinformationsdatenbank gespeicherten Benutzereinstellungen für diesen Empfänger fest, um eine ordnungsgemäße Leitwegführung der Nachricht zu den gewählten Client-Geräten des Empfängers zu gewährleisten. Dies beinhaltet im Wesentlichen das Anpassen der CIN des Empfängers an das entsprechende Format des jeweiligen Client-Typs des Benutzers, an den die Nachricht adressiert werden soll. Im Falle von Client-Anwendungen auf PC-Basis und auf Browser-Basis ist dies einfach die UIN selbst. Im Falle der GSM-Anwendung ist dies tatsächlich die Telefonnummer des Zielempfängers, in diesem Beispiel in jedem Fall die UIN. Im Falle des Client auf Email-Basis ist dies einfach die Email-Adresse des angepeilten Empfängers. Da die Email-Adresse alphanumerisch ist, wird die Email-Adresse tatsächlich in eine numerische Adresse abgebildet.
  • Falls der Client-Typ für den Zielempfänger ein GSM-Gerät ist, wird das in 4 gezeigte Nachrichtenpaket 97 von der IM-Server-Anwendung 53 verarbeitet, indem sie die Adressfelder des Nachrichtenpakets 97 korrekt für eine Leitwegführung zu dem und durch das SMSC-Server-System 25 als SMS-Nachricht formatiert. Die Formatierung beinhaltet das Ausziehen des Zugangscodes aus dem „Zu"-Adressfeld 99 des Nachrichtenpakets 97 und das Hinzufügen des Zugangscodes zum Anfang der CIN des im „Von"-Adressfeld 101 angegebenen Senders.
  • Das Nachrichtenpaket wird dann direkt über das Internet 19 zum SMSC-Server-System 25 des GSM-Netzwerks gesendet, wie durch den Pfeil 103 angedeutet. Der GSM-Client-Benutzer empfängt schließlich das Meldungspaket 97 unter dem SMS des GSM-Netzwerks, wenn das GSM-Netzwerk die Verfügbarkeit des vorgegebenen GSM-Gerätes 105 des Benutzers erkennt, um Meldungen über eine der GSM-Zellularsites 107 zu empfangen.
  • In den in den 3 und 4 gezeigten speziellen Beispielen hat der die Nachricht sendende Benutzer die CIN ,639189336647' und der die Nachricht empfangende Benutzer hat die CIN ,639185556666'. Der GSM-Client muss jedoch den dem Host-Server vom SMSC-Server-System 25 zugeordneten Zugangscode, in diesem Beispiel ,373', an den Anfang der CIN des angepeilten Empfängen anhängen, um durch das GSM-Netzwerk hinauszuwählen, wenn der GSM-Zielempfänger auf die Nachricht einfach per „Rückantwort" antwortet – d.h. die NIN des Senders wird automatisch in die numerische „Senden an" Adresse eingegeben.
  • Es ist in allen Fallen zu bemerken, dass die CIN des Benutzers die primäre Benutzerkennung für die Zwecke der Handhabung von an ihn adressierten oder von ihm verfassten Sofortnachrichten ist. Die Eins-zu-Eins-Übereinstimmung dieser UIN mit den eindeutigen Kennungen für jedes Gerät erzeugt das Grundfundament für das Einzelkontosystem des IM-Systems.
  • Ein Hauptgrund für die Verwendung einer Nummer wie z.B. die CIN ist Geschwindigkeit. Dies ist besonders bei der Ausführung der schnellen Übertragung von Sofortnachrichten mit GSM-Geräten nützlich. Um auf eine von einem GSM-Gerätebenutzer empfangene IM-Nachricht zu antworten, braucht der Sender lediglich die Antwort-Schaltfläche anzuklicken, wonach die CIN des Senders automatisch in die „Antwort an" Adresse des GSM-Gerätes eingegeben wird. Darüber hinaus ist das Verfassen von Nachrichten durch den GSM-Gerätebenutzer ebenfalls eine einfache und schnelle Sache. Dazu braucht der Benutzer lediglich in die „Senden an" Adresse die CIN des beabsichtigten Empfängers an den Zugangscode des GSM-Carriers angehängt einzugeben. Diese Kombination aus Zugangscode und CIN kann in der Tat in den Adresslisten der meisten GSM-Geräte gespeichert werden, was einen schnellen Abruf von Adressen und eine schnelle Übertragung von Nachrichten erleichtert.
  • KOMMERZIELLE TRANSAKTIONSANWENDUNG
  • Wie oben angegeben, ist in der vorliegenden Ausgestaltung der Host-Server 15 so ausgelegt und konfiguriert, dass er eine Routine zum Ausführen einer vorgeschriebenen Aktion in Form einer kommerziellen Transaktion aufruft. Mit E-Commerce sind zahlreiche Typen von kommerziellen Transaktionen entstanden, für die die vorliegende Erfindung nutzbringend angewendet werden kann. Die Beschreibung der vorliegenden Ausgestaltung wird jedoch auf die Beschreibung der Anwendung der Erfindung auf einen Handels- und Auktionsdienst mit Bezug auf die 5 bis 8 begrenzt.
  • Wenn die UIN in einem von einem Client empfangenen Nachrichtenpaket anzeigt, dass die Nachricht mit dem vom Host-Server 15 bereitgestellten Handels- und Auktionsdienst befasst ist, dann wird eine Auktionsserver-Anwendung 111 auf dem Host-Server aufgerufen.
  • Die Auktionsserver-Anwendung 111 umfasst im Wesentlichen ein Registrierungshandhabungsmittel (Registration-Handler), ein Nachrichtenversandmittel (Message-Dispatcher), ein Nachrichtenempfangsmittel (Message-Receiver), ein Mittel zum Zuweisen einer eindeutigen Identifikationsnummer (UN-Assignor), eine Auktionsdatenbank (Auction Database 112) sowie ein Handels- und Auktionshandhabungsmittel (Auction Handler). Diese sind in Form von Programmroutinen ausgestaltet, die kontinuierlich unter der Steuerung eines Betriebssystems in der Auktionsserver-Anwendung 111 ausgeführt werden und somit den Registrierungs- und Gebotsvorlageprozess automatisieren.
  • Der Registrierungsprozess eines voraussichtlichen Benutzers des Auktion- und Handelsdienstes erfolgt mit der Forderung, dass der voraussichtliche Kunde einen Client auf PC- oder Browser-Basis auf einem Computer 113 hat, der über das Internet 19 mittels des ISP (Internet Service Provider) 115 des Benutzers auf den Host-Server 15 zugreifen kann, sowie ein GSM-Gerät 117.
  • Der Host-Server 15 ist auch in der zuvor beschriebenen Weise direkt oder durch das Internet mit dem SMSC-Server-System 25 des GSM-Netzwerks verbunden, von dem das GSM-Gerät 117 des Benutzers ein Subscriber ist. Der Message-Dispatcher und der Message-Receiver der Auktionsserver-Anwendung 111 kommunizieren direkt mit dem SMSC-Server-System 25 über den Host-Server 15 zum Senden und Empfangen von Kurznachrichten oder Befehlen über SMS, sobald der Host-Server die Auktionsserver-Anwendung aufruft.
  • In der vorliegenden Ausgestaltung greift der voraussichtliche Benutzer über den Computer 113 auf ein Registrierungsformular zu, das die Auktionsserver-Anwendung 111 voraussichtlichen Benutzern des Handels- und Auktionsdienstes durch den Host-Server 15 zur Verfügung stellt. Das Registrierungsformular beinhaltet Felder, in die der Benutzer wesentliche Daten für den Registrierungsprozess eingeben muss, sowie weitere Felder, in die der Benutzer bei Bedarf optionale Daten eingeben kann.
  • Wenn der voraussichtliche Benutzer Daten in die erforderlichen Felder im Registrierungsformular eingegeben hat, dann submittiert der voraussichtliche Benutzer die Daten der Auktionsserver-Anwendung 111 auf dem Host-Server 15. Dies kann auf eine Reihe verschiedener Weisen geschehen, wie z.B. unter Verwendung einer HTML-Formularwebseite für das Registrierungsformular, wobei der Benutzer die eingegebenen Daten der Auktionsserver-Anwendung 111 submittieren kann. Nach dem Empfang der wesentlichen und optionalen Daten vom Computer 113 des Benutzers ruft die Auktionsserver-Anwendung 111 den Registration-Handler auf.
  • Der Registration-Handler erzeugt einen neuen Eintrag in der Haupt-Benutzerinformationsdatenbank 17 des Host-Servers 15, um den Benutzer vorübergehend beim Host-Server für die Handels- und Auktionsdiensteeinrichtung auf dem Host-Server zu registrieren. Dieser Eintrag enthält vorgeschriebene wesentliche und optionale Daten für Registrierungszwecke. In der Ausgestaltung umfassen die wesentlichen Daten für den Handels- und Auktionsdienst den Namen und die Adresse des Benutzers, eine NIN eines im Besitz des Benutzers befindlichen nachrichtenfähigen drahtlosen Gerätes wie z.B. eine GSM-Mobiltelefonnummer, eine Email-Adresse und einen Kosenamen. Zu den optionalen Daten in der Ausgestaltung gehört beispielsweise das Geburtsdatum des Benutzen.
  • Der Registrierung-Handler weist dem Benutzer ein vorübergehendes Passwort zu, das in der Benutzerinformationsdatenbank 17 gespeichert wird, ohne dem Benutzer in dieser Phase übermittelt zu werden. Die Daten für den in der Benutzerinformationsdatenbank 17 gespeicherten Benutzer werden als inaktiv markiert, bis ein Authentifizierungsprozess beendet ist.
  • 6 zeigt einen ersten Teil des in der Ausgestaltung verwendeten Authentifizierungsprozesses. Der Authentifizierungsprozess für neue Benutzer, die sich bei der Auktionsserver-Anwendung 111 registrieren, erfolgt durch den Registration-Handler. Wie gezeigt, beinhaltet der Registrierungsprozess zunächst, dass der Registration-Handler das dem Benutzer zugewiesene vorübergehende Passwort und die GSM-Mobiltelefonnummer des Benutzers aus der Benutzerinformationsdatenbank 17 holt.
  • Der Registration-Handler weist dann den Message-Dispatcher an, eine SMS-Nachricht zum Mobiltelefon 117 des Benutzers zu senden. Die GSM-Mobiltelefonnummer des Benutzers wird als „Empfänger"-Feld in der SMS-Nachricht verwendet. Der Nachrichtentext der SMS-Nachricht enthält das dem Benutzer vom Registration-Handler zugewiesene vorübergehende Passwort. Der Nachrichtentext kann auch eine Anweisung an den Benutzer beinhalten, das Passwort einzugeben und es dem Host-Server 15 unter Verwendung des Computers 113 zu submittieren.
  • 7 zeigt einen zweiten Teil des Authentifizierungsprozesses. Wie gezeigt, submittiert der Benutzer nach dem Empfang der SMS-Nachricht auf seinem GSM-Mobiltelefon 117 das vorübergehende Passwort dem Host-Server 15 mit dem Computer 113. In der Ausgestaltung bringt die Auktionsserver-Anwendung 111, wenn der Benutzer dem Host-Server 15 auf dem Registrierungsformular eingegebene Daten submittiert hat, auf dem Computer 113 des Benutzers eine weitere HTML-Webseite zur Anzeige, die den Benutzer darüber informiert, dass er in Kürze eine Nachricht auf seinem Mobiltelefon erhalten wird, die ein vorübergehendes Passwort enthält. Die weitere HTML-Webseite weist den Benutzer dann an, das Passwort in ein Feld auf der Webseite einzugeben, und submittiert es dem Host-Server 15. Die weitere HTML-Webseite erläutert dann, dass sein Konto aktiviert wird, sobald das Passwort durch die Auktionsserver-Anwendung 111 verifiziert wurde.
  • Der Benutzer gibt das Passwort in seinen Computer 113 ein und sendet die Information zum Host-Server 15. Die vom Host-Server 15 empfangenen Informationen müssen auch den Benutzer identifizieren. Dies kann auf eine Reihe verschiedener Weisen geschehen, wie z.B. durch die Verwendung von „Cookies". Ein „Cookie" ist eine Datendatei, die sich auf dem Computer 113 befindet und Informationen auf der Basis der früheren Aktivitäten des Benutzers enthält was es dem Host-Server 15 ebenfalls ermöglicht einen Benutzer oder irgendeine Person zu identifizieren, die soeben die URL-Adresse besucht hat, die der Auktionsserver-Anwendung 111 entspricht. Für diese Session ist ein Cookie, das den Benutzer identifiziert, mit dem Konto dieses Benutzers assoziiert.
  • Nach dem Empfang des Passworts ruft der Host-Server 15 die Auktionsserver-Anwendung 111 auf, um zu prüfen, ob das vorgelegte Passwort dasselbe ist wie das in der Benutzerinformationsdatenbank 17 gespeicherte vorübergehende Passwort. Wenn das Passwort richtig ist, dann wird das Konto für den Benutzer als aktiv markiert und auf dem Computer 113 des Benutzers erscheint eine weitere HTML-Webseite, die den Benutzer darüber informiert, dass eine Registrierung erfolgreich war. Alternativ wird der Computer 113 des Benutzers, wenn das vorgelegte Passwort nicht korrekt mit dem in der Datenbank 17 gespeicherten eindeutigen Passwort übereinstimmt, zu einer HTML-Seite geleitet, die den Benutzer darüber informiert, dass sein Registrierungsversuch erfolglos war, und ihn auffordert, es noch einmal zu versuchen.
  • Es sind mehrere Versuche zulässig, bevor der Message-Handler keine weiteren Versuche des Benutzers mehr zulässt.
  • Diese Ausgestaltung wurde zwar so beschrieben, dass der Authentifizierungsprozess darin besteht, dass eine Nachricht zum GSM-Gerät des Benutzers gesendet wird und der Benutzer über seinen Computer eine Bestätigung eingibt, aber es ist zu verstehen, dass in anderen Ausgestaltungen alternative Registrierungsprozeduren möglich sind, die weiterhin verlangen würden, dass der Benutzer seine Mobiltelefonnummer eingibt, um sein Konto zu aktivieren.
  • So könnte der Benutzer beispielsweise nach dem Vorlegen der Registrierungsdaten zu einer Webseite gebracht werden, die das vorübergehende Passwort enthält und könnte angewiesen werden, über sein GSM-Gerät 117 eine sein Passwort enthaltende SMS-Nachricht zu einer bestimmten Telefonnummer zu senden. Diese Telefonnummer würde aus einer Verkettung des numerischen Zugangscodes des Host-Servers 15 für das SMSC-Server-System 25 und einer UIN bestehen, die die numerische Adresse umfasst, die vom Host-Server 15 zugewiesen und von diesem als die für Registrierungszwecke erkannt wird. Die SMS-Nachricht des Benutzers würde dann weiter vom SMSC-Server-System 25 zum Host-Server 15 weitergeleitet und nach dem Decodieren der UIN, die aus der als die Empfängeradresse eingegebenen verketteten Nummer extrahiert wurde, würde die Auktionsserver-Anwendung 111 aufgerufen und der Message-Receiver würde zum Handhaben der Nachricht hinzugezogen. Dann können ID und Passwort des Benutzers verifiziert werden, da der Nachrichtentext das Passwort enthält und die Mobiltelefonnummer des Benutzers sich im „Sender"-Felder der SMS-Nachricht befindet.
  • In einer Erweiterung des Registrierungsprozesses bewirkt die Auktionsserver-Anwendung 111, dass der Host-Server 15 eine Nachricht zum Mobiltelefon 117 sendet, die eine Nachricht enthält die diesen Benutzer anweist das vorübergehende Passwort einzugeben, das auf der auf seinem Computer 113 erscheinenden HTML-Seite angezeigt wird. Diese Nachricht hat als „Sender" eine Nummer, die die Verkettung des numerischen Zugangscodes für den Host-Server 15 mit dem SMSC-Server-System 25 des GSM-Netzwerks umfasst von dem das GSM-Gerät des Benutzers Subscriber ist, und eine UIN, die den Zugang zum Registration-Handler designiert. In vielen GSM-Geräten kann das Senden einer das vorübergehende Passwort enthaltenden SMS einfach dadurch erfolgen, dass der Benutzer die „Antwort"- Taste auf seinem GSM-Gerät anklickt. Die „Sender"-Adresse, die die Verkettung des numerischen Zugangscodes und der zum Registration-Handler gehörenden UIN ist, wird automatisch in das „Empfänger"-Feld der neuen SMS-Nachricht eingefügt, wodurch das Senden des vorübergehenden Passworts vereinfacht wird.
  • Bei diesem besonderen Registrierungsverfahren fügt der Message-Dispatcher in das „Sender"-Feld der SMS-Nachricht eine Nummer ein, die die Verkettung des numerischen Zugangscodes und die UIN umfasst, die vom Host-Server 15 zugewiesen und als für Registrierungszwecke bei der Auktionsserver-Anwendung 111 erkannt wird. Der numerische Zugangscode wird vom SMSC-Server-System 25 benutzt, um die Nachricht als für den Host-Server 15 beabsichtigt zu identifizieren. Jegliche vom SMSC-Server-System 25 empfangene SMS-Nachrichten, deren „Empfänger"-Feld mit dem numerischen Zugangscode des Host-Servers 15 beginnt, wird vom SMSC-Server-System 25 direkt zum Host-Server 15 weitergeleitet. Der Host-Server 15 decodiert nachfolgend die UIN und ruft dann, wenn er festgestellt hat, dass sich die Nachricht auf den vom Host-Server bereitgestellten Handels- und Auktionsdienst bezieht, die Auktionsserver-Anwendung 111 auf, wonach der Message-Receiver zum Verarbeiten der Nachricht aktiviert wird.
  • Die UIN zur Registrierung ist eine vorbestimmte Nummer, die auf den Registration-Handler weist. Auf diese Weise werden vom Message-Receiver empfangene Nachrichten, die an die UIN des Registration-Handlers adressiert sind, vom Message-Receiver zum Registration-Handler weitergeleitet.
  • Nach der Registrierung kann ein Benutzer für Handel und Auktion verfügbare Produkte und Dienste durchsuchen und Gebote für Produkte und Dienste wie nachfolgend ausführlicher beschrieben machen. Registrierte Benutzer können ihre Produkte auch für Handel oder Auktion in die Auktionsdatenbank 112 setzen, die von der Auktionsserver-Anwendung 111 verwaltet wird.
  • Zum Hinzufügen eines Produktes oder Dienstes zur Auktionsdatenbank 112 sendet ein Benutzer Produktdaten zum Host-Server 15 auf eine Weise, die der oben zum Submittieren von Registrierungsdaten beschriebenen ähnlich ist. Das heißt, der Benutzer greift auf die Auktionsserver-Anwendung 111 mit seinem Computer 115 zu und greift auf eine „neues Produkt hinzufügen" HTML-Webseite zu. Der Benutzer gibt dann Produktdaten ein und legt die Produktdaten zur Eingabe in die Auktionsdatenbank 112 von der Auktionsserver-Anwendung 111 gesteuert vor. In dieser Ausgestaltung sind die folgenden Produktdateneingaben vom Benutzer obligatorisch, einige fakultativ:
    • – Titel: Eine kurze Beschreibung des Produkts, die in Produktlisten in der Auktionsdatenbank 112 erscheint.
    • – Benutzer-ID: Der Kosename des das Produkt verkaufenden registrierten Benutzers.
    • – Benutzerpasswort: Das Passwort des Benutzers, das zum Validieren des Produkteintrags verwendet wird. Wenn das Passwort inkorrekt ist, dann wird das Produkt nicht in die Auktionsdatenbank 112 gesetzt.
    • – Auktionstyp/-methode: Der Benutzer kann vorgeben, ob die Auktion als regelmäßige Auktion oder beispielsweise als Dutch-Auktion durchgeführt werden soll.
    • – Artikelbeschreibung: Eine ausführliche Beschreibung des Verkaufsartikels.
    • – Land: Das Land des Verkäufers.
    • – Startdatum und -zeit der Auktion: Datum und Uhrzeit, wann die Auktion beginnt. Gebote für Artikel werden erst nach Beginn der Auktion akzeptiert.
    • – Auktionsdauer: Wie lange die Auktion dauert.
    • – Kategorie: Eine grobe Identifikation, aus einer Liste ausgewählt, des Typs des verkauften Produkts. Zum Beispiel: Antiquitäten, Musik oder Computer.
    • – URL-Adressen für externe Ressourcen: Eine optionale URL-Adresse (Universal Resource Location), die der Benutzer für Bilder, weitere Informationen usw. angeben kann.
    • – Computerbilddateien (Option): Ein Bild des angebotenen Artikels, das direkt vom Computer 115 über das Internet 19 auf die Auktionsdatenbank 112 heraufgeladen werden kann.
    • – Zahlungsmethode: Die Zahlungsmethode(n), die der Benutzer akzeptiert, wie z.B. Bargeld, Scheck oder Kreditkarte.
    • – Versandinformationen: Einzelheiten über den Versand des Produkts vom Verkäufer zum erfolgreichen Käufer wie z.B. Versandkosten, Länder, in die der Verkäufer zu versenden bereit ist oder nicht, usw.
    • – Mindestgebot: Ein Schwellenwert, der einen Mindestwert für das erste Gebot festlegt. Gebote unterhalb des Mindestgebotswertes werden von der Auktionsserver-Anwendung 111 nicht berücksichtigt.
    • – Reservegebot: Ein optionaler Wert, der einen Preis vorgibt, unterhalb dessen der Verkäufer die Waren nicht zu verkaufen bereit ist.
    • – Gebotsinkrement: Das Mindestangebotsinkrement.
    • – Toggle, um die dynamische Gebotszeit zu benutzen oder auch nicht (Option): Dieser Schalter weist den Auktionsserver an, die Auktionsdauer zu verlängern oder nicht, wenn Gebote nahe des Endes der vorgegebenen Auktionsdauer eingehen. Wenn der Schalter eingeschaltet ist, dann wird die Auktion so lange verlängert, bis keine Gebote für eine Zeitdauer mehr eingehen, die der dynamischen Gebotszeit entspricht.
  • Die vom Benutzer vorgelegten Produktdaten werden von der Auktionsserver-Anwendung 111 auf Vollständigkeit geprüft, und wenn die Informationen vollständig sind, dann weist der UIN-Assignor dem Produkt eine UIN zu. Die Produktdaten und die UIN werden dann in der Auktionsdatenbank 112 gespeichert.
  • Wenn die Auktion beginnt, dann werden auch das Produkt betreffende Gebote in der Auktionsdatenbank 112 gespeichert.
  • Ein Benutzer kann für die Auktion verfügbare Produkte in der Auktionsdatenbank 112 über das Internet 19 mit seinem Computer 115 durchsuchen. Wenn ein Benutzer für ein Produkt bieten möchte, dann wählt er das Produkt einfach an und wird dann zu einer Gebotsvorlage-Webseite gebracht. Die Identität des Benutzers wird dann mit dem oben beschriebenen Authentifizierungsprozess authentifiziert. Wenn die Identität des Benutzen authentisch ist, dann wird das Gebot des Benutzers für das Produkt von der Auktionsserver-Anwendung 111 akzeptiert und in der Auktionsdatenbank 112 gespeichert. Das Gebot des Benutzen wird anhand der Produkt-UIN für ein bestimmtes Produkt identifiziert. In alternativen Ausgestaltungen kann der Authentifizierungsprozess beim Bieten übersprungen werden oder nur erforderlich sein, wenn der Wert des Produkts einen vorbestimmten Wert übersteigt.
  • Benutzer können zwei Typen von Geboten eingeben, ein regelmäßiges Gebot oder ein automatisches oder Proxy-Gebot. Ein regelmäßiges Gebot besteht aus einem Einzelgebot für einen bestimmten Wert. Ein automatisches Gebot gibt ein Maximalgebot durch den Benutzer vor. Der Auction- und Trade-Handler dient dann als Proxy für den bietenden Benutzer um das Mindestinkrement für das Produkt bis zu dem vom Benutzer vorgegebenen Maximum in dem Versuch, das Gebot für das Produkt mit dem mindestmöglichen Inkrementalwert zu gewinnen.
  • Wenn der Benutzer sein erstes Gebot für ein Produkt registriert hat, dann können Avisierungen über das Gebot des Benutzers sowie weitere Gebote zum GSM-Mobiltelefon des Benutzers gesendet oder davon empfangen werden, ohne dass der Benutzer auf seinen Computer 115 zugreifen müsste. 8 hilft, den Avisierungs- und Gebotsvorgang zu illustrieren.
  • Wenn das Gebot eines Benutzers für ein Produkt überboten wird, dann weist der Auction- und Trade-Handler den Message-Dispatcher an, eine SMS-Nachricht zum GSM-Mobiltelefon 117 des Benutzers zu senden. Der Auction- und Message-Trade-Handler ruft die Mobiltelefonnummer des Benutzen aus der Benutzerinformationsdatenbank 17 ab und leitet sie zum Message-Dispatcher weiter, wo sie in das „Empfänger"-Feld der SMS-Nachricht gesetzt wird.
  • Der Auction- und Trade-Handler leitet auch die UIN des Produkts zum Message-Dispatcher weiter, der den numerischen Zugangscode des Host-Servers 15 mit der empfangenen Produkt-UIN verkettet und die resultierende Nummer in das „Sender"-Feld der SMS-Nachricht setzt.
  • Schließlich leitet der Auction- und Trade-Handler einen Nachrichtentext zum Message-Dispatcher für den Einbau als Nachrichtenhauptteil der SMS-Nachricht weiter. Der Nachrichtentext, der vom Auction- und Trade-Handler zusammengesetzt wird, enthält Informationen über das Produkt, wie z.B. Produkttitel, das derzeit höchste Gebot sowie Anweisungen zum Vorlegen eines weiteren Gebots. Ein Beispiel für einen Nachrichtentext könnte wie folgt lauten: „Ihr Gebot für ,Antique Bookcase' wurde überboten. Das derzeit höchste Gebot ist jetzt $1050. Zum Vorlegen eines weiteren Gebots antworten Sie einfach auf diese Nachricht und geben sie den Gebotstyp und den Betrag vor."
  • Die SMS-Nachricht wird vom Message-Dispatcher direkt zum SMSC-Server-System 25 des GSM-Netzwerks gesendet, der sie zum GSM-Mobiltelefon 117 des Benutzen weiterleitet.
  • Um ein weiteres Gebot für das Produkt zu machen, braucht der Benutzer lediglich mit der Antwortfunktion des GSM-Mobiltelefons 117 auf die SMS-Nachricht zu antworten. Vorteilhafterweise nimmt die Antwortfunktion des GSM-Mobiltelefons 117 automatisch die Nummer im „Sender"-Feld der ursprünglichen SMS-Nachricht und setzt sie in das „Empfänger"-Feld in der SMS-Antwortnachricht. Somit ist es nicht notwendig, dass sich der Benutzer Email-Adressen oder Produktcodes merkt, um ein Folgegebot zu machen. Der Benutzer gibt einfach den Gebotstyp und den Betrag des Gebots in den Hauptteil der SMS-Nachricht ein und sendet die SMS-Nachricht.
  • Um ein regelmäßigen Gebot für $1200 zu machen, gibt der Benutzer einfach „regular 1200" als Textnachricht der SMS-Antwortnachricht ein. Für ein automatisches Proxy-Gebot für $1200 gibt der Benutzer „auto 1200" als Text der SMS-Nachricht ein.
  • Wenn der Benutzer die SMS-Nachricht sendet, dann sendet sie das GSM-Mobiltelefon 117 zum SMSC-Server-System 25 des GSM-Netzwerks. Das SMSC-Server-System 25 identifiziert den numerischen Zugangscode des Host-Servers 15 im „Empfänger"-Feld der SMS-Nachricht und leitet die SMS-Nachricht über das Internet direkt zum Host-Server 15. Der Host-Server 15 decodiert die UIN aus der Nachricht und ruft, wenn er erkennt, dass sie die Auktionsserver-Anwendung 111 betrifft, den Message-Receiver der Auktionsserver-Anwendung auf.
  • Nach dem Erhalt der SMS-Nachricht extrahiert der Message-Receiver die Produkt-UIN aus dem „Empfänger"-Feld der SMS-Nachricht, die Mobiltelefonnummer des Benutzen aus dem „Sender"-Feld der SMS-Nachricht und die Textnachricht der SMS-Nachricht und leitet sie zum Handels- und Auktions-Handler weiter.
  • Der Handels- und Auktions-Handler kann das Produkt anhand der Produkt-UIN identifizieren. Ferner kann der Handels- und Auktions-Handler den Benutzer anhand seiner GSM-Mobiltelefonnummer identifizieren. Falls bereits ein höheres Angebot von einem anderen Benutzer eingegangen ist oder die Gebotsanweisungen des Benutzen nicht zu entziffern waren, sendet der Auktion- und Handels-Handler eine SMS-Antwortnachricht zum GSM-Mobiltelefon 117 des Benutzers und teilt ihm den Fehler mit. Ansonsten gibt der Handels- und Auktions-Handler das Gebot vom Benutzer in die Auktionsdatenbank 112 für dieses Produkt ein. Bei Bedarf kann der Auktion- und Handels-Handler, wenn das Gebot erfolgreich empfangen wurde, eine SMS-Antwortnachricht zum GSM-Mobiltelefon 117 des Benutzers senden und ihn darüber informieren, dass sein Gebot erfolgreich empfangen wurde.
  • Zusätzlich zum Senden einer Avisierung zum zuvor höchsten Bieter kann der Auction- und Trade-Handler auch so konfiguriert werden, dass er dieselben Avisierungen zu einigen oder allen Benutzern sendet, die für dieses Produkt geboten haben.
  • Es wird nun ein tatsächliches Beispiel für ein drahtloses Diskussions-Board im Auktionsformat zwischen drahtlosen Clients beschrieben, die sich bei der Auktionsserver-Anwendung registriert haben, um an einer vom Host-Server 15 durchgeführten Aktion teilzunehmen, mit Bezug auf die 9 bis 11.
  • 9 der Zeichnungen zeigt ein Beispiel für ein drahtloses Diskussions-Board 119 im Auktionsformat in einem ähnlichen Format, wie es auf der Website des oben beschriebenen Handels- und Auktionsdienstes erscheinen würde.
  • In dem illustrierten Beispiel betrifft das Diskussions-Board 119 speziell die Artikelnummer 987654321. Diese Artikelnummer würde die UIN für die vorgeschriebene Aktion bilden, die an der Teilnahme an der Auktion des Artikels selbst beteiligt ist, und wäre in der „Senden zu" Adresse zusammen mit dem Zugangscode des Host-Servers 15 zum SMSC-Server-System 25 des GSM-Carriers für die drahtlosen Clients enthalten, die an einer beliebigen Nachricht teilnehmen, die zum Diskussions-Board gesendet oder davon empfangen werden. Es ist zu bemerken, dass der Dienst nicht auf drahtlose Clients von nur einem GSM-Carrier begrenzt ist, sondern es können drahtlose Clients jedes Carriers, mit dem der Host-Server 15 verbunden ist und für die er einen Zugangscode zum Leiten von SMS-Nachrichten vom Nachrichtendienst-Server des Trägers hat, an jedem vom Host-Server verfügbaren BBS-Service teilnehmen.
  • „Mikey" 121 ist das Pseudonym oder der Buddy-Name eines ersten möglichen Käufers und „Jet" 123 ist das Pseudonym eines zweiten möglichen Käufers. „Lala" 125 ist das Pseudonym eines Verkäufers des Artikels, im vorliegenden Beispiel ein Mobiltelefon „Nokia 6110".
  • In diesem Beispiel des drahtlosen Diskussions-Boards 119 im Auktionsformat sendet der mögliche Käufer „Mikey" eine SMS-Nachricht von seinem Mobiltelefon zu einer bestimmten NIN, die die Verkettung des Zugangscodes des Host-Servers und der UIN des fraglichen Artikels umfasst. Der Nachrichteninhalt wie angezeigt enthält den Text: „Hat Ihr Telefon viele Kratzer?".
  • Wenn das SMSC-Server-System 25 diese SMS empfangen und zum Host-Server 15 gesendet hat, dann empfängt der Host-Server diese auf die zuvor beschriebene Weise und verarbeitet sie, authentifiziert den Sender der Nachricht mittels der Auktionsserver-Anwendung nach dem Decodieren der UIN, wonach die benötigte Nachricht in die Auktionsdatenbank eingegeben und virtuell auf das Diskussions-Board 119 gesetzt wird, so dass die Nachricht auf der Auktions-Website des Host-Servers betrachtet werden kann, der zu dem jeweiligen Artikel gehört.
  • In der vorliegenden Ausgestaltung wird die Nachricht, um die Teilnahme am Gebotsprozess durch Bieter zu erleichtern, die nur GSM-Geräte und keinen Zugang zu einer Client-Anwendung auf Browser-Basis haben, zu den obersten drei eindeutigen Bietern A, B und C und den letzten drei eindeutigen Benutzern U1, U2 und U3 gebroadcastet, die sich über den jeweiligen Artikel erkundigen, unter Berücksichtigung ihres jeweiligen Client-Typs. Wie in 11 gezeigt, werden im vorliegenden Beispiel, in dem alle sechs, d.h. die oberen drei Bieter und die letzten drei eindeutigen Benutzer, drahtlose Clients sind, SMS-Nachrichten, die die gepostete Nachricht enthalten, über den Host-Server 15 zum SMSC-Server-System 25 gesendet.
  • In diesem Fall können Benutzer, die eine gebroadcastete Nachricht empfangen, auf die Nachricht einfach dadurch „antworten,", dass sie einen Austausch von Informationen zwischen interessierten Parteien koordinieren, die ein oder mehrere drahtlose Clients beinhalten können.
  • Eine Erörterung des tatsächlichen Prozessablaufs ist in 10 der Zeichnungen illustriert. Dieses Diagramm illustriert im Wesentlichen den gesamten Ablauf von einem drahtlosen Client-Benutzer „Mikey" 121, der eine Anfrage auf das Diskussions-Board 119 setzt, bis zur Aussendung der Anfrage zu den obersten drei eindeutigen Bietern A, B und C sowie den letzten drei eindeutigen Benutzern, die sich über den Gebotsartikel erkundigen, nämlich U1, U2 und U3. Die Artikelnummer ist 987654321 und der Zugangscode für den Host-Server 15 auf dem SMSC-Server-System 25 eines gemeinsamen Carriers für alle Bieter und Benutzer ist 23301. Alle Benutzer haben sich zuvor bei dem vom Host-Server gehosteten Handels- und Auktionsdienst registriert, so dass der Registrierungsprozess umgangen wird.
  • Der Vorgang beginnt bei 131 und fährt damit fort, dass „Mikey" 121 eine weitere Textnachrichtenanfrage auf sein Mobiltelefon schreibt, wobei der Prozess durch die Box 133 angezeigt wird. Die Nachricht gemäß Anzeige in Box 135 lautet „Wo wurde das Telefon hergestellt?".
  • „Mikey" 121 sendet dann die Textnachricht wie in Box 137 illustriert zur MIN 23301987654321 des Host-Servers 15 auf dem GSM-Carrier-Netzwerk. Diese NIN kann als Pseudonym im Speicher des Mobiltelefons von einem vorherigen Registrierungsprozess gespeichert oder ansonsten von der Host-Server-Website eingeholt werden.
  • Diese Nachricht wird wie bei 139 gezeigt zum SMSC-Server-System 25 gesendet, das sie wiederum über das Internet 19 wie durch den Pfeil 141 angedeutet zum Host-Server sendet. Die Nachricht wird dann vom Host-Server 15 wie durch die Box 143 angedeutet verarbeitet, wobei je nach Situation auf die Benutzerinformationsdatenbank und die Auktionsdatenbank 112 zugegriffen wird, angedeutet in Box 145. Diese Verarbeitung beinhaltet die Eingabe der Nachricht in die Auktionsdatenbank 112 und dann das Ausführen einer Routine, die die gepostete Nachricht zu den obersten drei Bietern A, B und C und den letzten drei Benutzern U1, U2 und U3 broadcastet, die Nachrichten in die Datenbank gesetzt haben, sowie das Posten dem Sender der Nachricht bestätigt wird, nämlich „Mikey" 121.
  • Das Broadcasten der verschiedenen Nachrichten zur SMSC-Serverzentrale 25 erfolgt wiederum über das Internet 141, wie der Pfeil 146 andeutet. Das SMSC-Server-System, angedeutet durch Box 147, speichert und sendet dann nach Möglichkeit die relevante Nachricht, nämlich die SMS-Bestätigungsnachricht, zu „Mikey", wie durch Box 149 angedeutet, wobei die NIN-Adresse des Senders als 23301987654321 angezeigt wird. In diesem Beispiel lautet die Bestätigung „Ihre Nachricht wurde gepostet, danke schön.", wie in Box 151 am Ende der Übertragung bei 153 gezeigt.
  • Im Falle der drei höchsten Bieter A, B und C und der drei jüngsten Board-Benutzer U1, U2 und U3 wird die von „Mikey" gepostete Frage von der SMSC-Serverzentrale 25 zu diesen Parteien gesendet, wie durch Box 155 angedeutet. Im vorliegenden Beispiel lautet die Nachricht „Mikey: „Wo wurde das Telefon hergestellt?", wie in Box 157 angedeutet. Wie angezeigt, steht das Pseudonym oder der Buddy-Name des postenden Benutzers, um Verwirrungen zum vermeiden, immer vor dem Doppelpunkt „:".
  • Die NIN- oder GSM-Adresse des Senders ist ebenfalls mit 23301987654321 angegeben. Alle Benutzer hatten vermutlich diese „GSM-ähnliche" Adresse in ihren Mobiltelefonen gespeichert, so dass sie sofort das fragliche Produkt erkennen könnten. Danach bräuchte der Verkäufer, in diesem Fall „Lala" 125, lediglich auf die Frage zu antworten, wie auf jede andere SMS-Nachricht.
  • Ebenso haben die sechs Empfänger der letzten geposteten Nachricht alle die Option, einfach durch Antworten auf die empfangene Nachricht auf die Frage zu antworten.
  • Beim Antworten ist der Prozessablauf derselbe wie der, den „Mikey" beim anfänglichen Posten der Nachricht durchlaufen hat. Wird keine Antwort gegeben, dann wird die Session für die Person automatisch beendet, bis sie eine weitere Frage erhält.
  • In der vorliegenden Ausgestaltung sendet ein Benutzer, um auf den Inhalt des BBS zuzugreifen, ohne unbedingt eine Nachricht zu posten, einfach einen „?" Befehl im SMS-Nachrichtenteil eines zum Host-Server 15 gesendeten Nachrichtenpakets mittels der NIN, die die Verkettung des Carrier-Zugangscodes und der UIN des Artikels umfasst. Jedes „?", das allein im Nachrichtenteil einer empfangenen SMS-Nachricht von einem drahtlosen Client erscheint, wird vom Host-Server 15 als ein Befehl für den Host-Server decodiert, mit einer Liste einer vorbeschriebenen Anzahl von zuvor geposteten Nachrichten, gewöhnlich den letzten drei oder so, zu antworten.
  • Wie aus der vorangegangenen Beschreibung ersichtlich ist, stellt die Erfindung ein schnelles, effizientes und praktisches Verfahren und System zum Authentifizieren und Übertragen von Anweisungen für ein Auktion- und Handelssystem bereit, dessen Benutzer nachrichtenfähige drahtlose Geräte wie SMS-fähige GSM-Geräte haben.
  • ELEKTRONISCHES BULLETIN-BOARD
  • Die übrigen erwähnten Dienste, nämlich persönliche Dienste wie Dating- oder Verkupplungsdienste für die verschiedensten Paare, sowie Chatroom-Dienste auf der Basis von Themen oder Gegenständen, können alle als unterschiedliche Typen von elektronischen Bulletin-Board-Services (BBSs) angesehen werden, bei denen Nachrichten von einem Client-Benutzer auf eine Datenbank oder ein Bulletin-Board gesetzt und von einem anderen Client-Benutzer beantwortet werden können. Diese BBSs haben, wenn sie Zugriff durch drahtlose Clients beinhalten, wie in der vorliegenden Ausgestaltung vorgesehen, im Allgemeinen dasselbe Format wie das oben beschriebene drahtlose Diskussions-Board im Auktionsformat für den Handels- und Auktionsdienst der Gewerbetransaktionsanwendung. Somit können sie alle einfach vom selben allgemeinen Host-Server-Setup aufgenommen und vom Host-Server 15 technisch dadurch voneinander differenziert werden, dass ihnen unterschiedliche UINs für unterschiedliche BBS oder Chatroom-Themen zugewiesen werden. So können die Erfordernisse einer recht großen Vielfalt unterschiedlicher Interessengruppen von dem einen Host-Server-Provider erfüllt werden, der sowohl drahtlose als auch verdrahtete Clients beinhaltet, mit minimalem Overhead für den Host-Server-Provider.
  • Was die persönlichen Dienste betrifft, so zeigt 12 der Zeichnungen ein Beispiel für ein Diskussions-Board 159 in einem ähnlichen Format, in dem es auf einer Chatroom-Website erscheinen würde, die ein Client auf Browser-Basis sehen würde.
  • In dem illustrierten Beispiel gehört das Diskussions-Board 159 speziell zu dem persönlichen Dienst „Suche einen Freund", der eine dedizierte UIN hätte. Dies steht im Gegensatz zu anderen persönlichen Diensten wie „Suche eine Freundin", der sein eigenes Diskussions-Board und eine entsprechende UIN hätte, um ihn vom Diskussions-Board 159 zu unterscheiden.
  • Wie zuvor beschrieben, wäre die besondere UIN für die vorgeschriebene Aktion des Zugreifens auf das besondere Diskussions-Board in der „Senden an" Adresse zusammen mit dem Zugangscode des Host-Servers in einer beliebigen SMS-Nachricht enthalten, die von einem drahtlosen Client gesendet wird, der auf dieses besondere Diskussions-Board zugreifen möchte.
  • In dem in 12 illustrierten Diskussions-Board erlaubt es der persönliche Dienst „Suche einen Freund" interessierten Parteien, mit Personen in Kontakt zu kommen, die persönliche Werbeanzeigen auf das Diskussions-Board 159 gesetzt haben. Im vorliegenden Fall hat die Person mit dem Pseudonym „Pompom Girl" 161 die folgende persönliche Werbeanzeige 163 gepostet: „Ich bin 18 und hatte noch nie einen Freund, suche aber jemanden zum Surfen, Clubben und einfach Rumhängen". Die dieser geposteten persönlichen Werbeanzeige 165 entsprechende UIN und eine Hypertext-Chatschaltfläche 167 sind mit jeder geposteten persönlichen Werbeanzeige assoziiert.
  • Die Teilnahme an einem Chat mit der Person, die die persönliche Werbeanzeige gepostet hat, beinhaltet eine Kombination aus Zugriff auf Browser-Basis auf die Diskussions-Board-Website und die Benutzung eines GSM-Telefons.
  • Die Grundanforderung besteht darin, dass jede Person, die eine persönliche Werbeanzeige postet, einen drahtlosen Client hat, zu dem Nachrichten, die von interessierten Parteien in Verbindung mit der Werbeanzeige gesendet werden, vom Host-Server weitergeleitet werden.
  • Andererseits muss die interessierte Partei, die eine Nachricht senden möchte, einen Client auf Browser- und PC-Basis oder einen Web-fähigen drahtlosen Client haben, um auf das Diskussions-Board zuzugreifen, und braucht bei Bedarf einen drahtlosen Client, um an einem Chat mit der postenden Person teilzunehmen.
  • So möchte möglicherweise z.B. eine interessierte Partei, z.B. „Joe", mit der Person chatten, die die persönliche Werbeanzeige 163 gepostet hat, nämlich „Pompom Girl" 161, zur Diskussions-Board-Website gehen und entweder auf den Handle „Pompom Girl" 161 oder die Hypertext-Chat-Schaltfläche 167 klicken und dann ihre Nachricht senden. Das Anklicken des Handle 161 oder der Schaltfläche 167 bewirkt, dass eine Persönlicher-Dienst-Anwendung auf dem Host-Server 15 aufgerufen wird, so dass die Nachrichten zu dem Diskussions-Board oder zu der Person verwaltet werden können, die die Werbeanzeige von dieser besonderen interessierten Partei gepostet hat. Nachrichten von Joe können entweder über den auf die Website zugreifenden PC oder über das Mobiltelefon von Joe im Falle des letzteren mit SMS eingegeben werden. Was wichtig ist, der die SMS-Nachricht zum Host-Server sendende drahtlose Client muss den Zugangscode und die UIN des Chatrooms des persönlichen Dienstes in der „Senden an" Adresse benutzen.
  • Der Host-Server und die mit dem „Suche einen Freund" Dienst assoziierte Persönlicher-Dienst-Anwendung empfangt dann, im Falle von Joe, der die Nachricht von seinem Mobiltelefon sendet, das SMS-Nachrichtenpaket von Joe über das SMSC-Server-System 25 und sendet die Nachricht als eine SMS-Nachricht zum drahtlosen Client „Pompom Girl" mittels der CIN von „Pompom Girl" im „Senden an" Adressfeld des Nachrichtenpaketes unter Angabe des Host-Server-Zugangscodes und der UIN des Diskussions-Boards im Adressfeld des Senders. In der vorliegenden Ausgestaltung besteht die tatsächliche Nachricht aus dem Buddy-Namen „Joe", gefolgt von einem „Doppelpunkt"-Symbol und dann der ursprünglichen Nachricht von Joe. Hinweis: die Anonymität von Joe und Pompom-Girl wird in dem Ausmaß gewahrt, dass ihre CINs keiner anderen Partei offenbart werden.
  • „Pompom Girl" kann, wenn sie schließlich die Nachricht auf ihrem drahtlosen Client empfängt, einfach dadurch antworten, dass sie den „Antwort an" Nachrichtendienst auf ihrem GSM-Telefon benutzt und die Antwort eintastet. In diesem Fall werden der Zugangscode und die UIN des Diskussions-Boards 159 automatisch in das „Antwort an" Adressfeld des Antwortnachrichtenpakets gesetzt. Die Nachricht von „Pompom Girl" würde dann aber die SMS-Funktion und den Host-Server 15 zu „Joe" zurückgesendet, wodurch wiederum die Anonymität beider Parteien gewahrt bliebe.
  • Eine von der Persönlicher-Dienst-Anwendung durchgesetzte Grundregel ist, dass alle von der die Werbeanzeige hostenden Person gesendeten Nachrichten zur letzten interessierten Partei gesendet werden, und auf diese Weise würde normalerweise „Joe" die Antwort erhalten. In einigen Fällen braucht dies aber nicht unbedingt der Fall zu sein, wenn mehr als eine interessierte Partei Nachrichten zu der die Werbeanzeige postenden Person mehr oder weniger gleichzeitig sendet.
  • Um diese Situation zu bewältigen, wird die Persönlicher-Dienst-Anwendung speziell so ausgelegt und konfiguriert, dass in solchen Fällen entstehende Verwirrung vermieden wird, indem ein Befehl im Nachrichtenteil einer als Antwort auf eine interessierte Partei gesendeten SMS interpretiert wird, wobei das Pseudonym der die Nachricht gesendeten interessierten Partei identifiziert wird. In der vorliegenden Ausgestaltung wird dieser Befehl durch das Symbol „@" gefolgt vom Pseudonym oder Buddy-Namen der Person repräsentiert, die die Nachricht gesendet hat, auf die die Person, die die Nachricht gepostet hat, antwortet. Zum Beispiel, wenn „Pompom Girl" auf die von „Joe" erhaltene Nachricht antwortet, dann würde sie den Text „@Joe" (gefolgt von Leertaste) vor den speziellen Text der Nachricht einsetzen, den sie zu „Joe" in Beantwortung seiner Nachricht senden möchte.
  • Es ist zu bemerken, dass beim Austauschen von Nachrichten die Persönlicher-Dienst-Anwendung in jeder Kommunikation die Pseudonyme und Buddy-Namen der die Werbeanzeige postenden Person und der interessierten Parteien und nicht ihre tatsächlichen GSM-Nummern verwendet, wodurch die Anonymität bewahrt werden kann.
  • Jede Person, die sich in die Website des Diskussions-Boards einloggt, muss jedoch ihre registrierte CIN und ihren registrierten eindeutigen Buddy-Namen verwenden. Dies ist jedoch für Kommunikationen, die mit einem drahtlosen Client assoziiert sind, aufgrund des „persönlichen" Charakters des Telefons nicht notwendig.
  • Im Chatroom-Dienst in Bezug auf ein bestimmtes Diskussionsthema zeigt 13 der Zeichnungen ein virtuelles Diskussions-Board 169 über ein bestimmtes Thema, das von einer auf dem Host-Server 15 bereitgestellten Chatroom-Anwendung gestellt wird. Die Chatroom-Anwendung erlaubt es Personen mit demselben Interesse, über ein bestimmtes Thema miteinander zu kommunizieren. Das Thema des Chatrooms kann ein gemeinsames Interesse sein oder ein Benutzer kann seinen eigenen Chatroom kreieren, so dass nur bestimmte Personen, wie z.B. ausgewählte Freunde, teilnehmen können.
  • Jedes Chatroom-Thema oder jeder Benutzer-Chatroom wird anhand seiner eigenen UIN identifiziert und von einem Administrator verwaltet, dessen Aufgabe es ist, den Chatroom einzurichten, Personen zur Teilnahme einzuladen, die Sicherheit und das Beschränkungsniveau der Site festzustellen, z.B. ob Passwörter erforderlich sind oder ob er für die Öffentlichkeit offen ist, Postings nach Bedarf auszufiltern und Nummern zum Chatroom hinzuzufügen oder daraus zu löschen, wie dies in einer beschränkten Chatroom-Umgebung der Fall ist, usw.
  • Nach dem Einrichten des Chatrooms mit eigener UIN kann ein Benutzer, der zur Teilnahme am Chatroom berechtigt ist, Nachrichten durch seinen eigenen PC oder sein Mobiltelefon auf ähnliche Weise wie oben mit anderen vom Host-Server bereitgestellten Diensten beschrieben posten. Darüber hinaus kann er eine Nachricht durch Eingeben von Text durch die Website oder durch Senden einer SMS-Nachricht mit der NIN des Host-Servers auf dem jeweiligen betroffenen GSM-Carrier unter Verwendung der Verkettung aus Zugangscode und UIN des jeweiligen Chatrooms senden, auf den zugegriffen wird.
  • In dem in 13 der Zeichnungen gezeigten speziellen Beispiel ist der jeweilige Chatroom der „Teenager-Probleme-Chatroom" und hat die UIN 4321. Die die Nachricht postende Person hat einen drahtlosen Client, der Mitglied eines GSM-Carriers ist, wo der Host-Server den Zugangscode 7777 hat.
  • In dem illustrierten Beispiel A lautet die gepostete Nachricht 171 „Ich habe Probleme mit meiner Mutter. Sie versteht meine Teenager-Probleme einfach nicht. Was kann ich tun?"
  • Das Diskussions-Board 169 bietet auch zwei Optionen, eine, die eine „Klick"-Hypertext-Schaltfläche 173 für Benutzer auf Browser-Basis beinhaltet, die lautet „Zum Posten von Nachrichten hier klicken", und eine andere mit Details darüber, wohin eine SMS-Nachricht gesendet werden soll, um sie auf das Diskussions-Board 169 zu setzen. Die letztere wird im vorliegenden Beispiel als 175 angegeben und lautet: „oder für SMS-Nachricht SENDEN AN: 77774321". Die Sende-zu-Nummer ist die NIN des Host-Servers und das Diskussions-Board für einen bestimmten GSM-Carrier, wobei die NIN aus dem Carrier-Zugangscode 7777 und der UIN 4321 des „Teenager-Probleme"-Chatrooms besteht.
  • Die Chatroom-Anwendung ist in der vorliegenden Ausgestaltung so ausgelegt und konfiguriert, dass vom Chatroom ausgesendete Nachrichten zu denjenigen gebroadcastet werden, die sich im selben Chatroom befinden, mit Ausnahme der Person, die soeben die Nachricht gepostet hat. Die letzten Postings werden zu einer vorbestimmten Zahl der neuesten eindeutigen Posting-Benutzer und zum Chatroom-Administrator gebroadcastet, wenn der Chatroom-Administrator nicht derjenige war, der die Nachricht ursprünglich gepostet hat. Die jeweilige Anzahl von Benutzern, zu denen die Nachricht gebroadcastet wird, wird vom Chatroom-Administrator festgelegt.
  • Drahtlose Clients, die Nachrichten vom Chatroom empfangen und eine Antwort posten wollen, brauchen lediglich durch die auf ihrem Telefon vorhandenen SMS-Dienste zu antworten, wobei die NIN des Host-Servers und des Chatrooms wahrscheinlich gespeichert würden. In diesem Fall würde der Nachrichtenbeantwortungsdienst auf einem Mobiltelefon aufgerufen, wonach die NIN 77774321 automatisch in das „Senden an" Adressfeld im SMS-Nachrichtenpaket eingegeben würde, das schließlich vom drahtlosen Client zum Host-Server gesendet wird. Diese Nachricht würde vom Host-Server in der gewöhnlichen Weise wie zuvor beschrieben gehandhabt, so dass die UNI decodiert und die Nachricht zur jeweiligen Chatroom-Anwendung gesendet würde.
  • Das Format des Chatroom-Service in der vorliegenden Ausgestaltung sieht vor, dass zu Konversationen im Chatroom mit dem „?"-Befehl Fragen gestellt werden können, ähnlich wie die Art und Weise, in der dieser Befehl in dem zuvor beschriebenen Auction-Room-Szenario benutzt wird. Das Senden dieses Befehls zur NIN in einer SMS-Nachricht von einem drahtlosen Client bewirkt, dass eine vorbestimmte Anzahl der vorherigen Postings zu der die Frage stellenden Person vom Host-Server zurückgesandt wird, so können beispielsweise die letzten drei geposteten Nachrichten zurückgesandt werden. Der Fragebefehl kann mit weiteren Fragebefehlen verkettet werden, z.B. „??", um die Zahl der zuvor abgefragten Postings zu multiplizieren, die zum drahtlosen Client zurückgesandt werden. So werden beispielsweise bei der Frage „??" 2 × 3 oder sechs Nachrichten gesandt, und bei der Frage „???" würden 3 × 3 oder neun frühere Nachrichten gesendet, usw. Die tatsächliche Anzahl der involvierten Nachrichten ist ein Parameter, der vom Chatroom-Administrator justiert werden kann.
  • Es ist zu verstehen, dass jeder beliebige BBS-Typ auf diese Weise eingerichtet werden kann, der eine Reihe verschiedener Client-Typen verwendet, einschließlich drahtloser Clients unter Verwendung von SMS-Messaging, wie unter einem GSM-Netzwerk bereitgestellt wird.
  • Als Alternative zum direkten Posten der NIN 77774321, vielleicht weil der Benutzer die NIN-Informationen nicht sofort zur Hand hat, kann ein Benutzer menügesteuerte Navigation und – zunächst – ein Schlüsselwort benutzen, um die korrekte NIN zu bestimmen, die für die benötigte Aktion zu benutzen ist.
  • 14 illustriert ein Beispiel dafür, wie diese menügesteuerte Navigation ausgestaltet wird. In diesem Beispiel wird sie mit einem Electronic Bulletin Board Service benutzt, könnte aber genauso gut auch mit anderen Anwendungen angewendet werden. Sie ist nicht auf das hierin beschriebene Beispiel begrenzt.
  • Im Allgemeinen navigiert der Benutzer durch ein(en) Menü oder Baum mittels einer Folge von dynamischen Zugangscodes, die von der vorherigen Wahl des Benutzers in diesem Menü abhängig sind. Wenn der Benutzer am Ende des Baums ankommt, dann wird die volle NIN für die benötigte Aktion in der oben beschriebenen Weise zum Host-Server 15 weitergeleitet.
  • Mit Bezug auf das in 14 illustrierte Beispiel, der Benutzer sendet zum Zugreifen auf das Menü – in Schritt 180 – eine das Schlüsselwort umfassende Frage innerhalb einer SMS-Textnachricht. Das Schlüsselwort könnte ein beliebiges geeignetes Wort sein, das sich der Benutzer leicht merken kann. Ein Beispiel wäre der Name des Service-Providers oder einfach „Hilfe". Diese SMS-Nachricht wird über das SMSC-Server-System 15 in der gewöhnlichen Weise zum Host-Server 15 gesendet. Die SMS-Textnachricht verwendet einen Grundzugangscode, im hierin beschriebenen Beispiel „7777". Wie gewöhnlich wird die NIN des Benutzers an die gewöhnliche Stelle gesetzt und die Empfänger-NIN umfasst den Grundzugangscode. Das Schlüsselwort ist der Text.
  • Der Host-Server 15 empfängt die SMS-Fragenachricht und identifiziert, anhand einer Menüanwendung, den Sender der Fragenachricht und sendet eine SMS-Nachricht als Reaktion auf die Fragenachricht zum Benutzer. Diese anfängliche SMS-Nachricht oder „Homepage" führt die dem Benutzer verfügbaren Optionen auf. In 14 lautet diese Homepage-Nachricht – in Schritt 181 illustriert – wie folgt:
    „Homepage A – registrieren, B – Member-Chatrooms prüfen, C – an Chatrooms teilnehmen. Antworten Sie auf diese Nachricht mit A, B oder C"
  • Die „Antwort an" SMS-Adresse in der Homepage ist „777701". Dies ist der ursprüngliche Grundzugangscode „7777" plus „01", was bedeutet, dass dies die erste in einer Serie von Nachrichten ist, die zum Ermitteln der richtigen NIN für die benötigte Aktion verwendet werden kann. Der Benutzer kann dann einfach auf die SMS-Nachricht antworten und anzeigen – im Textteil der Nachricht – was er benötigt, indem er A, B oder C einfügt. Wenn der Benutzer wählt und mit „B" antwortet, dann bedeutet dies, dass er eine Nachricht zu einem seiner Member-Chatrooms posten möchte. Wie oben erwähnt, zeigt der erste Zugangscode – in diesem Fall „777701" – an, dass dies eine Antwort auf die Homepage-Nachricht ist. Dieser Zugangscode (sowie alle nachfolgenden Zugangscodes) sind dynamisch, da sie von der Antwort auf die vorherige Nachricht abhängig sind.
  • Der Host-Server 15 antwortet auf diese SMS-Nachricht mit einer weiteren SMS-Nachricht, wie in 182 in 14 angedeutet ist, die wie folgt lautet:
    „Ihre Chatrooms lauten: A – Teenager-Probleme, B – schnelle Autos und C – Soccer für Suckers. Antworten Sie bitte mit dem Chatroom, den Sie prüfen möchten."
  • Die „Antwort an" GSM-Nummer ist jetzt „7777012". Die „Antwort an" Nummer hängt von der vorherigen Wahl des Benutzers ab. In diesem Fall ist, da der Benutzer mit „B" geantwortet hat, die neue „Antwort an" GSM-Nummer jetzt der vorherige Zugangscode – „777701" – plus „2", was bedeutet, dass der Benutzer als Reaktion auf die vorherige SMS-Nachricht mit „B" geantwortet hat, d.h. „7777012". Wenn er mit „A" geantwortet hätte, dann wäre die neue „Antwort an" Nummer „7777011" gewesen, usw.
  • Im vorliegenden Beispiel möchte der Benutzer den Chatroom „Teenager-Probleme„ prüfen und antwortet daher mit „A". Der Host-Server 15 erkennt, dass der Benutzer „Teenager-Probleme" prüfen möchte. Der Host-Server 15 sendet die SMS-Nachricht (Schritt 183) mit den folgenden Optionen zurück:
    „Möchten Sie: A – letzte Postings prüfen oder B – eine Nachricht posten. Antworten Sie bitte mit ihrer Wahl."
  • Die „Antwort an" GSM-Nummer ist jetzt „7770121" (d.h. der vorherige Zugangscode „777012" plus „1"), was bedeutet, dass der Benutzer auf die vorherige SMS-Nachricht mit der Option „A" geantwortet hat, und besagt, dass die nächste Aktion daher auf den Chatroom „Teenager-Probleme" angewendet werden wird.
  • Im vorliegenden Beispiel antwortet der Benutzer mit „B". Dies teilt dem Host-Server 15 mit, dass die nächste Aktion des Benutzers sein wird, mit dem Posten von „Teenager-Probleme" in den Chatroom zu beginnen. Der Zugangscode für diesen Chatroom ist „4321", daher sendet der Host-Server 15 eine SMS-Nachricht (Schritt 184) zum Benutzer:
    „Sie können jetzt Ihre Nachricht bei Teenager-Probleme posten, indem Sie mit der Nachricht antworten."
  • Die „Antwort an" GSM-Nummer ist „77774321", wie dies in unseren vorherigen Illustrationen der Fall gewesen wäre. Das Menüsystem hat den Vorgang des Postens einer Nachricht vereinfacht, da es jetzt nicht mehr notwendig ist, sich die Schlüsselwörter oder auch nur die tatsächliche Kombination von Zugangscode plus Chatroom-Index zu merken.
  • Wenn der Benutzer am Ende des Baums ankommt, dann wird die richtige Aktion zum Host-Server wie in den Anwendungen oben beschrieben weitergeleitet.
  • Wie aus der Beschreibung ersichtlich ist, kann diese Methode des Verwenden von SMS-Messaging zum Zugreifen auf einen Host-Server um Informationen auf der Basis einer pseudo-menügesteuerten Frage in vielen Anwendungen zum Einsatz kommen – nicht nur im Zusammenhang mit dem oben beschriebenen Beispiel.
  • Es sollte offensichtlich sein, dass die vorliegende Ausgestaltung mehrere Vorteile gegenüber dem Stand der Technik hat. Sie bietet nicht nur Zugang zum Host-Server einer Reihe verschiedener Client-Typen, sondern hat bedeutsamerweise auch ein Format, das es für mobile Benutzer nützlich macht, die drahtlose Client-Typen verwenden, die Subscriber eines drahtlosen Messaging-Service wie SMS sind, auf die praktischste und effizienteste Weise.
  • Die verschiedenen Diensttypen, die auf der Basis des jeweiligen Formats der vorliegenden Erfindung erstellt wurden und entstanden sind, sind endlos und können eine Adaption beinhalten, um weitaus erweiterte und unterhaltsame Dienste bereitzustellen, die die Übermittlung von Nachrichten zwischen Parteien beinhalten, als dies mit derzeitigen Nachrichtensystemen der Fall ist.
  • Es ist zu verstehen, dass der Umfang der vorliegenden Erfindung nicht auf die hierin beschriebene spezielle Art und Ausgestaltung davon begrenzt ist. Demgemäß werden Ändenrungen und Verbesserungen an der Erfindung, die nicht mehr als übliche allgemeine Kenntnisse beinhalten, nicht als vom Umfang der Erfindung abweichend angesehen. Insbesondere können, obwohl sich die bevorzugte Ausgestaltung auf ein GSM-Netzwerk mit SMS-Nachrichtenfähigkeiten bezieht, auch andere Arten der Umsetzung der Erfindung mit unterschiedlichen drahtlosen Kommunikationsnetzen und Nachrichtensystemen wie Funkrufsystemen (Pager) vorgesehen werden.

Claims (23)

  1. Nachrichtensystem zum Übermitteln von Nachrichten zwischen einem Host-Server (15) und einem Client (13a), der Teil eines drahtlosen Kommunikationsnetzwerks mit einer Mehrzahl von drahtlosen Clients (13a) ist, mit einem Nachrichtendienst zum drahtlosen Übermitteln von Nachrichten dazwischen mit einem Nachrichtendienst-Server (25), wobei mit jedem drahtlosen Client (13a) eine Netzwerkidentifikationsnummer assoziiert ist, um den Client (13a) innerhalb des drahtlosen Kommunikationsnetzwerks eindeutig zu identifizieren, und wobei jede Nachricht ein Nachrichtenpaket (43) mit der Adresse (49) eines beabsichtigten Empfängen des Nachrichtenpakets (43) und der Adresse (47) des Senders der Nachricht beinhaltet; wobei das Nachrichtensystem (11) Folgendes umfasst: einen Host-Server (15), mit dem mehrere Clients (13) selektiv geschaltet werden können, um Nachrichten dazwischen zu übertragen, wobei mit jedem der Clients (13) eine Client-Identifikationsnummer assoziiert ist, um den Client (13) dem Host-Server (15) eindeutig zu identifizieren; wobei der Host-Server (15) und der Nachrichtendienst-Server (25) zwecks Kommunikation dazwischen verbunden sind; wobei einer der Clients (13a) des Host-Servers ein drahtloser Client (13a) ist und die Client-Identifikationsnummer hat, die dessen Netzwerkidentifikationsnummer entspricht; wobei der Host-Server (15) einen Zugangscode, um den Host-Server (15) dem Nachrichtendienst-Server (25) eindeutig zu identifizieren, und eine eindeutige Identifikationsnummer hat, die (a) einer vorgeschriebenen, vom Host-Server (15) ausgeführten Aktion und (b) einer Entität, die Gegenstand der vorgeschriebenen Aktion ist, zugeordnet ist; wobei zwischen dem Host-Server (15) und dem einen Client in Verbindung mit einer bestimmten vorgeschriebenen Aktion und Entität gesendete Nachrichten Folgendes beinhalten: (i) eine Kombination aus Zugangscode und eindeutiger Identifikationsnummer, die der jeweiligen Aktion und Entität als die Adresse des Host-Servers (15) in Nachrichtenpaketen (43) zugeordnet wurden, die zu oder von dem einen Client (13a) jeweils als der Sender bzw. der beabsichtigte Empfänger gesendet wurden, und (ii) die Netzwerkidentifikationsnummer als die Adresse des einen Clients in Nachrichtenpaketen, die zu und von dem Host-Server (15) jeweils als der Sender oder der beabsichtigte Empfänger gesendet wurden; und wobei der Nachrichtendienst-Server (25) den Zugangscode in der Adresse des beabsichtigten Empfängers oder des Senders zum Erkennen von zu oder von dem Host-Server (15) gesendeten oder empfangenen Nachrichten verwendet und Nachrichten entsprechend leitet.
  2. Nachrichtensystem nach Anspruch 1, wobei der Host-Server (15) Verarbeitungsmittel hat, um: (i) eine Client-Identifikationsnummer anhand der Adresse (47) des Senders eines von einem Client (13) empfangenen Nachrichtenpakets (43) zu validieren; (ii) die eindeutige Identifikationsnummer anhand der Adresse (49) des Empfängers in dem Nachrichtenpaket, das eine damit assoziierte gültige Client-Identifikationsnummer hat, zu verarbeiten; und (iii) die vorgeschriebene Aktion mit der durch die eindeutige Identifikationsnummer vorgegebenen Entität unter Berücksichtigung in dem Nachrichtenpaket (43) enthaltener Begleitnachrichten auszuführen.
  3. Nachrichtensystem nach Anspruch 1 oder 2, wobei der Host-Server (15) ein Nachrichtenkompilationsmittel zum Kompilieren einer Nachricht und zum Senden derselben zu einem Client (13) unter Verwendung seiner Client-Identifikationsnummer als die Adresse (49) des beabsichtigten Empfängers, oder ein Nachrichtenübertragungsmittel zum Übertragen einer davon von einem Client (13) empfangenen Nachricht und zum Senden derselben zu einem anderen Client (13) unter Verwendung seiner Client-Identifikationsnummer als die Adresse (49) des beabsichtigten Empfängers hat, gemäß der vorgeschriebenen Aktion und Entität die durch eine davon verarbeitete eindeutige Identifikationsnummer vorgegeben ist.
  4. Nachrichtensystem nach Anspruch 3, wobei der Host-Server (15) Identifikationsmittel zum Identifizieren einer Netzwerkidentifikationsnummer anhand einer Client-Identifikationsnummer in der Adresse (49) eines beabsichtigten Empfängers einer Nachricht die entweder von dem Nachrichtenkompilationsmittel kompiliert oder von dem Nachrichtenübertragungsmittel empfangen wurde, und Übertragungsmittel zum Übermitteln der für einen drahtlosen Client (13a) beabsichtigten Nachricht zum Nachrichtendienst-Server (25) dieses drahtlosen Client (13a) hat.
  5. Nachrichtensystem nach einem der vorherigen Ansprüche, wobei der Nachrichtendienst-Server (25) Verarbeitungsmittel hat, um die Adresse (49) des beabsichtigten Empfangen einer vom Host-Server (15) empfangenen Nachricht als die Netzwerkidentifikationsnummer eines drahtlosen Client (13a) des drahtlosen Kommunikationsnetzes davon zu verarbeiten und die Nachricht drahtlos zu dem drahtlosen Client (13a), der der Netzwerkidentifikationsnummer entspricht, zu übertragen.
  6. Nachrichtensystem nach einem der vorherigen Ansprüche, wobei die vorgeschriebene Aktion das Aufrufen einer Routine auf dem Host-Server (15) umfasst, die mit dem Zugriff auf ein elektronisches Bulletin-Board assoziiert ist, und die Entität der Gegenstand oder das Thema ist, auf den/das sich das Bulletin-Board bezieht.
  7. Nachrichtensystem nach Anspruch 6, wobei sich die Nachricht auf das Lesen, Posten oder Antworten auf eine(r) Nachricht auf dem Bulletin-Board bezieht.
  8. Nachrichtensystem nach einem der vorherigen Ansprüche, wobei die vorgeschriebene Aktion das Aufrufen einer Routine auf dem Host-Server (15) in Verbindung mit der Teilnahme an einer kommerziellen Transaktion umfasst und die Entität ein Produkt oder ein Dienst ist, das/der der Gegenstand der Transaktion ist.
  9. Nachrichtensystem nach Anspruch 8, wobei die kommerzielle Transaktion eine Auktion ist, die Entität ein auktioniertes/r Produkt oder Artikel ist und die Nachricht ein Gebot bei der Auktion in Bezug auf ein(en) spezielles/n Produkt oder Artikel betrifft.
  10. Nachrichtensystem nach einem der Ansprüche 1 bis 7, wobei die vorgeschriebene Aktion das Aufrufen einer Routine auf dem Host-Server (15) in Verbindung mit persönlichen Diensten umfasst und die Entität der jeweilige Typ des persönlichen Dienstes ist.
  11. Nachrichtensystem nach einem der Ansprüche 1 bis 7, wobei die vorgeschriebene Aktion das Aufrufen einer Routine auf dem Host-Server (15) in Verbindung mit einem Chatroom umfasst und die Entität den/das jeweilige(n) Gegenstand oder Thema des Chatrooms ist.
  12. Nachrichtensystem nach einem der Ansprüche 1 bis 5, wobei die vorgeschriebene Aktion das Aufrufen einer Routine auf dem Host-Server (15) in Verbindung mit dem Übertragen der Nachricht direkt zu einem anderen Client (13) oder einer Gruppe von Clients des Host-Servers (15) gemäß Vorgabe im Nachrichtenpaket (43) umfasst und die Entität der/die betroffene spezielle Client oder Clientgruppe ist.
  13. Nachrichtensystem nach Anspruch 12, wobei die Gruppe von Clients diejenigen sind, die als Buddies des Client gespeichert sind, der die Nachricht zu einer Datenbank des Host-Servers (15) sendet.
  14. Nachrichtensystem nach Anspruch 1, wobei Informationen über den Gebrauch des Nachrichtensystems vom Host-Server (15) zum Client (13) als Reaktion auf eine Anforderung vom Client (13) gesendet werden können, wobei die Anforderung ein Nachrichtenpaket (43) umfasst, das einen Zugangscode und Daten umfasst, die die angeforderten Informationen anzeigen, wobei der Zugangscode den Host-Server (15) dem Nachrichtenserver (25) eindeutig identifiziert, wobei der Host-Server (15) die Aufgabe hat, ein Informationsnachrichtenpaket (43) als Reaktion auf das Anforderungsnachrichtenpaket zum Client (13) zurückzusenden, wobei das Informationsnachrichtenpaket die vom Client (13) angeforderten Informationen und einen Zugangscode umfasst, der vom Client (13) als Anforderungsnachricht-Zugangscode als Reaktion auf das Informationsnachrichtenpaket zu verwenden ist, wobei der Anforderungsnachrichten-Zugangscode den Host-Server (15) identifiziert und einen Teil beinhaltet, der durch die in dem Informationsnachrichtenpaket (43) enthaltenen Informationen bestimmt wird.
  15. Nachrichtensystem nach Anspruch 14, wobei das anfängliche Anforderungsnachrichtenpaket einen Grundzugangscode plus die angeforderten Informationen anzeigenden Daten umfasst.
  16. Nachrichtensystem nach Anspruch 15, wobei die Daten ein Schlüsselwort aus alphanumerischen oder alphabetischen Zeichen umfassen.
  17. Nachrichtensystem nach Anspruch 15 oder Anspruch 16, wobei nachfolgende Anforderungsnachrichtenpaket-Zugangscodes den Grundzugangscode plus zusätzliche Indexe umfassen.
  18. Nachrichtensystem nach einem der vorhergehenden Ansprüche, wobei der Host-Server (15) Verarbeitungsmittel hat, um: (i) die Client-Identifikationsnummer anhand der Adresse des Senders eines von einem Client empfangenen Anforderungsnachrichtenpakets zu validieren; (ii) den Zugangscode anhand der Adresse des Empfängers im Nachrichtenpaket mit einer damit assoziierten gültigen Client-Identifikationsnummer zu verarbeiten; und (iii) das Informationsnachrichtenpaket als Reaktion auf eine empfangene Anforderungsnachricht mittels des Anforderungsnachrichtenpaket-Zugangscodes als Senderadresse im Informationsnachrichtenpaket zu erzeugen.
  19. Verfahren zum Übermitteln von Nachrichten zwischen einem Host-Server (15), mit dem mehrere Clients (13) selektiv verbunden werden können, um Nachrichten dazwischen zu übermitteln, und einem Client (13A), der Teil eines drahtlosen Kommunikationsnetzwerks mit einer Mehrzahl von drahtlosen Clients (13A) ist, mit einem Nachrichtendienst, um Nachrichten drahtlos dazwischen mit einem Nachrichtendienst-Server (25) zu übermitteln, wobei mit jedem drahtlosen Client (13a) eine Netzwerkidentifikationsnummer assoziiert ist, um den Client (13a) innerhalb des drahtlosen Kommunikationsnetzwerks eindeutig zu identifizieren, und wobei jede Nachricht ein Nachrichtenpaket (43) mit der Adresse (49) eines beabsichtigten Empfängers des Nachrichtenpakets und der Adresse (47) des Senders der Nachricht umfasst; wobei das Verfahren die folgenden Schritte umfasst: Zuordnen einer Client-Identifikationsnummer zu jedem Client des Host-Servers (15), um den Client (13) dem Host-Server (15) eindeutig zu identifizieren, so dass die Client-Identifikationsnummer für den Client (13a), der Teil des drahtlosen Kommunikationsnetzwerks ist, eine Client-Identifikationsnummer hat, die der Netzwerkidentifikationsnummer davon entspricht; Zuordnen eines Zugangscodes zum Host-Server (15), um den Host-Server dem Nachrichtendienst-Server (25) eindeutig zu identifizieren, und einer eindeutigen Identifikationsnummer, die Folgendes anzeigt: (a) eine vorgeschriebene Aktion, die vom Host-Server (15) auszuführen ist, und (b) eine Entität die Gegenstand der vorgeschriebenen Aktion ist; Kompilieren von Nachrichten, die zwischen dem Host-Server (15) und dem Client (13a) des drahtlosen Kommunikationsnetzwerks in Verbindung mit einer bestimmten vorgeschriebenen Aktion und Entität gesendet wurden, die Folgendes einschließen.: (i) eine Kombination aus dem Zugangscode und der der jeweiligen Aktion und Entität zugeordneten eindeutigen Identifikationsnummer als die Adresse des Host-Servers (15) in Nachrichtenpaketen, die zu und von dem einen Client als Sender bzw. beabsichtigter Empfänger gesendet wurden, und (ii) die Netzwerkidentifikationsnummer als die Adresse des einen Client (13a) in Nachrichtenpaketen (43), die zu und von dem Host-Server (15) als der Sender oder der beabsichtigte Empfänger gesendet wurden; und Leiten von Nachrichten durch den Nachrichtendienst-Server (25) unter Verwendung des Zugangscodes in der Adresse des beabsichtigten Empfängen oder Senders, um Nachrichten zu erkennen, die zu dem Host-Server (15) gesendet oder davon empfangen wurden.
  20. Verfahren zum Übermitteln von Nachrichten nach Anspruch 19, das das Verbergen der Client-Identifikationsnummer eines bestimmten Client (13) vor anderen Clients beinhaltet, die Nachrichten von dem jeweiligen Client empfangen oder Nachrichten dorthin senden, ebenfalls ein drahtloser Client (13a) ist.
  21. Verfahren nach Anspruch 19, das die folgenden Schritte umfasst: Kompilieren und Senden eines Anforderungsnachrichtenpakets (43) vom Client (13a) zum Host-Server (15), wobei die Anforderung ein Nachrichtenpaket umfasst, das einen Zugangscode und die angeforderten Informationen anzeigende Daten umfasst wobei der Zugangscode den Host-Server (15) dem Nachrichtenserver (25) eindeutig identifiziert, Zurücksenden eines Informationsnachrichtenpakets zum Client (13a) vom Host-Server (15) als Reaktion auf das Anforderungsnachrichtenpaket, wobei das Informationsnachrichtenpaket die vom Client (13a) angeforderten Informationen und einen Zugangscode umfasst der vom Client als Anforderungsnachricht-Zugangscode als Reaktion auf das Informationsnachrichtenpaket verwendet werden soll, wobei der Anforderungsnachricht-Zugangscode den Host-Server (15) identifiziert und einen Teil beinhaltet, der von den im Informationsnachrichtenpaket enthaltenen Informationen bestimmt wird.
  22. Verfahren nach Anspruch 21, das ferner die folgenden Schritte beinhaltet: Validieren der Client-Identifikationsnummer anhand der Adresse (47) des Senders eines von einem Client empfangenen Anforderungsnachrichtenpakets; Verarbeiten des Zugangscodes anhand der Adresse (49) des Empfängen in dem Nachrichtenpaket mit einer damit assoziierten gültigen Client-Identifikationsnummer; und Erzeugen des Informationsnachrichtenpakets (43) als Reaktion auf eine empfangene Anforderungsnachricht mittels des Anforderungsnachrichtenpaket-Zugangscodes als die Senderadresse in dem Informationsnachrichtenpaket.
  23. Verfahren nach Anspruch 21 oder Anspruch 22, das ferner das Austauschen einer Reihe von Anforderungs- und Informationsnachrichtenpaketen (43) beinhaltet, wobei sich jeder Austausch auf die Auswahl einer Option und das Bereitstellen einer Reibe weiterer Optionen in Bezug auf frühere Wahlen bezieht
DE60128486T 2000-12-08 2001-12-07 Nachrichtensystem mit drahtloser kommunikation und verfahren dafür Expired - Lifetime DE60128486T2 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
SG200007381 2000-12-08
SG200007381 2000-12-08
SG200104506 2001-07-25
SG200104506 2001-07-25
PCT/SG2001/000255 WO2002047320A1 (en) 2000-12-08 2001-12-07 A messaging system involving wireless communications and method therefor

Publications (2)

Publication Number Publication Date
DE60128486D1 DE60128486D1 (de) 2007-06-28
DE60128486T2 true DE60128486T2 (de) 2008-01-17

Family

ID=26665224

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60128486T Expired - Lifetime DE60128486T2 (de) 2000-12-08 2001-12-07 Nachrichtensystem mit drahtloser kommunikation und verfahren dafür

Country Status (10)

Country Link
US (1) US7319882B2 (de)
EP (1) EP1346510B1 (de)
CN (1) CN1278513C (de)
AT (1) ATE362678T1 (de)
AU (1) AU2002222890A1 (de)
CA (1) CA2457556C (de)
DE (1) DE60128486T2 (de)
ES (1) ES2288907T3 (de)
GB (1) GB2390783B (de)
WO (1) WO2002047320A1 (de)

Families Citing this family (92)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7624172B1 (en) 2000-03-17 2009-11-24 Aol Llc State change alerts mechanism
US9736209B2 (en) 2000-03-17 2017-08-15 Facebook, Inc. State change alerts mechanism
US7194557B1 (en) 2004-11-08 2007-03-20 Palmsource, Inc. Data exchange between a handheld device and another computer system using an exchange manager via synchronization
US7343335B1 (en) * 2000-08-08 2008-03-11 Ebay Inc. Method for managing group finances via an electronic network
FI119168B (fi) * 2006-04-21 2008-08-15 Jukka Tapio Aula Kyselyjen ja kutsujen SMS-jakelumenetelmä ja -järjestelmä
US7006793B2 (en) * 2002-01-16 2006-02-28 International Business Machines Corporation Safe use of electronic devices in an automobile
US7103372B1 (en) * 2002-02-12 2006-09-05 Cellco Partnership System and method for preventing delivery of unsolicited messages on an SMS network
GB0206985D0 (en) * 2002-03-25 2002-05-08 Intellprop Ltd Telecommunications services apparatus
GB0214113D0 (en) * 2002-06-20 2002-07-31 Intellprop Ltd Telecommunications services apparatus
US7720910B2 (en) * 2002-07-26 2010-05-18 International Business Machines Corporation Interactive filtering electronic messages received from a publication/subscription service
US9124447B2 (en) * 2002-07-26 2015-09-01 International Business Machines Corporation Interactive client computer communication
US7813484B2 (en) 2002-08-08 2010-10-12 Telecommunication Systems, Inc. All-HTTP multimedia messaging
US8701014B1 (en) 2002-11-18 2014-04-15 Facebook, Inc. Account linking
US7428580B2 (en) 2003-11-26 2008-09-23 Aol Llc Electronic message forwarding
US8965964B1 (en) * 2002-11-18 2015-02-24 Facebook, Inc. Managing forwarded electronic messages
US8005919B2 (en) 2002-11-18 2011-08-23 Aol Inc. Host-based intelligent results related to a character stream
WO2004046867A2 (en) 2002-11-18 2004-06-03 America Online, Inc. People lists
US7899862B2 (en) 2002-11-18 2011-03-01 Aol Inc. Dynamic identification of other users to an online user
US7640306B2 (en) 2002-11-18 2009-12-29 Aol Llc Reconfiguring an electronic message to effect an enhanced notification
US7590696B1 (en) 2002-11-18 2009-09-15 Aol Llc Enhanced buddy list using mobile device identifiers
US8122137B2 (en) 2002-11-18 2012-02-21 Aol Inc. Dynamic location of a subordinate user
CN102664818B (zh) * 2002-12-18 2015-08-19 诺基亚公司 用于通信的终端、方法和系统
EP1574085B1 (de) 2002-12-18 2010-09-22 Nokia Corporation Sofortige nachrichten bermittlung und präsenzdienste
SG106670A1 (en) * 2003-02-18 2004-10-29 Chikka Pte Ltd A messaging system and method therefor
US7603417B2 (en) 2003-03-26 2009-10-13 Aol Llc Identifying and using identities deemed to be known to a user
JP2004326318A (ja) * 2003-04-23 2004-11-18 Murata Mach Ltd 通信装置
US20050003837A1 (en) * 2003-05-08 2005-01-06 Midkiff David S. System and method for SMS text routing
US9094805B2 (en) * 2003-06-25 2015-07-28 Oracle International Corporation Mobile messaging concierge
US7653693B2 (en) 2003-09-05 2010-01-26 Aol Llc Method and system for capturing instant messages
JP2005070835A (ja) * 2003-08-25 2005-03-17 Fujitsu Ltd テスト支援プログラムおよびテスト支援方法
US20060212831A1 (en) * 2003-09-09 2006-09-21 Fogg Brian J Graphical messaging system
US20060212830A1 (en) * 2003-09-09 2006-09-21 Fogg Brian J Graphical messaging system
US20050132013A1 (en) * 2003-12-15 2005-06-16 International Business Machines Corporation Methods and systems of instant message secure client control
US20050185634A1 (en) * 2004-02-24 2005-08-25 Benco David S. Method and system for providing network support for messaging between short message service (SMS) subscribers and instant messaging (IM) subscribers
EP1784992B1 (de) * 2004-08-14 2018-07-04 Kirusa, Inc. Verfahren zur identifizierung von nachrichten und zur kommunikation mit benutzern eines multimodalen nachrichtendienstes
US7643822B2 (en) * 2004-09-30 2010-01-05 Google Inc. Method and system for processing queries initiated by users of mobile devices
US8060566B2 (en) * 2004-12-01 2011-11-15 Aol Inc. Automatically enabling the forwarding of instant messages
US9002949B2 (en) 2004-12-01 2015-04-07 Google Inc. Automatically enabling the forwarding of instant messages
US7730143B1 (en) * 2004-12-01 2010-06-01 Aol Inc. Prohibiting mobile forwarding
US20070190978A1 (en) * 2005-01-13 2007-08-16 Ianywhere Solutions, Inc. System and Methodology for Extending Enterprise Messaging Systems to Mobile Devices
DE102005002521A1 (de) * 2005-01-19 2006-07-27 Giesecke & Devrient Gmbh Teilnehmerkarte bei Internet Weblog Diensten
US20060229998A1 (en) 2005-03-31 2006-10-12 Mark Harrison Payment via financial service provider using network-based device
US7831520B2 (en) * 2005-06-28 2010-11-09 Ebay Inc. Mobile device communication system
WO2007026320A2 (en) * 2005-08-30 2007-03-08 Yoomba Ltd. Immediate communication system
US9311398B2 (en) * 2005-11-15 2016-04-12 Ebay Inc. Method and system to process navigation information
US8781942B2 (en) * 2005-11-30 2014-07-15 Genesys Telecommunications Laboratories, Inc. System and method for matching electronic proposals to electronic requests
CN100414889C (zh) * 2005-12-29 2008-08-27 中山大学 一种对用户进行区分和跟踪的中间系统
EP1989637A2 (de) * 2006-02-07 2008-11-12 3Jam, Inc. Verfahren und vorrichtungen zur aufnahme mehrerer benutzer in eine konversation über ein kommunikationsnetzwerk
US8442197B1 (en) 2006-03-30 2013-05-14 Avaya Inc. Telephone-based user interface for participating simultaneously in more than one teleconference
KR100834622B1 (ko) * 2006-06-26 2008-06-02 삼성전자주식회사 가상의 메신저 서비스를 제공하는 방법 및 이를 위한시스템
US7720082B2 (en) * 2006-07-13 2010-05-18 Neustar, Inc. System and method for short message service and instant messaging continuity
US8589239B2 (en) 2006-09-29 2013-11-19 Ebay Inc. Real-time bidding using instant messaging clients
US8064934B2 (en) * 2006-10-19 2011-11-22 Research In Motion Limited Method, system and apparatus for automatic notification to a plurality of communication nodes
US8006190B2 (en) 2006-10-31 2011-08-23 Yahoo! Inc. Social namespace addressing for non-unique identifiers
US8195749B2 (en) * 2006-11-13 2012-06-05 Bindu Rama Rao Questionnaire server capable of providing questionnaires based on device capabilities
US11256386B2 (en) 2006-11-22 2022-02-22 Qualtrics, Llc Media management system supporting a plurality of mobile devices
US8700014B2 (en) 2006-11-22 2014-04-15 Bindu Rama Rao Audio guided system for providing guidance to user of mobile device on multi-step activities
US8478250B2 (en) 2007-07-30 2013-07-02 Bindu Rama Rao Interactive media management server
US10803474B2 (en) 2006-11-22 2020-10-13 Qualtrics, Llc System for creating and distributing interactive advertisements to mobile devices
US8200763B2 (en) * 2006-11-22 2012-06-12 Yahoo! Inc. Enabling display of a recipient list for a group text message
US8599801B2 (en) * 2007-02-01 2013-12-03 Yahoo! Inc. Collecting implicit information for determining context of event actions
US8073475B2 (en) * 2007-02-02 2011-12-06 Disney Enterprises, Inc. Method and system for transmission and display of rich-media alerts
US8370349B2 (en) * 2007-02-28 2013-02-05 Yahoo! Inc. Instant contact searching and presentation by category
US7747705B1 (en) * 2007-05-08 2010-06-29 Avaya Inc. Method to make a discussion forum or RSS feed a source for customer contact into a multimedia contact center that is capable of handling emails
US8108459B1 (en) 2007-05-30 2012-01-31 Rocketon, Inc. Method and apparatus for distributing virtual goods over the internet
US8239487B1 (en) 2007-05-30 2012-08-07 Rocketon, Inc. Method and apparatus for promoting desired on-line activities using on-line games
US8233886B2 (en) * 2007-08-15 2012-07-31 Sony Mobile Communications Ab Accessing stored data objects using contact data corresponding to a remote communications party
US8831674B2 (en) * 2007-09-27 2014-09-09 Multi-Tech Systems, Inc. Message server
US20090125230A1 (en) * 2007-11-14 2009-05-14 Todd Frederic Sullivan System and method for enabling location-dependent value exchange and object of interest identification
EP2107741A1 (de) * 2008-03-31 2009-10-07 Nokia Siemens Networks Oy Zusammenarbeit zwischen Nachrichtendiensten
US8769652B2 (en) 2008-04-23 2014-07-01 Clear Channel Management Services, Inc. Computer based method and system for registering a user at a server computer system
WO2010013802A1 (ja) * 2008-07-31 2010-02-04 日本電気株式会社 匿名通信システム
US20110182211A1 (en) * 2008-07-31 2011-07-28 Natsuko Kagawa Anonymous communication system
US20100063926A1 (en) * 2008-09-09 2010-03-11 Damon Charles Hougland Payment application framework
US20100287052A1 (en) * 2009-05-06 2010-11-11 Minter David D Short-range commercial messaging and advertising system and mobile device for use therein
US8621011B2 (en) * 2009-05-12 2013-12-31 Avaya Inc. Treatment of web feeds as work assignment in a contact center
EP2275982A1 (de) * 2009-07-16 2011-01-19 Vodafone Holding GmbH Abfragen eines Benutzers eines mobilen Kommunikationsgeräts
KR101633928B1 (ko) * 2009-08-11 2016-06-27 엘지전자 주식회사 소셜 네트워크 서비스 제공 방법 및 장치
US9247400B2 (en) * 2009-12-08 2016-01-26 Alvin Butler, SR. System for routing text messages (SMS) to allow for two-way mobile to computer communication
US9161184B2 (en) 2010-12-23 2015-10-13 Telecommunications Systems, Inc. Alphanumeric address mapping for non-homogeneous short message networks
CN102045670B (zh) * 2010-12-30 2014-01-22 北京握奇数据系统有限公司 传输短消息的方法、服务器及智能卡
US8682289B2 (en) 2011-02-14 2014-03-25 Telecommunication Systems, Inc. Prepaid short message services revenue capture
US8860787B1 (en) 2011-05-11 2014-10-14 Google Inc. Method and apparatus for telepresence sharing
CN103713586A (zh) * 2012-10-01 2014-04-09 夏普株式会社 消息发送服务器、消息发送方法、终端、电气设备控制系统、电气设备及电气设备控制方法
US9992021B1 (en) 2013-03-14 2018-06-05 GoTenna, Inc. System and method for private and point-to-point communication between computing devices
KR102352391B1 (ko) * 2015-05-14 2022-01-18 엘지전자 주식회사 이동단말기 및 그 제어방법
US10803391B2 (en) * 2015-07-29 2020-10-13 Google Llc Modeling personal entities on a mobile device using embeddings
CA2978928A1 (en) * 2016-09-09 2018-03-09 Diego Matute Method and system for user verification
US11190468B2 (en) 2019-04-19 2021-11-30 Microsoft Technology Licensing, Llc Method and system of synchronizing communications in a communication environment
US11683282B2 (en) 2019-08-15 2023-06-20 Microsoft Technology Licensing, Llc Method and system of synchronizing communications
US11301583B2 (en) * 2019-10-09 2022-04-12 Mastercard International Incorporated Method and system for protection of customer PII via cryptographic tokens
US11121945B2 (en) * 2020-01-10 2021-09-14 Oracle International Corporation Methods, systems, and computer readable media for request response processing

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5113442A (en) * 1989-03-06 1992-05-12 Lachman Associates, Inc. Method and apparatus for providing access control in a secure operating system
NZ281061A (en) * 1994-02-24 1997-12-19 Gte Mobile Comm Servinc Cellular wireless telephone system equipped with remote program mobile station
US5497411A (en) * 1994-03-14 1996-03-05 Pellerin; Joseph C. E. Telecommunications card-access system
US6005870A (en) * 1996-08-12 1999-12-21 At&T Corp. Method for called party control of telecommunications network services
US5966699A (en) * 1996-10-11 1999-10-12 Zandi; Richard System and method for conducting loan auction over computer network
US6366962B1 (en) * 1998-12-18 2002-04-02 Intel Corporation Method and apparatus for a buddy list
ES2237022T3 (es) * 1999-12-02 2005-07-16 Sony International (Europe) Gmbh Mensajeria instantanea.
EP1104965B1 (de) * 1999-12-02 2007-02-28 Sony Deutschland GmbH Protokoll für sofortige Nachrichtenübermittlung
US6714793B1 (en) * 2000-03-06 2004-03-30 America Online, Inc. Method and system for instant messaging across cellular networks and a public data network
KR20010064671A (ko) * 2000-05-15 2001-07-11 김광묵 이동 통신 단말기용 채팅 서비스 제공 시스템 및 방법
US6895425B1 (en) * 2000-10-06 2005-05-17 Microsoft Corporation Using an expert proxy server as an agent for wireless devices
US8315651B2 (en) * 2001-05-03 2012-11-20 Kyocera Corporation Instant messaging to a mobile device
US7190956B2 (en) * 2001-05-15 2007-03-13 Motorola Inc. Instant message proxy for circuit switched mobile environment
US6856809B2 (en) * 2001-05-17 2005-02-15 Comverse Ltd. SMS conference
US7386303B2 (en) * 2001-05-18 2008-06-10 Research In Motion Limited Multi-function, multi-state input control device
US7020457B2 (en) * 2001-05-31 2006-03-28 Orative Corporation System and method for proxy-enabling a wireless device to an existing IP-based service

Also Published As

Publication number Publication date
EP1346510A1 (de) 2003-09-24
CA2457556A1 (en) 2002-06-13
ATE362678T1 (de) 2007-06-15
GB2390783A (en) 2004-01-14
GB0315075D0 (en) 2003-07-30
EP1346510B1 (de) 2007-05-16
CN1278513C (zh) 2006-10-04
CN1502187A (zh) 2004-06-02
GB2390783B (en) 2004-10-27
US7319882B2 (en) 2008-01-15
WO2002047320A8 (en) 2003-02-13
CA2457556C (en) 2010-02-02
ES2288907T3 (es) 2008-02-01
HK1066670A1 (en) 2005-03-24
US20040058694A1 (en) 2004-03-25
AU2002222890A1 (en) 2002-06-18
WO2002047320A1 (en) 2002-06-13
DE60128486D1 (de) 2007-06-28

Similar Documents

Publication Publication Date Title
DE60128486T2 (de) Nachrichtensystem mit drahtloser kommunikation und verfahren dafür
DE10117282B4 (de) System und Verfahren zur gleichzeitigen Ausführung von POP E-Mailing und Chatten sowie Verwendung des Verfahrens in einem Internet-Einkaufszentrum
US7639672B2 (en) System and method for peer-to-peer internet communication
US10264095B2 (en) Control for inviting an unauthenticated user to gain access to display of content that is otherwise accessible with an authentication mechanism
DE60038054T2 (de) Verfahren zur erleichterung der elektronischen kommunikation
DE60114692T2 (de) Verfahren zur Übertragung von gespeicherten Daten einer Datenbank
DE60038460T2 (de) Anonymität in einem präsenzverarbeitungssystem
CN101018141B (zh) 为电子公告版提供即时通信的方法与系统
DE60313187T2 (de) Verfahren und Vorrichtung für sofortigen Nachrichtendienst
DE60103210T2 (de) Anonymer nachrichtenaustausch mit mobiltelefonen
CN101374120A (zh) 以位置为基础的匿名实时讯息交换方法及系统
CN104410562A (zh) 一种能够与业务进行关联的即时信息处理方法
CN100397822C (zh) 一种广告信息传送方法
CN111899118A (zh) 一种社交系统及方法
DE60033191T2 (de) Abrechnungssystem für ein system zur sofortigen nachrichtenübermittlung
DE102004032225B4 (de) Verfahren und Einrichtung zum Aufbau und zum Betrieb einer Kommunikationsverbindung
KR20140043881A (ko) 웹페이지와 채팅서비스 연동방법 및 시스템
DE602004004673T2 (de) Verfahren und Vorrichtung um von einem ersten Nachrichtenprotokoll/-dienst zu einem zweiten Nachrichtenprotokoll/-dienst zu wechseln
KR100603551B1 (ko) 로밍 커뮤니티 서비스를 제공하는 방법 및 시스템
JP2002007276A (ja) 電子掲示板システム
CN1984083A (zh) 实现电子公告版系统消息即时通知的方法及系统
KR100568154B1 (ko) 포탈 서비스 제공 시스템 및 이를 이용한 서비스 제공 방법
IES20090831A2 (en) An automated response marketing system which enables mobile device user receive information automatically to an email address when an email address is sent to the system by sms message.
KR20010102648A (ko) 인터넷을 통한 이벤트 관리방법 및 이를 위한 시스템
KR20000030838A (ko) 전자메일 시스템

Legal Events

Date Code Title Description
8364 No opposition during term of opposition