DE60310812T2

DE60310812T2 - Domänebasierte Verwaltung zur Verteilung von digitalen Inhalt von mehreren Lieferanten an mehreren Drahtloserdienstekunden

Info

Publication number: DE60310812T2
Application number: DE60310812T
Authority: DE
Inventors: Rikard M. Santa Cruz Kjellberg; Sheng Cupertino Liang; Tomas G. Foster City Lund; William San Mateo Chan
Original assignee: Openwave Systems Inc
Current assignee: Great Elm Group Inc
Priority date: 2002-06-28
Filing date: 2003-06-30
Publication date: 2007-10-31
Anticipated expiration: 2023-07-01
Also published as: DE60310812D1; EP1376438A1; USRE43113E1; ATE350725T1; US7299033B2; EP1376438B1; US20040054787A1

Description

BEREICH DER ERFINDUNG
Wenigstens eine Ausgestaltung der vorliegenden Erfindung betrifft Systeme und Verfahren zum Bereitstellen von digitalem Inhalt für die Abonnenten von Drahtlosdiensten und spezieller die Erleichterung der Verwaltung und Zuführung von digitalem Inhalt von mehreren Inhaltsanbietern zu mehreren Drahtlosedienste-Abonnenten in mehreren Domains.
HINTERGRUND
Persönliche mobile Kommunikations-/Rechengeräte, wie z.B. Zellulartelefone, Personal Digital Assistants (PDAs) und Zweiweg-Funkrufgeräte, sind in vielen Ländern weit verbreitet. Diese Geräte werden hierin kollektiv als „mobile Geräte" oder „drahtlose Geräte" bezeichnet. Der derzeitige Stand der Technik von mobilen Geräten ist weit über den ihrer Vorgänger hinaus fortgeschritten. So wurden beispielsweise frühe Zellulartelefone mit Analogsignalen benutzt, um über drahtlose Kommunikationsnetze (oder einfach „Funknetze") zu kommunizieren, und waren nichts weiter als Mobiltelefone. Heutige Zellulartelefone sind typischerweise alle digital und bieten viele weitere Funktionen als nur Telefonie. So ermöglichen es z.B. viele Mobiltelefone (und andere mobile Geräte) der neuesten Generation ihren Benutzern, Spiele zu spielen, auf World Wide Web Seiten zuzugreifen, Emails auszutauschen, Dateien auszutauschen und herunterzuladen, SMS-(Short Messaging Service)-Mitteilungen auszutauschen sowie Videos zu senden und zu empfangen.
Mit neuen mobilen Geräten, die einen breiteren Fähigkeitsbereich bieten, ist unter den Benutzern dieser Geräte (d.h. Drahtlosdienste-Abonnenten) die Nachfrage nach neuen und interessanten Typen von digitalem Inhalt gestiegen, der mit diesen mobilen Geräten benutzt werden kann, wie z.B. Spiele und andere Anwendungen, Bilder, Klingeltöne, Screensaver, Tapeten usw. Neuere mobile Geräte sind zwar beim Kauf durch den Abonnenten bereits mit bestimmten digitalen Produkten ausgestattet, aber es ist wünschenswert, es dem Abonnenten zu gestatten, weitere digitale Produkte für die Verwendung in seinen mobilen Geräten zu erwerben, sobald solche Produkte erhältlich sind. Diese Möglichkeit existiert zwar bereits, aber derzeitige Abonnenten erwerben digitalen Inhalt direkt von den Inhaltsanbietern (gewöhnlich über das Funknetz und das Internet). Dieser Vorgang ist dann unpraktisch, wenn ein Abonnent verschiedene Digitalinhaltsartikel von unterschiedlichen Anbietern erwerben möchte, da der Abonnent zu den Websites verschiedener Anbieter gehen muss. Daher ist es weiter wünschenswert, Abonnenten viele verschiedene Typen von digitalem Inhalt gleichzeitig über einen zentralen „Laden" verfügbar zu machen.
Vom Standpunkt des Inhaltsanbieters aus gesehen, ist ein weiteres Hindernis für eine effiziente Verteilung von digitalem Inhalt die Tatsache, dass unterschiedliche mobile Geräte häufig verschiedene Inhaltspaketformate und Provisioning-Protokolle erfordern. Um einen bestimmten Digitalinhaltsartikel mehreren Mobilgeräten verfügbar zu machen, die unterschiedliche Provisioning-Modelle unterstützen, stellt ein digitaler Inhaltsanbieter normalerweise diesen Inhaltsartikel mehrere Male bereit und verpackt ihn für jedes der Provisioning-Modelle anders. So würde beispielsweise ein Bild, das zu Nokia-COD^(TM) und Sprint-GCD OTA^(TM) Telefonen geliefert werden soll, zweimal angeboten, für jede dieser beiden Lieferarten speziell verpackt. Es ist für die Anbieter von digitalem Inhalt äußerst aufwändig, den von ihnen erzeugten digitalen Inhalt auf eine Weise zu verpacken und anbieten zu müssen, die für alle Geräte auf dem Markt geeignet ist. Darüber hinaus ist es für Inhaltsanbieter schwierig, mit den ständigen Änderungen der Gerätekapazitäten für die vielen Mobilgeräte auf dem Markt Schritt zu halten. Folglich gibt es häufig einen Abstand zwischen der Interoperabilität eines bestimmten digitalen Produkts und der Wirksamkeit seiner Nutzung auf einem Gerät. Daher besteht das Problem, es digitalen Inhaltsanbietern auf effiziente Weise zu ermöglichen, viele verschiedene Typen von digitalem Inhalt an Abonnenten zu verteilen, die viele verschiedene Typen von mobilen Geräten benutzen.
Ein verwandtes Problem ist, Abonnenten diesen von ihnen erworbenen digitalen Inhalt zu berechnen. In einem bekannten System kann der drahtlose Träger Verbindung mit einem externen Gebührenberechnungssystem haben und speist dieses System mit Gebührenberechnungsevents, wenn ein Abonnent eine zahlungspflichtige Aktion durchführt. Dieses Szenario geht jedoch davon aus, dass alle Abonnenten zu einer einzigen Organisation gehören, die auch Eigentümer des Gebührenberechnungssystems ist. Ferner geht es davon aus, dass eine einzige Währung verwendet wird. Aber viele multinationalen Organisationen haben eine Mutterorganisation mit Tochtergesellschaften in vielen Ländern. Unterschiedliche Länder haben verschiedene Währungen, Steuern und andere Gebühren. Jede Tochtergesellschaft kann ihre eigene Support- /Geschäftsinfrastruktur führen, um lokale Vorschriften und Gebräuche umzusetzen, besonders in Bezug auf den Gebührenberechnungsablauf. Demzufolge muss das System des Trägers in der Lage sein, Gebührenberechnungsevents zu erzeugen und sie zum richtigen externen Gebührenberechnungssystem zu leiten. Ferner muss es dem Kunden für jeden Dienst eine Gebührenrechnung präsentieren können, in der richtigen Währung und auf eine solche Weise ausgedrückt, wie dies unter Anbetracht der örtlichen Steuern, Gebühren und sonstigen Vorschriften geeignet ist.
Eine Art und Weise, dieses Problem anzugehen, die dies aber nur zum Teil löst, besteht in der Verwendung von Kreditkartensystemen. Bei diesem Szenario agiert das Kreditkartenunternehmen als Mittler im Gebührenberechnungsprozess. Dieser Ansatz konsolidiert sämtliche Gebührenberechnungen an einer Stelle. Die Abrechnung erfolgt gegen eine Gebühr zwischen dem Produkt/Dienste-Anbieter und dem Abonnement-Provider (dem drahtlosen Träger). Dieser Ansatz berücksichtigt jedoch keine Währungen, Steuern, Gebühren und Vorschriften wie oben erwähnt.
Die WO 98 35469 (Sabre Group Inc.) offenbart ein Informationssammlungs- und -synthetisierungssystem, das den Zugang eines Benutzers zu lokalen Informationen oder zu auf einem Netzwerk verteilten Informationen erleichtern soll. Benutzerkonten und sonstige benutzerspezifischen Informationen werden in einer Benutzerprofildatenbank gespeichert.
Die US 2001/037192 (Shimamoto et al.) befasst sich im Wesentlichen mit der Lösung bestimmter Probleme in Verbindung mit E-Commerce auf dem World Wide Web. Sie betrifft insbesondere ein System, das automatisch eine Sprache einer grafischen Benutzeroberfläche wählen kann. Es heißt, das System variiere auch automatisch die Bedingungen der Bereitstellung eines Dienstes und des Verteilens von Benutzerregistrierung und -verwaltung unter mehreren Personen.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Bereitstellen von Zugang zu Inhalt für die Verwendung in drahtlosen Kommunikationsgeräten bereitgestellt, wobei das Verfahren die folgenden Schritte umfasst:
Betreiben eines Serversystems zum Speichern von Domaindaten, die mehrere Domains definieren, wobei jede Domain eine andere Teilmenge aus einer Mehrzahl von Drahtlosdienste-Abonnenten repräsentiert, wobei jede der Domains ferner eine Gebührenberechnungsbeziehung zwischen einer Geschäftsentität und der entsprechenden Teilmenge aus der Mehrzahl von Drahtlosdienste-Abonnenten repräsentiert, und wobei die mehreren Domains ferner einen Teil von Inhalt, der für die Verwendung in drahtlosen Kommunikationsgeräten ausgelegt ist, zu dem Zweck repräsentieren, den Inhalt den Drahtlosdienste-Abonnenten verfügbar zu machen;
Betreiben des Serversystems, um es zu ermöglichen, dass mehrere Inhaltsanbieter auf dem Serversystem Inhalt für die Verwendung in drahtlosen Kommunikationsgeräten über ein Computernetz veröffentlichen, so dass der Inhalt für die mehreren Drahtlosdienste-Abonnenten zugängig ist; und
Betreiben des Serversystems, um es Drahtlosdienste-Abonnenten in jeder der mehreren Domains zu ermöglichen, Inhalt über wenigstens ein drahtloses Netz zu erwerben und den erworbenen Inhalt auf zugehörigen drahtlosen Kommunikationsgeräten zu benutzen.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein System bereitgestellt, um einer Mehrzahl von Drahtlosdienste-Abonnenten digitalen Inhalt von einer Mehrzahl von Digitalinhaltsanbietern unter Verwendung mehrerer drahtloser Kommunikationsgeräte bereitzustellen, wobei das System Folgendes umfasst:
einen Domainmanager zum Führen einer Assoziation zwischen jedem der Drahtlosdienste-Abonnenten und einer von mehreren Domains, zu der die mehreren Abonnenten gruppiert sind, wobei jede Domain eine andere Teilmenge der mehreren Drahtlosdienste-Abonnenten repräsentiert, wobei jede der Domains ferner eine Gebührenberechnungsbeziehung zwischen einer Geschäftsentität und der entsprechenden Teilmenge der mehreren Drahtlosdienste-Abonnenten repräsentiert, und wobei die mehreren Domains ferner einen Teil von Inhalt, der für die Verwendung in drahtlosen Kommunikationsgeräten ausgelegt ist, zu dem Zweck repräsentieren, den Inhalt den Drahtlosedienste-Abonnenten verfügbar zu machen;
einen Produktmanager zum Verwalten der Veröffentlichung von digitalem Inhalt für die Verwendung in drahtlosen Kommunikationsgeräten auf dem System durch die mehreren Digitalinhaltsanbieter;
einen Liefermanager zum Verwalten der Lieferung eines Digitalinhaltsartikels für die Verwendung in einem drahtlosen Kommunikationsgerät zu einem drahtlosen Kommunikationsgerät eines anfordernden Abonnenten über ein drahtloses Netz in Verbindung mit einer empfangenen Anforderung für den Digitalinhaltsartikel; und
einen Zahlungsmanager zum Ausführen eines Zahlungsprozesses, um den Digitalinhaltsartikel dem anfordernden Abonnenten zu berechnen.
Weitere Merkmale der vorliegenden Erfindung gehen aus den Begleitzeichnungen und aus der nachfolgenden ausführlichen Beschreibung hervor.
Weitere Ausgestaltungen gemäß der vorliegenden Erfindung sind wie in den Unteransprüchen dargelegt.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Eine oder mehrere Ausgestaltungen der vorliegenden Erfindung werden beispielhaft und nicht begrenzend in den Figuren der Begleitzeichnungen illustriert, bei denen gleiche Bezugsziffern gleiche Elemente anzeigen. Dabei zeigt:
1 die Beziehung zwischen dem Download-Manager, Inhaltsanbietern und Abonnenten;
2 eine Netzwerkarchitektur, in der ein erfindungsgemäßer Download-Manager eingesetzt werden kann;
3 eine schematische Darstellung der Komponenten des Download-Managers;
4 die Komponenten des Gerätefähigkeitenmanagers;
5 die Beziehung zwischen einem Produkteintrag und Implementationen des Produkts im Produktkatalog;
6 die Beziehung zwischen einem Produkt und seinen Implementationen;
7 die Art und Weise, wie verschiedene Datenelemente im Gebührenberechnungsprozess benutzt werden;
8 einen vereinfachten Prozess, mit dem ein Produkt im Produktkatalog auf eine Weise aufgeführt werden kann, die eine gerätespezifische Produktentdeckung und -bereitstellung erleichtert;
9 einen Prozess, mit dem der Produktkatalog einem Abonnenten angezeigt wird;
10 einen Prozess, mit dem ein Produkt unter Verwendung des Download-Managers gekauft werden kann;
11 die Trennung zwischen Inhalt und dessen Bereitstellung innerhalb des Download-Managers;
12 einen Vorgang, mit dem ein Produkt in einem Client-Gerät mit einem geeigneten aus verschiedenen Provisioning-Protokollen bereitgestellt wird;
13 ein Beispiel für die Software-Einsatzarchitektur des Download-Managers; und
14 die Hardware-Architektur eines Computersystems, in dem der Download-Manager implementiert werden kann.
AUSFÜHRLICHE BESCHREIBUNG
Es werden nachfolgend ein System und ein Verfahren zum effizienten Verwalten der Veröffentlichung, des Kaufs und der Lieferung von digitalem Inhalt von mehreren Inhaltsanbietern für mehrere Drahtlosedienste-Abonnenten in mehreren Domains beschrieben. Die in dieser Beschreibung verwendeten Begriffe „digitaler Inhalt", „digitales Produkt", „Inhalt" und „Produkt" sind untereinander austauschbar und bedeuten Software und/oder Daten, die Dinge wie Spiele und andere Anwendungen, Applets oder dergleichen ausgestalten; Bilder; Screensavers; Tapete; Klingeltöne usw., besonders (aber nicht unbedingt ausschließlich) solche, die für die Verwendung in mobilen Geräten wie Zellulartelefonen, Personal Digital Assistants (PDAs) und anderen drahtlosen/mobilen Geräten mit kleiner Stellfläche ausgelegt sind. Der Einfachheit halber sollen die verwendeten Begriffe „Einkauf" oder „Kauf" jeden tatsächlichen Kauf oder jede andere konventionelle Art und Weise bedeuten, in der ein Abonnent Rechte zur Verwendung von digitalem Inhalt (z.B. durch Erwerben einer Lizenz) erwerben kann.
Überblick
Wie nachfolgend ausführlicher beschrieben wird, wird ein System, das die Veröffentlichung, den Kauf und die Lieferung von digitalem Inhalt verwaltet, in einem Netzwerkserversystem implementiert, das ein oder mehrere Servercomputersysteme auf einem Netzwerk beinhaltet. Das Serversystem beinhaltet einen Anwendungsserver, der nachfolgend als „Download-Manager" bezeichnet wird. Digitalinhaltsanbieter können ihre Produkte mit dem Download-Manager über ein Computernetz wie z.B. das Internet veröffentlichen und verwalten und können ihre Produkte Drahtlosdienste-Abonnenten durch den Download-Manager zwecks Kaufs oder Lizensierung verfügbar machen. Abonnenten können über Drahtlosnetze auf das Serversystem zugreifen, um Rechte zum Herunterladen und Benutzen des digitalen Inhalts auf ihren drahtlosen Kommunikationsgeräten zu kaufen.
1 illustriert die Beziehung zwischen dem Download-Manager, Inhaltsanbietern und Drahtlosedienste-Abonnenten (Benutzer von mobilen Geräten). Der Download-Manager 1 dient als Mittler zwischen mehreren Inhaltsanbietern 2 (z.B. 2A, 2B usw.) und mehreren Kunden (z.B. 3A, 3B usw.), z.B. Drahtlosdienste-Abonnenten, die zu mehreren „Domains" gehören. Im Versorgungskettenprozess zur Verteilung von digitalem Inhalt fügt ein Inhaltsanbieter 2 dem vom Download-Manager 1 verwalteten Satz von Produkten (d.h. Produkte „im Laden") ein digitales Produkt hinzu. Der Anbieter 2 assoziiert dann verschiedene Attribute mit dem Produkt. Wenn das Produkt dem Produktladen submittiert wurde, dann verifiziert ein mit dem Download-Manager 1 assoziierter Produktadministrator dessen Qualität und ermittelt, ob es den Kunden 2 angeboten oder zurückgewiesen werden soll. Wenn das Produkt zugelassen wird, dann können Kunden 2 das Produkt kaufen, indem sie von ihren Client-Geräten aus auf den Download-Manager 1 zugreifen.
Zur Erleichterung der Beschreibung wird nachfolgend davon ausgegangen, dass die Kunden Benutzer von mobilen Geräten und daher Abonnenten von Drahtlosdiensten sind; somit werden Kunden hierin nachfolgend als „Abonnenten" bezeichnet.
Domains und Partnermanagement
Unter anderen vorteilhaften Merkmalen erleichtert der Download-Manager 1 das Partnermanagement. Der hierin verwendete Begriff „Partner" ist eine Entität, die eine Beziehung zu einem Abonnenten für die Zwecke der Lieferung von digitalen Produkten, Gebührenberechnung, Rückgaben usw. unterhält. So kann ein Partner beispielsweise ein Internet-Portal, ein Internet Service Provider (ISP), ein Drahtlosträger, ein Applikationsservice-Anbieter (ASP) usw. sein. Ein Partner bestimmt auch eine Reihe von Inhaltsanbietern, um Produkte zum Produktladen hinzuzufügen. Partnermanagement ist das Konzept, die Verantwortlichkeiten für verschiedene Teile der Digitalprodukt-Versorgungskette unterschiedlichen Benutzerkategorien zuweisen zu können.
Die Entitäten „im Laden" (vom Download-Manager 1 verwaltet), die zu einem Partner gehören, werden in „Domains" genannte Entitäten unterteilt. Der hierin verwendete Begriff „Domain" ist eine Entität, die im Download-Manager 1 definiert ist und die Gebührenberechnungsbeziehung zwischen einem Partner und einem Satz von Abonnenten sowie eine Partitionierung von Produktraum und administrative Verantwortlichkeiten beschreibt. Als solches kann eine Domain eine Gruppe von Drahtlosdienste-Abonnenten repräsentieren, wie z.B. einen Drahtlosträger oder eine Tochtergesellschaft eines Drahtlosträgers, ein Geschäftsunternehmen oder irgendeine andere definierte Gruppe von Drahtlosdienste-Abonnenten. Der Domain-Manager führt eine Datenbank mit Daten, die die Assoziationen zwischen Domains und Partnern, Administratoren, Abonnenten und Produkten definieren.
Domains erleichtern die ordnungsgemäße Gebührenberechnung für Abonnenten von mehreren Organisationen und/oder mit mehreren Drahtlosträgern (oder anderen Abonnenten-Anbietern), und erleichtern die Darbietung von Produktbeschreibungen für Abonnenten in den Sprachen und Währungen, die für ihre jeweiligen Länder oder Regionen geeignet sind.
Die Domain-Entität wird im Download-Manager 1 benutzt, um andere Entitäten als zu einer Domain 1-zu-1, zu einer Domain 1-zu-viele, viele-zu-viele oder nicht zu einer Domain gehörend zu klassifieren. Im Allgemeinen erfasst eine Domain die folgenden Beziehungen zu den Abonnenten:

1) wie Abonnenten die von ihnen gekauften Produkte berechnet werden und in welcher Währung;
2) zu welchen Benutzergruppen die Abonnenten gehören können;
3) von welchen Produktkategorien die Abonnenten Produkte auswählen können; und
4) welche Produkte für die Abonnenten zugängig sind.

In bestimmten Ausgestaltungen der Erfindung hat eine Domain die folgenden Eigenschaften:

– ein Name (lokalisiert)
– eine Beschreibung (lokalisiert)
– eine URL-(Uniform Resource Locator)-Adresse zu einer Website, die eine weitere Beschreibung der Domain gibt;
– eine Kontaktadresse einschließlich Kontaktpersonen, Kontakttelefonnummern, Telefaxnummern und postalischer Adresse
– die für Gebührenberechnungs- und Anzeigezwecke zu verwendende Währung
– Querverweise auf Handler für verschiedene unterschiedliche Zahlungsmodelle (z.B. Online-Zahlung, Vorauszahlung und Nachzahlung)
– ein Satz von Verweisen auf Bewertungshandler, die für die Anpassung von Produktpreisen verwendet werden.

Die Namen und Beschreibungen haben lokalisierte Werte für den Satz von Sprachen, die im System registriert sind.
Die Unterscheidung zwischen Domain-Entitäten und Nicht-Domain-Entitäten bildet auch die Basis für delegierte Administration. Spezieller, für jede Domain kann die Verantwortlichkeit für die Lieferung von Produkten, die Zulassung oder Rückweisung von Produkten usw. an unterschiedliche Anbieter und Administratoren delegiert werden. So ist jede Domain mit einem Satz von Administratoren assoziiert, die die Produkte im Laden handhaben. In bestimmten Ausgestaltungen der Erfindung beinhalten diese Administratoren einen Systemadministrator, einen Domain-Administrator, einen Produktadministrator und einen Kundendienstadministrator.
Der Systemadministrator ist der Gesamtadministrator für den Download-Manager 1, der neue Domains und ihre jeweiligen Domain-Administratoren erzeugen kann, um bei deren Regulierung zu helfen. Er kann auch Nicht-Domain-Entitäten wie Geräte, Inhaltstypen usw. steuern. Der Domain-Administrator ist der Gesamtadministrator für eine bestimmte Domain. Er hat die Fähigkeit, alle Anbieter und Abonnenten für seine Domain zu verwalten sowie Produkt- und Kundendienstadministratoren für die Domain zu schaffen. Der Produktadministrator ist für die Verwaltung der gesamten Produktlebenszeit für den von den Anbietern der Domain vorgelegten Inhalt verantwortlich. Der Kundendienstadministrator ist für die Verwaltung von zu der Domain gehörenden Abonnenten verantwortlich. Jeder Abonnent gehört nur zu einer Domain und kann nur Produkte für die Domain sehen, zu der er gehört.
Ein Partner bestimmt eine Reihe von Inhaltsanbietern, die Produkte zum Produktladen liefern. Ein Anbieter kann Produkte nur der/den Domain(s) submittieren, zu der/denen er gehört. Die Beziehung zwischen Anbietern und Domains ist viele-zu-viele. Produkte werden für jede Domain separat zugelassen und eingesetzt.
Vom Standpunkt des Inhaltsanbieters aus gesehen können alle Entitäten im Download-Manger 1, die Domain-bezogen sind, nur auf der Basis der Domains gewählt werden, zu denen der Anbieter Produkte liefern kann. So kann beispielsweise ein Anbieter nur aus den Produktkategorien und Lizenzmodellen auswählen, die zu den Domains gehören, für die der Anbieter die Produktlieferungsrechte besitzt. Netzwerkumgebung
2 zeigt eine Netzwerkarchitektur, in der ein erfindungsgemäßer Download-Manager nützlich eingesetzt werden kann. Ein oder mehrere Drahtlosnetze 22 werden durch entsprechende Gateways 23 mit einem Computernetz 24 verbunden. Das Computernetz 24 kann das Internet sein, könnte aber alternativ auch im Wesentlichen jeder andere Computernetztyp sein, wie z.B. ein Unternehmens-Intranet, ein LAN (lokales Netz) usw. oder eine Kombination solcher Netzwerke.
Eine Reihe von mobilen Client-Geräten 21 (z.B. 21A, 21B usw.) sind auf jedem Drahtlosnetz 22 tätig. Eine Reihe von Servern 25 (z.B. 25A, 25B usw.) sind auf dem Computernetz 24 tätig, um eine Reihe verschiedener Dienste für die mobilen Geräte 21 und/oder zu einem oder mehreren nichtmobilen Client-Geräten 29 anzubieten, die mit dem Computernetz 24 verbunden sind. So könnten die Server 25 beispielsweise World Wide Web Server, File-Server, Anwendungsserver usw. beinhalten.
Jedes Gateway 23 wird vom Drahtlosträger des Drahtlosnetzes betrieben, mit dem es direkt verbunden ist. Jedes Gateway 23 bietet eine Schnittstelle zwischen einem bestimmten Drahtlosnetz 22 und dem Computernetz 24 (z.B. dem Internet) und bietet Routing und bei Bedarf eine geeignete Protokollumsetzung und/oder Inhaltstranscodierung. In einigen Fällen kann das Gateway 23 ein alleinstehendes Gerät oder System sein. In anderen Fällen kann das Gateway 3 ein Serversystem mit größeren Fähigkeiten sein, das zusätzliche Wertschöpfungsdienste für Benutzer von Client-Geräten 21 bietet; wie z.B. einen Proxy-Dienst 27, einen Provisioning-Manager 28 usw.
Ein Download-Manager 1 gemäß der vorliegenden Erfindung ist entweder direkt (wie gezeigt) oder indirekt mit dem Computernetz 24 verbunden. Der Download-Manager 1 kann, muss aber nicht, von einem Drahtlosträger betrieben werden.
Download-Manager
3 zeigt schematisch den Download-Manager ausführlicher gemäß bestimmten Ausgestaltungen der Erfindung. In der illustrierten Ausgestaltung beinhalten die Hauptkomponenten des Download-Managers einen Liefermanager 31, einen Produktmanager 32, einen Business- & Operationsmanager 33 und mehrere Protokollhandler 34. Jede dieser Komponenten wird vorzugsweise als Software, Daten oder als eine Kombination aus Software und Daten ausgeführt. In anderen Ausgestaltungen könnten jedoch einige oder alle dieser Komponenten als festverdrahteter Schaltkomplex ausgeführt werden. Der Download-Manager 1 kann auch eine Datenbank 35 mit veröffentlichem Inhalt (wie gezeigt) beinhalten, aber wenigstens ein Teil des veröffentlichten Inhalts könnte stattdessen auch ortsfern gespeichert werden.
Der Produktmanager 32 ist die Schnittstelle des Download-Managers zu den verschiedenen Inhaltsanbietern und bietet zentralisierte Produktkatalogisierung (z.B. ermöglicht es qualifizierten Inhaltsanbietern, Inhalt zur Analyse und Veröffentlichung zu registrieren) und umfassenden Produktlebenszeit-Support (d.h. Management von Submission, Analyse, Zulassung, Veröffentlichung, Verwendung, Wartung und schließlich Deaktivierung von Inhalt). Der hierin verwendete Begriff „Veröffentlichung" bedeutet, dass ein Produkt auf dem Download-Manager Drahtlosdienste-Abonnenten zum Herunterladen auf ihre Client-Geräte verfügbar gemacht wird. Der Liefermanager 31 ist die Schnittstelle des Download-Managers zu den verschiedenen Abonnenten und ist für die Lieferung von gekauftem Digitalinhalt zu Abonnenten verantwortlich, einschließlich des Aufrufs eines Protokollhandlers, der für die Kommunikation mit jedem anfordernden mobilen Gerät geeignet ist. Die Protokollhandler 34 unterstützen mehrere Produktentdeckungsprotokolle und mehrere Produktlieferprotokolle gleichzeitig. Somit beinhalten die Protokollhandler 34 Produktentdeckungshandler (z.B. einen WAP-Handler, einen Web-Handler, einen Motorola Discovery^(TM) Handler) und Produktlieferhandler (z.B. einen MIDP OTA Handler, einen Motorola^(TM) OTA Handler, einen Nokia^(TM) COD OTA Handler). Der Business- & Operationsmanager 33 ist hauptsächlich für die Verwaltung von Domain-Informationen und Prozessen verantwortlich, um Abonnenten gekauften Inhalt zu berechnen. Diese Komponenten werden nachfolgend ausführlich beschrieben.
Wie in 3 gezeigt, beinhaltet der Liefermanager 31 in bestimmten Ausgestaltungen einen Sicherheitsmanager 36, einen Gerätefähigkeitenmanager 37, ein Personal Vault 38, eine Storefront 39 und einen Avisierungsmanager 40. Die Storefront 39 ist eine herkömmliche grafische Benutzeroberfläche, die es Abonnenten ermöglicht, Online-Käufe zu tätigen. Sie kann z.B. mit der Marke eines bestimmten Drahtlosträgers oder einer anderen Geschäftsentität gekennzeichnet werden. Der Sicherheitsmanager 36 ist für die Authentifizierung von Abonnenten und Client-Geräten für die Zwecke des Kaufens von Inhalt verantwortlich und kann vorzugsweise mehrere Authentifizierungsschemata unterstützen, wie z.B. HTTP-gestützte Authentifizierung, MSISDN/NIA-gestützte Authentifizierung usw. Das Personal Vault 38 speichert, auf Einzelabonnentenbasis, Informationen, um das Digitalrechtemanagement (DRM) zu erleichtern, wie z.B. Produktlizenzen und/oder andere „Kauf"-Informationen der von jedem Abonnenten gekauften Produkte. So kann ein Abonnent von einem mobilen Gerät heruntergeladenen Inhalt beseitigen, ohne Rechte an dem Produkt zu verlieren, oder die Produkte im Falle einer Hartrücksetzung eines Gerätes, eines Verlustes usw. auf einem Gerät wiederherstellen.
Der Avisierungsmanager 40 kann Abonnenten unter Verwendung verschiedener Kommunikationskanäle wie z.B. Email, SMS und WAP Push verschiedene Avisierungstypen bereitstellen. Der Avisierungsmanager 40 kann Avisierungen automatisch erzeugen, wie z.B. Avisierungen über neue Produkte oder Produkt-Upgrades, oder als Reaktion auf Befehle von einem Systemadministrator, wie z.B. Kontenavisierungen, Avisierungen über Sonderangebote usw.
Der Gerätefähigkeitenmanager 37 ist für die Geräteerkennung (z.B. Unterstützung der Geräteerkennung durch UAProf mit Profile-Headern und Profile-Diff-Headern), die Gerätefähigkeitenermittlung (z.B. Abrufen von Gerätedeskriptoren unter Einsatz bester Bemühungen und Anhängen von Gerätefähigkeiten an den Session-Kontext) und Gerätefähigkeitenmanagement (z.B. automatisiertes Management von UAProf-fähigen Geräten und Quarantäne von undefinierten oder teildefinierten Geräten) verantwortlich. Wie nachfolgend ausführlicher beschrieben, wird die Erkennung von Geräten und deren Fähigkeiten für eine Reihe verschiedener Zwecke benutzt, wie z.B. zum Filtern des Satzes verfügbarer Produkte, die ein Teilnehmer entdecken kann, wenn er mit dem Download-Manager 1 verbunden ist, um die geeigneten Ausführungen von Produkten, die gekauft werden, und das geeignete Provisioning-Modell zum Bereitstellen eines gekauften Produkts in einem Client-Gerät zu wählen.
4 zeigt die Komponenten des Gerätefähigkeitenmanagers 37 gemäß einer Ausgestaltung der Erfindung. Der Gerätefähigkeitenmanager 37 beinhaltet einen Gerätemanager 41, einen Geräte-Handler-Manager 42, einen Lieferkontext-Cache 43, einen Satz von Geräteerkennungshandlern 44, ein Gerätedatenzugriffsobjekt (DAO) 45, eine Geräteinformationsdatenbank 46, einen UAProf-Parser 47, einen UAProf-Resolver 48, eine Datei dm-config.xml 49 und eine DeviceVocabulary-Datei 50. Die Geräteinformationsdatenbank 46 speichert Informationen, die mobile Geräte und deren entsprechende Fähigkeiten identifizieren. Der Gerätemanager 41 enthält die gesamte Geschäftslogik, die die Benutzeroberfläche unterstützt, und den Rest des Download-Managers 1. Das Geräte-DAO 45 enthält sämtliche Datenlogik und das für die Kommunikation mit der Geräteinformationsdatenbank 46 nötige Abfragesprachskript.
Der Geräte-Handler-Manager 42 ist für die Entdeckung und Ermittlung der Gerätetypen verantwortlich, auf die der Download-Manager 1 zugreift. Nach dem Start des Download-Managers 1 lädt der Geräte-Handler-Manager 42 die in der Datei dm-config.xml 49 geordneten Geräteerkennungshandler 44. Diese Ordnung wird dann verwendet, um zu ermitteln, welche Header zuerst verarbeitet werden. Der Lieferkontext-Cache 43 soll dabei helfen, die Leistung bei nachfolgenden Lookups zu verbessern. Wenn die Kette von Handlern 44 keine Gerätefähigkeiten finden oder verarbeiten kann, benutzt der Geräte-Handler-Manager 42 einen Vorgabelieferkontext gemäß Definition durch eine administrative Benutzeroberfläche.
Die illustrierte Ausgestaltung beinhaltet drei Geräteerkennungshandler 44: einen XwapProfile-Handler, einen UserAgent-Handler und einen Quarantäne-Handler. Der XwapProfile-Handler ist für die Verarbeitung der Anforderungsheader „x-wap-profile" und „x-wap-profil-diff" in Anforderungen von mobilen (Client-) Geräten verantwortlich. Er verwendet den UAProf-Parser 47 zum Parsen von RDF-kompatiblen Dateien und den UAProf-Resolver 48 zum Auflösen der Header-Differenzen. Der UAProf-Parser 47 parst RDF-kompatible Dateien. Der UAProf-Resolver 48 liest Auflösungsregeln von der Konfigurationsdatei device-vocabulary.xml 50 und verwendet diese Regeln, um beim Zusammenführen von x-wap-profile und x-wap-profile-diff Headern zu helfen.
Der UserAgent-Handler ist für die Verarbeitung der „User-Agent"-Anforderungsheader verantwortlich. Er arbeitet mit regelmäßiger Ausdrucksanpassung zum optimalen Abgleichen der Fähigkeiten mit dem eingehenden „User-Agent"-Header. Wenn kein User-Agent-Header gefunden werden kann oder wenn einer gefunden wird, der mit keinen existierenden Fähigkeiten übereinstimmt, dann wird der Anforderungsheader zum nächsten Handler in der Kette weitergeleitet.
Der Quarantäne-Handler ist für die Verarbeitung von „Accept"-Anforderungsheadern verantwortlich. Wenn der Quarantäne-Handler einen User-Agent-Header findet, dann fügt er einer Geräteabgleichtabelle einen neuen Datensatz hinzu. Ansonsten gibt er einfach einen Lieferkontext mit einem Satz von von den „Accept"-Headern ermittelten Fähigkeiten und von bereits vom Vorgabegeräteprofil definierten Fähigkeiten zurück.
Der Gerätefähigkeitenmanager 37 kann Client-Geräte in jeder von zwei Kategorien verwalten: tatsächliche Geräte und generische Geräte. Als Reaktion auf Client-Geräteanforderungen nutzt der Gerätefähigkeitenmanager 37 tatsächliche Geräteinformationen aus der Anforderung sowie eventuelle anwendbare gespeicherte generische Gerätedefinitionen zum Erkennen des zugreifenden Client-Gerätes und seiner Fähigkeiten. Der Systemadministrator kann Geräte (oder Gerätefähigkeiten) in beiden Kategorien definieren. Ein tatsächliches Gerät ist ein(e) besondere(s) Client-Gerätemarke oder -modell wie z.B. „Nokia 6310^(TM). Tatsächliche Geräte werden allein von eingehenden Anforderungen z.B. auf der Basis der UserAgent und x-wap-profile Header in den Anforderungen identifiziert. Ein generisches Gerät ist ein vordefiniertes Gerät oder ein Satz von Gerätefähigkeiten. Beispiele für einige generische Gerätedefinitionen sind: alle Nokia-Geräte (z.B. „vendorname=nokia"), alle Geräte mit Anzeigegröße >40 und alle Geräte, die SMS unterstützen. Als Reaktion auf Client-Geräteanforderungen verwendet der Gerätefähigkeitenmanager 37 den UserAgent oder x-wap-profile Header zum Identifizieren des tatsächlichen auf das System zugreifenden Gerätes und zum Nachschlagen seiner entsprechenden Fähigkeiten in der Geräteinformationsdatenbank 46, die mit beliebigen anwendbaren generischen Gerätedefinitionen kombiniert werden, um die Fähigkeiten des Client-Gerätes zu ermitteln. Die Nutzung dieser Informationen wird nachfolgend ausführlicher beschrieben.
Es ist jetzt nützlich, zwei Typen von Gerätefähigkeiten zu definieren, die der Gerätefähigkeitenmanager auflösen kann: statische Fähigkeiten und aktive Fähigkeiten. Wie im Download-Manager definiert, sind „statische" Fähigkeiten der gut bekannte Satz von Attributen für ein bestimmtes Gerät, die bei der Vorverarbeitung, nicht nebenbei (on-the-fly) definiert werden. Diese werden mit einem Client-Gerät gemäß Identifikation im UserAgent oder im x-wap-profile Header assoziiert. Generische Geräte, wie oben definiert, haben nur statische Fähigkeiten. „Aktive" Fähigkeiten repräsentieren eine dynamische Sammlung von Attributen, die bei einer Interaktion zwischen dem Client-Gerät und dem Download-Manager extrahiert wurden, gewöhnlich von den Accept-Headern. Diese beiden Typen von Gerätefähigkeiten werden separat in der Geräteinformationsdatenbank 46 gespeichert.
Die Fähigkeit eines Benutzers, Inhalt auf der Basis der statischen (gut bekannten) Fähigkeiten seines Gerätes zu entdecken, ist wertvoll. Angesichts der großen Zahl von Geräteherstellern und Inhaltsanbietern auf dem Markt gibt es häufig einen Abstand zwischen der Interoperabilität eines bestimmten Inhalts und der Effektivität seiner Nutzung auf einem Gerät. Indem die einzigartige Fähigkeit eines Systems genutzt wird, die Fähigkeiten eines Gerätes zu erfassen und Inhaltsanbieter kompatible Geräte für ihren Inhalt auswählen zu lassen, kann der Download-Manager 1 auf unterstützte Produkte für seine jeweiligen Geräte für einen Abonnenten abzielen. Darüber hinaus kann sich der Download-Manager 1 leicht an die ständig wandelnden Modifikationen im Hinblick auf Fähigkeiten und Anforderungen anpassen und ist äußerst skalierbar, wenn weitere Geräte und Inhalt in das System eingeführt werden, ohne erhebliche Leistungseinbußen.
Wieder mit Bezug auf 3, der Produktmanager 32 beinhaltet in bestimmten Ausgestaltungen einen Produkt-Workflow-Manager 51, einen Inhaltsanalysemanager 52, einen Preisstellungsmanager 53 und einen Produktkatalog 54. Der Produkt-Workflow-Manager 51 erlaubt es dem Systemadministrator, Details des Produkt-Workflow zur Bearbeitung von Inhalt zu definieren und zu modifizieren, um von Inhaltsanbietern submittierten Inhalt zu verarbeiten. Ein Beispiel für einen Produkt-Workflow ist (in chronologischer Reihenfolge): 1) Submission, 2) Inhaltsanalyse, 3) Auflisten von Inhalt im Produktkatalog, 4) Gebrauch des Inhalts, 5) Wartung von Inhalt und 6) Entfernen von Inhalt (d.h. Stornierung oder Löschung).
Der Inhaltsanalysemanager 52 verwaltet den Vorgang des Verifizierens der Inhaltsqualität und der Erfüllung verschiedener Anforderungen, wenn der Inhalt anfänglich vom Inhaltsanbieter submittiert wird (z.B. Compliance mit seinem deklarierten Typ, Ausnutzung der Inhaltsstrukturressourcen usw.). Der Inhalt muss den Inhaltsanalyseprozess zufriedenstellend durchlaufen haben, bevor er im Produktkatalog 54 aufgeführt (d.h. veröffentlicht) wird.
Der Preisstellungsmanager 53 lässt es zu, dass Administratoren Lizenzen für Produkte im Lager hinzufügen, modifizieren und löschen. Der Preisstellungsmanager 53 enthält und aktiviert auch einen Satz von Bewertungshandlern zum Kaufzeitpunkt, die den Preis des Produkts auf der Basis verschiedener Funktionen (z.B. Sonderangebote, anwendbare Rabatte usw.) wie nachfolgend näher beschrieben justieren können.
Der Produktkatalog 54 enthält Beschreibungen aller veröffentlichten Inhaltsartikel (Produkte). Gemäß 5 beinhaltet der Katalog 54 für jeden Produkteintrag 56 einen Verweis 58 auf wenigstens eine Ausführung 57 dieses Produkts. Eine Ausführung 57 kann einfach eine das Produkt repräsentierende Binärdatei (eine „Binary") sein. In einigen Fällen kann eine Ausführung 57 jedoch auch zwei oder mehrere Binärdateien 61 repräsentieren, wie in 6 gezeigt ist. Ebenso wie in den 5 und 6 gezeigt, kann jedes besondere Produkt mehrere Ausführungen haben, die auf dem Download-Manager veröffentlicht werden, die jeweils für ein anderes spezielles Client-Gerät oder einen Satz von Client-Geräten bestimmt sind.
So kann jeder Produkteintrag in dem Katalog 54 Verweise auf mehrere Ausführungen des Produkts beinhalten. Die einem bestimmten Abonnenten gezeigten Produkte, wenn der Abonnent den Katalog betrachtet, werden je nach den Gerätefähigkeiten des Gerätes des Abonnenten gefiltert. Spezieller, dem Abonnenten werden nur diejenigen Produkte gezeigt, die wenigstens eine Ausführung haben, die mit dem Gerät des Abonnenten kompatibel ist. Wie in 5 gezeigt, beinhaltet jeder Ausführungseintrag 57 auch eine Liste (59A oder 59B) der Geräte, die diese Ausführung unterstützt. Jeder Produkteintrag 56 in dem Katalog 54 enthält eine Liste 59 der Geräte, die durch dieses Produkt unterstützt werden. Diese Liste repräsentiert die Gesamtheit aller Geräte, die von allen Ausführungen 57 dieses Produktes unterstützt werden.
Zusätzlich kann der Katalog für jedes Produkt eine Beschreibung 60 des Produktes in mehreren verschiedenen Sprachen beinhalten, um Abonnenten in verschiedenen Ländern zu berücksichtigen. Jedem Abonnenten werden Produktbeschreibungen 60 in der angemessenen Sprache dargestellt, und die Preise von Produkten werden in der entsprechenden Währung gemäß der Domain dargestellt, zu der der Abonnent gehört. Die Domain des Abonnenten wird durch den Domain-Manager 62 identifiziert, wie nachfolgend beschrieben wird.
Wieder mit Bezug auf 3, der Business- & Operationsmanager 33 beinhaltet in bestimmten Ausgestaltungen ein OA&M-(Operation Administration and Management)-Modul 61, einen Domain-Manager 62 und einen Zahlungsmanager 63. Das OA&M-Modul 61 bietet eine Web-gestützte Benutzeroberfläche zum Verwalten des Download-Managers 1. Es unterstützt eine auf der Rolle basierende Delegation von Verwaltungsaufgaben (z.B. Systemadministrator, Domain-Administrator, Produktadministrator, Kundendienstadministrator usw.) und hat Verbindung mit dem Provisioning-Manager zwecks Protokollierung und Meldung von wichtigen Events und Transaktionen.
Der Zahlungsmanager 63 ist für den Gebührenberechnungsvorgang für Abonnenten verantwortlich, wenn sie Inhalt kaufen, und unterstützt mehrere verschiedene Sprachen und Währungen, nach Domains getrennt. Der Gebührenberechnungs- und Zahlungsansatz geht davon aus, dass örtliche Gebührenberechnungsmechanismen in Betrieb sind, die jeweils bereits eine etablierte Beziehung mit dem Abonnenten haben. Der lokale Gebührenberechnungsmechanismus arbeitet in der örtlichen Währung mit den örtlichen Steuern, Gebühren und anderen anwendbaren Kosten für die Region des Abonnenten. Er stellt auch die Rechnungen in den für die Region üblichen Intervallen.
In bestimmten Ausgestaltungen der Erfindung kann ein Abonnent das bevorzugte anzuwendende Zahlungsmodell aus drei verfügbaren Zahlungsmodellen auswählen.

– Online-Zahlung – die Zahlung erfolgt „just-in-time". Eine typische Ausführung führt die Zahlungstransaktion zum Kaufzeitpunkt durch.
– Vorauszahlungen – die Zahlung erfolgt vor dem Kauf und der Kauf wird vom Vorauszahlungsbetrag abgezogen.
– Nachzahlungen – die Zahlung erfolgt nach dem Kauf per Rechnung.

Ein separater Zahlungshandler aus einem Satz von Zahlungshandlern 64 ist für den Zahlungsmanager 63 für jedes dieser Zahlungsmodelle zugängig (siehe 3), und der Zahlungsmanager ist für die Aktivierung des geeigneten Zahlungshandlers 64 zum Kaufzeitpunkt verantwortlich.
Nun mit Bezug auf 7, immer wenn sich ein Abonnent beim Download-Manager einloggt, wird eine Session 71 gestartet. Die Session 71 enthält einen Verweis auf ein mit dem Abonnenten assoziiertes eindeutiges Abonnentenprofil 72. Jeder Abonnent hat ein solches Abonnentenprofil, das auf die Organisation zeigt, die die Gebührenberechnungsbeziehung mit dem Abonnenten hat (d.h. der Partner, der für die Rechnungsstellung an den Abonnenten verantwortlich ist) und eine Anzeige des gewählten Zahlungsmodells des Abonnenten (d.h. Nachzahlung, Vorauszahlung oder Online) enthält.
Der Download-Manager 1 führt auch ein Abonnenten-Provider-Profil 73 für jeden Abonnenten-Provider (d.h. Drahtlosträger usw.). Jedes Abonnenten-Provider-Profil 73 enthält einen Verweis auf jeden der Zahlungshandler 64, eine Anzeige der örtlichen Währung sowie eine Anzeige eventueller Mehrwertsteuern und/oder sonstiger Kosten, die normalerweise für die angebotenen Dienste in der Region fällig sind. [0068] Der Produktkatalog 54, wie oben beschrieben, enthält den Namen, die Beschreibung und den Preis für jedes Produkt sowie Informationen, die die unterstützten Geräte anzeigen. Es gibt einen separaten Eintrag für jede unterstützte lokale Währung. Es gibt keine Abhängigkeiten zwischen den Preisen in verschiedenen Währungen für dasselbe Produkt.
Dieser Ansatz lässt es zu, dass ein Produkt (oder Service) viele verschiedene Preise hat, einen in jeder unterstützten Währung. Es gibt keine Abhängigkeiten zwischen Preisen, außer der, dass sie sich alle auf ein Produkt beziehen. Dieser Ansatz unterstützt daher lokalisierte Preisstellungsrichtlinien und lokale Steuern usw.
Der Zahlungsmanager 63 beinhaltet einen Satz von Bewertungshandlern (nicht dargestellt), die für das Justieren des Produktpreises auf der Basis verschiedener Faktoren wie z.B. Sonderangebote, Anwendung von Rabatten usw. verantwortlich sind. Preise für Inhalt können sich von Zeit zu Zeit je nach Faktoren wie Rabatte, Sonderangebote usw. ändern. Zum Kaufzeitpunkt wird der Preis des Produktes durch Aktivieren der Bewertungshandler bestimmt. Jeder Bewertungshandler wird vom Zahlungsmanager 63 mit einem Verweis auf die entsprechende Produktlizenz und einem Verweis auf den Abonnenten abgerufen. Der Bewertungshandler ist ggf. für das Justieren des Preises und das Angeben eines neuen Preises verantwortlich.
Jeder der Zahlungshandler beinhaltet eine Belastungsmethode. Beim Kauf wird die Belastungsmethode des registrierten Zahlungshandlers für das vom Abonnenten gewählte Zahlungsmodell aufgerufen. Das Argument für die Belastungsmethode ist eine Datenstruktur, ChargeDetailRecord, die vom Zahlungsmanager 63 erzeugt wird und die Informationen über den Abonnenten, das Produkt, die Produktlizenz mit dem Preis und die Domain des Abonnenten enthält. Die Belastungsmethode kann die Kosten entweder akzeptieren und somit den Kauf zulassen oder kann den Kauf ablehnen.
Wieder mit Bezug auf 3, der Domain-Manager 62 verwaltet die Assoziationen zwischen Domains und Partnern, Abonnenten, Anbietern und Produkten und speichert alle Domain-Informationen. Wie oben erwähnt, kann jede Domain die folgenden Eigenschaften haben:

– ein Name (lokalisiert)
– eine Beschreibung (lokalisiert)
– eine URL-(Uniform Resource Locator)-Adresse zu einer Website, die die Domain näher beschreibt
– eine Kontaktadresse mit Kontaktpersonen, Kontakttelefonnummern, Telefaxnummern und postalischer Adresse
– die Währung für Rechnungsstellungs- und Anzeigezwecke
– Verweis auf Handler für Online-Zahlung, Vorauszahlung und Nachzahlung
– einen Satz von Verweisen auf Bewertungshandler

Der Domain-Manager 62 ermöglicht die Implementierung flexibler Geschäftsmodelle durch Einnahmenteilung zwischen und Gebührenberechnung durch verschiedene Teilhaber (Partner).
Es werden nun verschiedene Aspekte des Betriebs des Download-Managers 1 ausführlicher mit Bezug auf die 8 bis 13 beschrieben. 8 illustriert einen vereinfachten Vorgang, mit dem ein Produkt im Produktkatalog auf eine Weise aufgeführt werden kann, die gerätespezifische(s) Produktentdeckung und -provisioning erleichtert, gemäß einer Ausgestaltung der Erfindung. Bestimmte Operationen im Produkt-Workflow sind in 8 nicht dargestellt, um die Erläuterung zu vereinfachen, wie z.B. Inhaltsanalyse und -zulassung. Zunächst empfängt der Download-Manager 1 in Block 801 Eingänge von einem Produktanbieter, die ein Produkt sowie eine oder mehrere Ausführungen dieses Produktes definieren. In Block 802 empfängt der Download-Manager Eingänge vom Anbieter, die ein oder mehrere Geräte (tatsächlich oder generisch) vorgeben, die jede Ausführung unterstützen, sowie ein oder mehrere Provisioning-Protokolle, die für jede Ausführung zu verwenden sind. In Block 803 speichert der Download-Manager 1 die Produktdefinition, die Ausführungen sowie eine Liste aller unterstützten Geräte und Provisioning-Protokolle. Schließlich bestimmt der Download-Manager 1 in Block 804 den Satz aller moglichen Geräte, die das Produkt unterstützen, und speichert diese Informationen in Verbindung mit den Produktinformationen im Produktkatalog 54.
9 zeigt einen Vorgang, mit dem der Katalog einem Abonnenten angezeigt wird, gemäß einer Ausgestaltung der Erfindung. In Block 901 ist ein vom Abonnenten betriebenes Client-Gerät mit dem Download-Manager 1 verbunden. Der Domain-Manager 62 identifiziert dann die Domain des Abonnenten in Block 902 auf der Basis seiner gespeicherten Domain- und Abonnentenassoziationen. In Block 903 wählt der Produktmanager 32 die zu verwendende Sprache und Währung auf der Basis der Domain des Abonnenten (jede Domain hat eine Sprache und eine Währung). In Block 904 identifiziert der Gerätefähigkeitenmanager 37 das Client-Gerät (z.B. aus dem UserAgent oder x-wap-profile Header) und seinen entsprechenden Satz von statischen (gut bekannten) Gerätefähigkeiten. Wenn eine Anforderung zum Betrachten verfügbarer Produkte vom Client-Gerät eingeht (Block 905), dann bestimmt der Produktmanager 32 auf der Basis der (statischen) Fähigkeiten des Client-Gerätes in Block 906 anhand des Produktkatalogs 54, welche Produkte von dem Client-Gerät unterstützt werden. Der Download-Manager 1 sendet dann eine Antwort zum Client in Block 907, um zu bewirken, dass das Client-Gerät Produktinformationen nur über die vom Client-Gerät unterstützten Produkte in der entsprechenden Währung und Sprache für die Domain des Abonnenten anzeigt.
10 zeigt einen Vorgang, mit dem ein Produkt gekauft werden kann, gemäß einer Ausgestaltung der Erfindung. Nach dem Anzeigen des Produktkatalogs 54 für den Abonnenten empfängt der Download-Manager 1 in Block 1001 dessen Produktkaufentscheidung. In Block 1002 ruft der Preisstellungsmanager 53 alle registrierten Bewertungsadapter auf. Die Bewertungsadapter justieren dann den Preis des gewählten Produktes ggf. in Block 1003. In Block 1004 präsentiert der Preisstellungsmanager 53 dem Abonnenten dann ein den Preis anzeigendes Lizenzobjekt. Wenn der Abonnent den Kauf bestätigt (Block 1005), dann fordert der Provisioning-Manager in Block 1006 den Zahlungsmanager 63 zum Berechnen des einschlägigen Preises für das Produkt auf. Der Zahlungsmanager 63 antwortet in Block 1007 durch Wählen des anwendbaren Zahlungshandlers 44 auf der Basis der Domain, zu der der Abonnent gehört, und dem bevorzugten Zahlungsmodell des Abonnenten (vorausbezahlt, nachbezahlt oder online). Schließlich führt der gewählte Zahlungshandler 44 in Block 1008 die Belastungsmethode zum Abschließen der Transaktion durch.
Mehrere Provisioning-Modelle
Unterschiedliche Client-Geräte verlangen häufig unterschiedliche Inhaltsprovisioning-Protokolle und Verpackungsformate. Um einen bestimmten Digitalinhaltsartikel für mehrere mobile Geräte verfügbar zu machen, die verschiedene Provisioning-Modelle unterstützen, würde ein Digitalinhaltsanbieter normalerweise diesen Inhaltsartikel mehrere Male nehmen und ihn für jedes der Provisioning-Modelle unterschiedlich verpacken müssen. Der Download-Manager 1 trennt jedoch Inhalt danach, wie er auf einem Gerät bereitgestellt wird. Wie oben beschrieben und in 11 prinzipiell illustriert, werden die Produktinformationen im Download-Manager 1 vom Inhalt selbst getrennt, der Inhalt wird je nach dem getrennt, wie er für die Lieferung verpackt ist, der verpackte Inhalt wird vom Liefermechanismus getrennt und der Liefermechanismus wird vom Entdeckungsmechanismus getrennt (dem Mechanismus, mit dem der Abonnent ein Produkt entdeckt). Aufgrund dieser Trennung kann ein Inhaltsanbieter Inhalt nur einmal verwenden und auf eine breite Palette von Geräten abzielen und der Download-Manager 1 liefert den Inhalt zu diesen Geräten über eine breite Palette von Provisioning-Protokollen.
Wenn ein Produkt dem Download-Manager 1 von einem Anbieter submittiert wird, dann gibt der Anbieter vor, welche Geräte von den einzelnen Ausführungen des Produkts unterstützt werden. Diese Information wird dann vom Download-Manager 1 gespeichert und zum Wählen der/des richtigen Verpackung und Provisioning-Protokolls verwendet, wenn das Produkt nachfolgend gekauft wird.
Das zum Bereitstellen eines bestimmten Produktes in einem bestimmten Client-Gerät verwendete Provisioning-Modell basiert auf den Gerätefähigkeiten des Client-Gerätes sowie dem Inhaltstyp der am besten passenden Ausführung. Ein Provisioning- „Modell" beinhaltet in diesem Zusammenhang ein bestimmtes Provisioning-Protokoll und ein Inhaltsverpackungsformat. Die Fähigkeit, den am besten passenden Inhalt auf der Basis „aktiver" (dynamischer) Fähigkeiten eines Gerätes zu liefern, ist von Vorteil. Die Inhaltsbereitstellung ist der zweite Teil des Richtens von Produkten an einen bestimmten Abonnenten auf der Basis der Fähigkeiten von dessen Gerät. Die Produktentdeckung wie oben beschrieben beruht zwar auf den „statischen" Fähigkeiten, aber die Bereitstellung beruht auf den „aktiven" Fähigkeiten, die genauen und häufig neuen Erweiterungen des Client-Gerätes zu bestimmen. In Anbetracht dessen, dass ein Gerät mit neuen Merkmalen ausgestattet oder erweitert werden kann, die in dem ursprünglich für das Gerät gedachten Vorgabefähigkeitensatz noch nicht beschrieben sind, kann der Download-Manager 1 diese aktiven Fähigkeiten nutzen, um den am besten passenden Inhalt für die Übertragung zu dem Gerät zu finden.
12 illustriert einen Vorgang, mit dem ein Produkt in einem Client-Gerät mit dem geeigneten einen von verschiedenen Provisioning-Protokollen bereitgestellt wird. In Block 1201 wählt der Liefermanager 31 als Reaktion auf einen Produktkauf durch einen Abonnenten die beste Ausführung des Produkts auf der Basis der Gerätefähigkeiten (statisch und aktiv) des Client-Gerätes aus. In Block 1202 ruft der Download-Manager den Inhaltstyp der gewählten Ausführung (z.B. MIDlet, EXE-Datei, Applet, iAppli usw.) auf. In Block 1203 wählt der Download-Manager 1 das geeignete Provisioning-Modell, das für diese Ausführung zur Verfügung steht, auf der Basis der Gerätefähigkeiten des Client-Gerätes und des Inhaltstyps der gewählten Ausführung aus. Der Provisioning-Manager 28 erzeugt dann einen Inhaltsdeskriptor für die Ausführung in Block 1204 auf der Basis des gewählten Provisioning-Modells. Der Inhaltsdeskriptor gibt den Namen des bereitzustellenden Inhalts, die Größe des Inhalts, einen Ort (z.B. eine URL-Adresse), an dem der Inhalt gespeichert ist, sowie den Inhaltstyp des Inhalts an. Der Inhaltsdeskriptor ist für den Provisioning-Handler (Protokoll) des gewählten Provisioning-Modells einmalig.
Der Provisioning-Manager 28 lädt dann den Inhaltsdeskriptor in Block 1205 auf das Client-Gerät herunter. Das Client-Gerät parst den Deskriptor und fordert dann den Inhalt an. Wenn der Provisioning-Manager 28 die Inhaltsanforderung vom Client-Gerät in Block 1206 empfängt, antwortet der Provisioning-Manager 28 in Block 1207 durch Herunterladen des Inhalts mit dem Provisioning-Protokoll des gewählten Provisioning-Modells (z.B. COD OTA, Openwave^(TM) Download Fun, MIDP OTA usw.).
Einsatzarchitektur des Download-Managers
13 zeigt ein Beispiel für die Software-Einsatzarchitektur des Download-Managers 1 auf einer allgemeinen Ebene gemäß einer Ausgestaltung der Erfindung. Jede Instanz des Download-Managers 1 befindet sich auf einem Host 131, der Zugang zu einer Datenbank 140 hat. Der Host 131 ist ein Computersystem der Server-Klasse mit einem Betriebssystem (z.B. Solaris^(TM)). Die Datenbank 140 kann mehrere physische Datenbanken repräsentieren, die gemeinsam alle Daten speichern, die vom Download-Manager 1 verwendet werden (d.h. Produktinformationen, Abonnenteninformationen, Partnerinformationen, Domain-Informationen usw.). In der illustrierten Ausgestaltung beinhaltet jeder Host 131 eine Java^(TM) Virtual Machine (JVM) 132, die auf dem Betriebssystem läuft und einen Applikationsserver 133 hostet. Auf dem Applikationsserver 133 läuft ein Web-Container 134, der Java^(TM) Server Pages (JSPs) 135 und Servlets 136 sowie Applikationskomponenten 137 mit der Geschäftslogik und der Datenzugriffsschicht 138 des Download-Managers 1 enthält.
Der Download-Manager 1 wird vom Web-Container 134 und seinem Inhalt, den Applikationskomponenten 137 und wenigstens einem Teil der Datenbank 140 gebildet. Eine horizontale Skalierung kann durch Hinzufügen weiterer Hosts 131 erzielt werden, die Instanzen des Download-Managers 1 hosten. In diesem Fall stellt ein IP-(Internet Protocol)-Lastausgleicher 133 Sticky-Load-Ausgleich bereit, d.h. leitet sämtlichen Session-spezifischen Vekehr zum selben Host.
Die oben beschriebene Software-Architektur (d.h. der Download-Manager) kann in einem oder mehreren herkömmlichen Computersystemen der Server-Klasse ausgeführt werden. 14 illustriert die Hardware-Architektur eines solchen Computersystems auf einer hohen Ebene. Man beachte, dass diese Architektur auch für wenigstens einige Client-Geräte repräsentativ ist, die auf den Download-Manager 1 zugreifen. Man beachte auch, dass 14 eine Konzeptdarstellung ist, die beliebige von zahlreichen möglichen spezifischen physischen Anordnungen von Hardware-Komponenten repräsentiert; die Details solcher Anordnungen sind für die vorliegende Erfindung jedoch nicht relevant und liegen im Kompetenzbereich der Fachperson.
Das in 14 gezeigte Verarbeitungssystem beinhaltet einen oder mehrere Prozessoren 140, d.h. eine Zentraleinheit (CPU), einen Festwertspeicher (ROM) 141 und einen Arbeitsspeicher (RAM) 142, die jeweils mit einem Bussystem 146 verbunden sind. Mit dem Bussystem 146 sind auch ein Massenspeichergerät 143, ein Datenkommunikationsgerät 144 und, in einigen Ausgestaltungen, ein oder mehrere zusätzliche Ein-/Ausgabe-(E/A)-Geräte 145 verbunden.
Der/die Prozessor(en) 140 kann/können einen oder mehrere programmierbare Universal- oder Spezialmikroprozessoren oder Digitalsignalprozessoren (DSPs), Mikrosteuerungen, anwendungsspezifische integrierte Schaltungen (ASICs), programmierbare Logikgeräte (PLDs) oder eine Kombination solcher Geräte beinhalten. Das Bussystem 146 beinhaltet einen oder mehrere Busse oder andere physische Verbindungen, die über verschiedene Bridges, Bussteuerungen und/oder Adapter, die in der Technik gut bekannt sind, miteinander verbunden werden können. Das Bussystem 146 kann beispielsweise einen Systembus beinhalten, der über einen oder mehrere Adapter mit einem oder mehreren Erweiterungsbussen wie z.B. einem PCI-(Peripheral Component Interconnect)-Bus, HyperTransport- oder ISA-(Industry Standard Architecture)-Bus, SCSI-(Small Computer System Interface)-Bus, USB-(Universal Serial Bus) oder einem Bus nach IEEE-(Institute of Electrical and Electronics Engineers)-Standard 1394 (zuweilen als „Firewire" bezeichnet) verbunden sein kann. In alternativen Ausgestaltungen können einige oder alle der oben erwähnten Komponenten direkt anstatt über ein Bussystem miteinander verbunden werden.
Das Massenspeichergerät 143 kann ein oder mehrere beliebiges) Geräte) sein oder beinhalten, das/die zum nichtflüchtigen Speichern großer Datenvolumen geeignet ist/sind, z.B. ein(e) Magnetplatte oder -band, ein magnetooptisches (MO) Speichergerät oder ein beliebiger aus verschiedenen Typen von Speichern auf der Basis von Digital Versatile Disk (DVD) oder Compact Disk (CD) oder eine Kombination solcher Geräte.
Das Datenkommunikationsgerät 144 ist ein Gerät, das es dem Verarbeitungssystem ermöglichen kann, Daten mit einem Fernverarbeitungssystem über eine Datenkommunikationslink 148 zu kommunizieren. Es kann z.B. ein herkömmliches Telefonmodem, ein drahtloses Modem, ein ISDN-(Integrated Services Digital Network)-Adapter, ein DSL-(Digital Subscriber Line)-Modem, ein Kabelmodem, ein Funktransceiver, ein Satellitentransceiver, ein Ethernet-Adapter oder dergleichen sein.
Die E/A-Geräte 145 (die in einem System, das ausschließlich als Server arbeitet und keine direkte lokale Benutzeroberfläche hat, wegfallen können) können z.B. ein oder mehrere Geräte wie die folgenden beinhalten: ein Zeigegerät wie z.B. eine Maus, eine Rollkugel, ein Berührungsfeld oder dergleichen; eine Tastatur; Audiolautsprecher; und/oder ein Anzeigegerät wie z.B. eine Kathodenstrahlröhre (CRT), eine Flüssigkristallanzeige (LCD) oder dergleichen. Weitere Variationen am illustrierten Satz von Komponenten sind auf eine Weise im Einklang mit der Erfindung ausführbar.
Software (einschließlich Befehle und Daten) 147 zum Implementieren der oben beschriebenen Techniken können in ROM 141, RAM 142 und/oder Massenspeichergerät 143 gespeichert werden. In bestimmten Ausgestaltungen kann die Software 147 zunächst durch Herunterladen von einem Fernsystem durch das Kommunikationsgerät 144 in das Verarbeitungssystem geladen werden.
Somit wurden ein System und ein Verfahren zum Verwalten der Veröffentlichung, des Kaufs und der Lieferung von digitalem Inhalt von mehreren Inhaltsanbietern zu mehreren Drahtlosedienste-Abonnenten in mehreren Domains beschrieben. Die vorliegende Erfindung wurde zwar mit Bezug auf spezielle beispielhafte Ausgestaltungen beschrieben, aber man wird erkennen, dass die Erfindung nicht auf die beschriebenen Ausgestaltungen begrenzt ist, sondern mit Modifikationen und Änderungen im Rahmen der beiliegenden Ansprüche umgesetzt werden kann. Demgemäß sind die Beschreibung und die Zeichnungen als veranschaulichend und nicht als beschränkend anzusehen.

Claims

Verfahren zum Bereitstellen von Zugang zu Inhalt für die Verwendung in drahtlosen Kommunikationsgeräten (21A, 21B usw.), wobei das Verfahren die folgenden Schritte umfasst: Betreiben eines Serversystems (131) zum Speichern von Domaindaten, die mehrere Domains definieren, wobei jede Domain eine andere Teilmenge aus einer Mehrzahl von Drahtlosdienste-Abonnenten (3A, 3B usw.) repräsentiert, wobei jede der Domains ferner eine Gebührenberechnungsbeziehung zwischen einer Geschäftsentität und der entsprechenden Teilmenge aus der Mehrzahl von Drahtlosdienste-Abonnenten (3A, 3B usw.) repräsentiert, und wobei die mehreren Domains ferner einen Teil von Inhalt, der für die Verwendung in drahtlosen Kommunikationsgeräten (3A, 3B usw.) ausgelegt ist, zu dem Zweck repräsentiert, den Inhalt den Drahtlosdienste-Abonnenten (3A, 3B usw.) verfügbar zu machen; Betreiben des Serversystems (131), um es zu ermöglichen, dass mehrere Inhaltsanbieter (2A, 2B usw.) auf dem Serversystem (131) Inhalt für die Verwendung in drahtlosen Kommunikationsgeräten (3A, 3B usw.) über ein Computernetz (24) veröffentlichen, so dass der Inhalt für die mehreren Drahtlosdienste-Abonnenten (3A, 3B usw.) zugängig ist; und Betreiben des Serversystems (131), um es Drahtlosdienste-Abonnenten in jeder der mehreren Domains zu ermöglichen, Inhalt über wenigstens ein drahtloses Netz (22) zu erwerben und den erworbenen Inhalt auf zugehörigen drahtlosen Kommunikationsgeräten (21A, 21B usw.) zu benutzen.
Verfahren nach Anspruch 1, wobei die mehreren Domains ferner eine Delegation von administrativen Verantwortlichkeiten für den Inhalt und die Abonnenten repräsentieren.
Verfahren nach Anspruch 2, wobei jeder der Abonnenten ein Mitglied von genau einer der Domains ist.
Verfahren nach Anspruch 1, wobei jede der Domains eine assoziierte Währung hat, um den Abonnenten Inhalt darzubieten und den Abonnenten Inhalt in Rechnung zu stellen, wobei die Währung jeder Domain von der Währung jeder anderen Domain unabhängig ist, wobei die Währung jeder Domain im Serversystem durch die jede genannte Domain repräsentierenden Domaindaten angezeigt wird.
Verfahren nach Anspruch 1, wobei jede der Domains eine assoziierte Sprache hat, um mit den zu der Domain gehörenden Abonnenten zu kommunizieren, wobei die Sprache jeder Domain von der Sprache jeder anderen Domain unabhängig ist, wobei die Sprache jeder Domain im Serversystem durch die jede genannte Domain repräsentierenden Domaindaten angezeigt wird.
Verfahren nach Anspruch 1, das ferner das Betreiben des Serversystems beinhaltet, um es den Inhaltsanbietern zu ermöglichen, ihren jeweiligen auf dem Server gespeicherten Inhalt über das Computernetz zu verwalten.
Verfahren nach Anspruch 1, das ferner das Bestimmen eines Preises für jeden der Inhaltsartikel unabhängig für jede der mehreren Domains umfasst.
Verfahren nach Anspruch 1, das ferner das Bestimmen einer Währung beinhaltet, in der der Preis für Inhalt unabhängig für jede der mehreren Domains angegeben werden soll.
Verfahren nach Anspruch 1, das ferner das Bestimmen einer Sprache beinhaltet, in der Abonnenten Inhalt unabhängig für jede der mehreren Domains beschrieben werden soll.
Verfahren nach Anspruch 1, das ferner Folgendes beinhaltet: Empfangen einer Anforderung für Zugang zu Inhalt von einem der Abonnenten; Identifizieren der Domain, in der sich der Abonnent befindet, als Reaktion auf die Anforderung; Bestimmen einer Sprache, die der Domain entspricht, in der sich der Abonnent befindet; Bewirken, dass dem Abonnent ein Produktkatalog mit Beschreibungen des verfügbaren Inhalts in der genannten Sprache vorgelegt wird; Empfangen einer Wahl eines Inhaltsartikels in dem Produktkatalog von dem Abonnenten; Bestimmen eines Preises und einer Währung für den gewählten Artikel auf der Basis der Domain, in der sich der Abonnent befindet; und Bewirken, dass der Preis dem Abonnent in der genannten Währung angegeben wird.
System, um einer Mehrzahl von Drahtlosdienste-Abonnenten (3A, 3B usw.) digitalen Inhalt von einer Mehrzahl von Digitalinhaltsanbietern (2A, 2B usw.) unter Verwendung mehrerer drahtloser Kommunikationsgeräte (21A, 21B usw.) bereitzustellen, wobei das System Folgendes umfasst: einen Domainmanager (62) zum Führen einer Assoziation zwischen jedem der Drahtlosdienste-Abonnenten (3A, 3B usw.) und mehreren Domains, zu der die mehreren Abonnenten (3A, 3B usw.) gruppiert sind, wobei jede Domain eine andere Teilmenge der mehreren Drahtlosdienste-Abonnenten (3A, 3B usw.) repräsentiert, wobei jede der Domains ferner eine Gebührenberechnungsbeziehung zwischen einer Geschäftsentität und der entsprechenden Teilmenge der mehreren Drahtlosdienste-Abonnenten (3A, 3B usw.) repräsentiert, und wobei die mehreren Domains ferner einen Teil von Inhalt, der für die Verwendung in drahtlosen Kommunikationsgeräten (3A, 3B usw.) ausgelegt ist, zu dem Zweck repräsentiert, den Inhalt den Drahtlosedienste-Abonnenten (3A, 3B usw.) verfügbar zu machen; einen Produktmanager (32) zum Verwalten der Veröffentlichung von digitalem Inhalt für die Verwendung in drahtlosen Kommunikationsgeräten (3A, 3B usw.) auf dem System durch die mehreren Digitalinhaltsanbieter (2A, 2B usw.); einen Liefermanager (31) zum Verwalten der Lieferung eines Digitalinhaltsgegenstands für die Verwendung in einem drahtlosen Kommunikationsgerät (3A, 3B usw.) zu einem drahtlosen Kommunikationsgerät (21A, 21B usw.) eines anfordernden Abonnenten (3A, 3B usw.) über ein drahtloses Netz (22) in Verbindung mit einer empfangenen Anforderung für den Digitalinhaltsgegenstand; und einen Zahlungsmanager (63) zum Ausführen eines Zahlungsprozesses, um den Digitalinhaltsgegenstand dem anfordernden Abonnenten (3A, 3B usw.) zu berechnen.
System nach Anspruch 11, bei dem die mehreren Domains ferner eine Delegation von administrativen Verantwortlichkeiten für den Inhalt und die Abonnenten repräsentieren.
System nach Anspruch 12, wobei jeder der Abonnenten zu genau einer der Domains gehört.
System nach Anspruch 11, wobei jede der Domains eine assoziierte Währung hat, um den Abonnenten Inhalt darzubieten und den Abonnenten den Inhalt in Rechnung zu stellen, wobei die Währung jeder Domain von der Währung jeder anderen Domain unabhängig ist, wobei die Währung jeder Domain in dem System durch jede der genannten Domains repräsentierende Domaindaten angezeigt wird.
System nach Anspruch 11, wobei jede der Domains eine assoziierte Sprache hat, um mit den zu der Domain gehörenden Abonnenten zu kommunizieren, wobei die Sprache jeder Domain von der Sprache jeder anderen Domain unabhängig ist, wobei die Sprache jeder Domain in dem System durch jede der genannten Domains repräsentierende Domaindaten angezeigt wird.
System nach Anspruch 11, wobei das System die Aufgabe hat, es Inhaltsanbietern zu ermöglichen, ihren jeweiligen auf dem System gespeicherten Inhalt über ein Computernetz zu verwalten.
System nach Anspruch 11, wobei das System die Aufgabe hat, einen Preis für jeden der Inhaltsartikel unabhängig für jede der mehreren Domains zu bestimmen.
System nach Anspruch 11, wobei das System die Aufgabe hat, eine Währung, in der der Preis für Inhalt angegeben wird, unabhängig für jede aus der Mehrzahl von Domains zu bestimmen.
System nach Anspruch 11, wobei das System die Aufgabe hat, eine Sprache, in der den Abonnenten Inhalt beschrieben wird, unabhängig für jede der mehreren Domains zu bestimmen.
System nach Anspruch 11, wobei das System die folgenden Aufgaben hat: Empfangen einer Anforderung für Zugang zu Inhalt von einem der Abonnenten; Identifizieren der Domain, in der sich der Abonnent befindet, als Reaktion auf die Anforderung; Bestimmen einer Sprache, die der Domain entspricht, in der sich der Abonnent befindet; Bewirken, dass ein Produktkatalog mit Beschreibungen des verfügbaren Inhalts dem Abonnent in der genannten Sprache vorgelegt wird; Empfangen einer Wahl des Inhaltsgegenstandes in dem Produktkatalog von dem Abonnent; Bestimmen eines Preises und einer Währung für den gewählten Gegenstand auf der Basis der Domain, in der sich der Abonnent befindet; und Bewirken, dass der Preis dem Abonnent in der genannten Währung angegeben wird.