-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft drahtlose Datennetze.
-
Insbesondere
und nicht einschränkend
richtet sich die vorliegende Erfindung auf ein verteiltes Cachingsystem
und ein Verfahren zum Nutzen von mobilen Clienten zum Zwischenspeichern
von Dateninhalt und Umverteilen des Inhalts an andere Benutzer.
-
Allgemeiner
Stand der Technik
-
Im
Third Generation Partnership Project (3GPP) wird Multicast (Sammelsendung)
und Broadcast (Rundsendung) in ein Arbeitselement eingeführt, das
als Multimedia-Broadcast/Multicast-Service (MBMS) bezeichnet wird. 1 ist
ein vereinfachtes Blockdiagramm, das die aktuelle MBMS-Architektur darstellt,
wie in der Spezifikation der Stufe 2 definiert. Die Architektur
nutzt Netzknoten aus dem GPRS-Funknetz
(GPRS = General Packet Radio Service, allgemeiner Datenpaket-Funkdienst).
-
Mit
dem Digital Rights Management (DRM) wird der Inhalt möglicherweise
verschlüsselt
und von einem Rechteobjekt begleitet. Das Rechteobjekt spezifiziert,
was der Benutzer mit dem Inhalt machen darf. Ein grundlegendes Konzept
mit DRM besteht darin, dass die Berechnung/Bezahlung auf dem Rechteobjekt
und nicht auf dem Inhaltsobjekt basiert, da der Wert nicht mehr
im (möglicherweise
verschlüsselten)
Inhalt liegt, sondern in den Rechten zum (möglicherweise Entschlüsseln und)
Verwenden des Inhalts.
-
Von
einem Inhaltsanbieter (Content-Provider) kann ein geschütztes Inhaltsobjekt über ein
drahtloses lokales Netz (Wireless Local Area Network, WLAN) oder
ein beliebiges anderes leitungsvermitteltes oder paketvermitteltes
Netz, einschließlich
des globalen Systems für
mobile Kommunika tion (Global System for Mobile Communications, GSM),
des allgemeinen Datenpaket-Funkdienstes (General Packet Radio Service,
GPRS) oder eines terrestrischen Funkzugangsnetzes eines universellen
Mobilkommunikationssystems (Universal Mobile Telecommunications
System (UMTS) Terrestrial Radio Access Network, UTRAN) an ein Teilnehmergerät (User
Equipment, UE) eines mobilen Clienten gesendet werden. Währenddessen
kann das Rechteobjekt von dem Inhaltsanbieter auf einem separaten
Pfad über
einen Rechteserver und einen anderen Gateway-GPRS-Unterstützungsknoten
(Gateway GPRS Support Node, GGSN) und bedienenden GPRS-Unterstützungsknoten
(Serving GPRS Support Node, SGSN) gesendet werden, bevor es das
UTRAN und den mobilen Clienten erreicht. Somit besteht zwischen
dem Inhalt und den Rechten ein potentieller Unterschied in Bezug
auf die Verteilungszeit und den Pfad vor.
-
Anycast
ist ein Internet-Netzdienst, der einem Sender ermöglicht,
auf den nächsten
einer Gruppe von Empfängern
zuzugreifen, die sich dieselbe Anycast-Adresse teilen, wobei „nächste" gemäß der Distanzmessung
des Routingsystems definiert ist. Anycasting ist insofern wie Multicasting,
dass das Ziel eine Gruppe von Adressen ist, anstatt jedoch zu versuchen,
das Paket an alle Mitglieder der Gruppe zu liefern, versucht das Netz,
die Nachricht nur an das nächste
Mitglied zu liefern. Die Quelle muss nicht das räumlich nächste Ziel auswählen, da
das Routingsystem es herausfindet. In der Regel sind die Empfänger in
der Anycast-Gruppe Kopien, die denselben Dienst unterstützen können (beispielsweise
gespiegelte Web-Server). Folglich verbessert das Zugreifen auf den
nächsten
Empfänger
die Leistung, die vom Sender wahrgenommen wird, spart Bandbreite
des Netzes und stellt den erwünschten
Dienst bereit.
-
Im
IPv6 wurden zusätzlich
zu den Unicast- und Multicast-Adressen
spezielle Anycast-Adressen spezifiziert. Eine Anycast-Adresse identifiziert
einen Satz von Schnittstellen, die in der Regel zu verschiedenen Knoten
gehören.
Ein an eine Anycast-Adresse gesendetes Paket wird an die „nächste" Schnittstelle geliefert, die
von dieser Adresse identifiziert wurde, gemäß der Distanzmessung des Routingprotokolls.
Anycast-Adressen werden aus dem Unicast-Adressraum zugeteilt, wobei
ein beliebiges der definierten Unicast-Adressformate verwendet wird. Somit
sind Anycast-Adressen von Unicast-Adressen syntaktisch nicht zu
unterscheiden. Wenn eine Unicast-Adresse mehr als einer Schnittstelle
zugewiesen wird, wodurch sie in eine Anycast-Adresse umgewandelt
wird, müssen
die Knoten, denen die Adresse zugewiesen ist, ausdrücklich darauf
konfiguriert sein, dass sie wissen, dass es sich bei ihr um eine
Anycast-Adresse handelt. Anycast-Adressen werden nur IPv6-Routern,
nicht IPv6-Hosts zugewiesen.
-
Um
einer Anycast-Gruppe beizutreten, fragt ein Host seinen First-Hop-Router,
die Adresse der Gruppe in seinem Namen zu annoncieren. Diese Kommunikation
kann erzielt werden, indem ein neuer Nachrichtentyp entweder dem
Internet-Group-Management-Protokoll
(IGMP) oder dem Neighbour-Discovery-Protokoll hinzugefügt wird. Der Router annonciert
die Adresse dann gemäß dem Anycast-Routingprotokoll,
das von der Domäne
angenommen wurde.
-
In
drahtlosen Netzen der dritten Generation (3G) können sich Benutzer auf der
Verarbeitungsebene in einer beliebigen Anycast-Gruppe registrieren.
Dies kann mit Hilfe von Registrierungsnachrichten durchgeführt werden,
wie sie im IGMP oder dem Multicast-Listener-Discovery-Protokoll
(MLD) verfügbar
sind. Da jedes UE jedoch von dem GGSN nur einen IP-Hop entfernt
ist, gibt es derzeit kein Mittel für den GGSN, zwischen verschiedenen
Anycast-Gruppenmitgliedern im selben öffentlichen Landfunknetz (Public
Land Mobile Network, PLMN) zu unterscheiden. Im Fall von großen PLMNs
kann die Distanz zwischen dem GGSN und den Anycast-Mitgliedern erheblich
variieren. Dies gilt insbesondere im Fall von Anycast auf der Gp-Schnittstelle
(d. h. zwischen einem GGSN und einem SGSN in unterschiedlichen PLMNs).
Somit wird augenblicklich im PLMN kein effizientes Anycasting unterstützt. Im
Fall von mehreren Hosts in der Anycast-Gruppe im PLMN, muss der GGSN
einfach einen Round-Robin-Algorithmus anwenden, um einen der Clienten
auszuwählen.
Folglich wird nicht immer der räumlich
nächste
Host ausgewählt.
-
Die
europäische
Patentanmeldung
EP
1282029 A2 offenbart ein Verfahren zum Verteilen von elektronischem
Inhalt über
das Internet. Gemäß
EP 1282029 A2 wird
der Inhalt anfangs über
das Internet an PCs verteilt und kann dann über einen Docking-Port auf
eine tragbare Einheit, wie einen Minicomputer (Personal Digital
Assistant, PDA), heruntergeladen werden. Der PDA kann weiterhin
den Inhalt über
eine direkte drahtlose Verbindung mit einem anderen PDA teilen.
Es gibt in
EP 1282029
A2 jedoch keine Offenbarung oder Andeutung, dass der Inhalt
anfangs in drahtloser Weise direkt an mobile Clienten verteilt werden
könnten.
Darüber
hinaus gibt es keine Offenbarung oder Andeutung in
EP 1282029 A2 , dass ein
mobiler Client, der den Inhalt nicht empfangen hat, eine Umverteilung
des Inhalts anfordern könnte
oder dass Anycasting dazu verwendet werden könnte, einen umverteilenden
mobilen Clienten, der den Inhalt verfügbar hat, zu identifizieren
und danach den Inhalt von dem identifizierten umverteilenden mobilen
Clienten an den anfordernden mobilen Clienten umzuverteilen.
-
Mobilfunknetze
ermöglichen
mobilen Clienten augenblicklich nicht, als ein Cachespeicher für verteilten Inhalt
zu fungieren und den Inhalt an andere Clienten zu verteilen. Die
Datenzwischenspeicherung und -verteilung wird weitgehend zentral
von einem Server in dem Netz gesteuert. Aufgrund dieser Einschränkung müssen Inhaltsanbieter
und/oder Netzbetreiber entweder die Tatsache akzeptieren, dass sie
nicht garantieren können,
dass Multicast- oder Broadcast-Clienten
den Inhalt stets abrufen können,
oder sie müssen andere
Mittel zum Bereitstellen einer garantierten Lieferung und eines
garantierten Abrufens bereitstellen. Sie können beispielsweise zyklisches
Wiederholen einsetzen oder zusätzliche
Netzressourcen, wie zusätzliche
Cachespeicher in dem Netz, hinzufügen, um zu garantieren, dass
die Daten nicht verloren gehen. Diese Ressourcen speichern den Inhalt
selbst oder speichern Verknüpfungen
(Links) zu dem Inhaltsanbieter, damit der Client den Inhalt von
dem Inhaltsanbieter abrufen kann. Im letzteren Fall ist der Inhaltsabrufpfad
länger
und folglich teurer für
den Inhaltsanbieter, den Netzbetreiber und von Natur aus auch für den Endbenutzer.
-
Kurzdarstellung
der Erfindung
-
Die
Erfindung ist in den Ansprüchen
1, 13 und 21 definiert. Besondere Ausführungsformen sind in den abhängigen Ansprüchen dargelegt.
-
Die
vorliegende Erfindung ermöglicht
mobilen Clienten, Dateninhalt zwischenzuspeichern, der an mehrere
Clienten verteilt wurde, und den Inhalt von dem Cachespeicher an
andere Benutzer umzuverteilen. Die anfängliche Verteilung kann mit
Hilfe von Broadcast-, Multicast- oder mehreren Unicast-Nachrichten
durchgeführt
worden sein. Dann lokalisiert ein Benutzer, der Daten abzurufen
wünscht,
unter Verwendung von auf das PLMN angewendeten Anycast-Techniken
den nächsten
Benutzer, der den Inhalt verfügbar
hat, und fordert den nächsten
Benutzer auf, den Inhalt weiterzuleiten. Der „nächste" Benutzer kann der räumlich nächste Benutzer sein, kann aber
auch der optimale Benutzer von einem Gesichtspunkt der Dienstgüte (Quality
of Service, QoS) her sein. Das Netz behält die Steuerung der Umverteilung
bei und kann dem anfordernden Benutzer den Inhalt berechnen und/oder
dem Benutzer, der den Inhalt weiterleitet, eine Anreizprämie bieten.
-
Folglich
ist die vorliegende Erfindung in einem Gesichtspunkt auf ein verteiltes
Caching- und Umverteilungssystem zum Zwischenspeichern und Umverteilen
von Dateninhalt in einem drahtlosen Datennetz gerichtet. Das System
beinhaltet Übertragungsmittel
zum Übertragen
des Dateninhalts in einer anfänglichen
Datenübertragung
von dem Netz an mobile Clienten, die in dem drahtlosen Datennetz
arbeiten, und mindestens einen umverteilenden mobilen Clienten,
der den Dateninhalt empfängt
und zwischenspeichert. Das System beinhaltet außerdem einen anfordernden mobilen
Clienten, der den Dateninhalt nach der anfänglichen Übertragung des Dateninhalts
durch das Übertragungsmittel
anfordert; und Umverteilungsmittel zum Umverteilen des Dateninhalts
von dem umverteilenden mobilen Clienten an den anfordernden mobilen
Clienten. Das System kann außerdem
einen Berechnungs- und Abrechnungsserver beinhalten, der dem anfordernden
mobilen Clienten den Dateninhalt berechnet, nachdem der Dateninhalt
an den anfordernden mobilen Clienten umverteilt wurde. Gegebenenfalls
kann der Berechnungs- und Abrechnungsserver dem umverteilenden mobilen
Clienten einen Anreiz bieten, nachdem der umverteilende mobile Client
angeboten hat, den Dateninhalt umzuverteilen, oder die Umverteilung
des Dateninhalts an den anfordernden mobilen Clienten abgeschlossen
hat.
-
In
einem anderen Gesichtspunkt ist die vorliegende Erfindung auf ein
Verfahren zum Zwischenspeichern und Umverteilen von Dateninhalt
in einem drahtlosen Datennetz gerichtet. Das Verfahren beinhaltet
die Schritte des Übertragens
des Dateninhalts in einer anfänglichen
Datenübertragung
durch das Netz an mobile Clienten, die in dem drahtlosen Datennetz
arbeiten, und des Empfangens und Zwischenspeicherns des Dateninhalts
durch mindestens einen umverteilenden mobilen Clienten. Das Verfahren
beinhaltet außerdem
das Anfordern des Dateninhalts nach der anfänglichen Übertragung des Dateninhalts
durch einen anfordernden mobilen Clienten und das Umverteilen des
Dateninhalts von dem umverteilenden mobilen Clienten an den anfordernden
mobilen Clienten.
-
In
noch einem anderen Gesichtspunkt ist die vorliegende Erfindung auf
einen umverteilenden mobilen Clienten zur Verwendung in einem verteilten
Caching- und Umverteilungssystem in einem drahtlosen Datennetz gerichtet.
Der umverteilende mobile Client speichert von dem Netz empfangenen
Dateninhalt zwischen und verteilt den Dateninhalt an einen anfordernden
mobilen Clienten um. Der umverteilende mobile Client beinhaltet
einen Empfänger
zum Empfangen des in einer anfänglichen
Datenübertragung
von dem Netz übertragenen
Dateninhalts und einen Datenspeicher zum Zwischenspeichern des empfangenen
Dateninhalts. Der umverteilende mobile Client beinhaltet außerdem einen
Sender zum Übertragen
des zwischengespeicherten Dateninhalts an einen identifizierten
anfordernden mobilen Clienten und einen Prozessor, der programmiert
ist, den zwischengespeicherten Dateninhalt aus dem Datenspeicher
abzurufen und den Dateninhalt als Antwort auf das Empfangen einer
Umverteilungsanweisung, die das anfordernde mobile Endgerät identifiziert,
an den Sender zu senden.
-
In
noch einem anderen Gesichtspunkt ist die vorliegende Erfindung auf
einen anfordernden mobilen Clienten zur Verwendung in einem verteilten
Caching- und Umverteilungssystem in einem drahtlosen Datennetz gerichtet.
Der anfordernde mobile Client erhält von einem umverteilenden
mobilen Clienten Dateninhalt, der zuvor von dem Netz an mindestens
einen umverteilenden mobilen Clienten übertragen wurde. Der anfordernde
mobile Client beinhaltet einen Sender, der eine Anforderung des
zuvor übertragenen
Dateninhalts überträgt; einen
Prozessor, der programmiert ist, Anycast-Nachrichten an einem nächsten umverteilenden
mobilen Clienten, der den Dateninhalt zur Umverteilung verfügbar hat,
zu senden und zu empfangen; und einen Empfänger zum Empfangen des Dateninhalts,
der von dem nächsten
umverteilenden mobilen Clienten übertragen
wurde.
-
Kurzbeschreibung
der Zeichnungen
-
1 (Stand
der Technik) ist ein vereinfachtes Blockdiagramm, das die gegenwärtige Multimedia-Broadcast/Multicast-Service-Architektur
(MBMS-Architektur) darstellt;
-
2 ist
ein vereinfachtes Funktionsblockdiagramm einer Ausführungsform
des Systems der vorliegenden Erfindung;
-
3 ist
ein vereinfachtes Blockdiagramm einer Gesamtarchitektur eines drahtlosen
Datennetzes, in dem Anycasting implementiert wurde;
-
4 ist
eine veranschaulichende Zeichnung eines Protokollstapels, der zum
Transportieren eines Anycast-Stroms zwischen Netzelementen in dem
PLMN gemäß der vorliegenden
Erfindung eingesetzt wird;
-
5 ist
ein Zeichengabediagramm, das den Fluss von Zeichengabenachrichten
zwischen verschiedenen Netzfunktionseinheiten in der in 2 gezeigten
Ausführungsform
der vorliegenden Erfindung darstellt;
-
6 ist
ein vereinfachtes Funktionsblockdiagramm einer anderen Ausführungsform
des Systems der vorliegenden Erfindung;
-
7 ist
ein Zeichengabediagramm, das den Fluss von Zeichengabenachrichten
zwischen verschiedenen Netzfunktionseinheiten in der in 6 gezeigten
Ausführungsform
der vorliegenden Erfindung darstellt;
-
8 ist
ein vereinfachtes Funktionsblockdiagramm einer anderen Ausführungsform
des Systems der vorliegenden Erfindung;
-
9 ist
ein Zeichengabediagramm, das den Fluss von Zeichengabenachrichten
zwischen verschiedenen Netzfunktionseinheiten in der in 8 gezeigten
Ausführungsform
der vorliegenden Erfindung darstellt; und
-
10 ist
ein vereinfachtes Funktionsblockdiagramm eines mobilen Clienten,
der modifiziert ist, Dateninhalt gemäß der vorliegenden Erfindung
zwischenzuspeichern und umzuverteilen.
-
Ausführliche
Beschreibung von Ausführungsformen
-
2 ist
ein vereinfachtes Funktionsblockdiagramm einer Ausführungsform
des Systems der vorliegenden Erfindung. Dateninhalt 11 von
einem Inhaltsanbieter 12 wird über ein Dienstnetz 13,
ein Kernnetz 14 und ein Funknetz 15 gesendet.
Am Funknetz wird der Inhalt von einer Funkbasisstation (Base Transceiver
Station, BTS) 16 an vier mobile Clienten 17–20 rundgesendet/gruppengesendet
und drei der vier Clienten (17–19) empfangen den
Inhalt korrekt. Es sollte anerkannt werden, dass, obgleich eine
BTS dargestellt und hierin als das Mittel beschrieben ist, mit dem
der Inhalt übertragen
wird, andere Übertragungsknoten
ebenfalls eingesetzt werden können.
Zum Beispiel kann die Erfindung einen WDCMA-Knoten (WDCMA = Wideband
Code Division Multiple Access, Breitband-Codemultiplex-Vielfachzugriff)
B oder ein WLAN-Funkgerät
einsetzen. Der Client 20, der den Inhalt nicht empfangen
hat oder ihn nicht korrekt empfangen hat, sendet eine Abfrage 21 an das
Netz, die den Inhalt von dem nächsten
Clienten anfordert, der ihm den Inhalt bereitstellen kann. Das Netz sendet
eine Anweisung 22 an den nächsten Clienten 19,
der den Inhalt hat, die den nächsten
Clienten anweist, den Inhalt an den anfordernden Clienten 20 zu
senden. Der Inhalt 11 wird von dem nächsten Clienten an den anfordernden
Clienten umverteilt.
-
Die
vorliegende Erfindung integriert Anycasting, die vom Internet wohl
bekannt ist, in das PLMN. Mobile Clienten registrieren sich in einer
beliebigen Anycast-Gruppe und können über die
Anycast-Adresse kontaktiert werden. Die Anycast-Registrierung wird
auf der IP-Verarbeitungsschicht durchgeführt, wohingegen die Anycast-Übertragung
in dem PLMN auf der IP-Transportebene durchgeführt wird.
-
3 ist
ein vereinfachtes Blockdiagramm einer Gesamtarchitektur eines drahtlosen
Datennetzes, in dem Anycasting implementiert wurde. Mobile Clienten 31–35 arbeiten
in PLMNs 36 und 37, die von GGSN 38 bzw. 39 bedient
werden. Jeder der GGSNs kann mit einer jeweiligen Anycast-Datenbank 41 und 42 verbunden sein.
Die GGSNs kommunizieren über
ein Fernnetz 43, das Anycast-Nachrichten tragen kann, miteinander und
mit anderen Netzfunktionseinheiten. Ein Heimteilnehmerserver (Home
Subscriber Server, HSS) 44 speichert Teilnehmerprofil und
-standortinformationen und eine Master-Anycast-Datenbank 45 speichert
Anycast-Registrierungsinformationen.
-
Verschiedene
Variationen des Anycasting-Vorgangs sind möglich. In einer ersten Ausführungsform werden
die folgenden Vorgänge
eingesetzt: (1) Abrufen von Distanzinformationen durch Bestimmen
der Distanzen zwischen der BTS/den Knoten B in dem PLMN und dem
GGSN; (2) Registrierung von mobilen Hosts in der Anycast-Gruppe;
(3) Verbreitung von Anycast-Mitgliedschaftsinformationen durch den
GGSN auf dem Funknetz und (4) Empfang und Verarbeitung von Anycast-Daten
in dem PLMN.
-
Um
die Zeichengabe- und Verarbeitungsverzögerung zu begrenzen, wenn mobile
Hosts sich in einer Anycast-Gruppe registrieren, ist es effizienter,
die Distanz zwischen der BTS/den Knoten B im Vorhinein zu bestimmen.
Man beachte, dass diese Bestimmung auch vorgenommen werden kann,
wenn ein mobiler Host sich von einer spezifischen BTS/einem spezifischen
Knoten B aus registriert. Die Informationen können dann zur späteren Referenz
gespeichert werden. Es gibt zwei elementare Vorgehensweisen für den GGSN,
die Distanzen (z. B. Verzögerungsdistanz)
in Richtung der BTS/der Knoten B zu bestimmen. Erstens kann der
GGSN auf Basis der bekannten Konfiguration des Netzes, je nach dem
in dem PLMN verwendeten IP-Routingprotokoll, die Distanz in Richtung
jedes der Router in der BTS/dem Knoten B von aus den Routingprotokolltabellen
implizit kennen. Zweitens können
die BTS/die Knoten B mittels des Internet-Group-Management-Protokolls (IGMP), des Neighbour-Discovery-Protokolls, des Multicast-Listener-Discovery-Protokolls
(MLD) oder eines beliebigen dedizierten Protokolls bei dem GGSN
als Transport-Anycast-Gruppenmitglieder registrieren.
-
4 ist
eine veranschaulichende Zeichnung eines Protokollstapels, der zum
Transportieren eines Anycast-Stroms zwischen Netzelementen in dem
PLMN eingesetzt wird. Die Registrierung von Mobilstationen (MSs)
kann beispielsweise mittels Verwenden einer neuen Nachricht in dem
IGMP oder dem MLD durchgeführt
werden. Gegenwärtig
in den Spezifikationen hat der GGSN keine Informationen zu der Zelle
(BTS/Knoten B), in der das Mobilgerät roamt. Der SGSN hat jedoch
die Zellen-ID in den PDP-Kontextinformationen (PDP = Packetdatenprotokoll)
für den
mobilen Host gespeichert. Darüber
hinaus kennt der SGSN die BTS/den Knoten B, zu dem die Zellen-ID
gehört.
Im Fall eines IP-basierten Funknetzes kennt der SGSN die IP-Adresse
der BTS/des Knotens B.
-
Der
GGSN ruft die IP-Adresse der BTS/des Knotens B von dem SGSN mittels
neuer GTP-Informationselemente oder -nachrichten (GTP = GPRS-Tunnelprotokoll)
oder mittels eines dedizierten Anforderungs-/Antwortprotokolls zwischen
dem GGSN und dem SGSN ab. Gegebenenfalls führt der SGSN Subskriptions-
oder Berechnungsanalysen durch und antwortet dem GGSN mit einem
positiven oder negativen Anycast-Registrierungsresultat. Der GGSN
teilt dann gegebenenfalls dem mobilen Host das Ergebnis mit. Darüber hinaus
führt der
GGSN auch Analysen durch und schließt die Anycast-Registrierung ab.
Die mobilen Hosts werden einer Tabelle in dem GGSN hinzugefügt. Wenn
mehr als ein mobiler Host für
dieselbe Anycast-Gruppe in derselben BTS/demselben Knoten B registriert
ist oder wenn mehrere Hosts in derselben Anycast-Gruppe mit derselben
Distanz zwischen dem GGSN und der entsprechenden BTS/den entsprechenden
Knoten B registriert sind, kann der GGSN beispielsweise einen Round-Robin-Ablauf
anwenden, um eines der Anycast-Gruppenmitglieder auszuwählen. Gegebenenfalls
werden andere Charakteristika, wie in Tabelle 1 unten gezeigt, für die Auswahl
berücksichtigt.
Es wird erwartet, dass das „Ausgehandeltes
Qos-Profil"-Informationselement
am häufigsten
zum Auswählen
von Anycast-Gruppenmitgliedern verwendet wird.
-
-
-
Der
GGSN verbreitet die Anycast-Mitgliedschaftsinformationen für das erste
Mitglied in dem PLMN in Richtung des Fernnetzes. Bei Empfang von
Daten für
die Anycast-Gruppe in dem GGSN bestimmt der GGSN das entsprechende
nächste
oder optimale Anycast-Gruppenmitglied, in Abhängigkeit von einer vordefinierten Metrik.
Diese Bestimmung wird beispielsweise vorgenommen, indem in den etablierten
Anycast-Distanztabellen nach dem mobilen Host gesucht wird, der
zu der nächsten
BTS/dem nächsten
Knoten B gehört.
Dann wird eine weitere Verarbeitung der Daten zu diesem mobilen
Host gemäß aktuellen
Standards durchgeführt.
-
Diese
Architektur und Methodik stellen einen effizienten und flexiblen
Auswahlmechanismus zum Bestimmen des angemessenen, d. h. des nächsten Hosts
aus einer Anycast-Gruppe
in einem PLMN bereit. Der Nächste
kann gemäß einer
beliebigen Metrik definiert werden, die auf die Routingprotokolle
angewendet werden kann.
-
5 ist
ein Zeichengabediagramm, das den Fluss von Zeichengabenachrichten
zwischen verschiedenen Netzfunktionseinheiten in der in 2 gezeigten
Ausführungsform
der vorliegenden Erfindung darstellt. Die Funktionseinheiten beinhalten
den Inhaltsanbieter 12, einen Berechnungs- und Abrechungsserver
(charging and billing Server, C&B-Server) 51,
ein Broadcast/Multicast-Service-Center (BMSC) 52, wie in
den MBMS-Standards definiert, einen Cachespeicher-Kontrollserver 53 und
die BTS/den Knoten B 16. Zu Veranschaulichungszwecken sind
auch drei mobile Clienten 18–20 gezeigt. Bei 54 sendet
der Inhaltsanbieter den Inhalt an das BMSC. Der Inhalt kann Dateien,
Multimedia-Nachrichten (die z. B. von einem Multimedia-Messaging-Center,
MMC, stammen), Kurznachrichten, Streaming-Video oder -Audio und
dergleichen sein. Neben dem eigentlichen Inhalt sendet der Inhaltsanbieter
einen DCR-Indikator (DCR = distributed caching request, verteilte
Caching-Anfrage), um dem BMSC mitzuteilen, dass verteilte Zwischenspeicherung
(Caching) bevorzugt wird. Gegebenenfalls kann der DCR-Indikator
von dem BMSC erzeugt werden. In einer anderen Option kann das BMSC
die DCR löschen,
wenn das BMSC aus einem beliebigen Grund nicht wünscht, dass Clienten den Inhalt
zwischen speichern und umverteilen.
-
Bei
Schritt 55 leitet das BMSC 52 den Inhalt und den
DCR-Indikator an
ein entsprechendes geografisches Gebiet weiter (Broadcast) oder
leitet den Inhalt an jene geografischen Gebiete weiter, die viele
registrierte Clienten haben (Multicast). Des Weiteren wird eine
Anycast-Adresse eingebunden und von den Clienten 18–20 dazu
verwendet, dem Netz (beispielsweise dem dedizierten Cachespeicher-Kontrollserver 53 in
dem Netz) mitzuteilen, dass sie bereit sind, den Inhalt zwischenzuspeichern
und umzuverteilen. Die Clienten können beispielsweise Mobiltelefone
mit einem 128-MB-Memory
Stick von Sony sein, der den Telefonen ermöglicht, den Inhalt einige Zeit
lang zu speichern. In diesem Beispiel wird der Inhalt von den mobilen
Clienten 18 und 19 korrekt empfangen. Bei Schritt 56 registrieren
die empfangenden Clienten bei dem Netz ihre Bereitschaft, den Inhalt
zwischenzuspeichern und umzuverteilen. Die Clienten können sich
unter Verwendung von Anycast-Nachrichten oder anderen geeigneten
Registrierungsmechanismen registrieren. Bei Verwendung von Anycast
speichert entweder der Cachespeicher-Kontrollserver oder das BMSC die Broadcast-Anycast-
oder Multicast-Anycast-Adresskombinationen zur späteren Verwendung.
Zusätzliche
Informationen können
zusammen mit dieser Anycast-Nachricht gesendet werden, wie von dem
sendenden Clienten bevorzugt. Die zusätzlichen Informationen können beispielsweise
die Fähigkeiten
des Clienten, den Inhalt unter Anwendung einer Vielfalt an Kommunikationsprotokollen
wie GSM, WCDMA und Bluetooth umzuverteilen, sowie Informationen wie
Informationen zum Vorliegen, Zeiten, zu denen der Client verfügbar ist,
und dergleichen beinhalten.
-
Bei
Schritt 57 fordert der mobile Client 20, der den
Inhalt nicht empfangen hat oder den Inhalt nicht korrekt empfangen
hat, das Netz auf, den Inhalt umzuverteilen. Dies kann auch eine
allgemeine Anfrage an das Netz wie „Sind in den letzten 24 Stunden
Neuigkeiten für
Multicast-Gruppe 123 ver teilt worden?". Eine Webseite kann eine Tabelle mit
Einträgen
enthalten, die die Zeiten widerspiegeln, zu denen Inhalt für eine spezifische
Broadcast- oder Multicast-Adresse
verteilt wurden. Alternativ kann eine regelmäßige Benachrichtigungsnachricht
diese Informationen enthalten. Die Anfrage, den Inhalt umzuverteilen,
kann Umverteilungspräferenzen,
wie die Träger,
die Zeit, Informationen zum Vorliegen und dergleichen, beinhalten.
Alternativ kann eine Verknüpfung
(ein Link) zu den Informationen zum Vorliegen bereitgestellt werden,
damit das Netz die Informationen von dort abrufen kann.
-
In
dem Fall, dass Multicasting verwendet wird, kann der Cachespeicher-Kontrollserver 53 gegebenenfalls
bei Schritt 58 bei dem BMSC 52 nachprüfen, um
zu bestimmen, ob der anfordernde Client 20 Teil der Multicast-Gruppe
ist. Ob nun Multicasting verwendet wird oder nicht, der Cachespeicher-Kontrollserver kann
auch bei anderen Servern nachprüfen,
um zu bestimmen, ob der anfordernde Client ansonsten autorisiert
ist, den Inhalt zu empfangen. Nach einer Analyse sendet das BMSC
(oder ein anderer Server) das Ergebnis bei Schritt 59 an
den Cachespeicher-Kontrollserver zurück. Im Fall eines nicht erfolgreichen
Analyseergebnisses kann der Cachespeicher-Kontrollserver gegebenenfalls
dem anfordernden Clienten mitteilen, dass der Inhalt nicht verfügbar ist.
Im Fall eines erfolgreichen Ergebnisses weist der Cachespeicher-Kontrollserver
einen der registrierten umverteilenden Clienten, wie den Clienten 19,
an, den Inhalt bei Schritt 61 an den anfordernden Clienten
zu senden. Die Auswahl des umverteilenden Clienten 19 kann
auf den Kriterien für
Anycasting in einem PLMN oder auf den von dem anfordernden Clienten
gesendeten Präferenzen
basieren. Bei Schritt 62 sendet der umverteilende Client 19 den
Inhalt an den anfordernden Clienten 20. Dies kann über einen
beliebigen der verfügbaren
leitungsvermittelten oder paketvermittelten Träger oder eine Kombination dieser
vorgenommen werden. Bei Schritt 63 sendet der Cachespeicher-Kontroll server
einen Berechnungsdatensatz an den C&B-Server 51, so dass dem
anfordernden Client 20 der Inhalt berechnet werden kann.
Darüber
hinaus kann dem umverteilenden Clienten 19 ein vordefinierter
Anreiz geboten werden. Der vordefinierte Anreiz wird vorzugsweise
im C&B-Server
abgewickelt und kann beispielsweise das Aufrüsten des Kontos des Clienten,
Verringern einer vorherigen Gebühr
oder das Verringern oder Streichen der Gebühr für den aktuellen Inhalt, der weitergeleitet
wird, beinhalten.
-
In
dem Fall, dass DRM gilt, werden der Inhalt und die Rechte getrennt
behandelt. Die in 5 gezeigte Abfolge beschreibt
die Umverteilung des Inhalts, der anfordernde Client 20 muss
jedoch die Rechte abrufen, um den Inhalt verwenden zu können. Das
BMSC 52 und der Cachespeicher-Kontrollserver 53 können ortsgleich
in einer einzigen Einheit angeordnet sein. Bei Schritt 56 kann,
anstelle von Anycasting, ein Client, der Inhalt umverteilen kann,
das Netz über
ein elementares Mitteilungsübermittlungssystem über seine
Verfügbarkeit
informieren. Im Fall eines nicht erfolgreichen Analyseergebnisses
bei Schritt 59 kann die fakultative Nachricht an den anfordernden
Clienten die Adresse des Inhaltsanbieters 12 (die von dem
BMSC über
den Cachespeicher-Kontrollserver weitergeleitet wurde) enthalten.
Der anfordernde Client kann dann diese Adresse dazu verwenden, den
Inhalt direkt von dem Inhaltsanbieter abzurufen oder zu versuchen,
ihn von diesem abzurufen. Nach Lieferung des Inhalts bei Schritt 62 kann
der anfordernde Client gegebenenfalls eine Inhaltsempfangsbestätigung an
den Cachespeicher-Kontrollserver senden, woraufhin der Cachespeicher-Kontrollserver
dem C&B-Server 51 mitteilt,
die Berechnung entsprechend zu ändern.
-
6 ist
ein vereinfachtes Funktionsblockdiagramm einer anderen Ausführungsform
des Systems der vorliegenden Erfindung. Dateninhalt 11 von
dem Inhaltsanbieter 12 wird über das Dienstnetz 13,
das Kernnetz 14 und das Funknetz 15 gesendet.
Am Funknetz wird der Inhalt von der BTS 16 an vier mobile
Clienten 17–20 rundgesendet/gruppengesendet
und drei der vier Clienten empfangen den Inhalt korrekt. Der Client 20,
der den Inhalt nicht empfangen hat oder ihn nicht korrekt empfangen
hat, überträgt Anfragen 65 lokal
auf der Suche nach Clienten, die den Inhalt an ihn umverteilen können. Ein
Client 19, der diese Anfrage zuerst hört, teilt dem Netz bei 66 mit,
dass er den Inhalt zwischengespeichert hat, und verteilt ihn dann
an den anfordernden Clienten um. Das Netz wird benachrichtigt, so
dass Berechnungsdaten entsprechend gehandhabt werden können.
-
7 ist
ein Zeichengabediagramm, das den Fluss von Zeichengabenachrichten
zwischen verschiedenen Netzfunktionseinheiten in der in 6 gezeigten
Ausführungsform
der vorliegenden Erfindung darstellt. In dieser Ausführungsform
wird eine lokale Schnittstelle, wie beispielsweise Bluetooth, zwischen
dem anfordernden und dem umverteilenden Clienten eingesetzt. Bei 71 sendet
der Inhaltsanbieter den Inhalt und den DCR-Indikator an das BMSC 52.
Gegebenenfalls kann der DCR-Indikator von dem BMSC erzeugt werden.
In einer anderen Option kann das BMSC die DCR löschen, wenn das BMSC aus einem
beliebigen Grund nicht wünscht,
dass Clienten den Inhalt zwischenspeichern und umverteilen. Bei
Schritt 72 leitet das BMSC 52 den Inhalt, den
DCR-Indikator und eine Anycast-Adresse unter Verwendung von geeigneten Übertragungsverfahren
an mehrere Clienten weiter. Der Inhalt und der DCR-Indikator können beispielsweise
an ein entsprechendes geografisches Gebiet weitergeleitet werden
(Broadcast) oder können
an jene geografischen Gebiete weitergeleitet werden, die viele registrierte
Clienten haben (Multicast). In diesem Beispiel wird der Inhalt von
den mobilen Clienten 18 und 19 korrekt empfangen.
Bei Schritt 73 bestimmt der mobile Client 20,
der den Inhalt nicht empfangen hat oder den Inhalt nicht korrekt
empfangen hat, ob andere nahe gelegene Clienten den Inhalt empfingen.
Diese Überprüfung kann
auf denselben, wie in Schritt 57 von
-
5 beschriebenen
Anfragenachrichten basieren. Ein Beispiel von Technologie, die hier
eingesetzt werden kann, ist Bluetooth. Umverteilungscharakteristika
(z. B. Träger,
QoS, Zeit usw.) können über diese
lokale Schnittstelle vereinbart werden. Die Überprüfung kann fragen, ob ein empfangender
Client Teil einer bestimmten Multicast-Gruppe ist, und, wenn jemand
antwortet, kann der anfordernde Client sich weiter erkundigen, ob
der antwortende Client innerhalb einer vordefinierten Zeitspanne,
wie beispielsweise drei Tage, jedweden Inhalt zwischenspeicherte.
Der mobile Client 20 kann auch eine allgemeine Anfrage
an das Netz senden, bei der er sich erkundigt, ob jedweder neuer
Inhalt verteilt wurde.
-
Bei
Schritt 74 kontaktiert ein umverteilender Client 19,
der die Anfrage empfängt
und dazu in der Lage und bereit ist, den Inhalt umzuverteilen, zunächst den
Cachespeicher-Kontrollserver 53 mit
einem Angebot, den Inhalt umzuverteilen, um die Erlaubnis zu erhalten,
dies vorzunehmen. Die Erlaubnisanfragenachricht enthält gegebenenfalls
die vereinbarten Umverteilungscharakteristika. Wenn Multicasting
verwendet wird, prüft der
Cachespeicher-Kontrollserver 53 bei Schritt 75 bei
dem BMSC 52 nach, um zu bestimmen, ob der anfordernde Client 20 Teil
der Multicast-Gruppe ist. Ob nun Multicasting verwendet wird oder
nicht, der Cachespeicher-Kontrollserver kann auch bei anderen Servern
nachprüfen,
um zu bestimmen, ob der Client ansonsten autorisiert ist, den Inhalt
zu empfangen. Nach einer Analyse sendet das BMSC (oder ein anderer
Server) das Ergebnis bei Schritt 76 an den Cachespeicher-Kontrollserver
zurück.
Bei Schritt 77 erteilt der Cachespeicher-Kontrollserver
dem umverteilenden Clienten 19 die Erlaubnis, den Inhalt
an den anfordernden Clienten 20 umzuverteilen. Bei Schritt 78 sendet
der umverteilende Client den Inhalt über die lokale Schnittstelle
an den anfordernden Clienten, sofern nicht zuvor eine andere Art
der Umverteilung vereinbart wurde. Der anfordernde Client bestätigt bei
Schritt 79 den Empfang des Inhalts von dem umverteilenden
Clienten und bei Schritt 80 sendet der Cachespeicher-Kontrollserver
einen Berechnungsdatensatz an den C&B-Server 51, so dass dem anfordernden
Client 20 der Inhalt berechnet werden kann. Darüber hinaus
kann dem umverteilenden Clienten 19 ein vordefinierter
Anreiz geboten werden. In dem Fall, dass DRM angewendet wird und
die Rechte vom Inhalt getrennt sind, können die Schritte 74–77 weggelassen
werden, da das Netz aus der Bestätigung
bei Schritt 79 weiß,
dass eine Inhaltsumverteilung stattgefunden hat.
-
8 ist
ein vereinfachtes Funktionsblockdiagramm einer anderen Ausführungsform
des Systems der vorliegenden Erfindung. Dateninhalt 11 von
dem Inhaltsanbieter 12 wird über das Dienstnetz 13,
das Kernnetz 14 und das Funknetz 15 gesendet.
Am Funknetz wird der Inhalt von der BTS/dem Knoten B 16 an
vier mobile Clienten 17–20 rundgesendet/gruppengesendet
und drei der vier Clienten empfangen den Inhalt korrekt. In dieser
Ausführungsform
senden die Clienten 17–19,
die den Inhalt erfolgreich empfingen und die die verteilte Cachespeichermethodik
unterstützen,
Nachrichten 81 an eine Inhaltabrufsregistrierungsdatenbank
(Content Retrieval Registry, CRR) 82, bei der sie die Tatsache
registrieren, dass sie den Inhalt verfügbar haben. Die CRR kann eine
zentrale Registrierungsdatenbank sein, kann ortsgleich in dem Inhalteserver
oder dem Cachespeicher-Kontrollserver angeordnet sein oder kann
eine verteilte Registrierungsdatenbank sein. Bei 83 fragt der
Client 20, der den Inhalt nicht empfangen hat oder ihn
nicht korrekt empfangen hat, die CRR, welcher der mobilen Clienten
den Inhalt verfügbar
hat. Vorzugsweise wird dann dem anfordernden Clienten bei Schritt 84 die
Kennung des nächsten
Clienten, der den Inhalt umverteilen kann, bereitgestellt. Der anfordernde
Client kontaktiert danach bei 85 den nächsten Clienten und der Inhalt 11 wird
anschließend
von dem nächsten
Clienten, der den Inhalt verfügbar
hat, an den anfordernden Clienten umverteilt.
-
9 ist
ein Zeichengabediagramm, das den Fluss von Zeichengabenachrichten
zwischen verschiedenen Netzfunktionseinheiten in der in 8 gezeigten
Ausführungsform
der vorliegenden Erfindung darstellt. Zu Veranschaulichungszwecken
sind auch drei mobile Clienten 18–20 gezeigt. Bei 91 sendet
der Inhaltsanbieter den Inhalt an das BMSC 52. Neben dem
eigentlichen Inhalt sendet der Inhalteserver einen DCR-Indikator, um dem
BMSC diese Präferenz
mitzuteilen. Gegebenenfalls kann der DCR-Indikator von dem BMSC
erzeugt werden. In einer anderen Option kann das BMSC die DCR löschen, wenn
das BMSC aus einem beliebigen Grund nicht wünscht, dass Clienten den Inhalt
zwischenspeichern und umverteilen. Bei Schritt 92 leitet
das BMSC den Inhalt und den DCR-Indikator unter Verwendung von geeigneten Übertragungsverfahren
an mehrere Clienten weiter. Der Inhalt und der DCR-Indikator können beispielsweise
an ein entsprechendes geografisches Gebiet weitergeleitet werden
(Broadcast) oder können
an jene geografischen Gebiete weitergeleitet werden, die viele registrierte
Clienten haben (Multicast). Des Weiteren kann eine Anycast-Adresse
eingebunden und von den Clienten 18–20 dazu verwendet
werden, dem Netz (beispielsweise dem dedizierten Cachespeicher-Kontrollserver 53 in
dem Netz) mitzuteilen, dass sie bereit sind, den Inhalt zwischenzuspeichern
und umzuverteilen. In dem gezeigten Beispiel empfangen die mobilen
Clienten 18 und 19 den Inhalt.
-
Die
mobilen Clienten 18 und 19 senden Nachrichten 81 an
die CRR 82, bei der sie die Tatsache registrieren, dass
sie den Inhalt verfügbar
haben. Bei Schritt 83 überträgt der Client 20,
der den Inhalt nicht empfangen hat oder ihn nicht korrekt empfanger
hat, eine Anfrage nach dem Inhalt an die CRR 82. Der mobile
Client kann auch eine allgemeine Anfrage an das Netz senden, bei
der er sich erkundigt, ob jedweder neuer Inhalt verteilt wurde.
Bei Schritt 93 fragt die CRR den Cachespeicher-Kontrollserver 53 ab,
um zu bestimmen, ob der anfordernde Client 20 autorisiert
ist, den Inhalt zu empfangen. Wenn Multicasting verwendet wird,
prüft der
Cachespeicher-Kontrollserver 53 bei Schritt 94 bei
dem BMSC 52 nach, um zu bestimmen, ob der anfordernde Client 20 Teil
der Multicast-Gruppe ist. Ob nun Multicasting verwendet wird oder
nicht, der Cachespeicher-Kontrollserver kann auch bei anderen Servern
nachprüfen,
um zu bestimmen, ob der Client ansonsten autorisiert ist, den Inhalt
zu empfangen. Nach einer Analyse sendet das BMSC (oder ein anderer
Server) das Ergebnis bei Schritt 95 an den Cachespeicher-Kontrollserver
zurück.
Im Fall eines erfolgreichen Ergebnisses teilt der Cachespeicher-Kontrollserver
der CRR bei Schritt 96 mit, dass der anfordernde Client
autorisiert ist, den Inhalt zum empfangen. Im Fall eines nicht erfolgreichen
Analyseergebnisses kann der Cachespeicher-Kontrollserver oder die
CRR gegebenenfalls dem anfordernden Clienten mitteilen, dass der
Inhalt nicht verfügbar
ist. Bei Schritt 84 wird dann dem anfordernden Clienten
die Kennung des nächsten
Clienten, der den Inhalt umverteilen kann, bereitgestellt. Bei Schritt 85 fordert
danach der anfordernde Client den Inhalt von dem nächsten Clienten 19 an
und bei Schritt 97 wird der Inhalt von dem nächsten Clienten 19 an
den anfordernden Clienten 20 umverteilt. Bei Schritt 98 teilt
der anfordernde Client der CRR mit, dass der Inhalt empfangen wurde.
Bei Schritt 99 sendet die CRR eine Meldung an den Cachespeicher-Kontrollserver,
die anzeigt, dass die Umverteilung abgeschlossen ist. Bei Schritt 100 sendet
der Cachespeicher-Kontrollserver dann einen Berechnungsdatensatz an
den C&B-Server 51,
so dass dem anfordernden Client 20 der Inhalt berechnet
werden kann.
-
10 ist
ein vereinfachtes Funktionsblockdiagramm eines mobilen Clienten 19,
der modifiziert ist, Dateninhalt gemäß der vorliegenden Erfindung
zwischenzuspeichern und umzuverteilen. Hochfrequenzsignale werden über eine
Antenne 102, die über
einen Multiplexerschaltkreis 103 an einen Sender 104 und
einen Empfänger 105 angeschlossen
ist, übertragen und
empfangen. Der Sender und der Empfänger sind an einen Prozessor 106 angeschlossen
und werden von diesem gesteuert. Eine Benutzeroberfläche 107 beinhaltet
eine Anzeige 108 und eine Tastatur 109. Der Prozessor
kann Programmieranweisungen von einem Festwertspeicher (read-only
memory, ROM) 111 abrufen. Dateninhalt 11, der
von dem mobilen Clienten empfangen wurde, ist in einem Dateninhaltsspeicher 112 gespeichert.
-
Der
Prozessor 106 kann gegebenenfalls mit einer Anycast-Funktion 113 programmiert
sein, die dem mobilen Clienten ermöglicht, Anycast-Adressen zu
empfangen und zu verstehen und auf den nächsten einer Gruppe von mobilen
Clienten zuzugreifen, die sich dieselbe Anycast-Adresse teilen.
Der Prozessor ist außerdem
mit einer Umverteilungsfunktion 114 programmiert, die dem
mobilen Clienten ermöglicht,
den DCR-Indikator
(DCR = distributed caching request, verteilte Caching-Anfrage) zu
empfangen und zu verstehen, Nachrichten an den Cachespeicher-Kontrollserver 53 oder
die CRR 82 zu senden, wobei er anbietet, zwischengespeicherten
Inhalt umzuverteilen, auf Anweisungen von dem Cachespeicher-Kontrollserver oder
der CRR, den Inhalt an einen identifizierten anfordernden Clienten
umzuverteilen, zu antworten und auf Anfragen von einem anfordernden
Clienten, Inhalt an den anfordernden Clienten umzuverteilen, zu
antworten.
-
Die
vorliegende Erfindung stellt eine effiziente Lösung für Inhaltsanbieter (Content-Provider)
und/oder Netzbetreiber bereit, einen Inhaltsempfang in einer späteren Phase
zu garantieren, wenn Inhalt an mehrere Clienten verteilt wird. Sie
stellt diese Garantie bereit, wenn der Inhalt überhaupt nicht empfangen wurde
oder nicht korrekt empfangen wurde (and somit möglicherweise nicht verwendet
werden kann). Die Lösung
ist effizient, da der Inhaltsumverteilungspfad in vielen Fällen verkürzt ist
und keine Netzressourcen zum Zwischenspeichern und Umverteilen des
Inhalts verwendet werden. Stattdessen verteilen Client-Vorrichtungen,
die möglicherweise
den Inhalt sowieso für
eine gewisse Zeit speichern, den Inhalt auf Anfrage um. Somit sparen der
Inhaltsanbieter und/oder der Netzbetreiber Netzressourcen und somit
Geld, indem sie einen solchen verteilten Inhaltcachespeicher anwenden.
Folglich können
der Inhaltsanbieter und/oder der Netzbetreiber Clienten (Kunden),
die den Inhalt zwischenspeichern und umverteilen, verschiedene Anreize
bieten. Der Inhaltsanbieter kann beispielsweise Inhalt oder Benutzerrechte
kostenfrei bereitstellen oder der Betreiber kann einen Abzug auf
der Monatsrechnung eines Kunden bieten, jedes Mal, wenn der Kunde
sich anbietet oder tatsächlich den
Inhalt an einen anfordernden Clienten weiterleitet.
-
Obgleich
die vorliegende Erfindung detailliert unter Bezugnahme auf nur ein
paar beispielhafte Ausführungsformen
beschrieben wurde, werden Fachmänner
zu schätzen
wissen, dass verschiedene Modifikationen vorgenommen werden können, ohne
von der Erfindung abzuweichen. Demgemäß ist die Erfindung nur durch
die folgenden Ansprüche
definiert, die alle Äquivalente
davon umspannen sollen.
