DE60111425T2

DE60111425T2 - Herunterladbarer multimedialer inhalt und abrechnungsverfahren

Info

Publication number: DE60111425T2
Application number: DE60111425T
Authority: DE
Inventors: Micheal Gargiulo; Justin Beghtol
Original assignee: Nokia Mobile Phones Ltd
Current assignee: Nokia Oyj
Priority date: 2000-10-25
Filing date: 2001-09-24
Publication date: 2006-06-29
Anticipated expiration: 2021-09-25
Also published as: KR20030048070A; ATE297572T1; US20020087656A1; EP1362311B1; WO2002037369A2; EP1362311A2; WO2002037369A3; JP2005501301A; DE60111425D1; US7555537B2; AU2001294680A1; ES2243557T3; KR100625783B1

Description

GEBIET DER ERFINDUNG
Diese Erfindung betrifft im Allgemeinen Verfahren und Systeme zum Liefern und Erledigen von Medieninhalten.
ALLGEMEINER STAND DER TECHNIK
DE 19543843 A offenbart eine Vorgangsweise zum Aktualisieren der Software eines Mobiltelefons, wobei Software von einem Server heruntergeladen wird, im RAM-Speicher gespeichert wird, geprüft wird, und schließlich im nichtflüchtigen Speicher installiert wird. Während der Installation ist das Mobilendgerät blockiert, damit der Benutzer die Installation nicht unterbricht. DE 19543843 A befaßt sich jedoch nicht mit dem Problem des Behandelns der heruntergeladenen Software.
Mobiltelefone (die auch als Mobilstationen und persönliche zertifizierte Geräte bekannt sind) hatten ursprünglich Ruftöne, die jenen von gewöhnlichen Telefonen ähnlich waren. Dies verursachte ein Problem, wenn zwei Benutzer im gleichen Raum über den gleichen Rufton verfügten, da insofern Verwirrung verursacht wurde, welche Mobilstation läutete. Dieses Problem wurde gelöst, als Mobiltelefone fortschrittlicher wurden. Gegenwärtig weisen Mobiltelefone mehrere vorgespeicherte Ruftöne auf, aus denen ein Benutzer einen bevorzugten Rufton wählen kann. Zusätzlich zu gewöhnlichen Ruftönen wurden Melodien von vertrauten Musikstücken als Ruftöne ausgeführt und können sich unter den Ruftönen befinden, aus denen ausgewählt werden kann. Ruftöne können auch als Rufmelodien bezeichnet werden, insbesondere, wenn sie die Form einer Melodie aufweisen. Mit der zunehmenden Verwendung von Mobiltelefonen besteht nach wie vor eine Möglichkeit, daß Benutzer im gleichen Raum die gleiche Rufmelodie verwenden.
Das Programmieren des Ruftons eines Telefons wurde in der am 25. Juli 2000 an Armanto et al. ausgegebenen US-Patentschrift Nr. 6,094,587, die dem Inhaber der vorliegenden Erfindung übertragen wurde, gelehrt. In Armanto et al. wird der Rufton in der Form einer Ruftonnachricht, die eine Kennung enthält, welche die Nachricht als einen Rufton identifiziert, zu einer Mobilstation gesendet. Beim Empfang wird die Ruftonnachricht auf Basis der Ruftonnachrichtenkennung identifiziert. Die Ruftonnachricht wird dann in eine geeignete Form für einen Ruftongenerator und -speicher umgewandelt. Der Rufton kann als Zeichen in einer Kurznachricht wie etwa dem Kurznachrichtendienst (SMS), unstrukturierten Zusatzdienstdaten (USSD), oder durch eine off-line-Infrarotverbindung z.B. des Infrarotdatenvereinigungs(IrDA)typs gesendet werden.
Der Kurznachrichtendienst (SMS) ist ein Beispiel für die Nachrichtenkommunikation in Mobilnetzen, besonders in GSM-Netzen. SMS unterscheidet sich von Sprach- und Datendiensten darin, daß zum Senden einer Kurznachricht keine Verbindung vom Sender zum Empfänger hergestellt werden muß, da Kurznachrichten in digitalen Mobilnetzen durch Signalisierung bei Steuerung oder Signalisierungskanäle gesendet werden.
Dieser Umstand stellt keine Fähigkeiten für einen Verbraucher, eine Auswahl von Ruftönen durchzusehen, bereit. Darüber hinaus kann jede SMS- oder ähnliche Nachricht zu einer Gebühr für den Verbraucher führen, auch wenn der Rufton dem Verbraucher nicht gefällt. Beispiele für die Nachrichtenverrechnung werden durch die am 18. Mai 2000 veröffentlichte internationale Anmeldung Nr. PCT/FI99/00935, der die Veröffentlichungsnummer WO 00/28746 zugeteilt wurde, und die mit MESSAGE COMMUNICATION CHARGING betitelt ist (zugeteilte US-Seriennummer 09/850,036), und die am 10. Dezember 1998 veröffentlichte internationale Anmeldung Nr. PCT/FI98/00474, der die Veröffentlichungsnummer WO 98/56202 zugeteilt wurde, und die mit BILLING MOBILE TERMINATED SHORT MESSAGES betitelt ist (zugeteilte US-Seriennummer 09/545,119) bereitgestellt. Alle genannten Patentanmeldungen sind einer verbundenen Einheit des Inhabers der vorliegenden Erfindung übertragen.
Es gibt gegenwärtig Websites, von denen ein Verbraucher Anweisungen und Texte erhalten kann, die ihm gestatten werden, eine Melodie von Hand in eine Mobilstation zu programmieren, oder die Ruftöne zu Mobilstationen der Marke Nokia senden. Beispiele für derartige Sites sind www.clubnokia.com and www.yourmobile.com. Dies erfordert, daß der Benutzer über einen Zugang zu einem Personalcomputer (PC) oder einer anderen World-Wide-Web(WWW)-Surfvorrichtung verfügt, die Browser verwendet, welche grundlegende Industriestandards wie etwa das Hypertextübertragungsprotokoll (HTTP) und die Hypertextauszeichnungssprache (HTML) unterstützt. Derartige WWW-Sites wurden für Desktop-PCs und schnellere Verbindungen gestaltet und funktionieren in Geräten mit schmaler Bandbreite und begrenzter Bildschirmgröße nicht gut.
Jüngere Fortschritte bei Webprotokollen haben zur Schaffung des drahtlosen Anwendungsprotokolls (WAP) geführt. WAP-Lösungen, die die Handgeräteauszeichungssprache (HDML) oder die drahtlose Auszeichnungssprache (WML) verwenden, gestatten, daß Webinhalte an die Verwendung an Handgeräten mit schmaler Bandbreite und begrenzter Bildschirmgröße wie etwa Mobilstationen angepaßt werden. Mobilstationshersteller betten Hochdienstleistungsanwendungen wie etwa WAP-konforme Mikrobrowser in ihre Mobilstationen ein, die den Mobilstationen gestatten, durch ein drahtloses Portal als Kunde für Dienste und Inhalte aus dem Internet zu funktionieren. Mikrobrowser können Logik in der Form von Software oder in das Endbenutzergerät eingebettete Firmware sein, die dem Gerät ermöglicht, mit einem Übergang in einem Netz zusammenzuwirken. Beispiele für Mikrobrowser sind der wie in Anhang A gezeigte Nokia Microbrowser und der UP.Browser von Phone.com (Redwood City, Kalifornien; www.phone.com). Ein Formleitfaden für HDML kann ebenfalls von (www.phone.com) erhalten werden.
Ein drahtloses Portal oder ein Übergang ist der Eintrittspunkt, durch den der Benutzer auf Internetinhalte und -dienste zugreift. Das Portal kann Inhalte und/oder Dienste zum Benutzer senden (als PUSH bezeichnet), oder der Benutzer kann Inhalte oder Dienste vom Portalprovider anfordern (als PULL bezeichnet). Ein Beispiel eines derartigen Portals wäre die Nokia Artus MAX Platform (www.nokia.com/wap/products.html).
Informationen über das WAP können durch (www.wapforum.org) oder Understanding WAP; Wireless Applications, Devices, and Services; ISBN 1-58053-093-1; Artech House Publishers (Boston; www.artechhouse.com) erhalten werden.
Es wäre daher wünschenswert, Rufmelodien über das WAP oder andere ähnliche Dienste zu einer Mobilstation zu liefern. Es besteht auch ein Bedarf, dem Verbraucher ein System zum Genehmigen oder Ablehnen der Verrechnung einer gelieferten Melodie bereitzustellen. Es besteht auch ein Bedarf, die Vornahme von Gutschriften an einen Verbraucher, der Werbung in der Form von Logos und/oder Werbemelodien akzeptiert, bereitzustellen.
KURZDARSTELLUNG DER ERFINDUNG
Es wird ein neuartiges System zum Liefern und Wiedergeben personalisierender Rufmelodiendaten oder anderer derartiger Medieninhalte an den WAP-Browser eines drahtlosen Handapparats bereitgestellt. Zusätzlich wird ein neuartiges System bereitgestellt, das einem Verbraucher gestattet, den Multimedieninhalt vorab zu betrachten und die Verrechung für diesen bestimmten Multimediennachrichteninhalt entweder zu genehmigen oder abzulehnen. Der Verbraucher kann auch Gutschriften für die Annahme von Werbeinhalten erhalten. Der Benutzer fordert durch Senden einer Nachricht mit einem Datenkopf, der eine Kennungsnummer umfaßt, einen Medieninhalt an, und der Benutzer empfängt dann eine Nachricht, die den Medieninhalt und einen universellen Quellenlokalisierer (URL) umfaßt. Nach der Annahme der Medien durch Speichern der Medien in einem nichtflüchtigen Speicher wird auf Basis des URL ein Dienstfunktionselement erzeugt. Dieses wird in eine Nachricht aufgenommen und zu einem abrechnenden Server gesendet.
Ein Vorteil dieser Erfindung ist, daß ein Verbraucher Multimedieninhalte wie etwa Rufmelodien direkt von einem Handapparat auswählen kann und sich nicht vor einem PC befinden muß, um Multimedieninhalte zur Lieferung über SMS oder den Multimediennachrichtendienst (MMS) auszuwählen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Das oben Ausgeführte und weitere Merkmale der Erfindung werden in der nachfolgenden "Ausführlichen Beschreibung der Erfindung" offensichtlicher gemacht, wenn diese in Verbindung mit den beiliegenden Zeichnungen gelesen wird, wobei
1 eine Darstellung einer Mobilstation mit begrenzter Bildschirmgröße und Tastatur ist;
2 eine Darstellung eines WAP-Browsers ist;
3 eine zusätzliche Darstellung eines WAP-Browsers ist;
4 ein Ablaufdiagramm ist, das eine Ausführungsform nach der Erfindung veranschaulicht, und aus 4A und 4B besteht;
5 ein Sitzungsdiagramm ist, das die Hardware zeigt, die mit den verschiedenen in 4A und 4B gezeigten Schritten verbunden ist;
6 eine Anzeigesequenz einer Mobilstation zeigt, die eine Multimediennachricht nach einer Ausführungsform der Erfindung empfängt; und
7 eine Tonaktivierungssequenz nach einer Ausführungsform der Erfindung zeigt.
AUSFÜHRLICHE BESCHREIBUNG
Die Erfindung kann in Funksystemen verwendet werden, die Browsern Rechnung trägt. Die Beispiele beschreiben die Verwendung der Erfindung in einem universellen Mobilkommunikationssystem (UMTS), das ein mit jedem beliebigen WAP oder dergleichen ausgeführtes Breitband-Codemultiplexzugriffs(CDMA),(TDMA)-Verfahren verwendet, wobei die Erfindung jedoch nicht darauf beschränkt wird.
Der Kurznachrichtendienst SMS hat sich so weiterentwickelt, daß er mobile Multimedien enthält. Der Multimediennachrichtendienst (MMS) enthält Bilder, Audio, Video, Daten und Text oder Kombinationen davon. Der Inhaber der vorliegenden Erfindung hat bei der CeBit 1997 ein "Smart Messaging" genanntes Benachrichtigungskonzept vorgestellt. Smart Messaging gestattet, daß Internetinformationen zu jeder beliebigen GSM-Mobilstation geliefert werden, die Kurznachrichten unterstützt. Smart Messaging verwendet die Artus Messaging Platform, die Internetinformationen im HTML-Format abruft und über TTML in eine Kurznachricht umwandelt. TTML, ein Untersatz der HTML, ist das Protokoll von Nokia zum Darstellen von Informationen, auf die vom Internet zugegriffen wurde, an GSM-Telefonen. Da das Abrufen von Internetinhalten in HTML erfolgt, müssen Inhalteprovider keine Veränderungen an Webservern vornehmen. Entwickler erlangen, ebenfalls über das drahtlose Telefonsystem, einen vereinheitlichten Zugang zur gesamten globalen Benutzergemeinde.
Andere Auszeichnungssprachen wie etwa XHTML und TML (Aufgabenauszeichnungssprache) stehen gegenwärtig in Verwendung. Fachleute können fähig sein, diese anderen Sprachen zu verwenden. Der Umfang der Erfindung soll nicht auf irgendeine Auszeichnungssprache beschränkt sein.
Smart Messaging verwendet das Schmalband-Socket-Protokoll, das von Intel und Nokia gemeinsam entwickelt wurde. Es tut dies für drahtlose Telefone, was der Windows-Socket-Stapel für das Betriebssystem von Microsoft tut, d.h., es stellt ein Standardmittel für die Verbindung mit dem Internet bereit.
Die Schmalband-Sockets(NBS)-Spezifikation ist eine offene Industriespezifikation, die ursprünglich durch Intel und Nokia entwickelt wurde. Unter Verwendung der Funktionen, die in dieser Spezifikation definiert sind, können unter Verwendung vertrauter Internetprogrammierungsschnittstellen drahtlose Benachrichtigungsanwendungen für Mobil-PC- und SmartPhone-Benutzer geschaffen werden. Die NBS-Spezifikation erweitert die Reichweite des Internets, um "stets verbundene" Mobilstationskunden zu schaffen.
Die NBS-Spezifikation definiert eine wirksame Ausführung von UDP- und TCP-Diensten über drahtlose Benachrichtigungsnetze. NBS ist auch netzunabhängig, so daß Anwendungen NBS verwenden können, um Daten via Kurznachrichten über jedes beliebige Netz zu senden und zu empfangen. Die NBS-Spezifikation stellt BSD-Socket- und Winsock2-Programmierungsschnittstellen bereit, die Fachleuten alle wohlbekannt sind.
Die Narrow-Band Sockets Specification, Überarbeitung 1.0, 7. März 1997, wie auch ein Weißbuch mit dem Titel "Narrowband Sockets: a wireless messaging protocol and API for enabling AOAC mobile communications", kann vom URL www.forum.nokia.com heruntergeladen werden.
Das Senden von Nachrichten, die Graphiken enthalten, wird durch die am 28. September 2000 als Veröffentlichungsnummer WO 00/57617 veröffentlichte internationale Patentanmeldung Nr. PCT/EP00/02370 gelehrt. Diese internationale Anmeldung ist dem Inhaber der vorliegenden Anmeldung übertragen.
Unter Bezugnahme auf die Figuren in der vorliegenden Erfindung ist 1 eine Darstellung einer typischen Mobilstation, die eine Ausführungsform der vorliegenden Erfindung enthalten würde. Diese Darstellung ist nur beispielhaft und die beschriebene Anordnung ist für die praktische Ausführung der Erfindung nicht kritisch. In diesem Fall ist die Mobilstation 100 ein drahtloser Telefonhandapparat mit einer begrenzten Bildschirmansicht und einem Handapparat. Die Mobilstation 100 könnte ein drahtloses System umfassen, das nach jedweden verschiedenen Zellularstandards wie etwa dem globalen System für mobile Kommunikation (GSM), dem Codemultiplexzugriff (CDMA) oder jedem beliebigen ihrer Nachkommen und dergleichen tätig ist.
Informationen über CDMA werden durch Telecommunications Standards (TIA) bereitgestellt. Die Bücher IS-95 CDMA and CDMA2000 von Vijay K. Garg; ISBN 0-13-087112-5; erschienen bei Prentice Hall (New Jersey; www.phptr.com) und WCDMA for UMTS Radio Access for Third Generation Mobile Communications, herausgegeben von Harri Holma und Antti Toskala (beide von Nokia, Finnland); ISBN 0 471 72051 8; erschienen bei John Wiley and Sons, Ltd. (England, www.wiley.com) stellen ein Verständnis des Materials bereit.
Die Mobilstation 100 umfaßt eine Anzeige 110, die Daten, Menüs und Bereiche für Funktionstastenfunktionen 121A und 121B, die durch Drücken von Funktionstasten 120A und 120B aktiviert werden können, anzeigt. Rolltasten 130 sind ebenfalls bereitgestellt, um durch Menüpunkte, die an der Anzeige 110 gezeigt werden, zu rollen. Die Rolltasten 130 können auch ein Rollzylinder, eine Kugel oder ähnliches sein, das ein Rollen durch angezeigte Punkte gestattet. Eine Tastatur 140 ist zur Eingabe von Daten tätig. Die Tasten der Tastatur 140 können auch durch verschiedenste Verfahren, die Fachleuten bekannt sind, beleuchtet sein, um eine sichtbare Erinnerung als Reaktion auf ein Ereignis zu erzeugen. Die Eingabe von Daten kann durch die Verwendung einer vorhersagenden Tastatureingabe, die Fachleuten bekannt ist, erleichtert werden. Die Daten werden in einem Speicher 180 gespeichert. Der Speicher 180 kann einen flüchtigen Direktzugriffsspeicher (RAM) enthalten, der einen Cache-Bereich für die Zwischenspeicherung von Daten enthält. Die Mobilstation 110 kann auch einen nichtflüchtigen Speicher 160 umfassen, der eingebettet sein kann oder entfernbar sein kann, wie etwa ein entfernbares Teilnehmererkennungsmodul (SIM). Der nichtflüchtige Speicher 160 kann ein EEPROM oder ein Flash-Speicher und dergleichen sein, der von SanDisk (Sunnyvale, Kalifornien) oder Lexar Media (Fremont, Kalifornien) erhältlich ist. Die Speicher 160 und 180 können eine Logik enthalten, die den Betrieb eines Prozessors 170 zur Ausführung von Funktionen nach Ausführungsformen der Erfindung steuert. Die Logik kann ein Software- oder ein Firmwarecode sein. Der Prozessor 170 erzeugt passende Befehle und steuert die anderen Komponentenblöcke der Mobilstation 100. Der Prozessor 170 kann auch einen eingebetteten Cache-Speicher aufweisen. Die Mobilstation 100 umfaßt auch einen Lautsprecher, um für das Ertönen der Rufmelodien zu sorgen.
Die Anzeige kann auch eine virtuelle Anzeige sein, wie sie durch MicroVision (Seattle, Washington) bereitgestellt wird. Die Anzeige kann auch das Gehäuse der Mobilstation 100 sein, wobei elektronische Tinte von E-Ink Corporation (www.eink.com; Cambridge, Massachusetts), und auf Kunststoff gedruckte Aktivmatrix-Antriebskreise von Lucent Technologies (Cambridge, Massachusetts) verwendet werden. Die Spezialtinten bestehen aus Halbleiterteilchen in Nanometergröße wie die von Joseph Jacobson et al. entwickelten. Es wird auf die US-Patentschriften Nr. 5,930,026; 5,961,804; 6,017,584; 6,072,716; 6,118,426; 6,120,588; 6,120,839; und 6,130,773 aufmerksam gemacht. Die Arbeit an dieser Technologie wurde am MIT und in der jüngeren Zeit bei E-Ink vorgenommen.
Die Mobilstation 100 kann auch mit einer Schnittstelle versehen sein, um zu gestatten, daß die Töne der Mobilstation einschließlich der Rufmelodien über ein bestehendes Audiosystem abgespielt werden. Eine derartige Schnittstelle wird durch die am 19. Dezember an Juntunen et al. ausgegebene US-Patentschrift Nr. 6,163,711 mit dem Titel METHOD AND APPARATUS FOR INTERFACING A MOBILE PHONE WITH AN EXISTING AUDIO SYSTEM, die dem Inhaber der vorliegenden Anmeldung übertragen wurde, bereitgestellt. Dies sorgt für ein besseres Lautsprechersystem, das das Abspielen von polyphonen Melodien gestatten wird.
Die Mobilstation 100 kann auch einen Infrarot-Transceiver 150 oder ein anderes Mittel für die lokale Datenübertragung aufweisen, damit Daten mit anderen Geräten wie etwa anderen Mobilstationen, Fahrzeugleitsystemen, Druckern und dergleichen geteilt werden können. Das Teilen von Daten kann auch durch eine Funkfrequenzidentifikations(RFID)transpondermarkierung, die Fachleuten als Mittel für eine lokale Datenübertragung bekannt ist, bereitgestellt werden. Die Mobilstation 100 kann auch ein ladungsgekoppeltes Element oder eine andere derartige Bilderfassungsvorrichtung enthalten. Ein anderes Mittel zum Teilen von Daten wird durch Bluetooth bereitgestellt. Informationen in Bezug auf Bluetooth können unter www.bluetooth.com gefunden werden.
Ausführungsformen nach der Erfindung können in Trägerdiensten wie etwa SMS, leitungsvermittelten Daten (CSD), dem Third Generation Partnership Project (3GPP) und trägerunabhängigen Lösungen wie etwa dem drahtlosen Anwendungsprotokoll (WAP) und dergleichen verwendet werden.
Einzelheiten zur WAP-Architektur und zu Spezifikationen sind vom WAP-Forum erhältlich, das sich unter www.wapforum.org befindet. Die WAP-Spezifikationen sorgen für eine drahtlose Anwendungsumgebung (WAE). Die WAE stellt eine allgemeine Anwendungsumgebung bereit, die auf dem World-Wide-Web(WWW)-Modell von Technologien aufbaut.
Im WWW-Modell bieten Server Kunden Inhalte in einem Standardformat wie etwa HTML oder XML, das auch als Webseiten oder Dokumente bezeichnet wird. Die Dokumente werden durch Benutzeragenten, die als Browser bekannt sind, welche im Kunden eingebettet sind, durchgesehen. Quellen im WWW werden mit universellen Quellenlokalisierern (URLs) des Internetstandards benannt. Der Browser kommuniziert mit dem Server unter Verwendung von Standardvernetzungsprotokollen, deren gebräuchlichstes das Hypertexttransportprotokoll (HTTP) ist.
Die WAE folgt dem WWW-Modell. Der Inhalt befindet sich in einem Standardformat wie etwa WML, das XML ähnlich ist. Seiten oder Dokumente der WWW-Domäne werden im WAP Karten oder Kartenauswahlen. Es sind Anwendungen bereitgestellt, die HTML-formatierte Dokumenten parsen und sie in HDML- oder WML-Format-Kartenauswahlen/Karten übersetzen. Der Inhalt wird in der WWW-Domäne des Netzes unter Verwendung von HTTP und in der drahtlosen Domäne unter Verwendung eines HTTP-artigen Protokolls, das als drahtloses Sitzungsprotokoll (WSP) bezeichnet wird, transportiert.
2 ist eine Darstellung eines WAP-Kunden. In der bevorzugten Ausführungsform der vorliegenden Erfindung ist die Mobilstation als ein WAP-Kunde konfiguriert. Wie der Großteil der Netzarchitektur ist das WAP als eine Reihe von Schichten organisiert. Der WAP-Kunde 200 umfaßt eine Benutzeragentenschicht 230, eine URL-und-HTTP-Schicht 240, und eine Protokollschicht 250. Der WAP-Kunde 200 von 2 umfaßt auch verschiedene Anwendungsprogrammschnittstellen APIs) wie etwa die drahtlose Anwendungsumgebung (WAE API) 210, Plattform-APIs 215, und das drahtlose Datagrammprotokoll (WDP API) 220.
Das WDP übernimmt das in der WWW-Domäne definierte Benutzerdatagrammprotokoll (UDP), und die WDP API kann Datenträgerdienste von Standards wie etwa GSM, CDMA, GPRS, CDPD und dergleichen unterstützen.
Die Benutzeragentenschicht 230 umfaßt einen WML-Browser 231, eine virtuelle WMLScript-Maschine 232, um die Mobilstation zu programmieren, und WMLScript-Bibliotheken 933, die ein Satz von Standardfunktionen sind. Der WML-Browser, der auch als ein Mikrobrowser bezeichnet wird, kommuniziert unter Verwendung von WSP mit einem Übergang. Der Übergang kommuniziert unter Verwendung von HTTP mit dem Server.
Die URL-und-HTTP-Schicht 240 umfaßt einen URL-Lader 241, einen HTTP-Lader 242, und einen Cache 243.
Die Protokollschicht 250 umfaßt einen drahtlosen Protokollstapel, der wiederum ein drahtloses Sitzungsprotokoll (WSP) 261, ein drahtloses Vorgangsprotokoll (WTP) 262, und eine drahtlose Vorgangsschichtensicherheit (WTLS) 263 für die Sicherheitssteuerung umfaßt. Ein drahtloses Datagrammprotokoll (WDP) 264 kann an Trägerdienste gekoppelt sein und stellt Dienste für die oberen Schichten im Protokollstapel 260 bereit.
3 ist ein anderes Beispiel für einen WAP-Kunden an der Mobilstation 100 von 1, Der Kunde 300 umfaßt WML-Browser-Komponenten 310, eine Benutzerschnittstellen(UI)ebene 380, und eine Trägerebene 390. Der WML-Browser interpretiert die WML-Inhalte (Karten und Kartenauswahlen), die vom WAP-Übergang erhalten wurden, und gibt den Inhalt unter Verwendung der bereitgestellten APIs an die UI weiter. Der WML-Browser bewahrt auch die Browserzustandsinformationen.
Die UI-Ebene 380 umfaßt ferner eine Hauptfenster-und-Menükomponente 381 und Komponenten für Einstellungen 382, die Kartengabe 383, und Lesezeichen 384.
Die Trägerebene 390 umfaßt eine Ausführung eines Benutzerdatagrammprotokoll(UDP)-Trägers. Dieser Träger ist fähig, leitungsvermittelte Daten(CSD)netze zu unterstützen.
Die Benutzeragenten(UA)ebene umfaßt den Kern des Browsers 310, nämlich einen WML-Interpretierer 321, einen WMLScript-Interpretierer und Standardbibliotheken 322, und ein Push-Untersystem 323. Der WML-Interpretierer unterstützt die WML-Sprachspezifikation einschließlich von WBMP-Bilddateien, eines asynchronen Bildladers, und Cookies. Der WMLScript-Interpretierer handhabt codierte WMLScript-Inhalte und führt Vorgänge durch, die durch diese Inhalte bestimmt werden. Die Bibliotheken enthalten Unterstützungen für Browser- und URL- Behandlungsfunktionen. Die UA-Ebene steht unter Verwendung von WML, WMLScript und Push-APIs mit der UI-Ebene in Verbindung.
Das Push-Untersystem 320 umfaßt ferner einen Push-Behandler 324, einen Dienstanzeige(SI)-Decodierer 325, einen Dienstlader(SL)-Decodierer 326, und einen WBXML-Parser 327. Das Push-Untersystem benutzt den WBXML-Parser, um Push-Nachrichten entweder zum SI-Decodierer 325 oder zum SL-Decodierer 326 zu versenden. Sobald die Nachricht decodiert wurde, wirkt der Push-Behandler 324 mit den Diensten der Mobilstation (z.B. Benachrichtigungen, Alarme) und der Laderebene 330 des Kunden zusammen, um den Push-Vorgang abzuschließen.
Die Laderebene 330 umfaßt einen HTTP-Lader 331, einen URL-Lader 332, einen Cache 333, einen Anwendungsversender 334, eine WSP-Datenkopf-Handhabung 335, einen Inhaltsversender 356, und einen WSP-Adapter 357. Die Laderebene 330 handhabt das Laden von URLs unter Verwendung des HTTP-Schemas. URL- und Datenkopf-Gültigkeitserklärungen werden in dieser Ebene durchgeführt. Es wird auch eine Unterstützung für Cookies und die grundlegende Beglaubigung bereitgestellt. Die Cache-Logik und -Speicherung kann ebenfalls an dieser Schicht unterstützt werden. Die Laderebene 330 sorgt auch für die Inhalts- und Anwendungsversendung einschließlich der Push-Versendung. Die Laderebene 330 steht über eine WSP-Handhabungs-API mit der Ebene des drahtlosen Protokollstapels (WSP) und über Lader-APIs mit der UA-Ebene in Verbindung.
Beispielhafte Kunden und Browser stellen wirtsspezifische Inhaltstypen, auch als multimediale Internetposterweiterungs(MIME)typen bekannt, bereit, die gestatten, daß die Mobilstationen Funktionen über den normalerweise durch den Kunden erlaubten ausführt. Wie hierin offenbart erlauben der MIME-Typ und Dateiformate einer Mobilstation, besondere Netzvorgänge wie etwa das Herunterladen von Rufmelodien und Bitmaps durchzuführen. Dadurch können eine Rufmelodie oder andere Multimedieninhalte heruntergeladen werden und kann die Antwort zum enthaltenen URL gesendet werden.
Die Bitmaps können an der Anzeige 110 der Mobilstation 100 dargestellt werden. Eine andere Ausführungsform kann bereitgestellt werden, wenn das Gehäuse der Mobilstation 100 mit besonderen Tinten hergestellt ist, die von E-Ink geschaffen wurden und gestatten, daß Anzeigen auf biegsamen Kunststoffen geschaffen werden. Daher kann das gesamte Mobilstationsgehäuse eine Werbung sein.
MIME beschreibt, wie Nachrichten im Internet gesendet werden. HTTP und ähnliche Protokolle verwenden die MIME-Typisierung, um die Art der Daten zu bestimmen, die sie zu einem Kunden zurücksenden. Für die Mobilstation Nokia 6185 ist ein neuer MIME-Typ als "Anwendungs/nmp-Inhalt" definiert. Dieser MIME-Typ ist normalerweise mit Dateien verbunden, die eine ".nmp"-Erweiterung aufweisen, doch kann ein Server diesen MIME-Typ für jede beliebige Datei verwenden.
DER DATENKOPF VOM TYP "NMP-INHALT"
Daten, die als "Anwendungs/nmp-Inhalt" markiert sind, sollten mit einem bestimmten Datenkopf beginnen, damit die Mobilstation ihren Datentyp erkennen kann.
Tabelle 1: NMP_DATENKOPF
Wie aus Tabelle 1 ersichtlich ist, umfaßt der Datenkopf ein Feld FILE_TYPE, das acht Byte an ASCII-Text umfaßt, die den Dateityp bezeichnen. Weitere Informationen über den Dateityp werden durch Tabelle 2 bereitgestellt.

LENGTH_MSB – höchstwertige Byte von Daten, die dem Datenkopf folgen
LENGTH_LSB – niedrigstwertige Byte von Daten, die dem Datenkopf folgen
SUB_FIELD_CONTENT – Anzahl von Unterfeldblöcken
RESERVED – reservierte Bits

Tabelle 2: Dateitypen
"NMP-RNG0"-DATEITYPEN
Der Dateityp NMP-RNG0 wird zum Herunterladen von Rufmelodien verwendet. Tabelle 3 stellt das Format für einen Rufmelodien-Dateityp bereit: Tabelle 3: Rufmelodien-Dateityp
FILE_TYPE, LENGTH_MSB, LENGTH_LSB, und RESERVED sind wie in Tabelle 1, wobei FILE_TYPE "NMP-RNG0" ist.
RING_NAME ist eine ASCII-Zeichenkette, die die Rufmelodie benennt. RING DATA ist ein binäres NMP-Rufformat. Dieses Datenformat wurde in der am 25. Juli 2000 an Armanto et al. ausgegebenen US-Patentschrift Nr. 6,094,587 mit dem Titel PROGRAMMING OF A TELEPHONE'S RING TONE, die dem Inhaber der hierin beschriebenen Erfindung übertragen wurde, bereitgestellt.
Der Rufton kann auch zu Zeichen verändert und in der folgenden Weise als Zeichen in der Form von Noten in der Kurznachricht enthalten sein.
Noten in Zeichen:

C, D,..., G, A, H: Noten von A bis G einer niedrigeren Oktave
c, d,..., g, a, h: Noten von A bis G einer höheren Oktave
# erhöht die vorhergehende Note um einen Halbton (z.B., hoch)
b erniedrigt die vorhergehende Note um einen Halbton (z.B., dumpf)

Dauer:

kein Zeichen: Grundlänge
–: die Hälfte der Grundlänge der vorhergehenden Note
+: Verdopplung der Grundlänge der vorhergehenden Note
.: das 1,5-fache der Grundlänge der vorhergehenden Note
..: das 1,75-fache der Grundlänge der vorhergehenden Note
Ein Längenzeichen kann kumulativ sein, z.B. trägt ein einzelnes Zeichen stets zur Wirkung des ihm vorhergehenden Zeichens bei. Zum Beispiel bedeutet C+ das Dreifache der Grundlänge und C--- das 0,125fache der Grundlänge.

Pausen:

; Pause, von gleicher Länge wie die Grundlänge
, Pause, von der Hälfte der Grundlänge
Andere Pausen können durch Verwendung von Zeichen, die die Länge einer Note abändern, zusammen mit den Pausenzeichen eingegeben werden.

Wie oben gezeigt kann ein Rufton, der durch Noten erzeugt wird, in Zeichen codiert werden, die in einer Kurznachricht gesendet werden können, woraufhin beim Empfang die empfangenen Zeichen zum gesendeten Rufton verarbeitet werden können, der in einem Ruftonspeicher gespeichert werden kann und wiedergegeben werden kann, wenn das Telefon läutet. Daher ist das Verfahren besonders für ein Gerät geeignet, bei dem der Rufton als Noten durch eine Benutzerschnittstelle programmiert werden kann, oder als Noten in einem Ruftonspeicher vorgespeichert wurde.
Zusätzlich zu den oben gezeigten Beschreibungen können auch andere Faktoren, die mit einem Rufton und seiner Beschreibung in Zusammenhang stehen, als Zeichen bestimmt werden, z.B. in der folgenden Weise:

:ACD :X, wobei X eine optionale Zahl (ganze Zahl) ist, wiederholt eine Notensequenz ACD X mal, zwei Mal, wenn X fehlt
/X ACD/, wobei X eine optionale Zahl (ganze Zahl) ist, verringert die Länge der Noten innerhalb der Zeichen "/" z.B. durch Teilen durch die Zahl X. Drittelnoten würden nach dieser Beschreibung als "/3 ACD/ gekennzeichnet sein.
$ gibt um einen Halbton erhöhte und verringerte Noten, z.B für alle Noten in Klammern, an, in welchem Fall es nicht nötig ist, die Zeichen # oder b für diese Noten gesondert einzugeben.
(:) bestimmt Wiederholungen, z.B. so, daß (5CD:2E:F) als CDE, CDE CDF CD CD gespielt wird.
! schaltet einen "Stakkato"musikmodus z.B. bis zum folgenden Zeichen ein/aus, wobei die Länge einer Note um einen passenden Prozentsatz erhöht wird und das Verhältnis einer Pause verringert wird, wodurch ein fragmentarischer Stil erreicht wird, ohne die Gesamtzeit zu verändern. In einer Computersimulation klingt eine Erhöhung der Länge einer Note um 50 bis 60 % oder sogar um 70 % immer noch gut.
? schaltet eine Funktion gesonderter Noten z.B. bis zum folgenden Zeichen ein/aus, wobei die Länge einer Note für einen Mindestzeitraum erhöht wird und eine Pause für den Rest der Zeit, in der Musik erzeugt wird, dauert, wobei zwei gleiche Noten hintereinander anders als bei einem "fließenden" Musikmodus, in dem vorhergehende Noten als eine einzelne Note gehört würden, als gesonderte Noten gehört werden können. Eine Pause zwischen Noten muß die gleiche Dauer aufweisen. Noten, die kürzer als die bestimmten Pausen sind können nicht als gesonderte Noten gehört werden. In einer Computersimulation klingen Pausen zwischen Noten, die etwa 30 ms lang dauern, durch die Funktion gesonderter Noten gut.
– erhöht eine Standardoktave. Wenn die Standardoktave 1 ist, wird auf 2 erhöht, andernfalls 1.
" verringert eine Standardoktave. Wenn die Standardoktave 3 ist, wird auf 2 verringert, andernfalls 3.
Wenn angenommen wird, daß vier Oktaven in Verwendung stehen, ist es möglich, wie oben dargestellt durch Verwendung von Groß- und Kleinbuchstaben C ... H, c ... h, zwei Oktaven gleichzeitig zu verwenden.
X erhöht alle folgenden Noten X um einen Grad, wobei X eine ganze Zahl ist. Wenn X eine negative Zahl ist, kommt es zu einer Erniedrigung.
Zahl bestimmt ein Tempo, Schläge pro Minute, z.B., wie viele Noten mit (allein) der Grundlänge pro Minute.
Ein Leerraum soll ignoriert werden.
Zusätzlich kann ein Rufton mit irgendeiner anderen Nachricht durch eine Benutzerschnittstelle kombiniert werden, zum Beispiel: * ein blinkendes Licht wenn das Telefon läutet – schaltet das Licht ein/aus

ASCII-Zeichen werden in binäre Zeichen umgewandelt. Die ASCII-Zeichen können als Hexadezimalzahlen dargestellt werden, die leicht weiter zu Binärzahlen umgewandelt werden können. Im Folgenden werden wir darstellen, wie das Wort "Calling" in eine Binärzahl umgewandelt wird. Im Folgenden entsprechen zwei Zahlen, in einer Hexadezimalform, dem durch einen Leerschritt getrennten ASCII-Zeichen, wobei jedes der Hexadezimalzeichen in vier Bits dargestellt werden kann, d.h., im Folgenden jedes ASCII-Zeichen durch 8 Bits dargestellt ist.

Als ASCII-Zeichen: "Calling"
In der Hexadezimalform: 43 61 6C 6C 69 6E 67
In der Binärform: 0100 0011 0110 0001 0110 1100 0110 1100 0110 1001 0110 1110 0110 0111

Bei der tatsächlichen Übertragung werden die Zeichen nacheinander ohne Leerschritte, d.h. als ununterbrochene Bitsequenz, gesendet. Somit gibt es für jedes ASCII-Zeichen eine bestimmte hexadezimale und eine bestimmte binäre Form, in welchem Fall die oben dargestellten Beispiele zum Bestimmen von Noten durch ASCII-Zeichen in Binärzeichen umgewandelt werden können.
Eine andere Alternative zum Senden einer Rufmelodie als Zeichen ist, sie zuerst in eine MIDI-Form (digitale Schnittstelle für Musikinstrumente) umzuwandeln, die eine wohlbekannte Kommunikationssprache für Instrumente ist. Dies könnte durch Anordnen eines MIDI-Umwandlers in einer Mobilstation ausgeführt werden. Der MIDI-Umwandler würde sich vorzugsweise im Prozessor befinden, der, in diesem Fall, die in MIDI empfangenen Zeichen beim Empfang in eine passende Form für den Ruftongenerator und -speicher des Telefons umwandeln würde. In der gleichen Weise würde der MIDI-Umwandler die Rufmelodie in Zeichen nach der MIDI-Form umwandeln. Der MIDI-Umwandler würde die Komposition von Rufmelodien z.B. durch computerunterstützte Kompositionsprogramme, die die MIDI-Form unterstützen, und dadurch die Übertragung der erzeugten Melodie, z.B. in einer Kurznachricht, von einem Computer oder Server zu einer Mobilstation ermöglichen.
"NMP-BMP0"-DATEITYPEN
Dieser Dateityp wird zum Herunterladen von Weck- oder anderen Bitmaps verwendet.
Tabelle 4: Weck-BMP-Dateityp
FILE_TYPE, LENGTH_MSB, LENGTH_LSB, RESERVED sind wie in Tabelle 1, wobei FILE_TYPE "NMP-BMP0" ist.
Das Feld BMP_FORMAT ist für ein NMP-Bitmapformat 0×00. 0×01 bis 0×FF sind reserviert.
Tabelle 5: BMP-Formate
Das Feld BITS_PER_PIXEL gibt die Anzahl der nicht unterzeichneten Bits für jedes Pixel an.
Das Feld BMP_HEIGHT gibt die Höhe der Bitmaphöhe in Pixel (nicht unterzeichnet) an.
Das Feld BMP_WIDTH gibt die Breite des Bitmaps in Pixel (nicht unterzeichnet) an.
PIXEL_DATA ist ein Strom von Bytes, der die Bitmapdaten darstellt.
"NMP-PPC0"-DATEITYPEN
Dieser Dateityp wird zum Herunterladen einer PPC-Anforderungsdatei verwendet. Diese Datei enthält eine Liste von Kennungen, deren entsprechende Daten heraufgeladen werden sollten.
Tabelle 6: PPC-Anforderungsdateiformat
FILE_TYPE, LENGTH_MSB, LENGTH_LSB, RESERVED sind wie in Tabelle 1, wobei FILE_TYPE "NMP-PPC0" ist.
SCRIPT_URL ist eine mit NULL beendete ASCII-Zeichenkette, die den URL einer gemeinsamen Übergangsschnittstelle (cgi) enthält, oder ein anders Skript, das die sich ergebenden Daten verarbeiten wird. SPECIAL_DATA ist eine Bitmaske der angeforderten besonderen Daten. Nähere Informationen sind in Tabelle 7 bereitgestellt.
PPC_LIST ist eine Liste von PPC_Kennungen, deren Daten heraufgeladen werden sollen.
Tabelle 7: Besondere Anforderungen PPC
"NMP-CNT0"-DATEITYPEN
Dieser Dateityp ist eine Weiterentwicklung vom herunterladbaren Dateiformat und enthält eine Vielfalt von Inhaltsarten.
Tabelle 8: CNT0-Dateiformat
FILE_TYPE, LENGTH_MSB, LENGTH_LSB, RESERVED sind wie in Tabelle 1, wobei FILE_TYPE "NMP-PPC0" ist.
Wie in Tabelle 1 ersichtlich ist SUB_FIELD_CNT ein neuartiges Feld.
SUB_ID-TYPEN
SUB_ID-BLOCK-DATENFORMATE
Jeder SUB_ID-Block weist ein einzigartiges Datenformat gemäß seinem Typ auf. Diese Daten sind im Feld SUB_ID_DATA der Blockaufzeichnung angeordnet. Zum Zeitpunkt der Einreichung der vorliegenden Anmeldung sind nur drei Datentypen definiert:
RING_BINARY – enthält den gleichen Datentyp wie NMP_RNG0 (siehe Tabelle 3)
BMP_BINARY – enthält den gleichen Datentyp wie NMP_BMP0 (siehe Tabelle 4)
RESPONSE_URL – enthält einen URL zu "goto", um die Übergabenachricht zu empfangen. Wenn dieses Feld in der Datendatei vorhanden ist, muß das Gerät, z.B. die Mobilstation, eine HTTP-"GET"-Anforderung an den enthaltenen URL vornehmen und darf sie die Daten nicht schreiben, bis sie eine Übergabenachricht erhält.
URL_DATA ist eine Zeichenkette von ASCII-Zeichen.
"NMP-CMT0"-DATEITYPEN
Dieser Dateityp bezeichnet einen Auftrag zur Inhaltsübergabe. Wenn eine Datei, die einen Antwort-URL enthält, heruntergeladen wird, muß das Gerät eine HTTP-"GET"-Anforderung an den enthaltenen URL vornehmen. Der Server kann dann mit einer Datei dieses Typs antworten, um die Mobilstation darüber zu informieren, daß sie die Erlaubnis hat, die Daten im Dauerspeicher zu speichern. Dieser MIME-Typ weist keine Daten auf.
Das System und das Verfahren zum Verwenden des neuartigen Datenkopfs und Dateiformats ist wie folgt:
In einer Nachricht sind zwei Datenblöcke, eine Rufmelodie und ein Übergabe-URL enthalten.
Der Übergabe-URL kann zum Beispiel
http://marge.americas.nokia.com/wml/commit.nmp sein. Im Grunde ist dies eine Datei mit nur dem Übergabedatenkopf.
Die Rufmelodien sind in eine binäre Blockdatei (in der bevorzugten Ausführungsform vom Format SUB_ID BLOCK) umgewandelt. Dann wird eine andere binäre Datei für den Übergabe-URL-Block geschaffen. Die Dateien werden verkettet und ein Dateikopf, der die kombinierte Länge enthält, wird vorangestellt.
Als Beispiel:
ALTES FORMAT:

8 Byte Kennung (d.h. NMP-RNG0)
2 Byte Länge
2 Byte reserviert
N Byte von Daten (für jeden Typ spezifisch)

NEUES FORMAT:

8 Byte Kennung (im Besonderen "NMP-CNT0", das alte Format/der Datenkopf wird unterstützt)
2 Byte Länge
1 Byte num_sub_params
1 Byte reserviert
(optional wiederholte Versionen des Folgenden)
1 Byte Subblockkennung (00 – Ring Binary, 01 – Ring Smart Msg, 20 – Übergabe-URL)
2 Byte Länge
N Byte Daten

Eine andere Ausführungsform des neuen Formats lautet:

8 Byte Kennung (im Besonderen "NMP-CMT0"-Übergabeauftrag)
2 Byte Länge == 0
2 Byte reserviert == 0

Dieses neuartige Format unterstützt mehrere Inhaltsarten in der gleichen Datei. Daher können in einer Datei fünf Ruftöne heruntergeladen werden, oder ein Rufton und ein Bitmap. Dies gestattet, daß Multimedien wie etwa Nachrichtenprofilthemen heruntergeladen werden.
4, die aus 4A und 4B besteht, ist ein Ablaufdiagramm, das verschiedene Schritte zeigt, die nach einer Ausführungsform der vorliegenden Erfindung unternommen werden sollen. 5 ist ein Sitzungsdiagramm, das den Fluß zwischen den verschiedenen Netzeinheiten zeigt. Die Bezugnahme auf die Schritte in 4 wird in 5 wiederholt, um den Fluß von Einheit zu Einheit zu zeigen.
Unter Bezugnahme auf 4A und 5 beginnt das System mit Schritt 4000. In Schritt 4010 fordert der Benutzer eines Geräts wie etwa einer Mobilstation 100 von 1 (500 in 5) durch Eingabe des URL des Medienservers eine Hauptrufmelodienkartenauswahl von einem Rufmelodien- oder Medienserver 530 an. Der URL kann auch aus einer vorgespeicherten Liste von URLs, die in der Technik als Lesezeichen oder Favoriten bezeichnet wird, ausgewählt werden. In der vorliegenden Ausführungsform kann dem Benutzer ein besonderes Menü an der Anzeige geboten werden, wenn der Einschaltknopf der Mobilstation gedrückt wird. In diesem Fall wurde der URL bereits in der Mobilstation gespeichert und ruft das Drücken einer Auswahl in diesem besonderen Menü den Browser auf, der den gespeicherten URL verwendet.
Das Trägernetz (CN) 510 leitet die Anforderung in Schritt 4020 über einen WAP-Übergang oder dergleichen durch das Internet zum Medienserver 530. Der HTTP-Datenkopf enthält die mobile Kennungsnummer (MIN) der Mobilstation 500.
Der Medienserver 530 kann ein Server für eine Copyrightfreigabestelle wie etwa BMI sein. Der Medienserver kann im Besitz eines Internetdiensteproviders (ISP) oder eines Trägernetzes stehen. Der Medienserver kann auch im Besitz einer Plattenfirma oder einer Copyrightfreigabestelle wie etwa BMI stehen. In der bevorzugten Ausführungsform ist der Medienserver Teil des Club-Nokia-Netzes (www.clubnokia.com).
In Schritt 4020 hat der Medienserver 530 die Anforderungen empfangen und liefert er eine Haupt-HDML-Kartenauswahl, die aus Links besteht, welche der Mobilstation 500 Rufmelodien oder andere Medienkategorien definiert. Dies wird durch das Trägernetz über den WAP-Übergang geleitet. Die Kategorien werden an der Anzeige 110 (siehe 1) der Mobilstation 500 (100 in 1) gezeigt, siehe Schritt 4030. Der Benutzer kann dann in Schritt 4040 eine Medienkategorie wählen. Zum Beispiel kann der Benutzer an Filmmelodien/Werbemelodien interessiert sein, und wählt diese Kategorie. Das Trägernetz leitet die Anforderung für die Kategorie über den WAP-Übergang oder dergleichen durch das Internet zum Medienserver (Schritt 4050). Erneut weist der HTTP-Datenkopf die MIN der Mobilstation auf.
In Schritt 4060 liefert der Medienserver 530 auf Basis der Kategorie, die durch den Benutzer in Schritt 4040 ausgewählt wurde, eine HDML-Kartenauswahl, die aus besonderen Links zu den Rufmelodien besteht. Erneut wird diese in der bevorzugten Ausführungsform durch das Trägernetz geleitet. In Schritt 4070 wählt der Benutzer eine bestimmte Rufmelodie. 6A ist ein Beispiel einer typischen Anzeige zur Auswahl einer Melodie. Die Figur zeigt "5 Austin Powers" als die durch den Benutzer gewählte Auswahl. Die Liste der Melodien für diese Kategorie wird an der Anzeige 110 der Mobilstation 100 gezeigt. Der Benutzer kann die Rolltaste 130 und die Funktionstasten 120A oder 120B verwenden, um die Auswahl zu treffen. Alternativ kann der Benutzer die Zahlentaste "5" 145 drücken, um die Auswahl zu treffen.
Die Auswahl weist einen URL auf, der an eine Aktivserverseite (ASP) gebunden ist. Dieser wird durch das Trägernetz 510 über den WAP-Übergang durch das Internet 520 zum Medienserver geleitet (Schritt 4080). Der HTTP-Datenkopf weist die MIN der Mobilstation auf.
In Schritt 4090 erzeugt der Medienserver 530 unter Verwendung der ASP eine Datenbankaufzeichnung und eine Vorgangsnummer, die die bestimmte Mobilstationsanforderung auf Basis der Zeit und der MIN widerspiegelt. Der Medienserver sendet die Melodiendatei und einen (unter Verwendung von ASP, JAVA Applet und dergleichen) programmatisch erzeugten Antwort-URL-Datenkopf unter Verwendung wie oben beschriebener bestimmter MIME-Typen im richtigen Format zum Handapparat. Dies erfolgt in Schritt 4100 und wird in Schritt 4110 durch das Trägernetz geleitet.
In Schritt 4120 erkennt die Mobilstation den MIME-Inhalt und gibt sie die Daten zur Geräteschicht der Mobilstation weiter. Die Systembeschreibung geht in 4B weiter. In Schritt 4130 in 4B verifiziert die Mobilstation das Datenformat und speichert sie die Datei in den temporären Direktzugriffsspeicher (RAM), z.B. den Speicher 180 oder den Cache des Prozessors 170 in 1. Die Datei kann einen Antwort-URL mit der Vorgangsnummer, den Melodie/Bitmapdaten und einer Kennzeichenmarkierung enthalten.
Der Benutzer wird dann über die Anzeige an der Mobilstation abgefragt. (Schritt 4140). Der Benutzer kann "zurücktreten" und die Medien löschen (Schritt 4143). In diesem Fall würde der Vorgang beendet sein und wird der Medieninhalt dem Benutzer nicht verrechnet werden. Der Benutzer kann auch ohne vorheriges Ansehen oder Hören des Ruftons und/oder Ansehen des Bilds speichern, 4145. An diesem Punkt wird der Benutzer erneut nach einer Entscheidung gefragt (4140):
Löschen (4143);
neuerlich Hören (4145); oder
Annehmen der Medien und Fortfahren mit dem Vorgang (4147).
6B zeigt ein Beispiel einer typischen Anzeige, die eine Auswahl zeigt, die dem Benutzer an der Anzeige 110 der Mobilstation 100 angeboten wird. Die Anzeige gibt an, daß ein neuer Rufton (oder eine neue Rufmelodie) empfangen wurde. Der Benutzer kann die Melodie durch Drücken der Funktionstaste 120A hören oder die Melodie durch Drücken der Funktionstaste 120B speichern.
Unter erneuter Bezugnahme auf 4B erzeugt die Mobilstation in Schritt 4150 unter Verwendung des im RAM gespeicherten URL ein HTTP-"GET"-Dienstfunktionselement. Dadurch wird die Annahme der Medien (Rufmelodie oder Bild) angezeigt. Das Trägernetz leitet die Annahmenachricht über einen WAP-Übergang zum Medienserver 530 (Schritt 4160). Der HTTP-Datenkopf enthält die MIN der Mobilstation.
Der Medienserver 530 macht die Aufzeichnung in Schritt 4170 unter Verwendung von Informationen aus der Nachricht wie etwa der Vorgangsnummer, der MIN, oder einer Kombination von Informationen ausfindig. Der Medienserver 530 erzeugt eine Benutzungsaufzeichnung und sendet diese zum Träger, der den Vorgang am Abrechnungsserver 540 speichern kann. In einer anderen Ausführungsform kann der Medienserver auch als ein Abrechnungsagent dienen. Doch in der bevorzugten Ausführungsform nimmt der Träger die Verrechnung mit dem Benutzer durch eine Rechnung an den Benutzer vor, die andere Belastungen oder Gutschriften für Dienste und Inhalte enthält.
Läßt man den Träger die Verrechnung handhaben, gestattet dies, daß kleine Vorgänge, die Bruchteile von Cents enthalten können, für eine bequeme Verrechnung/Gutschrift und Zahlung mit anderen Gebühren kombiniert werden. Der Träger kann die Abrechnung "betriebsintern" durchführen oder sich auf Abrechnungsagenten oder andere dritte Parteien verlassen, die Abrechnungssysteme entwickelt haben. Beispiele derartiger Systeme sind das Kenan-System von Lucent (www.kenan.com; Cambridge, Massachusetts) oder das Ensemble von Amdocs (www.amdocs.com, Stamford, Connecticut). Die Abrechnung von Copyrightgebühren und anderen Kosten, die mit der Inhaltsbereitstellung verbunden sind, können durch das Abrechnungssystem durchgeführt werden.
Es kann Fälle geben, in denen der Benutzer fähig sein kann, auf Basis der gewählten Rufmelodie und jedes Mal, wenn die Melodie gespielt wird, eine Gutschrift auf seine Rechnung zu erhalten. Zum Beispiel kann der Benutzer wählen, ein Thema aus einem beworbenen Film oder eine Werbemelodie für ein beworbenes Produkt, z.B. Coca-Cola, herunterzuladen. Der Werber kann dem Benutzer Gutschriften auf seine Rechnung oder digitales Bargeld oder Gutscheine, die zum Kauf eines Artikels verwendbar sind, bereitstellen. Digitales Bargeld und ein Verfahren für Mobilstationszahlungssysteme werden durch die am 20. Juni 2000 erteilte US-Patentschrift Nr. 6,078,806 bereitgestellt, die eine Fortführung der am 7. Februar 1996 eingereichten US-Seriennummer 08/597,845 und nunmehrigen, am 23. März 1999 erteilten Patentnummer 5,887,266 ist, wobei beide mit METHOD FOR USING APPLICATIONS IN A MOBILE STATION, A MOBILE STATION AND A SYSTEM FOR EFFECTING PAYMENTS betitelt sind, an Heinonen et al. ausgegeben sind, und dem Inhaber der vorliegenden Erfindung übertragen sind. Der Werber erhält Präsenz, da jeder in Hörweite des Benutzers die Werbemelodie hören wird. Ein herunterladbares Bild einer Firmenmarke wird ebenfalls Werbung für den Werber bereitstellen. Das Bild kann an der Anzeige 110 oder unter Verwendung von Technologie wie sie von E-Ink Corporation (Cambridge, Mass.) erhältlich ist, an der Abdeckung selbst dargestellt werden.
Anstelle eines Pull-Vorgangs, der hierin beschrieben wurde, bei dem der Benutzer den Inhalt vom Medienserver zieht, kann ein Push-Vorgang verwendet werden. Als ein Beispiel würden Werber in einer Bluetooth-befähigten Mobilstation fähig sein, dem Benutzer Ruftöne anzubieten. Informationen in Bezug auf Bluetooth können unter www.bluetooth.com gefunden werden.
Unter erneuter Bezugnahme auf 4B und 5 erzeugt der Medienserver 530 in Schritt 4190 unter Verwendung des oben beschriebenen neuartigen MIME-Typs auch eine Bestätigungsantwortnachricht an die Mobilstation. Das Trägernetz leitet diese Nachricht durch einen WAP-Übergang oder dergleichen zur Mobilstation (Schritt 4200).
Nach dem Empfang der Bestätigungsnachricht wird die Mobilstation die Mediendatei (Melodie/Bitmap und Kennzeichen) im nichtflüchtigen RAM speichern. 6C zeigt eine typische Anzeige, die den Benutzer informiert, daß die Rufmelodie "gespeichert" wurde. Der Benutzer muß dann unter Befolgung des Vorgangs, der durch die benutzerspezifischen Anpassungsmerkmale, die durch die Mobilstation angeboten werden, bereitgestellt wird, die Rufmelodie oder das Bild auswählen.
Der Antwort-URL kann auch im nichtflüchtigen RAM gespeichert werden. Der URL kann verwendet werden, um es jedes Mal aufzuzeichnen und dem Trägerabrechnungsserver oder Medienserver rückzumelden, wenn eine Melodie gespielt wird. Wie oben beschrieben kann das Spielen einer Melodie den Empfang von digitalem Bargeld oder einer Gutschrift zur Rechnung des Benutzers auslösen. 7 zeigt eine Tonaktivierungssequenz 700. Wenn der Ton einen damit verbundenen Antwort-URL aufweist, kann ein Funktionsruf 710 ausgelöst werden, um den WAP-Browser zu aktivieren und die Verwendung des Tons einem Verrechnungsserver zu melden, der eine Gutschrift auf das Benutzerkonto durchführen kann. Dieser Vorgang kann auch dazu dienen, Zahlungen von Gebühren pro Verwendung für Medien zu behandeln.
Die Gutschriften können an der Mobilstation selbst geführt werden. Digitales Bargeld oder Vorgangsgutschriftenwertinformationen können, z.B. als ein Codewort, im Speicher der Mobilstation gespeichert werden. Digitales Bargeld und ein Verfahren zum Durchführen von Zahlungen werden durch die am 20. Juni 2000 erteilte US-Patentschrift Nr. 6,078,806 bereitgestellt, die eine Fortführung der am 7. Februar 1996 eingereichten US-Seriennummer 08/597,845 und nunmehrigen, am 23. März 1999 erteilten, Patentnummer 5,887,266 ist, wobei beide mit METHOD FOR USING APPLICATIONS IN A MOBILE STATION, A MOBILE STATION AND A SYSTEM FOR EFFECTING PAYMENTS betitelt sind, an Heinonen et al. ausgegeben sind, und dem Inhaber der vorliegenden Erfindung übertragen sind.
Die obigen Vorgänge können unter Verwendung einer gesicherten Verbindung durchgeführt werden. Derartige Verbindungen sind in der Technik bekannt. Ein Beispiel von gesicherten Kommunikationen in einem Telekommunikationssystem wird durch die am 22. Juni 1999 an Herlin et al. ausgegebene US-Patentschrift Nr. 5,915,021, die dem Inhaber der vorliegenden Erfindung übertragen ist, gelehrt.
Wie Fachleute erkennen werden, können die in der vorliegenden Anmeldung beschriebenen innovativen Konzepte über einen ungeheuren Bereich von Anwendungen abgewandelt und verändert werden, und demgemäß wird der Umfang des patentierten Gegenstands nicht durch irgendeine der gegebenen besonderen beispielhaften Lehren beschränkt. Der Umfang der Erfindung ist durch die beiliegenden Ansprüche definiert.

Claims

Verfahren zum Erledigen von Medieninhalten in einem drahtlosen Handapparat, der zur Kommunikation in einem Netz gestaltet ist, umfassend die folgenden Schritte: Anfordern (4010, 4020) eines Medieninhalts durch Senden einer Nachricht mit einem Datenkopf, der eine erste Kennungsnummer umfaßt; Empfangen (4030) einer Nachricht, die den Medieninhalt, einen Antwort-URL (universellen Quellenlokalisierer), welcher einen Server identifiziert, und eine Vorgangskennung umfaßt; Speichern (4130) der Medien in einem Zwischenspeicher; Senden (4150, 4160) eines Dienstfunktionselements mit zumindest der ersten Kennungsnummer zum Server, der durch den URL identifiziert ist; Empfangen (4200) einer Bestätigungsnachricht, die eine Erlaubnis angibt, die Medien vom Server, der durch den URL identifiziert ist, zu speichern; Speichern (4210) der Medien in einem Dauerspeicher nur dann, wenn die Erlaubnis zum Speichern empfangen wurde.
Verfahren zum Erledigen von Medieninhalten in einem Server, der zur Kommunikation in einem Netz gestaltet ist, umfassend die folgenden Schritte: Bereitstellen (4030) mehrerer Medienangebote an eine drahtlose Vorrichtung im Netz; Empfangen (4050) einer Auswahl aus den mehreren Medienangeboten von der Vorrichtung; Erzeugen (4090) einer Datenbankaufzeichnung; Erzeugen (4090) einer Vorgangsnummer; Erzeugen (4090) eines URL; Senden (4100, 4110) einer Nachricht an die Vorrichtung, welche Nachricht den URL und den Medieninhalt umfaßt, wobei die Vorrichtung ein Dienstfunktionselement an den URL senden muß und eine Bestätigungsnachricht empfangen muß, die eine Erlaubnis zum Speichern der Medien angibt, bevor der Medieninhalt im Dauerspeicher der Vorrichtung gespeichert werden kann.
Drahtloser Handapparat (100), der zur Kommunikation in einem Netz gestaltet ist, wobei der Handapparat dazu gestaltet ist, Medieninhalte zu erledigen, und Mittel umfaßt, um durch Senden einer Nachricht mit einem Datenkopf, der eine erste Kennungsnummer umfaßt, einen Medieninhalt anzufordern; eine Nachricht zu empfangen, die den Medieninhalt, einen Antwort-URL (universellen Quellenlokalisierer), welcher einen Server identifiziert, und eine Vorgangskennung umfaßt; die Medien in einem Zwischenspeicher zu speichern; ein Dienstfunktionselement mit der ersten Kennungsnummer an den durch den URL identifizierten Server zu senden; die Medien nur dann in einem Dauerspeicher zu speichern, wenn eine Erlaubnis zum Speichern empfangen wurde.
Servercomputer, der zur Kommunikation in einem Netz gestaltet ist, wobei der Server dazu gestaltet ist, Medieninhalte zu erledigen, und Mittel umfaßt, um den Computer anzuweisen, einer drahtlosen Vorrichtung mehrere Medienangebote bereitzustellen; den Computer anzuweisen, von der Vorrichtung eine Auswahl aus den mehreren Medienangeboten zu empfangen; den Computer anzuweisen, eine Datenbankaufzeichnung zu erzeugen; den Computer anzuweisen, eine Vorgangsnummer zu erzeugen; den Computer anzuweisen, einen URL zu erzeugen; und den Computer anzuweisen, eine Nachricht zur Vorrichtung zu senden, die den URL und die Medien umfaßt, wobei die Vorrichtung ein Dienstfunktionselement an den URL senden muß, bevor der Medieninhalt im Dauerspeicher der Vorrichtung gespeichert werden kann.
Computerprogramm, das eine Netzwerkeinheit befähigt, Medieninhalte zu erledigen, umfassend einen computerlesbaren Code, der einem Computer befiehlt, ein Verfahren nach Anspruch 1 oder 2 durchzuführen.
Computerprogramm nach Anspruch 5, das auf einem greifbaren Medium gespeichert ist, welches aus einer Gruppe gewählt wird, die aus einer Festplatte, einer CD-ROM, einer DVD, einer Floppy-Disk, und einem Flash-Speicher besteht.