-
QUERVERWEISE ZU VERWANDTEN ANMELDUNGEN
-
Diese Anmeldung beansprucht die Priorität und den Vorteil der am 2. September 2014 eingereichten endgültigen US-Patentanmeldung Nr.
14/475,042 mit dem Titel „SMS PROXYING“ und der am 30. Mai 2014 eingereichten vorläufigen US-Patentanmeldung Nr.
62/005,336 mit dem Titel „SMS PROXYING“. Jede dieser Anmeldungen ist für alle Zwecke vollständig durch Verweis hierin integriert.
-
Diese Anmeldung bezieht sich auf die folgenden US-Patentanmeldungen: Vorläufige
US-Patentanmeldung Nr. 62/005,550 , eingereicht am 30. Mai 2014, mit dem Titel „ANSWER AND HOLD WITH CLIENT AND HOST“, von Rauenbuehler et al. (Az. Nr. P23I72USP1); Vorläufige US-Patentanmeldung Nr.
62/005,534 , eingereicht am 30. Mai 2014, mit dem Titel „ANSWERING A CALL WITH CLIENT THROUGH A HOST“, von Rauenbuehler et al. (Az. des Anwalts P23171 USP1); Vorläufige US-Patentanmeldung Nr.
62/005,606 , eingereicht am 30. Mai 2014, mit dem Titel „CLIENT APPLICATIONS COMMUNICATING VIA A USER TUNNEL“ von Tung et al. (Az. P23188USP1); Vorläufige US-Patentanmeldung Nr.
62/005,325 , eingereicht am 30. Mai 2014 mit dem Titel „PROXIED PUSH“ von Pollack et al. (Az. P23053USP1); Vorläufige US-Patentanmeldung Nr.
62/005,505 eingereicht am 30. Mai 2014 mit dem Titel „MANAGING CONNECTIONS OF A USER DEVICE“ von Schobel et al. (Az. P23295USP1) Vorläufige US-Patentanmeldung Nr.
62/005,565 eingereicht am 30. Mai 2014 mit dem Titel „APPLICATION-LEVEL ACKNOWLEDGEMENTS“ von Pollack et al. (Az. P23189USP1); Vorläufige US-Patentanmeldung Nr.
62/005,586 eingereicht am 30. Mai 2014 mit dem Titel „MESSAGES WITH ATTENUATING RETRANSMIT IMPORTANCE“ von Pollack et al. (Az. P23190USP1); Vorläufige US-Patentanmeldung Nr. eingereicht am 30. Mai 2014 mit dem Titel „UNIFIED MESSAGE DELIVERY BETWEEN PORTABLE ELECTRONIC DEVICES“ von Pollack et al. (Az: P22929USP1); Vorläufige US-Patentanmeldung Nr.
62/005,990 eingereicht am 30. Mai 2014 mit dem Titel „USER INTERFACE FOR PHONE CALL ROUTING AMONG DEVICES“ von Coffman et al. (Az. P23298USP1); und Vorläufige US-Patentanmeldung Nr. 62/505,799, eingereicht am 30. Mai 2014 mit dem Titel „PROTOCOL SWITCHING IN INTER-DEVICE COMMUNICATION“ von Prats et al. (Az. P22319USP1), die sich in gemeinsamem Besitz befinden und hierin für alle Zwecke durch Verweis integriert sind. Die vorliegende Anmeldung ist ebenfalls verwandt mit der Vorläufigen
US-Patentanmeldung Nr. 61/953,591 , mit dem Titel „DYNAMIC LINK ADAPTATION FOR IMPROVED LINK MARGIN,“ von Liu et al., eingereicht am 14. März 2014, die hierin für alle Zwecke durch Verweis integriert ist.
-
HINTERGRUND
-
Die vorliegende Offenbarung bezieht sich im Allgemeinen auf Kommunikation zwischen elektronischen Geräten und insbesondere auf die Verwendung von Kommunikationsfähigkeiten von Proxy-Geräten im Auftrag von Proxied-Geräten.
-
Elektronische Geräte, wie beispielsweise Computer, Laptops, Palmtops, Mobiltelefone, Smartphones, Multimedia-Handys, tragbare Media-Player, GPS-Geräte, mobile Spielesysteme etc. sind sehr beliebt geworden. Viele Benutzer nehmen ein solches Gerät fast überall hin mit. Sie benutzen ihre Geräte auch für viele verschiedene Zwecke, unter anderem zum Telefonieren, zum Senden und Empfangen von Textnachrichten und E-Mails, zur Navigation (z.B. Benutzung von Karten und/oder GPS-Empfängern), Kauf von Artikeln in Stores (z.B. Verwendung von kontaktlosen Bezahlsystemen) und/oder Zugriff auf das Internet (z.B. zum Abfragen von Informationen).
-
Der Kurznachrichtendienst „Short Message Service“ (SMS) ist eine Textnachrichtendienst-Komponente von Telefon-, Web- oder mobilen Kommunikationssystemen. Er verwendet standardisierte Kommunikationsprotokolle, um es Festnetz- oder Mobiltelefonen zu ermöglichen, kurze Textnachrichten auszutauschen. SMS ist zu einer der am weitesten verbreiteten Datenanwendungen geworden, in Studien wurden geschätzte 3,5 Mrd. aktive Benutzer bzw. ca. 80% aller Mobilfunkteilnehmer ermittelt. Obwohl die meisten SMS-Nachrichten Textnachrichten von Mobiltelefon zu Mobiltelefon sind, wurde der Support für diesen Dienst ausgeweitet und umfasst nunmehr auch andere Mobilfunktechnologien, wie zum Beispiel die ANSI CDMA-Netzwerke und Digital AMPS, sowie Satelliten- und Festnetze. Der Multimedia Messaging Service (MMS) ist ein Standardverfahren zum Versenden von Nachrichten mit multimedialen Inhalten sowohl an Mobiltelefone als auch ausgehend von Mobiltelefonen. Er erweitert die SMS-Kernfähigkeit, die den Austausch von Textnachrichten mit einer Länge von bis zu 160 Zeichen ermöglicht. Die beliebteste Nutzung besteht darin, Fotos von Handys mit integrierter Kamera zu versenden, obwohl die Bereitstellung von Nachrichten und Unterhaltungsinhalten einschließlich Musik, Videos, Bildern, Internetseiten und Einkäufe in der digitalen Welt sich ebenfalls großer Beliebtheit erfreut.
-
Häufig kauft ein Benutzer ein Gerät wegen seiner primären Funktion, beispielsweise kauft er ein Smartphone, um damit zu telefonieren und zieht dafür wohl weniger ein Tablet in Betracht. Daher kommt es häufig vor, dass Benutzer mehrere Geräte besitzen. Die Geräte eines Benutzers können viele verschiedene Zweckbestimmungen haben, einige davon überlappen sich, andere wiederum nicht. Ein Problem ist, dass die Benutzer es als frustrierend empfinden, dass sie ihre Aufmerksamkeit von einem Gerät auf ein anderes lenken müssen, wenn sie eine spezifische Fähigkeit des letzteren Geräts nutzen wollen, die das erste Gerät nicht besitzt. Außerdem können einige Geräte Hardware-Fähigkeiten haben, deren Nutzung aber - durch entsprechende Vorkehrungen, sei es in der Hardware oder in der Software - nicht aktiviert oder in irgendeiner Form eingeschränkt ist.
-
Was folglich erwünscht ist, ist die Lösung von Problemen im Hinblick auf die Koordination und Abwicklung der Zustellung von SMS/MMS-Nachrichten, die von Geräten ausgehen, denen die Hardware oder die Fähigkeit fehlt, SMS/MMS-Nachrichten über Mobilfunknetze zu senden, an Geräte, die sehr wohl dazu in der Lage sind, diese Nachrichten über Mobilfunknetze zu versenden, von denen einige hier erläutert werden. Außerdem ist es erwünscht, die Nachteile im Zusammenhang mit der Erweiterung der Funktionalität und der Erreichbarkeit von Geräten zu verringern, denen die Hardware oder Fähigkeit fehlt, SMS/MMS-Nachrichten über Mobilfunknetze zu versenden, von denen einige hier erläutert werden.
-
Die Druckschrift
US 2010 0093382 A1 offenbart ein Verfahren zum Senden und Empfangen textbasierter Nachrichten unter Verwendung eines Proxy-Mobiltelefons. Das Senden umfasst das Empfangen einer ausgehenden textbasierten Nachricht und das Senden der Nachricht und einer Anweisung für ein Proxy-Mobiltelefon zum Empfangen der Nachricht und Weiterleiten der Nachricht über ein drahtloses Telefonnetz an eine Zielvorrichtung.
-
Die Druckschrift
US 2008 0313284 A1 offenbart eine drahtlose Vorrichtung, die als Caching-Daten-Proxy für eine erste Vorrichtung dient. Insbesondere ist ein Mobiltelefon als ein Caching-Daten-Proxy mit einer drahtlosen tragbaren Computervorrichtung assoziiert. Das Mobiltelefon speichert Daten als Proxy für die tragbare Computervorrichtung zwischen, wenn die tragbare Computervorrichtung sich entweder außerhalb der Netzabdeckung befindet, ausgeschaltet ist oder dergleichen.
-
KURZE ZUSAMMENFASSUNG
-
Die Erfindung ist in den unabhängigen Ansprüchen definiert. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen definiert.
-
Es werden ein System und ein Verfahren zur Herstellung einer Zweiwegekommunikation zwischen Geräten beschrieben, die eine bestimmten Menge an Hardware und/oder Fähigkeiten haben, die es den Geräten ermöglichen, SMS/MMS-Nachrichten im Auftrag von Geräten, welche diese Hardware und/oder Fähigkeiten nicht besitzen, über Mobilfunknetze zu versenden und zu empfangen. Da es für einen Benutzer teuer oder ineffizient sein kann, Geräte, denen die gewünschte Fähigkeit fehlt, durch die Anschaffung neuer Geräte zu ersetzen, welche die gewünschte Fähigkeit besitzen, oder mehrere Geräte zu haben, welche die gleichen Fähigkeiten aufweisen, können in verschiedenen Ausführungsformen Geräte, denen bestimmte Fähigkeiten fehlen (und die als Proxied-Geräte fungieren) die Fähigkeiten nutzen, die in anderen Geräten vorhandenen sind (indem diese als Proxy-Geräte fungieren).
-
In einigen Ausführungsformen kann ein Benutzer mehrere Geräte, die jeweils andere Hardware- und/oder Software-Fähigkeiten besitzen, unter einer eindeutigen Benutzerkennung registrieren. Während der Registrierung kann ein Identitätsverwaltungsdienst die Hardware- und/oder Software-Fähigkeiten der mit dem Benutzer assoziierten Geräte erfassen. Die erfassten Fähigkeiten eines der Geräte eines Benutzers können einem anderen Gerät dieses Benutzers zugeteilt werden. Wenn ein erstes einem Benutzer zugeordnetes Gerät die Gerätefähigkeit nicht besitzt, die ein anderes diesem Benutzer zugeordnetes Gerät hat, kann das erste Gerät beim Identitätsverwaltungsdienst die Geräte des Benutzers erfragen, welche die gewünschte Fähigkeit besitzen. Das erste Gerät kann direkt oder indirekt mit dem zweiten Gerät interagieren, um zu veranlassen, dass das zweite Gerät mithilfe der gewünschten Gerätefähigkeit bestimmte Vorgänge ausführt.
-
In einem Ausführungsbeispiel fragt das Gerät eines Benutzers, dem SMS/MMS-Fähigkeiten fehlen, bei einem Identitätsverwaltungsdienst die Gerätefähigkeiten anderer Geräte ab, die demselben Benutzer zugeordnet sind. Das Gerät des Benutzers, dem die SMS/MMS-Fähigkeiten fehlen, kann vom Identitätsverwaltungsdienst für jedes dem Benutzer zugeordnete Gerät ein Geräteprofil erhalten. Das Geräteprofil kann ein oder mehrere Felder, Markierungen (Flags) oder Kennungen beinhalten, welche die Hardware und/oder Software-Fähigkeiten eines Geräts anzeigen oder in anderer Weise darauf hinweisen. Das Gerät des Benutzers ohne SMS/MMS-Fähigkeiten kann ein Gerät wählen, das SMS/MMS-Fähigkeiten hat und basierend auf seinem Geräteprofil, welches die SMS/MMS-Fähigkeiten ausweist, als Proxy fungieren soll.
-
In einigen Ausführungsformen kann ein Benutzergerät ohne SMS/MMS-Fähigkeiten eine Nachricht erzeugen, die an ein Gerät mit SMS/MMS-Fähigkeiten geht und dieses Gerät mit SMS/MMS-Fähigkeiten anweist, mithilfe seiner SMS/MMS-Fähigkeiten Nutzdaten (Payload) an ein Ziel zu übermitteln. Das Benutzergerät ohne SMS/MMS-Fähigkeiten kann die Nachricht an einen Messaging-Dienst senden, der dann die Nachricht an das vorgesehene Gerät, das SMS/MMS-Fähigkeiten hat, übermittelt, zusammen mit der Anweisung, mithilfe der SMS/MMS-Fähigkeiten des Geräts die Nutzdaten an das Ziel zu senden. Eine Benutzeroberfläche des Geräts ohne SMS/MMS-Fähigkeiten kann während des Vorgangs Fortschrittsinformationen anzeigen. In verschiedenen Ausführungsformen kann das Gerät mit SMS/MMS-Fähigkeiten Informationen senden, die das Versenden der Nutzdaten an das Ziel auf einem oder allen dem Benutzer zugeordneten Geräten anzeigen.
-
Bestimmte Ausführungsformen der Erfindung beziehen sich auf die Kommunikation zwischen einem Tablet, das keine SMS/MMS-Fähigkeiten hat (als ein Proxied-Gerät) und einem Smartphone mit SMS/MMS-Fähigkeiten (als Proxy-Gerät). Zum Beispiel kann ein Tablet als verwaltete Entität eine Verbindung zu einem Identitätsverwaltungsdienst herstellen. Das Tablet kann vom Identitätsverwaltungsdienst eine Reihe von Geräteprofilen erhalten, die das Geräteprofil des Smartphones umfassen. Das Tablet kann aus dem Geräteprofil des Smartphones erkennen, dass das Smartphone SMS/MMS-Fähigkeiten hat. Aus einer Reihe von Verfahren zum Erzeugen einer Nachricht oder zum Senden einer Nachricht an das Smartphone, mit der das Smartphone angewiesen wird, die Nachricht als SMS/MMS-Nachricht an einen Empfänger zu übermitteln, kann das Tablet irgendein Verfahren auswählen. Folglich können die SMS/MMS-Fähigkeiten des Smartphones durch das Tablet genutzt werden, das selbst keine SMS/MMS-Fähigkeiten besitzt.
-
In einigen Ausführungsformen kann ein Proxy-Gerät mit SMS/MMS-Fähigkeiten eine Nachricht von einem Proxied-Gerät ohne SMS/MMS-Fähigkeiten empfangen. Das Proxy-Gerät kann bestimmen, dass die Nachricht unter Einsatz seiner SMS/MMS-Fähigkeiten an einen Empfänger zu senden ist. Das Proxy-Gerät kann sich mit seinem Mobilfunkanbieter verbinden und eine SMS/MMS-Nachricht an den Empfänger senden. Wenn beim Proxy-Gerät eine Antwortnachricht vom Empfänger der SMS/MMS-Nachricht eingeht, kann das Proxy-Gerät eine Nachricht mindestens an das Gerät senden, das keine SMS/MMS-Fähigkeiten hat und es ermöglichen, dass die Antwortnachricht auf einer Benutzeroberfläche des Geräts ohne SMS/MMS-Fähigkeiten erscheint.
-
Ein weitergehendes Verständnis des Wesens des Erfindungsgegenstands und seiner Äquivalente (sowie alle darin vorgesehenen inhärenten oder ausdrücklichen Vorteile und Verbesserungen) dürfte zusätzlich zum Vorstehenden durch Berücksichtigung auch der nachfolgenden Teile dieser Offenbarung einschließlich der beigefügten Zeichnungen und der Ansprüche erlangt werden.
-
Figurenliste
-
Zur angemessenen Beschreibung und Veranschaulichung der in dieser Offenbarung enthaltenen Innovationen, Ausführungsformen und/oder Beispiele kann auf eine oder mehrere beigefügte Zeichnung(en) Bezug genommen werden. Die zur Beschreibung einer oder mehrerer beigefügter Zeichnungen verwendeten Details oder Beispiele sollten nicht als Einschränkungen des Schutzumfangs irgendeiner der beanspruchten Erfindungen, irgendwelcher der hierin beschriebenen Ausführungsformen und/oder Beispiele, und auch nicht als die beste Ausführungsart irgendwelcher in dieser Offenbarung dargestellten Innovationen betrachtet werden.
- 1 ist ein Blockdiagramm eines Geräteverwaltungs- und Inhaltsbereitstellungs-Ökosystems gemäß verschiedener Ausführungsformen.
- 2 ist ein Blockdiagramm eines Inhaltsbereitstellungssystems im Geräteverwaltungs- und Inhaltsbereitstellungs-Ökosystem der 1 gemäß verschiedener Ausführungsformen.
- 3 ist ein Flussdiagramm eines Verfahrens zur Durchführung von Proxied SMS/MMS-Messaging gemäß verschiedener Ausführungsformen.
- 4 ist ein Blockdiagramm, welches veranschaulicht, wie gemäß einer Ausführungsform ein Identitätsverwaltungsdienst Geräteprofile verwaltet.
- 5 ist ein Message Sequence Chart (Nachrichten-Reihenfolge-Diagramm), welches die Herstellung von Proxy- und Proxied-Fähigkeiten für SMS/MMS-Proxying gemäß verschiedener Ausführungsformen veranschaulicht.
- 6 ist ein Message Sequence Chart, welches einen Überblick über SMS/MMS-Proxying gewährt, gemäß verschiedener Ausführungsformen.
- 7 ist ein Flussdiagramm eines Verfahrens, das von einem Proxied-Gerät ohne eigene SMS/MMS-Fähigkeiten zur Übermittlung von SMS/MMS-Nachrichten an ein Proxy-Gerät, das SMS/MMS-Fähigkeiten besitzt, durchgeführt wird, gemäß einer Ausführungsform.
- 8 ist ein Flussdiagramm eines Verfahrens, das von einem Proxy-Gerät mit SMS/MMS-Fähigkeiten zur Handhabung von SMS/MMS-Nachrichten im Auftrag von Proxied-Geräten durchgeführt wird, die selbst keine SMS/MMS-Fähigkeiten haben, gemäß einer Ausführungsform.
- 9 ist ein Message Sequence Chart, welches veranschaulicht, wie Antwort-SMS/MMS-Nachrichten, die an Proxy-Geräte mit SMS/MMS-Fähigkeiten übermittelt wurden, an Proxied-Geräte gesendet werden, die selbst keine SMS/MMS-Fähigkeiten besitzen, gemäß einer Ausführungsform.
- 10 zeigt einen Protokollstapel für die Kommunikation von Daten gemäß Ausführungsformen der vorliegenden Erfindung.
- 11 ist ein Blockdiagramm eines tragbaren elektronischen Geräts oder eines Mobilgeräts gemäß einer Ausführungsform.
-
AUSFÜHRLICHE BESCHREIBUNG
-
I. EINFÜHRUNG
-
Es werden System und Verfahren für die Herstellung von Zweiwegekommunikation zwischen Geräten beschrieben, die eine bestimmte Menge an Hardware und/oder Fähigkeiten haben, welche es den Geräten ermöglicht, SMS/MMS-Nachrichten über Mobilfunknetze im Auftrag von Geräten zu senden und zu empfangen, denen diese Hardware und/oder Fähigkeiten fehlen. Da es für einen Benutzer teuer oder ineffizient sein kann, Geräte, denen die gewünschte Fähigkeit fehlt, durch die Anschaffung neuer Geräte zu ersetzen, welche die gewünschte Fähigkeit besitzen, oder mehrere Geräte zu haben, welche die gleichen Fähigkeiten aufweisen, können in verschiedenen Ausführungsformen Geräte, denen bestimmte Fähigkeiten fehlen (und die als Proxied-Geräte fungieren) die Fähigkeiten nutzen, die in anderen Geräten vorhandenen sind (indem diese als Proxy-Geräte fungieren).
-
A. System
-
1 ist ein Blockdiagramm eines Geräteverwaltungs- und Inhaltsbereitstellungs-Ökosystems 100 gemäß verschiedener Ausführungsformen. 1 und andere Figuren veranschaulichen lediglich eine Ausführungsform oder Implementierung einer hierin offenbarten Erfindung und sollten den Schutzumfang einer Erfindung nicht über die Angaben in den Ansprüchen hinaus beschränken. Durch diese Offenbarung und die hierin dargestellten Lehren kann ein Durchschnittsfachmann weitere Variationen, Modifikationen und/oder Alternativen zu den Ausführungsformen oder Implementierungen erkennen, die in den Figuren veranschaulicht sind. Die Vorrichtungen im Ökosystem 100 können Hardware- und/oder Software-Elemente umfassen.
-
In einer Ausführungsform enthält das Ökosystem 100 eine Identitätsverwaltungs-Infrastruktur 105, eine Inhaltsinfrastruktur 110 (d.h. einen oder mehrere Server, die einen Sprach-/Videoanrufdienst, einen Messaging-Dienst und/oder einen Push-Benachrichtigungsdienst implementieren), Mobilgerät 115, Begleitgerät 120, Benutzergerät 125, Provider 130 und Provider 135 und Kommunikationsnetzwerk 140. Wie veranschaulicht, sind die Identitätsverwaltungs-Infrastruktur 105, die Inhaltsinfrastruktur 110, das Mobilgerät 115, das Begleitgerät 120, das Benutzergerät 125, der Provider 130 und der Provider 135 allesamt in der Lage, mit und durch das Kommunikationsnetzwerk 140 zu kommunizieren (welches das Internet, Wide Area Networks (WANs), Metropolitan Area Networks (MANs), Local Area Networks (LANs), Wireless Local Area Networks (WLANs), Radio Access Networks (RANs), das öffentliche Telefonnetz (Public Switched Telephone Network - PSTN) etc. und/oder Kombinationen derselben darstellt. Das Mobilgerät 115 kann direkt mit dem Begleitgerät 120 kommunizieren, ohne das Kommunikationsnetzwerk 140 zu verwenden.
-
Die Identitätsverwaltungs-Infrastruktur 105 kann in verschiedenen Ausführungsbeispielen, mit einem Einzelserver-Computersystem implementiert werden, sie kann aber auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects u.Ä. umfassen. In verschiedenen Aspekten leistet die Identitätsverwaltungs-Infrastruktur 105 die Verwaltung einzelner Entitäten, ihre Authentifizierung, Autorisierung und Privilegien innerhalb von Systemen oder systemübergreifend, wie z.B. die Inhaltsinfrastruktur 110. Von der Identitätsverwaltungs-Infrastruktur 105 geleistete Identitätsverwaltungsdienste können Technologien und Dienste wie zum Beispiel Active Directory, Identity Providers, Passwortmanager, Zugriffssteuerungsanbieter, Single Sign-on (SSO)-Dienste, OAuth, Sicherheitstoken-Dienste , o.Ä. umfassen
-
In verschiedenen Ausführungsformen hält die Identitätsverwaltungs-Infrastruktur 105 Informationen bereit, welche die Identität der verwalteten Entität (z.B. einen Benutzer, eine Organisation und damit verbundene Geräte, Ressourcen, Applikationen o. Ä.) authentifiziert. Die Identitätsverwaltungs-Infrastruktur 105 kann verifizieren, dass eine Entität wirklich die Person oder Organisation ist, die sie behauptet zu sein, und zwar durch die Verwendung eines Passworts, eines biometrischen Verfahrens, z.B. Fingerabdruck oder eines charakteristischen Verhaltens, z.B. Gestenmuster auf einem Touchscreen, Aufforderungs-Antwort-Protokolle (Challenge-Response-Protokolle), Einmalpasswörter (OTPs), zweistufige Authentifizierung und sonstige Techniken. Die Identitätsverwaltungs-Infrastruktur 105 kann des Weiteren Autorisierungsinformationen verwalten, die bestimmen, welche Tätigkeiten eine Entität im Kontext einer spezifischen Applikation, eines Dienstes oder einer Ressource ausführen darf. Einige Autorisierungen können auf einer dieser Entität zugeordneten Rolle, einem Gerätetyp, einer Applikation, einem Applikationstyp oder Ähnlichem basieren. Die Identitätsverwaltungs-Infrastruktur 105 kann auch deskriptive Informationen über verwaltete Entitäten verwalten und bestimmen, wie und von wem diese Informationen abgerufen und modifiziert werden können.
-
In einigen Ausführungsformen erzeugt die Identitätsverwaltungs-Infrastruktur 105 digitale Identitäten für die verwalteten Entitäten, darunter z.B. entitäts- bzw. personenbezogene Informationen (PII) und Zusatzinformationen. In einem Aspekt kann eine verwaltete Entität mehrere digitale Identitäten haben, und jede digitale Identität kann mehrere Attribute umfassen. So kann bspw. ein Benutzer eine Benutzerkennung haben (z.B. Telefonnummer, E-Mail etc.), die mit mehreren Geräten verbunden ist. Die Identitätsverwaltungs-Infrastruktur 105 kann die Erzeugung, Löschung und Modifizierung digitaler Identitäten verwalten, und darüber hinaus kann sie auch entitätsbezogene Zusatzdaten verwalten, die zur Nutzung durch Dienste wie dem Inhaltsinfrastrukturdienst 110 bestimmt sind.
-
In weiteren Ausführungsformen kann die Identitätsverwaltungs-Infrastruktur 105 die Fähigkeiten eines jeden Geräts, das mit der Benutzerkennung verbunden ist, speichern. Beispiele für Gerätefähigkeiten umfassen, ob ein Gerät einen spezifischen Hardwaretyp oder eine Hardwareversion beinhaltet, ob ein Gerät einen spezifischen Softwaretyp oder eine Softwareversion (z.B. Betriebssystem oder Applikationen) beinhaltet, ob ein Gerät in der Lage ist, eine spezifische Funktion auszuführen, wie zum Beispiel Tätigen und Entgegennehmen von Anrufen oder Senden und Empfangen von SMS/MMS-Kurzmitteilungen, ob ein Gerät in der Lage ist, Verbindungen mit anderen Geräten aufrechtzuerhalten o.Ä. Die Liste der einem Benutzer zugeordneten Geräte kann an jedes andere Gerät des Benutzers gesendet und dort gespeichert werden, beispielsweise an das Mobilgerät 115 und das Begleitgerät 120, wenn diese derselben Benutzerkennung zugeordnet sind. Die Identitätsverwaltungs-Infrastruktur 105 kann außerdem die Fähigkeiten eines Geräts ermitteln und erfassen, solange dieses Gerät registriert und der Benutzerkennung zugeordnet ist. Die Identitätsverwaltungs-Infrastruktur 105 kann die Fähigkeiten eines Geräts in regelmäßigen Abständen aktualisieren, zum Beispiel wenn das Gerät sich erneut registriert oder mit einem oder mehreren Diensten kommuniziert, die von der Identitätsverwaltungs-Infrastruktur 105 verwaltet werden.
-
In verschiedenen Ausführungsformen kann die Identitätsverwaltungs-Infrastruktur 105 eine einzelne Benutzerkennung erhalten, die verwendet wird, um Gerätekennungen von Geräten zu ermitteln, die der Benutzerkennung zugeordnet sind. Um auf die Dienste oder Ressourcen zuzugreifen, die von der Identitätsverwaltungs-Infrastruktur 105 verwaltet werden, können während der Registrierung der Entität ein oder mehrere Benutzerkennungen oder sonstige Kennungen sowie eine eindeutige Entitäts- oder Gerätekennung (UID) kombiniert werden um ein Entitäts- oder Geräte-Token zu erzeugen. In verschiedenen Ausführungsformen wird das Token durch Anwendung eines Hashing-Algorithmus verschlüsselt (z.B. SHA-0, SHA-1, SHA-2, MD5, Whirlpool oder sonstige Hashing-Algorithmen). Das für eine Entität erzeugte und verschlüsselte Token kann in verschiedenen Ausführungsformen konstant bleiben. Sobald ein Token durch die Identitätsverwaltungs-Infrastruktur 105 erzeugt und verschlüsselt wurde, kann das Token zur Entität zurückgesendet werden. Für verschiedene Zwecke im Hinblick auf Authentifizierung, Autorisierung, Abrechnung u. Ä. der Entität bei den verwalteten Diensten oder Ressourcen, oder für die zuverlässige Bereitstellung von Inhalten an die Entität durch Dritte, kann die Entität in einigen Aspekten das Token an Dienste oder Ressourcen weiterleiten, die von der Identitätsverwaltungs-Infrastruktur 105 verwaltet werden, oder auch an Drittdienste.
-
Die Inhaltsinfrastruktur 110 kann vor Entitäten, die von der Identitätsverwaltungs-Infrastruktur 105 verwaltet werden, geschützt werden und/oder für sie zugänglich sein. Die Inhaltsinfrastruktur 110 kann in verschiedenen Ausführungsformen mit einem Einzelserver-Computersystem implementiert werden, sie kann aber auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects u. Ä. umfassen.
-
Die Inhaltsinfrastruktur 110 kann für das Mobilgerät 115, das Begleitgerät 120 und das Benutzergerät 125, sowie auch für andere Geräte und Entitäten Inhalte bereitstellen. Beispiele für Inhalte umfassen eine Textnachricht, eine Multimedia-Nachricht, ein bevorstehendes Kalenderereignis, ein Audio/Videoanruf (z.B. mithilfe von VOIP), oder eine Benachrichtigung über neue Daten auf einem Remote Server. In einer Ausführungsform können die Inhalte aus einer oder aus mehreren Quellen stammen, die von der Identitätsverwaltungs-Infrastruktur 105 verwaltet oder direkt von der Inhaltsinfrastruktur 110 bereitgestellt werden. In anderen Ausführungsformen können die Inhalte aus anderen Quellen stammen. Die Inhalte können z.B. vom Mobilgerät 115, vom Begleitgerät 120, vom Benutzergerät 125 oder von den Providern 130 und 135 ausgehen.
-
In einem anderen Ausführungsbeispiel können die Inhalte von anderen Quellen empfangen werden, wie zum Beispiel dem Internet, den Mobilfunknetzwerken, dem öffentlichen Telefonnetz u.Ä. Die Inhaltsinfrastruktur 110 kann dann die Inhalte zum Mobilgerät 115, Begleitgerät 120, Benutzergerät 125 und zu den Providern 130 und 135 befördern. In einer Ausführungsform kann die Inhaltsinfrastruktur 110 eine SMS-Nachricht, die von einem Mobilfunknetz empfangen wurde oder dorthin gehen soll, durch die Infrastruktur leiten. In einer anderen Ausführungsform kann die Inhaltsinfrastruktur 110 einen Sprachanruf, der von einem öffentlichen Telefonnetz eingegangen ist oder dorthin gehen soll, durch die Infrastruktur leiten.
-
In einigen Ausführungsformen können die an ein Mobilgerät 115 zu sendenden Inhalte an das Begleitgerät 120 zur Weiterleitung das Mobilgerät 115 gesendet werden. Das Begleitgerät 120 kann auch im Auftrag des Mobilgeräts 115 handeln und Signale senden. In diesen Ausführungsformen fungiert das Begleitgerät 120 als Hauptgerät oder Vermittlungsgerät, und das Mobilgerät 115 als Proxied-Gerät. Die Inhaltsinfrastruktur 110 kann koordinieren, ob und wie das Begleitgerät 120 im Auftrag des Mobilgeräts 115 handeln und Signale senden kann.
-
In einigen Ausführungsformen kann die Inhaltsinfrastruktur 110 gegebenenfalls Inhalte an mehr als ein Gerät senden. Einem Benutzer kann sowohl das Mobilgerät 115 als auch das Begleitgerät 120 zugeordnet werden. Die Inhaltsinfrastruktur 110 kann die Inhalte sowohl an das Mobilgerät 115 als auch an das Begleitgerät 120 leiten, so dass ein Anruf über VOIP auf beiden Geräten ein Klingelzeichen erzeugt oder eine Nachricht im Posteingang derselben Applikation erscheint, die auf beiden Geräten installiert ist. In anderen Ausführungsformen werden Inhalte an nur ein Gerät gesendet, z.B. an das Begleitgerät 120, das einen Anruf an das Mobilgerät 115 weiterleiten kann. Wenn ein Anruf an ein Gerät weitergeleitet wird, kann eine Telefonnummer feststellen, welches Gerät den Telefon-/Videoanruf erhalten soll, und gegebenenfalls kann dieses Gerät einen Anruf auch weiterleiten.
-
In einem Aspekt können Inhalte ein oder mehrere Datenelemente enthalten, wie zum Beispiel eine Gerätekennung (oder ein Token), wie vorstehend erläutert, sowie Nutzdaten. Ein Geräte-Token kann in Inhalten bereitgestellt werden, die von einem Provider (z.B. Provider 130 und/oder 135), von einem Gerät desselben Benutzers (z.B. entweder vom Mobilgerät 115 oder vom Begleitgerät 120 ), oder von einem Gerät eines anderen Benutzers (z.B. Benutzergerät 125), stammen, zusammen mit irgendwelchen Nutzdaten, welche der Provider unter Verwendung der Inhaltsinfrastruktur 110 geliefert bekommen möchte. Der Geräte-Token kann Informationen enthalten, die es der Inhaltsinfrastruktur 110 erlauben, ein Gerät zu orten, auf dem ein bestimmter Dienst oder eine Client-Applikation installiert ist und das für den Empfang der Inhalte registriert ist. Die Nutzdaten können neue Informationen umfassen, die in einer Server-Applikation empfangen werden, oder einen Hinweis darauf, wo die Informationen zu finden sind. Die Nutzdaten können außerdem eine Property List enthalten, in der angegeben ist, wie der Benutzer durch den entsprechenden Dienst oder die Client-Applikation auf die neuen Informationen aufmerksam gemacht werden soll.
-
Ein Hinweis (Alert) kann in einer Vielzahl von Formen auftreten. In einem Ausführungsbeispiel können die Inhalte dem Benutzer als eine Hinweismeldung oder sonstige visuelle Darstellung angezeigt werden, wie zum Beispiel ein Kennzeichen (Badge), das mit einem Applikations-Icon assoziiert ist. Die Verfügbarkeit der Inhalte kann zusätzlich durch das Abspielen einer Tonsequenz mitgeteilt werden, wenn gerade ein Hinweis oder Kennzeichen angezeigt wird. Wenn ein Benutzer benachrichtigt wird, dass eine Applikation oder ein Dienst gerade eine Nachricht, ein Ereignis oder weitere Inhaltsdaten für ihn hat, kann er die Applikation oder den Dienst starten und die Einzelheiten zum einen durch Betrachten der Inhalte oder der Informationen in einer Push-Mitteilung einsehen, wobei die Client-Applikation die angekündigten Informationen o. Ä. abruft. Zum anderen kann der Benutzer die Mitteilung auch ignorieren, und in diesem Fall wird die Applikation nicht aktiviert.
-
Wie vorstehend angedeutet, kann die Inhaltsinfrastruktur 110 Push-Benachrichtigungsdienste enthalten, die zusätzlich oder alternativ zu der Weiterleitung von Inhalten Mechanismen ausführen, so dass die auf den Benutzergeräten befindlichen Client-Applikationen von Push-Providern die Benutzer darüber informieren können, dass bei einer oder bei mehreren Server-Applikationen neue Inhalte verfügbar sind, und dass diese Inhalte bereits auf dem Gerät verfügbar sind oder gerade eingehen. Der hier benutzte Begriff Push-Provider (oder vereinfacht Provider) kann sich auf eine Entität beziehen, die Informationen hat, welche über eine Push-Benachrichtigungsinfrastruktur zu liefern und/oder weiterzuleiten sind. Im Allgemeinen setzen Softwareentwickler (die als Provider fungieren), Benachrichtigungen in ihrer Server-Software ab, sobald neue Daten für die Benutzer verfügbar sind. Ein Provider verbindet seine Server-Software über einen permanenten und sicheren Kanal mit der Inhaltsinfrastruktur 110. Die Identitätsverwaltungssoftware 105 kann sicherstellen, dass der Provider authentifiziert wird (d.h. dass der Provider derjenige ist, für den er sich ausgibt), dass er sodann dazu autorisiert wird, sich zu verbinden, und dass er die Inhaltsinfrastruktur in vertrauenswürdiger Weise nutzt.
-
Während der Provider auf eingehende Daten achtet, die für seine Client-Applikationen bestimmt sind, erstellt er in einem Aspekt immer dann, wenn neue Daten für eine Applikation eintreffen, eine Benachrichtigung und sendet sie über seine Kanalverbindung an die Inhaltsinfrastruktur 110, welche die Benachrichtigung an einen Push-Nutzer oder ein Zielgerät pusht. Die Identitätsverwaltungs-Infrastruktur 105 kann auch sicherstellen, dass der Nutzer oder das Zielgerät authentifiziert ist und dazu autorisiert ist, sich in vertrauenswürdiger Weise mit den Diensten der Inhaltsinfrastruktur 110 zu verbinden und diese zu nutzen. Ein Push-Nutzer (oder vereinfacht ein Nutzer oder ein Ziel) kann eine Entität sein, die dazu bestimmt ist, Informationen zu empfangen, die mithilfe der Inhaltsinfrastruktur 110 geliefert und/oder weitergeleitet werden. Obwohl das Vorstehende der Einfachheit halber einen Provider als den Absender von Inhalten oder von einer Benachrichtigung über verfügbare Inhalte darstellt, kann in einem Fall ein Provider zum Nutzer werden, und in einem anderen Fall kann dieses umgekehrt sein. Außerdem kann das Mobilgerät 115 ein Provider von Inhalten für das Begleitgerät 120 sein, und umgekehrt, ebenso kann der Provider 130 dem Provider 135 Inhalte anbieten, und umgekehrt.
-
In einem Beispiel für die Funktionsweise des Inhaltsinfrastrukturdiensts 110 wird der Push-Benachrichtigungsdienst von einem oder von mehreren Servern zur Verbreitung von Informationen zwischen dem Provider 130, dem Provider 135, dem Mobilgerät 115, dem Begleitgerät 120 und dem Benutzergerät 125 bereitgestellt, vorgehalten, verwaltet und betrieben. Jeder von ihnen kann mindestens eine permanente Verbindung (z.B. eine zertifizierte und verschlüsselte Internet Protocol-(IP) Verbindung) mit der Inhaltsinfrastruktur 110 herstellen, um über diese permanente Verbindung Inhalte zu senden und/oder zu empfangen. Wie vorstehend erwähnt, kann jeder von ihnen, sowie auch seine Verbindungen, durch die Identitätsverwaltungs-Infrastruktur 105 authentifiziert und autorisiert werden.
-
Wenn von der Inhaltsinfrastruktur 110 eine Benachrichtigung für eine auf einem Benutzergerät befindliche Applikation übermittelt wird, während diese Applikation gerade nicht ausgeführt wird, kann das Benutzergerät 125 dem Benutzer per Hinweis mitteilen, dass die Applikation für ihn Daten bereithält, wie vorstehend erörtert. Die Inhaltsinfrastruktur 110 kann auch eine standardmäßige Quality-of-Service-(Dienstgüte)-Komponente bereitstellen, die Fähigkeiten auf dem Gebiet des Teilstreckenverfahrens (Store-and-Forward) besitzt. Wenn die Inhaltsinfrastruktur 110 versucht, eine Benachrichtigung abzusetzen, aber ein Zielgerät gerade offline ist, kann die Benachrichtigung für eine begrenzte Zeit gespeichert werden und erst dann an das Gerät übermittelt werden, wenn es wieder verfügbar ist. In einigen Ausführungsformen werden alle jüngsten Benachrichtigungen für eine bestimmte Applikation gespeichert. Wenn zum Beispiel mehrere Benachrichtigungen gesendet werden, während das Gerät offline ist, veranlasst jede neue Benachrichtigung das Löschen der vorherigen Benachrichtigung. Dieses Verfahren, nur die jüngste Benachrichtigung zu behalten, wird als zusammenwachsende Benachrichtigungen (coalescing notifications) bezeichnet. In anderen Ausführungsformen können dann, wenn das Gerät über lange Zeit hinweg offline geblieben ist, alle Benachrichtigungen, die für das Gerät gespeichert wurden, verworfen werden.
-
Provider 130 und Provider 135 können in verschiedenen Ausführungsformen mit einem Einzelserver-Computersystem implementiert werden, sie können aber auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects u.Ä. umfassen. In verschiedenen Aspekten liefern Provider 130 und Provider 135 Client-Applikationen, die auf dem Mobilgerät 115, dem Begleitgerät 120 und dem Benutzergerät 125 ausgeführt werden, sowie Server-Applikationen, die einen oder mehrere Dienste bereithalten, mit denen sich die Client-Applikation verbinden kann. Provider 130 und Provider 135 können einem der drei Geräte Mobilgerät 115, Begleitgerät 120 oder Benutzergerät 125 oder mehreren von ihnen mitteilen, dass die Client-Applikationen für den/die jeweiligen Benutzer zugriffsbereit sind.
-
In einem Aspekt ist ein Push-Provider ein Softwareentwickler, ein Unternehmen oder eine Organisation, die Server-Software unterhält, welche so konfiguriert ist, dass sie mit einer oder mit mehreren Client-Applikationen auf einem der drei Geräte Mobilgerät 115, Begleitgerät 120 oder Benutzergerät 125 oder mehreren von ihnen interagiert. Provider 130 und Provider 135 verbinden sich jeweils mit der Inhaltsinfrastruktur 110 über einen permanenten und sicheren Kanal, während sie die eingehenden Daten beobachten, die für ihre Client-Applikationen bestimmt sind. In einer Ausführungsform verbinden sich Provider 130 und Provider 135 über eine Binärschnittstelle, die eine Hochgeschwindigkeits- und Hochleistungsschnittstelle verkörpert, z.B. durch die Verwendung eines Streaming TCP Socket Designs im Zusammenhang mit binären Inhalten. Die Binärschnittstelle kann synchron oder asynchron sein. Für jede Schnittstelle kann TLS (oder SSL) verwendet werden, um einen gesicherten Kommunikationskanal herzustellen.
-
Mobilgerät 115, Begleitgerät 120 und Benutzergerät 125 können jeweils als einzelnes Gerät ausgebildet sein, als einzelnes Computersystem, als mehrere Geräte oder als Mehrfachcomputersysteme. In verschiedenen Aspekten können das Mobilgerät 115, das Begleitgerät 120 und das Benutzergerät 125, obwohl sie hier aus Vereinfachungsgründen mit anderen Begriffen bezeichnet werden, jeweils als Mobilgerät, am Körper tragbares Gerät („Wearable“), oder als sonstige mobile Vorrichtung (z.B. Laptop, Palmtop, Mobiltelefon, Smartphone, Multimediahandy, tragbares Medienwiedergabegerät (PMP), GPS-Gerät, mobiles Spielesystem etc. ausgebildet werden. Als Beispiele hierfür seien genannt: ein am Körper tragbares Gerät („Wearable“) kann ein am Handgelenk tragbares Gerät, ein Gerät, das mit einem Clip oder einer Nadel an der Kleidung des Benutzers befestigt werden kann, ein Gerät mit einem Schlüsselband oder einer Kette, die der Benutzer um den Hals tragen kann, ein Stirnband-Gerät, eine Brille oder irgendein anderes Gerät, das am Körper einer Person oder an ihrer Kleidung befestigt werden kann, sein.
-
Zusätzlich oder alternativ dazu können das Begleitgerät 120 und das Benutzergerät 125 wie vorstehend beschrieben ausgebildet werden, sowie auch als Personal Computer Systeme, Mainframes, Server-Computersysteme, Cloud Services etc.. Das Mobilgerät 115, das Begleitgerät 120 und das Benutzergerät 125 können eine Vielzahl von Technologien umfassen, die Kommunikationsverbindungen herstellen. Einige Beispiele für Verbindungstechnologien beinhalten sowohl drahtgebundene Verbindungen (z.B. Ethernet, Glasfaser, digitaler Teilnehmeranschluss (DSL) etc.) als auch drahtlose Verbindungen (z.B. WLAN, Bluetooth, WiMax, 3G, 4G, LTE etc.).
-
In einem Aspekt hosten das Mobilgerät 115, das Begleitgerät 120 und das Benutzergerät 125 eine oder mehrere aus einer Anzahl Client-Applikationen, die mit einer oder mehreren Server-Applikationen kommunizieren, welche von einem oder mehreren Providern bereitgestellt werden (z.B. Provider 130 und Provider 135). Diese Client-Applikationen können Applikationen umfassen, die für die vorgesehene Funktion eines Gerätes spezifisch sind (z.B. Telefonie-Applikationen oder GPS-Applikationen), sowie auch E-Mail Clients, Update/Upgrade Clients, News Clients, Web/Log Clients, Podcast Clients und Social Networking Clients oder sonstige Arten von Client-Applikationen, bei denen Benachrichtigungen versendet werden können. Diese Client-Applikationen können eine oder mehrere Benachrichtigungen für einen Benutzer anzeigen, die mithilfe der Inhaltsinfrastruktur 110 empfangen wurden. Benachrichtigungen können den Benutzern in einer Form oder in verschiedenen Formen dargeboten werden, die von einem Betriebssystem des Geräts, einem Toolkit für eine grafische Benutzeroberfläche und/oder den Applikationen selbst bestimmt werden. Einige Beispiele für die Darbietung von Benachrichtigungen umfassen die Benachrichtigung bei neuen E-Mails, die Benachrichtigung bei neuen Pressemeldungen, die Benachrichtigung bei neuen Podcast-Episoden, die Veränderung des Online-Status eines Freunds in einem sozialen Netzwerk und Ähnliches. In verschiedenen Ausführungsformen kann ein anderer Dienst, der auf einem Gerät ausgeführt wird, Benachrichtigungen für Client-Applikationen handhaben.
-
Wie vorstehend erörtert, können das Mobilgerät 115, das Begleitgerät 120 und das Benutzergerät 125 eine Kennung (oder ein Geräte-Token) erhalten, wenn eine Client-Applikation sich erstmals mit der Inhaltsinfrastruktur 110 verbindet, um Push-Benachrichtigungen zu empfangen. Die Provider 130 und 135 können das Token zusammen mit allen Inhalten oder Benachrichtigungen verwenden oder es einfügen, so dass es ordnungsgemäß über die Inhaltsinfrastruktur 110 an das Gerät zurückgeschickt werden kann. In verschiedenen Ausführungsformen übermittelt der Provider das Token jedes Mal wenn es sich mit der Inhaltsinfrastruktur 110 verbindet, um auf diese Weise Vertrauen herzustellen. Die Inhaltsinfrastruktur 110 kann das Geräte-Token mithilfe der Identitätsverwaltungs-Infrastruktur 105 entschlüsseln und validieren, um zu bestätigen, dass das Token für das Zielgerät erzeugt wurde. In einer Ausführungsform bestätigt die Inhaltsinfrastruktur 110 beim Validieren, dass die im Token enthaltene Gerätekennung identisch mit der Gerätekennung in einem Gerätezertifikat ist, welches zur Registrierung des Geräts bei der Identitätsverwaltungs-Infrastruktur 105 verwendet wurde.
-
Im Hinblick auf die Funktionsweise eines in 1 dargestellten Ökosystems in einer Ausführungsform ist anzumerken, dass die Funktionsweise darin bestehen kann, eine Benachrichtigung von einem Provider 130 an ein Begleitgerät 120 weiterzuleiten oder in sonstiger Weise zu übermitteln, wie es durch Pfad 145 dargestellt wird. In verschiedenen Ausführungsformen sendet der Provider 130 nach einer ersten Verbindung mit der Inhaltsinfrastruktur 110 ein Secure Sockets Layer (SSL)-Zertifikat zur Authentifizierung. Die Identitätsverwaltungs-Infrastruktur 105 kann den Provider 130 als einen registrierten und autorisierten Versender von Push-Benachrichtigungen authentifizieren und autorisieren. Das SSL-Zertifikat kann auch mit zusätzlichen benutzerdefinierten Daten konfiguriert werden. Die Identitätsverwaltungs-Infrastruktur 105 kann die zusätzlichen benutzerdefinierten Daten verwenden um den Provider 130 als vertrauenswürdig zu identifizieren. In anderen Ausführungsformen können weitere sichere Kommunikationsprotokolle (z.B. kryptografische Protokolle wie z.B. Transport Security Layer (TLS)) etc. verwendet werden.
-
In einigen Ausführungsformen, bei denen dem Provider 130 eine bestimmte Applikation zugeordnet ist, (z.B. E-Mail, Facebook oder Twitter) und hier zusätzliche Identifizierungsdaten (z.B. benutzerdefinierte Daten) im SSL-Zertifikat enthalten sind, kann die Identitätsverwaltungs-Infrastruktur 105 nicht nur den Provider 130 authentifizieren, sondern auch automatisch mithilfe der Inhaltsinfrastruktur 110 den Push-Dienst für den Provider 130 und die Applikation bereitstellen. In anderen Worten, die Identitätsverwaltungs-Infrastruktur 105 kann automatisch alle zusätzlichen identifizierenden Daten aus dem Authentifizierungszertifikat extrahieren und veranlassen, dass die Inhaltsinfrastruktur 110 die zusätzlichen Identifikationsdaten (oder einen Teil dieser Daten) an die Inhalte anhängt (z.B. Push-Benachrichtigungen). In einigen Ausführungsformen können die zusätzlichen Identifikationsdaten ein Thema oder einen Feed identifizieren, der mit dem Provider 130 (oder einer Applikation des Providers 130) verbunden ist, und den der Benutzer über die Inhaltsinfrastruktur 110 abonnieren kann. Daher können die zusätzlichen Informationen im Authenfizierungszertifikat wirksam eingesetzt werden, um Inhalte zu Geräten zu lenken, die das Thema/den Feed abonniert haben oder Informationen zu dem Thema/Feed verlangt haben. Auf diese Weise wird der Push-Service dem Provider 130 automatisch bereitgestellt.
-
Sobald dem Provider 130 vertraut wird, erhält die Inhaltsinfrastruktur 110 die entsprechende Benachrichtigung vom Provider 130. Wie vorstehend erörtert, kann die Benachrichtigung einen Geräte-Token enthalten. Nachdem die Benachrichtigung vom Provider 130 empfangen wurde, bestimmt die Inhaltsinfrastruktur 110 das Ziel für die Benachrichtigung. In verschiedenen Ausführungsformen wird das Ziel basierend auf dem Geräte-Token bestimmt, der zusammen mit der Benachrichtigung verschickt wird. In einigen Ausführungsformen ist es nicht erforderlich, Zielinformationen als Teil eines Tokens zu verschicken. Durch Bestimmen oder Extrahieren des Ziels aus dem Geräte-Token oder Erlangung von Zielinformationen für die Inhalte auf andere Weise kann dann die Inhaltsinfrastruktur 110 bestimmen, ob das Ziel „online“ oder auf andere Weise zugänglich ist.
-
Wenn das Ziel online ist, kann in einer Ausführungsform die Inhaltsinfrastruktur 110 dann die Benachrichtigung zum Begleitgerät 120 des Ziels übermitteln, so wie es durch Pfad 150 veranschaulicht wird, und zwar beispielsweise über eine permanente Verbindung, die das Begleitgerät 120 mit der Inhaltsinfrastruktur 110 aufrechterhält. Wenn das Ziel „offline“ oder in sonstiger Weise für die Inhaltsinfrastruktur 110 unzugänglich ist, können die Inhalte gespeichert und die Übermittlung zu einem späteren Zeitpunkt noch einmal versucht werden. Die Inhaltsinfrastruktur 110 kann zusätzlich oder alternativ dazu die Nachricht an das Mobilgerät 115 leiten, wie in Pfad 155 gezeigt, und zwar beispielsweise über eine permanente Verbindung, die das Begleitgerät 120 mit der Inhaltsinfrastruktur 110 aufrechterhält. Die Inhaltsinfrastruktur 110 kann damit Inhalte an ein einzelnes Gerät, an mehrere Geräte gleichzeitig oder an ein Gerät zur Weiterleitung an ein anderes Gerät senden.
-
B. Inhaltsinfrastruktur
-
2 ist ein Blockdiagramm eines Content Delivery Systems 200, welches gemäß verschiedener Ausführungsformen Push-Benachrichtigungsdienste bietet. Das System 200 kann in verschiedenen Ausführungsformen mit einem Einzelserver-Computersytem implementiert werden, es kann jedoch auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects etc. umfassen. Das System 200 kann in verschiedenen Ausführungsformen als Inhaltsinfrastruktur 110 der 1 ausgebildet sein.
-
Insbesondere veranschaulicht 2 verschiedene Beispiele für die Übermittlung von Inhalten (z.B. Benachrichtigungen und Telefon-/Videoanrufe) zwischen Geräten, z.B. zwischen Providern und Mobilgeräten oder zwischen dem sendenden Gerät eines Benutzers und den empfangenden Geräten eines anderen Benutzers. In diesen Beispielen wird das System 200 mit dem (den) Identitätsdienst(en) (IDS) 205, der (die) eine Schnittstelle 210 und einen Identitätsverwaltungsserver (IMS) 220 hat (haben), mit dem (den) Push-Benachrichtigungsdienst(en) (PNS) 220, der (die) eine Provider-Schnittstelle hat (haben), mit dem Gateway 230, der die Anwesenheitsinformationen 235 hat, mit der Geräteschnittstelle 240, welche die Verbindungsinformationen 245 hat, und mit dem Benutzergerät 250 gezeigt. Jeder Dienst kann mit Hardware- und/oder Software-Elementen implementiert werden.
-
In einem Aspekt kann der IDS 205 als Identitätsverwaltungs-Infrastruktur 105 ausgebildet sein oder einen Teil davon bilden. Der IDS 205 kann in verschiedenen Ausführungsformen mit einem Einzelserver-Computersystem implementiert werden, er kann aber auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects u.Ä. umfassen. Die Schnittstelle 210 kann es einer Entität (z.B. einem Mobilgerät 115 oder einem Provider 130) ermöglichen, sich zu verbinden (z.B. über ein Netzwerk), um den vom IDS 205 bereitgestellten Dienst zu nutzen. Die Schnittstelle 210 kann Lastenausgleich und sonstige Verbindungsmanagement-Techniken umfassen, um es den Entitäten zu ermöglichen, mit dem Identitätsverwaltungsserver 215 zu kommunizieren.
-
In einer Ausführungsform sendet eine Entität Informationen, wie zum Beispiel ein Authentifizierungszertifikat, das nach einer ersten Verbindung mit dem IDS 205 oder mit einem/einer durch den IDS 205 verwalteten Dienst, Ressource oder Applikation (z.B. PNS 220) über die Schnittstelle 210 empfangen wird. Der Identitätsverwaltungsserver 215 kann ein Gerät, einen Benutzer oder eine Organisation, welche die Informationen als registrierte und autorisierte Entität sendet, authentifizieren und autorisieren. Eine oder mehrere Arten von Diensten können für das Gerät, den Benutzer oder die Organisation autorisiert oder bereitgestellt werden (z.B. Anrufdienste, Instant-Messaging-Dienste, Chat-Dienste, Benachrichtigungsdienste etc.). Um ein Sicherheitsmodell für den PNS 220 zu unterstützen, können Entitäten und ihre Geräte dazu verpflichtet sein, bestimmte Zertifikate, Certificate Authority-Zertifikate oder Tokens zu besitzen.
-
In einer Ausführungsform verwendet jeder Content Provider für die Validierung seiner Verbindung mit dem PNS 220 ein eindeutiges Provider-Zertifikat und einen privaten kryptographischen Schlüssel. Dieses Zertifikat kann vom Identitätsverwaltungsserver 215 zur Verfügung gestellt werden und den Provider und/oder ein bestimmtes, vom Provider publiziertes Thema identifizieren. Im Allgemeinen ist das Thema praktisch eine Bundle ID einer Client-Applikation. Der Provider kann gegebenenfalls wünschen, den Dienst zu validieren, mit dem er verbunden ist, und dafür ein vom PNS 220 bereitgestelltes öffentliches Server-Zertifikat verwenden. In verschiedenen Aspekten verwendet der Provider, wenn er sich anmeldet, das ihm vom Identitätsverwaltungsserver 215 zugewiesene öffentliche Server-Zertifikat um den Dienst zu authentifizieren, mit dem er sich verbunden hat.
-
Der Identitätsverwaltungsserver 215 kann auch an jedes Gerät, das Inhalte empfangen will, einen eindeutigen privaten Schlüssel und ein Zertifikat ausgeben, welches das Gerät verwendet um sich gegenüber dem Identitätsverwaltungsserver 215 zu identifizieren und eine Verbindung zum PNS 220 herzustellen. Üblicherweise erhält ein Gerät während der Geräteaktivierung vom Identitätsverwaltungsserver 215 ein Gerätezertifikat und einen Schlüssel und speichert diese in einem Schlüsselbund. Das Gerät besitzt auch seinen eigenen Geräte-Token, den es während des Dienstverbindungsprozesses erhält. Jede Client-Applikation, welche den PNS 220 verwendet, hat diesen Token an ihren Content Provider zu übermitteln.
-
Der Identitätsverwaltungsserver 215 kann alle Zertifikate, CA-Zertifikate und kryptographischen Schlüssel (sowohl private als auch öffentliche) speichern, die für die Validierung der Verbindungen und die Überprüfung der Identitäten von Providern und Diensten erforderlich sind.
-
Sobald der Entität vertraut wird, erlaubt es das System 200 in diesem Beispiel der Entität, die vom PNS 220 bereitgestellten Push-Benachrichtigungsdienste zu nutzen. Der PNS 220 kann in verschiedenen Ausführungsformen mit einem Einzelserver-Computersystem implementiert werden, er kann aber auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects u.Ä. umfassen. Die Entität kann ein Provider oder ein sonstiger Anbieter von Benachrichtigungen sein, der sich mit dem PNS 220 verbinden will (z.B. über ein Netzwerk). Wie vorstehend angedeutet, verkörpert die Provider-Schnittstelle 225 in einer Ausführungsform eine Hochgeschwindigkeits- und Hochleistungsschnittstelle, die es den Push-Benachrichtigungs-Providern ermöglicht, mit dem PNS 220 zu kommunizieren. Die Provider-Schnittstelle 225 kann Lastenausgleich und sonstige Verbindungsmanagement-Techniken umfassen, um es den Entitäten zu ermöglichen, mit dem PNS 220 zu kommunizieren. Obwohl die Provider-Schnittstelle 225 als mit dem Gateway 230 verbunden dargestellt wird, kann die Provider-Schnittstelle 225 in den Gateway 230 oder in die Geräteschnittstelle 240 integriert werden. Wie vorstehend erörtert, kann ein Benutzergerät in verschiedenen Ausführungsformen sowohl ein Anbieter von Inhalten als auch das Ziel von Inhalten sein, die mithilfe des PNS 220 übermittelt werden.
-
Der Gateway 230 kann in verschiedenen Ausführungsformen mit einem Einzelserver-Computersystem implementiert werden, er kann aber auch Mehrfachserver-Computersysteme, Webserver, Applikationsserver, Netzwerke, Interconnects u.Ä. umfassen. Der Gateway 230 kann das Ziel der Inhalte (z.B. Push-Benachrichtigungen) bestimmen, die über die Provider-Schnittstelle 225 oder die Geräte-Schnittstelle 240 empfangen werden. In verschiedenen Ausführungsformen kann der Gateway 230 basierend auf den Anwesenheitsinformationen 235 ein Ziel bestimmen. In einem Aspekt werden die Anwesenheitsinformationen 235 mithilfe des Push-Tokens eines Geräts festgehalten. Daher kann dann, wenn eine Push-Benachrichtigung am Gateway 230 empfangen wird, die an ein bestimmtes Push-Token gerichtet ist, der Gateway 230 eine Suche durchführen, um zu ermitteln, ob es einen TCP Socket Descriptor gibt, der mit diesem Push-Token verknüpft ist. Der Socket Descriptor kann die TCP Socket Informationen und sonstige Netzwerkinformationen liefern, die für die Übertragung der Push-Benachrichtigung benötigt werden. In verschiedenen Aspekten enthalten die Anwesenheitsinformationen 235 Mappings zwischen den authentifizierten Entitäten und ihren Verbindungen zum PNS 220. Diese Verbindungen können vom PNS 220 für die Lieferung von Inhalten, Benachrichtigungen und dergleichen oder für die anderweitige Kommunikation mit einer Entität verwendet werden. Jedes Mapping kann auf mindestens eine Entität und auf mindestens einen Verbindungsmechanismus zu dieser Entität verweisen, wie zum Beispiel eine Netzwerk-Socket-Verbindung oder eine andere Verbindungskennung. Ein Mapping kann zum Beispiel ein Zielgerät anhand seines Geräte-Tokens oder einen Provider anhand seiner Providerkennung identifizieren. In jedem Mapping können zusätzliche Informationen enthalten sein, um die Kommunikation mit dem Gerät der jeweiligen Entität zu erleichtern.
-
Um der Abwicklung von Verbindungen für eine zunehmende Anzahl von Benutzern, Geräten und Providern, welche die Dienste des PNS 220 nutzen, größenmäßig gerecht zu werden, können in einigen Ausführungsformen die Geräteverbindungen in den Anwesenheitsinformationen 235 (oder in den Geräten selbst) mit mindestens einer Gruppierung bzw. logischen Partition, die als Zone bezeichnet wird, gehandhabt werden. Die vom Gateway 230 ausgeführten Funktionen können partitionsweise auf mehrere Server ausgelagert werden, die dynamisch für die Handhabung dieser Gruppierungen oder Zonen zugewiesen werden. Zum Beispiel können ein oder mehrere Server eine Zeitlang die Belieferung von Zielen handhaben, die einer Zone zugewiesen werden; danach wird gewechselt oder rekonfiguriert, und es wird die Lieferung von Benachrichtigungen an andere Ziele gehandhabt, die zu einem späteren Zeitpunkt einer anderen Zone zugewiesen werden. Jeder dieser Server kann auch Routing-Informationen beinhalten, die verwendet werden, um Inhalte zu anderen Servern zu befördern, die mit einer bestimmten Zone des Ziels der Inhalte assoziiert sind. Wenn die Inhalte bei einem Server eingehen, wird daher ein weiterer Server dafür vorgesehen, eine vorbestimmte Zone zu bearbeiten, und dann können die Inhalte an den entsprechenden Server weitergeleitet werden. In einem Aspekt können die vom Gateway 230 durchgeführten Funktionen partitionsweise an mehrere Server ausgelagert werden, damit diese die entsprechenden Geräteverbindungen (z.B. Geräteschnittstelle 240) handhaben.
-
In verschiedenen Ausführungsformen ist der Gateway 230 mit der Geräteschnittstelle 240 verbunden. Die Geräteschnittstelle 240 verkörpert eine Schnittstelle für die Kommunikation mit dem Benutzergerät 250. Die Geräteschnittstelle 240 kann Lastenausgleich und sonstige Verbindungsmanagement-Techniken umfassen, die es Geräten ermöglichen, mit dem PNS 220 zu kommunizieren. Obwohl die Geräteschnittstelle 240 als mit dem Gateway 230 verbunden dargestellt wird, kann die Geräteschnittstelle 240 in den Gateway 230 oder die Provider-Schnittstelle 225 integriert werden.
-
Die in diesen Beispielen dargestellte Geräteschnittstelle 240 ermöglicht es, dass Anwesenheitsinformationen 235 erzeugt werden können, wenn die Geräteschnittstelle 240 mit dem Benutzergerät 250 verbunden ist. Nachdem eine permanente Verbindung hergestellt wurde, kann das Benutzergerät 250 dem PNS 220 gegenüber seine Anwesenheit bemerkbar machen. Die Geräteschnittstelle 240 erzeugt dann ein Geräte-/Verbindungs-Mapping in den Verbindungsinformationen 245. Die Geräteschnittstelle 240 kann die Verbindungsinformationen an den Gateway 230 zurücksenden und es dem Gateway ermöglichen, ein Geräte-/Verbindungs-Mapping in den Anwesenheitsinformationen zu erzeugen. In einem Aspekt enthalten die Anwesenheitsinformationen 235 ein Gerät-/Courier-Mapping oder einen Link, der es dem Gateway 230 erlaubt, einen geeigneten Courier zu bestimmen, der als mit dem Benutzergerät 250 verbundene Geräteschnittstelle 240 fungiert. Der Courier verwendet die Verbindungsinformationen 245 (einschließlich aller Geräte-/Verbindungs-Mappings oder Links), und damit kann er Verbindungsinformationen ermitteln, die für das Benutzergerät 250 spezifisch sind und für die Übermittlung von Inhalten an das Benutzergerät 250 verwendet werden können. In einem anderen Aspekt können die Anwesenheitsinformationen 235 und die Verbindungsinformationen 245 im wesentlichen identisch sein, darin dass sie Übereinstimmungen zwischen einem gegebenen Gerät und seiner Verbindung mit dem PNS 220 umfassen.
-
In verschiedenen Ausführungsformen sendet ein Gerät, das Inhalte über den PNS 220 empfangen will, Authentifizierungsinformationen entweder bei einer ersten Verbindung mit der Geräteschnittstelle 240 oder direkt an die IDS 205. Der Identitätsverwaltungsserver 215 kann die Authentifizierungsinformationen entweder direkt oder indirekt empfangen und dann das Gerät oder seinen zugewiesenen Benutzer bzw. seine zugewiesene Organisation als registrierte und berechtigte Entität autorisieren. Sobald dem Gerät vertraut wird, wird der PNS 220 informiert, und daraufhin verwaltet der PNS 220 alle Verbindungen, die zwischen dem Gerät und dem PNS 220 hergestellt werden (so z.B. auch mit der Geräteschnittstelle 240 in den Verbindungsinformationen 245). Die an der Geräteschnittstelle 240 in den Verbindungsinformationen 245 verfügbaren Geräteinformationen können in regelmäßigen Abständen zurück zum Gateway 220 befördert werden, um die Anwesenheitsinformationen 235 zu erzeugen oder zu aktualisieren.
-
Wenn das Gerät sich erstmals mit dem PNS 220 verbindet, beliefert der PNS 220 das Gerät. In verschiedenen Ausführungsformen wird, wie vorstehend angedeutet, für das Gerät eine Zone bereitgestellt. Obwohl jedem Gerät eine spezielle Zone zugewiesen wird, ist es aus verschiedenen Gründen möglich, dass die Geräte ihre Verbindung mit der Geräteschnittstelle 240 verlieren. Eine Verbindung kann beispielsweise unterbrochen werden, weil ein Mobilfunksignal oder ein WLAN-Signal verloren geht, weil der Strom ausfällt oder weil ein Mobilgerät 115 seinen geografischen Standort gewechselt hat etc. In anderen Aspekten kann eine Verbindung nicht permanent sondern intermittierend sein, um damit Strom zu sparen oder sonstige Effizienzvorgaben zu erfüllen.
-
Versucht das Benutzergerät 250, seine Verbindung zum PNS 220 wiederherzustellen, so kann es sich mit irgendeinem Courier verbinden, der als Geräteschnittstelle 240 fungiert. In Ausführungsformen, bei denen die Geräteverbindungen mindestens einer Gruppierung oder Zone zugewiesen werden, kann die Geräteschnittstelle 240 eine Verbindung mit einem oder mehreren Servern von Gateway 230 bereitstellen, die dafür vorgesehen sind, die Zone eines Verbindungsgeräts handzuhaben. Ist zum Beispiel die Geräteschnittstelle 240 mit dem Benutzergerät 250 verbunden, das der Zone 1 zugewiesen ist, dann kann die Geräteschnittstelle 240 eine Verbindung mit einem oder mehreren Servern herstellen, die für die Handhabung der Zone 1 zuständig sind. Die Geräteschnittstelle 240 kann dann die Geräteinformationen für das Benutzergerät 250 an den bzw. die Server zurückleiten, der bzw. die für die Handhabung der Zone 1 zuständig ist/sind. In ähnlicher Weise kann die Geräteschnittstelle 240 Verbindungen mit Servern verschiedener Zonen herstellen, damit spezifische Geräteinformationen für Geräte, die den jeweiligen Zonen zugewiesen sind, zurückgeleitet werden; damit soll sichergestellt werden, dass wo oder wie auch immer das Benutzergerät 250 sich mit dem PNS 220 verbindet, die Anwesenheitsinformationen 235 aktuell und verfügbar sind und dementsprechend bestimmen können, wie die Inhalte zu übermitteln sind. In einigen Ausführungsformen kann die Geräteschnittstelle 240 für jeden Netzbetreiber oder Internet Service Provider (ISP) spezifisch sein, wodurch es dem PNS 220 ermöglicht wird, die Protokolle oder physischen Verbindungen zu unterstützen, die für Entitäten, die aus einer Vielzahl Dritter bestehen, spezifisch sind.
-
Gemäß einem Beispiel leitet der Gateway 230 dann, wenn er Inhalte von der Provider-Schnittstelle erhält, diese von der Provider-Schnittstelle 225 erhaltenen Inhalte an die Geräteschnittstelle 240,weiter, und zwar basierend auf ihren Mappings in den Anwesenheitsinformationen 235. Die Geräteschnittstelle 240 kann die vom Gateway 230 erhaltenen Inhalte an das Benutzergerät 250 liefern, für das Informationen über eine permanente Verbindung in den Verbindungsinformationen 245 bereitgehalten werden.
-
Nach dem Erhalt von Inhalten vom Gateway 230 kann die Geräteschnittstelle 240 eine Suche durchführen oder auf andere Weise ihre Geräteverbindungen in den Verbindungsinformationen 245 inspizieren und dann die vom Gateway 230 erhaltenen Inhalte an das passende Gerät weiterleiten, zum Beispiel über die permanente Verbindung, die dem Benutzergerät 250 zugeordnet ist. In einem Aspekt inspiziert die Geräteschnittstelle 240 den Geräte-Token, der den zu liefernden Inhalten zugeordnet ist, und ermittelt, ob zwischen dem Geräte-Token und den von der Geräteschnittstelle 240 in den Verbindungsinformationen 245 verwalteten Verbindungen eine Übereinstimmung gefunden wird. Die Geräteschnittstelle 240 kann die Inhalte über die Verbindung übermitteln, die von dem Gerät mit dem entsprechenden Geräte-Token hergestellt wurde.
-
In einem Ausführungsbeispiel abonniert das Benutzergerät 250 eine bestimmte Applikation, die von einem Provider verwaltet wird, und möchte Benachrichtigungen für diese Applikation über PNS 220 erhalten. Daher ruft das Benutzergerät 250 den Provider entweder direkt über ein Kommunikationsnetzwerk oder über PNS 220 an und überträgt seinen Geräte-Token an den Provider. Der Geräte-Token oder seine Übertragung kann nicht nur die Identifikationsinformationen eines Geräts enthalten, sondern auch eine verschlüsselte Kombination der UID des Geräts und seiner Zonenkennung, die es dem PNS 220 erlaubt, Verbindungsinformationen für das Gerät mit den entsprechenden, der Zone zugewiesenen Ressourcen zu liefern.
-
Wenn der Provider eine Benachrichtigung an die jeweilige Applikation auf dem Benutzergerät 250 sendet, verbindet sich der Provider über die Provider-Schnittstelle 225 mit dem PNS 220 und schickt die Benachrichtigung an das Gateway 230. Selbst wenn das Benutzergerät 250 einer bestimmten Zone zugewiesen ist, braucht der Provider keine Verbindung mit einem bestimmten Gateway des PNS 220 herzustellen, um erfolgreich eine Benachrichtigung an das Benutzergerät 250 zu pushen. Wenn zum Beispiel der Gateway 230 Inhalte von einer Provider-Schnittstelle 225 erhält und die Inhalte einen Geräte-Token haben, so inspiziert der Gateway den Token und leitet entweder die Nachricht an einen geeigneten Server des PNS 220 (der dann die Nachricht an die Geräteschnittstelle 240 oder einen anderen Courier des PNS 230 weiterleiten kann) oder schickt die Nachricht direkt an die Geräteschnittstelle 240.
-
Wenn der Gateway 230 der vorgesehene Gateway ist, dann sendet dieser Gateway in einigen Ausführungsformen die Nachricht an die Geräteschnittstelle 240 basierend auf seinem Geräte-/Courier-Mapping in den Anwesenheitsinformationen 235 bzw. leitet sie dorthin weiter. Die Gerätschnittstelle 240 kann dann ihre Verbindungen in den Verbindungsinformationen 245 inspizieren und sendet die Nachricht über die vom Gerät mit der Geräteschnittstelle 240 hergestellte permanente Verbindung an das Gerät. Kurz gefasst, in Fällen, in denen der PNS 220 eine Nachricht mit einem bestimmten Ziel erhält, leitet ein Gateway des PNS 220 die Nachricht direkt an einen geeigneten Courier des PNS 220 unter Verwendung eines Geräte-/Courier-Mappings, das zum Zeitpunkt der Verbindung eines Geräts mit dem PNS 220 erzeugt wurde. In weiteren Ausführungsformen kann der Gateway 230 die Nachricht direkt an das Benutzergerät 250 senden/weiterleiten, basierend auf seinem Geräte-/Verbindungs-Mapping in den Anwesenheitsinformationen 235. Der Gateway 230 kann diese Mapping-Informationen von verschiedenen Quellen beziehen, zu denen jeweils ein Gerät eine Verbindung hergestellt hat.
-
II. PROXIED SMS
-
In verschiedenen Ausführungsformen können SMS/MMS-Nachrichten, die durch nicht-SMS/MMS-spezifische Content Delivery oder Messaging Services (z.B. Inhaltsinfrastruktur 110) gesendet werden, an ein Proxy-Gerät weitergeleitet werden, das mit dem jeweiligen Dienst verbunden ist, unter Verwendung von zuvor durch das Proxy-Gerät ermittelten Profilinformationen. Das Proxy-Gerät wird angewiesen, SMS/MMS-Nachrichten im Auftrag anderer Proxied-Geräte zu senden und zu empfangen, denen die SMS/MMS-Fähigkeiten des Proxy-Geräts bekannt sind. In einigen Ausführungsformen kann das Proxy-Gerät eine Masterliste autorisierter Geräte führen, für die das Proxy-Gerät als Vermittler fungiert. Dementsprechend betätigen sich Proxy-Geräte im Zusammenhang mit nicht-SMS/MMS-spezifischen Content Delivery oder Messaging Services als vermittelnde Geräte und übermitteln SMS/MMS-Nachrichten von und zu Proxied-Geräten.
-
3 ist ein Flussdiagramm des Verfahrens 300 zur Durchführung von Proxied SMS/MMS Messaging gemäß verschiedener Ausführungsformen. Die in 3 dargestellte Verarbeitung nach dem Verfahren 300 kann von einer Software (z.B. Anweisungen oder Code-Module) durchgeführt werden, wenn diese von einer zentralen Recheneinheit (CPU oder Prozessor) einer Logik-Maschine, wie zum Beispiel einem Computersystem, oder Informationsverarbeitungsgerät, von Hardware-Komponenten eines elektronischen Geräts, von anwendungsspezifischen integrierten Schaltkreisen oder von Kombinationen aus Software- und Hardwareelementen ausgeführt wird.
-
In Schritt 310 werden die Profilinformationen für ein Proxy-Gerät empfangen. Die Profilinformationen können eine UID, ein Zertifikat, einen Token und andere Informationen umfassen, die mit den Hardware- und/oder Software-Fähigkeiten des Proxy-Geräts assoziiert sind oder sich darauf beziehen. Die Profilinformationen können in einem Identitätsverwaltungsdienst (z.B. in der Identitätsverwaltungs-Infrastruktur 105) empfangen und gespeichert werden, durch den das Proxy-Gerät (z.B. das Begleitgerät 120) als Entität verwaltet wird. Das Proxy-Gerät kann eine TLS-Verbindung mit einem Server oder einem anderem Endpunkt, der mit dem Dienst assoziiert ist, initiieren, um die Profilinformationen bereitzustellen oder um es zu ermöglichen, dass der Dienst die Profilinformationen auf andere Weise erlangen kann. Der Dienst kann sein eigenes Server-Zertifikat zurücksenden, das vom Proxy-Gerät verwendet werden kann, um den Dienst (oder zumindest den Server oder Endpunkt) zu validieren und um sicherzustellen, dass die Profilinformationen in vertrauenswürdigen Händen sind.
-
Das Proxy-Gerät kann auch sein eigenes Gerätezertifikat an den Dienst senden. Das Gerätezertifikat kann ein Zertifikat sein, das erteilt wurde, als sich das Proxy-Gerät registrierte oder zu einer verwalteten Entität des Dienstes wurde, d.h. ein Zertifikat, das vom Identitätsverwaltungs-Server 215 bei einer erstmaligen Registrierung des Begleitgeräts 120 zurückgesendet wurde, so dass dieses zu einer verwalteten Einheit wurde. Der Dienst kann das Gerätezertifikat validieren, und bei erfolgreicher Validierung kann er es dem Proxy-Gerät erlauben, Verbindungen mit anderen Entitäten oder Diensten herzustellen, die von ihm verwaltet werden. Der Dienst kann ebenfalls Informationen über die Hardware- und/oder Software-Fähigkeiten des Proxy-Geräts zum Zeitpunkt der Authentifizierung erfassen.
-
In einer Ausführungsform wird nach einer erfolgreichen Registrierung, die es dem Proxy-Gerät erlaubt, Verbindungen mit anderen vom Dienst verwalteten Entitäten oder Diensten herzustellen, das Proxy-Gerät angewiesen, die Autorisierung dafür anzufordern, dass andere Geräte die Fähigkeiten des Proxy-Geräts nutzen dürfen. Ein Benutzer des Proxy-Geräts kann dazu aufgefordert werden, alle, einen Teil oder keines der Geräte aus einer Menge von Geräten zu autorisieren, die auf den Benutzer angemeldet oder ihm in sonstiger Weise zugeordnet sind. Eine gesicherte Masterliste kann erstellt werden, auf welcher die Geräte verzeichnet sind und verfolgt werden, die dazu autorisiert sind, die Fähigkeiten des Proxy-Geräts zu nutzen. In einem Aspekt wird die Masterliste auf dem Proxy-Gerät geführt. Die Masterliste kann an anderen Orten, wie zum Beispiel beim Dienst, gespeichert und geführt werden.
-
In Schritt 320 wird ein Geräteprofil für das Proxy-Gerät beim Dienst erzeugt. Ein Geräteprofil kann eine UID, einen Token oder eine andere Kennung des Proxy-Geräts sowie ein oder mehrere Felder oder Attribute umfassen, in denen die Hardware- und/oder Software-Fähigkeiten des Proxy-Geräts beschrieben sind. Das Geräteprofil kann in einer Datenbank oder in einem Benutzer-/Geräte-Verzeichnis, der bzw. das mit dem Dienst verbunden ist, gespeichert werden. In einigen Ausführungsformen kann das Geräteprofil mit einer digitalen Identität, mit einer Benutzerkennung, einem Benutzerprofil oder anderen Benutzerinformationen des Benutzers des Proxy-Dienstes verbunden sein.
-
In Schritt 330 werden Profilinformationen für ein Proxied-Gerät empfangen. Ähnlich wie beim vorstehend beschriebenen Prozess für das Proxy-Gerät können die Profilinformationen für das Proxied-Gerät beim Dienst gespeichert werden. In einigen Ausführungsformen validiert der Dienst das Gerätezertifikat des Proxied-Geräts. Bei erfolgreicher Validierung wird in Schritt 340 ein Geräteprofil für das Proxied-Gerät beim Dienst erzeugt. Das Geräteprofil kann eine UID, einen Token oder einen andere Kennung des Proxied-Geräts sowie ein oder mehrere Felder oder Attribute umfassen, in denen die Hardware- und/oder Software-Fähigkeiten des Proxied-Geräts beschrieben sind. Das Geräteprofil kann mit einem Benutzerprofil des Benutzers des Proxied-Geräts verbunden sein.
-
In verschiedenen Ausführungsformen können mit einem Benutzer oder mit einer anderen Entität verbundene Geräteprofile von den Geräten dieses Benutzers oder dieser Entität für verschiedene Zwecke miteinander geteilt werden. In einigen Ausführungsformen wird nach erfolgreicher Registrierung, die es dem Proxied-Gerät erlaubt, Verbindungen mit anderen dem Dienst verwalteten Entitäten oder Diensten herzustellen, das Proxy-Gerät angewiesen, die Autorisierung dafür anzufordern, dass das Proxied-Gerät die Fähigkeiten des Proxy-Geräts nutzen darf. Ein Benutzer des Proxy-Geräts kann dazu aufgefordert werden, alle, einen Teil oder keine der Dienste und Fähigkeiten aus einer Menge von Diensten und Fähigkeiten zu autorisieren, die das Proxied-Gerät nutzen kann oder auf die es in sonstiger Weise zugreifen kann. Dementsprechend kann das vorstehend beschriebene Proxy-Gerät im Auftrag des Proxied-Geräts SMS/MMS-Nachrichten senden und empfangen und dabei seine eigene Verbindung mit einem Netzwerk nutzen, welches das Senden und Empfangen von SMS/MMS-Nachrichten unterstützt. Das Proxied-Gerät kann als am Körper tragbares („Wearable“) Gerät, wie zum Beispiel eine Smart Watch oder eine Datenbrille (Optical Head-Mounted Display, OHMD), ein Tablet oder sonstiges Computergerät ausgebildet sein, dem die traditionellen SMS/MMS-Fähigkeiten fehlen. In verschiedenen Ausführungsformen braucht ein Benutzer sowohl des Proxied-Geräts als auch des Proxy-Geräts die beiden Geräte nicht miteinander zu koppeln, um eine Proxy-Kommunikation herzustellen. Jedes Benutzergerät kann so konfiguriert werden, dass es den Dienst kontaktiert um zu ermitteln, welche anderen dem Profil des Benutzers zugeordneten Geräte SMS/MMS-Fähigkeiten haben. Das Proxied-Gerät kann das Geräteprofil aller anderen Geräte, die SMS/MMS-Fähigkeiten haben, erhalten und veranlassen, dass sie sich als Proxy-Geräte betätigen.
-
Wie wiederum 3 zeigt, sendet der Dienst in Schritt 350 als Antwort auf eine Anfrage das Geräteprofil des Proxy-Geräts an das Proxied-Gerät. In einigen Ausführungsformen sendet der Dienst als Antwort auf periodische Anfragen seitens des Proxied-Geräts das Geräteprofil des Proxy-Geräts an das Proxied-Gerät, da die Benutzer ihrem Account Geräte hinzufügen sowie Geräte aus ihrem Account entfernen können. In einigen Ausführungsformen sendet der Dienst das Geräteprofil des Proxy-Geräts an das Proxied-Gerät als Antwort darauf, dass der Benutzer das Proxied-Gerät autorisiert oder veranlasst, dass eine Masterliste der für das Proxied-Gerät autorisierten Geräte ergänzt wird. In einigen Ausführungsformen sendet der Dienst das Geräteprofil des Proxy-Geräts an das Proxied-Gerät als Antwort darauf, dass der Benutzer auf der Benutzeroberfläche des Proxied-Geräts eine Nachricht verfasst, womit es dem Benutzer des Proxied-Geräts ermöglicht wird, ausdrücklich zu bestimmen, welches Gerät aus der Menge der Proxy-Geräte verwendet werden soll.
-
In Schritt 360 geht bei dem Dienst eine Nachricht ein, die dem Proxy-Gerät befiehlt, die Nachricht an einen Empfänger weiterzuleiten. In einigen Ausführungsformen identifiziert die eingegangene Nachricht das Proxy-Gerät als Ziel und verwendet dabei ein Geräte-Token. Die eingegangene Nachricht kann einen oder mehrere Empfänger einer SMS/MMS-Nachricht enthalten, die über das Proxy-Gerät unter Einsatz dessen SMS/MMS-Fähigkeiten zu versenden ist. Die eingegangene Nachricht kann Nutzdaten umfassen, welche die Inhalte der SMS/MMS-Nachrichten angeben, die über das Proxy-Gerät unter Einsatz dessen SMS/MMS-Fähigkeiten an den einen oder die mehreren Empfänger zu senden ist. Die eingegangene Nachricht kann des Weiteren eine Markierung (Flag) oder eine andere Kennung umfassen, die dem Proxy-Gerät befiehlt, die SMS/MMS-Nachricht unter Einsatz seiner SMS/MMS-Fähigkeiten an den einen oder die mehreren Empfänger zu senden. In Schritt 370 wird die Nachricht von dem Dienst an das Proxy-Gerät gesendet.
-
In einigen Ausführungsformen kann der Dienst ermitteln, dass das Proxied-Gerät nicht dazu autorisiert ist, auf die Dienste oder Fähigkeiten des Proxy-Geräts zuzugreifen oder sie in anderer Weise zu nutzen. Der Dienst kann zum Beispiel eine Masterliste konsultieren, in der die für das Proxy-Gerät autorisierten Geräte eingetragen sind. Wenn das Proxied-Gerät nicht autorisiert ist, kann der Dienst eine oder mehrere Aktionen durchführen. Der Dienst kann die Nachricht fallen lassen, die Nachricht zurückweisen mit einer Benachrichtigung an das Proxied-Gerät oder die Nachricht an das Proxy-Gerät weiterleiten und verlangen, dass der Benutzer des Proxy-Geräts das Proxied-Gerät autorisiert.
-
A. Verwaltung des Proxy-/Proxied-Geräts
-
4 ist ein Blockdiagramm, welches veranschaulicht, wie gemäß einer Ausführungsform der Identitätsverwaltungs-Server 215 die Geräteprofile verwaltet. In diesem Beispiel umfasst das Begleitgerät 120 einen Prozessor 402, der ein Verbindungsmodul 404, einen Speicher 406, in dem eine UID, ein Geräte-Token oder ein andere Kennung T1 abgespeichert sind, eine oder mehrere Applikationen 408, den Sender 410 und den Empfänger 412 hat. Der Prozessor 140 enthält das Verbindungsmodul 404 für die Verwaltung der Verbindungen. Der Speicher 406 speichert den Geräte-Token T1. Nach einer ersten Verbindung mit dem Identitätsverwaltungs-Server 215 kann das Verbindungsmodul 404 unter Verwendung des Senders 410 die Registrierungsinformationen übertragen, und zwar auf Verlangen einer oder mehrerer Applikationen 408 zwecks Registrierung des Begleitgeräts 120 mit einem Benutzerprofil, und unter Verwendung des Empfängers 412 den Geräte-Token T1 vom Identitätsverwaltungs-Server 215 erhalten. Nachdem der Geräte-Token T1 erzeugt wurde, übermittelt oder sendet der Sender 410 den Geräte-Token T1 an verschiedene Dienste, womit es diesen Diensten ermöglicht wird, Inhalte, Nachrichten, Mitteilungen etc. an das Begleitgerät 120 zu senden. Wie vorstehend erörtert, können die Provider-Applikationen den Geräte-Token T1 verwenden oder den Token in eine Benachrichtigung integrieren, so dass er ordnungsgemäß an das Begleitgerät 120 zurückgeleitet werden kann.
-
Das Verbindungsmodul 404 kann das Senden und Empfangen von SMS/MMS-Nachrichten unter Einsatz des Senders 410 und des Empfänger 412, die mit einem Mobilfunknetz oder einem anderen Netz verbunden sind, welches SMS/MMS Messaging unterstützt, verwalten. Des Weiteren kann das Verbindungsmodul 404 das Senden und Empfangen von SMS/MMS-Nachrichten im Auftrag des Mobilgeräts 115 verwalten. Beispielsweise kann das Verbindungsmodul 404 die Zustellung einer vom Mobilgerät 115 erzeugten SMS/MMS-Nachricht an einen Empfänger verwalten. Das Verbindungsmodul 404 kann die Zustellung von Antwort-SMS/MMS-Nachrichten oder sonstigen SMS/MMS-Nachrichten an das Mobilgerät 115 unter Verwendung des Empfängers 412 verwalten.
-
Das Mobilgerät 115 umfasst den Prozessor 414, der wiederum ein Verbindungsmodul 416, einen Speicher 418, in dem der Geräte-Token T2 gespeichert ist, eine oder mehrere Applikationen 420, den Sender 422 und den Empfänger 424 hat. Der Prozessor 414 enthält ein Verbindungsmodul 416 für die Verwaltung von Verbindungen. Der Speicher 418 speichert den Geräte-Token T2. Nach einer ersten Verbindung mit dem Identitätsverwaltungs-Server 215 kann das Verbindungsmodul 416 unter Einsatz des Senders 422 Registrierungsinformationen übertragen, und zwar auf Verlangen einer oder mehrerer Applikationen 408 zwecks Registrierung des Mobilgeräts 120 mit einem Benutzerprofil, und unter Einsatz des Empfängers 424 den Geräte-Token T2 vom Identitätsverwaltungs-Server 215 erhalten. Nachdem der Geräte-Token T2 erzeugt wurde, übermittelt oder sendet der Sender 422 den Geräte-Token T2 an verschiedene Provider-Applikationen.
-
Das Verbindungsmodul 416 kann des Weiteren das Senden und Empfangen von SMS/MMS-Nachrichten oder von Nachrichten, die unter Einsatz der SMS/MMS-Fähigkeiten des Begleitgeräts 120 als SMS/MMS-Nachrichten gesendet werden sollen, vom und zum Begleitgerät 120 verwalten. Zum Beispiel kann das Verbindungsmodul 416 die Weiterleitung einer Nachricht an das Begleitgerät 120 unter Einsatz einer Benutzeroberfläche des Mobilgeräts 115 sowie des Senders 422 verwalten. Das Verbindungsmodul 416 kann die Nachricht direkt oder indirekt an das Begleitgerät 120 senden. In einigen Ausführungsformen markiert, etikettiert oder kennzeichnet das Verbindungsmodul 416 solche Nachrichten in einer geeigneten Weise, so dass das Begleitgerät 120 bei Erhalt dieser Nachrichten angewiesen wird, die Nachrichten unter Einsatz seiner SMS/MMS-Fähigkeiten an die beabsichtigten Empfänger zu übermitteln.
-
In diesem Beispiel geht eine dem Begleitgerät 120 zugeordnete Nachricht beim Identitätsverwaltungs-Server 215 ein, um das Begleitgerät 120 mit einem Benutzer oder dem Profil eines Benutzers zu registrieren oder sich anderweitig damit zu assoziieren. Der Identitätsverwaltungs-Server 215 beinhaltet das Benutzerprofil 426 und das Benutzerprofil 428. 4 veranschaulicht, dass in diesen Ausführungsformen das Benutzerprofil 426 einen Satz Gerätekennungen und einen Satz Geräteprofile enthält oder anderweitig damit assoziiert ist. Jede Gerätekennung in dem Satz ist durch Mapping abgebildet oder hat in sonstiger Weise ein ihr entsprechendes Geräteprofil. Konkret wird für das Benutzerprofil 426 eine Gerätekennung, wie sie durch den Geräte-Token T1 dargestellt ist, durch Mapping abgebildet, korreliert oder befindet sich anderweitig in Übereinstimmung mit einem Geräteprofil wie dieses durch Ti-DP dargestellt wird. Eine Gerätekennung, wie sie durch den Geräte-Token T1 dargestellt ist, wird abgebildet, korreliert oder befindet sich anderweitig in Übereinstimmung mit einem Geräteprofil wie dieses durch T2-DP dargestellt wird. Für das Benutzerprofil 428 wird eine Gerätekennung, wie sie durch das Token T3 dargestellt ist, abgebildet, und zwar mit einem Geräteprofil, wie dieses durch T3-DP dargestellt ist. Obwohl Gerätekennungen in Bezug auf Geräte-Tokens abgebildet sind, können alternative Gerätekennungen, wie hierin erörtert, verwendet werden.
-
In diesen Ausführungsformen veranschaulicht 4, dass das Benutzerprofil 426 eine Gerätekennung umfasst, wie sie durch Token T1 dargestellt ist, und dass sie abgebildet, korreliert oder anderweitig in Übereinstimmung mit dem Geräteprofil T1-D1 ist, welches einen Satz Attribute und einen Satz Werte enthält. Attribut A1 ist mit dem Wert V1 gepaart. Attribut A2 ist mit dem Wert V2 gepaart. Ein SMS/MMS-fähiges Attribut wird mit einem Wert „TRUE“ gepaart. Daher kann das Geräteprofil Ti-DP eine Vielzahl von Attributen enthalten, die auf Benutzer, Organisationen, Hardware und/oder Software bezogene Fähigkeiten oder Aspekte beschreiben, denen ein Gerät, das den Geräte-Token T1 hat, zuzuordnen ist.
-
5 ist ein Message Sequence Chart, welches die Schaffung von Proxy- und Proxied-Fähigkeiten für SMS/MMS-Proxying gemäß verschiedener Ausführungsformen zeigt. Um Gerätefähigkeiten zu schaffen, erzeugt in diesen Beispielen das Begleitgerät 120 der 2, welches eigenständig oder als Proxy-Gerät handelt, allermindestens einen Anwesenheitsbefehl für den Geräte-Token T1 (bzw. wenn ohne Geräte-Token gesendet wird, kann der Geräte-Token Ti erzeugt werden) bei 505. Der Anwesenheitsbefehl kann Fähigkeiten des Begleitgeräts 120 umfassen. In weiteren Ausführungsformen kann der Anwesenheitsbefehl Informationen enthalten, die ein oder mehrere Geräte identifizieren, welche dazu autorisiert sind, die Fähigkeiten des Begleitgeräts 120 zu nutzen. Bei 510 sendet das Begleitgerät 120 den Anwesenheitsbefehl an den IDS 205.
-
Die im Anwesenheitsbefehl für das Geräte-Token T1 an den IDS 205 weitergegebenen Daten können bei 515 anhand einer Vielzahl von vorgegebenen Kriterien validiert werden. Wenn alles erfolgreich validiert ist, erzeugt der IDS 205 ein Geräteprofil für den Geräte-Token Ti, mit dem zumindest die Fähigkeiten des Begleitgeräts 120 beschrieben werden. Das Geräteprofil kann Fähigkeitsinformationen enthalten, die vom Begleitgerät 120 erhalten wurden, oder auch Informationen, die über das Begleitgerät 120 vom IDS 205 oder aus anderen Quellen in Erfahrung gebracht wurden. In einigen Ausführungsformen enthält das Geräteprofil Informationen, die mit einem Benutzer des Begleitgeräts 120 verbunden sind. In weiteren Ausführungsformen kann das Geräteprofil mit einem oder mehreren Geräten, die dazu autorisiert sind, die Fähigkeiten des Begleitgeräts 120 zu nutzen, assoziiert werden, oder anderweitige Informationen enthalten, die diese Geräte identifizieren. Bei 520 kann der IDS 205 eine Meldung „Status OK“ zurücksenden (zusammen mit einem neu erzeugten Token, wenn kein Token vorhanden war). Wenn die Validierung aus irgendeinem Grund fehlschlägt, kann der IDS 205 eine Meldung „connected with status invalid“ (verbunden - Status ungültig) zurück an das Begleitgerät 120 bei 520 senden.
-
Nach einem erfolgreichen Austausch, bei dem der Anwesenheitsbefehl für den Geräte-Token T1 ausgegeben wird, kann das Begleitgerät 120 damit beginnen, sich als Proxy-Gerät zu betätigen und SMS/MMS-Nachrichten für Proxied-Geräte senden und empfangen. Um eine Proxied-Anwesenheit zu schaffen, erzeugt das Mobilgerät 115 in ähnlicher Weise einen Anwesenheitsbefehl für den Geräte-Token T2 bei 525. Bei 530 sendet das Mobilgerät 115 den Anwesenheitsbefehl für den Geräte-Token T2 an den IDS 205.
-
Bei 535 werden die im Anwesenheitsbefehl für den Geräte-Token T2 an den IDS 205 weitergegebenen Daten ähnlich validiert wie vorstehend beschrieben. Wenn die Validierung aus irgendeinem Grund fehlschlägt, kann der IDS 205 eine Meldung „connected with status invalid“ (verbunden - Status ungültig) zurück an das Mobilgerät 115 bei 540 senden. Wenn alles erfolgreich validiert ist, kann der IDS 205 eine Meldung „Status OK“ (mit einem neu erzeugten Token, wenn kein Token vorhanden war) zurück an 540 senden. Der IDS 205 kann an diesem Punkt auch das Geräteprofil für das Begleitgerät 120 senden, mit dem die Fähigkeiten des Begleitgeräts 120 beschrieben werden. Es kann festgestellt werden, ob das Mobilgerät 115 ein autorisiertes Gerät ist. Wenn das Mobilgerät 115 dazu vorgesehen ist, kein autorisiertes Gerät zu sein, kann der IDS 205 die Übermittlung des Geräteprofils für das Begleitgerät 120, mit dem die Fähigkeiten des Begleitgeräts 120 beschrieben werden, an das Mobilgerät 115 einschränken.
-
In einigen Ausführungsformen erzeugt das Mobilgerät 115 einen Abfragebefehl für das Geräteprofil bei 545. Bei 550 sendet das Mobilgerät 115 den Abfragebefehl für das Geräteprofil an IDS 205. Bei 555 werden die im Abfragebefehl für das Geräteprofil an den IDS 205 weitergegebenen Daten validiert, beispielsweise um zu bestimmen, ob das Mobilgerät 115 oder ein Benutzer des Mobilgeräts 115 auf die angeforderten Geräteprofile zugreifen kann. Wenn die Validierung aus irgendeinem Grund fehlschlägt, kann der IDS 205 eine Meldung „connected with status invalid“ (verbunden - Status ungültig) zurück an das Mobilgerät 115 bei 560 senden. Wenn alles erfolgreich validiert ist, kann der IDS 205 eine Meldung „Status OK“ (zusammen mit irgendwelchen angeforderten Geräteprofilen) zurück an 560 senden.
-
B. Forward Push - Senden von SMS/MMS-Nachrichten an ein Proxy-Gerät
-
6 ist ein Message Sequence Chart, welches einen Überblick über SMS/MMS-Proxying gemäß verschiedener Ausführungsformen vermittelt. In diesen Beispielen erzeugt ein Proxied-Gerät (z.B. Mobilgerät 115) eine Nachricht, die unter Einsatz der SMS/MMS-Fähigkeiten eines Proxy-Geräts (z.B. Begleitgerät 120) an einen oder mehrere Empfänger bei 605 zu senden ist. Die Nachricht kann Nutzdaten umfassen, die mit den SMS/MMS-Fähigkeiten des Geräts an einen oder mehrere Empfänger zu kommunizieren sind. Des Weiteren kann die Nachricht eine Markierung oder eine andere Kennung umfassen, die dem Proxy-Gerät befiehlt, die Nutzdaten unter Einsatz seiner SMS/MMS-Fähigkeiten an den einen oder die mehreren Empfänger zu senden. Bei 610 wird die Nachricht an einen Dienst, beispielsweise an einen Content Delivery Service (z.B. PNS 220) oder an einen Messaging Service gesendet.
-
Bei 615 erhält der Dienst die Nachricht vom Proxied-Gerät und ermittelt das Ziel der Nachricht. In einigen Ausführungsformen bestimmt der Dienst das Proxy-Gerät als Ziel, zumindest für den Dienst, basierend auf einem Geräte-Token, der mit dem Proxy-Gerät assoziiert ist und entsprechend dem Geräteprofil des Proxy-Geräts der Nachricht des Proxied-Geräts beigefügt ist oder sich darin befindet. Bei 620 sendet der Dienst die Nachricht an das Proxy-Gerät. In einigen Ausführungsformen kann der Dienst eine Kopie der Nachricht an andere Geräte senden, die auf den Benutzer des Proxy-Geräts angemeldet sind. Der Dienst kann eine Kopie der Nachricht nur an die Geräte senden, die dazu autorisiert sind, die angegebenen Fähigkeiten des Proxy-Geräts zu nutzen oder in anderer Weise darauf zuzugreifen.
-
Bei 625 erhält das Proxy-Gerät die Nachricht und bestimmt, ob es selbst das vorgesehene Ziel und/oder der vorgesehene Empfänger ist. Das Proxy-Gerät kann bestimmen, dass es zwar das vorgesehene Ziel, aber nicht der vorgesehene Empfänger ist. Das Proxy-Gerät kann identifizieren, dass die Nachricht eine entsprechende Markierung oder einen sonstigen Hinweis darauf enthält, dass das Proxy-Gerät unter Einsatz seiner SMS/MMS-Fähigkeiten die Nutzdaten der Nachricht an einen oder mehrere Empfänger schicken soll. In einigen Ausführungsformen bestimmt das Proxy-Gerät, ob der Absender der Nachricht (d.h. das Proxied-Gerät) dazu autorisiert ist, die Fähigkeiten des Proxy-Geräts zu nutzen. Wenn das Proxy-Gerät die Nachricht weiterleiten soll und das Proxied-Gerät autorisiert ist, sendet das Proxy-Gerät eine SMS/MMS-Nachricht, die aufgrund der Nachricht erzeugt wurde (z.B. ihre Nutzdaten) unter Einsatz seiner SMS/MMS-Fähigkeiten an den einen oder die mehreren Empfänger bei 630.
-
In einigen Ausführungsformen kann das Proxy-Gerät den Sendungsstatus der an einen oder mehrere Empfänger gesendeten SMS/MMS-Nachricht bestimmen. Bei 635 erzeugt das Proxy-Gerät eine Bestätigung oder eine andere Nachricht, sendet die Nachricht an den Dienst und weist das Proxied-Gerät darauf hin, dass die SMS/MMS-Nachricht gesendet wurde. Bei 645 empfängt der Dienst die Nachricht vom Proxy-Gerät und bestimmt das Ziel der Nachricht. Bei 650 sendet der Dienst die Nachricht an das Proxied-Gerät. Bei 655 empfängt das Proxied-Gerät die Nachricht. Das Proxied-Gerät kann seine Benutzeroberfläche aktualisieren um damit den Status der SMS/MMS-Nachricht anzuzeigen.
-
Wie vorstehend erörtert, kann der Dienst und/oder das Proxy-Gerät eine Kopie der Nachricht oder der Statusinformation für die Nachricht an andere Geräte senden, die auf den Benutzer des Proxy-Geräts angemeldet sind. Der Dienst kann eine Kopie der Nachricht oder der Statusinformation für die Nachricht nur an die Geräte schicken, welche dazu autorisiert sind, die angegebenen Fähigkeiten des Proxy-Geräts zu nutzen oder anderweitig darauf zuzugreifen.
-
7 ist ein Flussdiagramm eines Verfahrens, das gemäß einer Ausführungsform von einem Proxied-Gerät durchgeführt wird, welchem die SMS/MMS-Fähigkeiten für die Übermittlung von SMS/MMS-Nachrichten an ein Proxy-Gerät fehlen, wobei das Proxy-Gerät diese SMS/MMS-Fähigkeiten besitzt. Die in 7 dargestellte Vorgehensweise nach dem Verfahren 700 kann von einer Software (z.B. Anweisungen oder Code-Module) durchgeführt werden, wenn diese von einer zentralen Recheneinheit (CPU oder Prozessor), einer Logik-Maschine, wie zum Beispiel einem Computersystem, oder Informationsverarbeitungsgerät, von Hardware-Komponenten eines elektronischen Geräts, von anwendungsspezifischen integrierten Schaltkreisen oder von Kombinationen aus Software- und Hardwareelementen ausgeführt wird.
-
In Schritt 710 wird ein Geräteprofil für ein Proxy-Gerät (z.B. Begleitgerät 120) ausgehend von einem Dienst (z.B. IDS 205) in einem Proxied-Gerät (z.B. Mobilgerät 115) empfangen. Das Geräteprofil kann eine Gerätekennung enthalten. Die Gerätekennung kann dazu verwendet werden, Nachrichten an das Proxy-Gerät zu senden. Das Geräteprofil kann des Weiteren Hardware- und/oder Software-Fähigkeiten des Proxy-Geräts enthalten, wie vorstehend erörtert.
-
In Schritt 720 werden Daten auf einer Benutzeroberfläche des Proxied-Geräts empfangen, so dass Nutzdaten gebildet werden können. Die Nutzdaten können Daten enthalten, die unter Einsatz der SMS/MMS-Fähigkeiten des Proxy-Geräts als SMS/MMS-Nachricht gesendet werden sollen. Die Nutzdaten können als Klartextnachricht, als Chat-Nachricht oder als sonstige elektronische Nachricht in vielen verschiedenen Formaten verkörpert werden. In Schritt 730 wird eine Nachricht im Proxied-Gerät erzeugt, basierend auf den Nutzdaten, einer Adresse mindestens eines SMS/MMS-Empfängers (z.B. einer Telefonnummer oder Kontaktkennung) und einer Markierung oder einer anderen Kennung, die dem Proxy-Gerät befiehlt, die Nutzdaten unter Einsatz seiner SMS/MMS-Fähigkeiten an irgendeinen oder irgendwelche beabsichtigten Empfänger zu senden.
-
In Schritt 740 wird die Nachricht unter Verwendung eines Content Delivery Service oder eines Messaging Service an das Proxy-Gerät gesendet. In einigen Ausführungsformen kann die Nachricht in Form eines Nachrichtenbefehls vorliegen. Der Nachrichtenbefehl kann die Art der Nachricht als Betreibermitteilung, das Ziel der Betreibermitteilung (d.h. ein Gerät oder ein App-Token) und/oder Nutzdaten identifizieren. Der Empfänger der SMS/MMS-Nachricht kann in der Betreibermitteilung oder in den Nutzdaten identifiziert werden. Im Gegensatz zu traditionellen Proxy-Techniken, bei denen Entitäten, die der SMS/MMS-Fähigkeiten entbehren, ein nicht unter ihrer Kontrolle stehendes Gateway oder einen externen Service Provider benutzen müssen, um Nachrichten von und zu Geräten ohne SMS/MMS-Fähigkeiten auf Proxy-Basis hin- und her zu senden, erleichtern diese Ausführungsformen die Entdeckung der eigenen Geräte eines Benutzers, welche die geeigneten Fähigkeiten zum Senden und Empfangen von SMS/MMS-Nachrichten haben, so dass die Geräte, die diese Fähigkeiten nicht haben, von einem anderen, eigenen Gerät des Benutzers Gebrauch machen können. Des Weiteren räumen diese Ausführungsformen einem Benutzer die Flexibilität ein, einen beliebigen Messaging Service zu nutzen, durch den sowohl das Proxy-Gerät als auch das Proxied-Gerät kommunizieren können.
-
In verschiedenen Ausführungsformen kann das Proxied-Gerät optional in Schritt 740 die Nachricht oder eine Kopie davon an andere Geräte senden, die dem Benutzer zugeordnet sind, und den anderen Geräten befehlen, ihre Benutzeroberflächen oder Nachrichtenrepositories mit der gesendeten Nachricht zu aktualisieren. Damit kann über alle Geräte eines Benutzers hinweg Konsistenz erzielt werden, da das Ausgangspostfach oder der Ordner Gesendete Elemente einer Messaging-Applikation aktualisiert werden kann, ungeachtet dessen, welches Gerät die Nachricht gesendet hat. Des Weiteren kann jedes der Geräte eines Benutzers eine Sendebenachrichtigung oder den Status solange anzeigen bis vom Proxy-Gerät oder Proxied-Gerät eine Aktualisierung eingegangen ist.
-
In Schritt 750 wird durch den Dienst eine Bestätigung darüber empfangen, dass die SMS/MMS-Nachricht gesendet wurde. In Schritt 760 wird die Benutzeroberfläche des Proxied-Geräts aktualisiert um anzuzeigen, dass die SMS/MMS-Nachricht gesendet wurde. Wie vorstehend angedeutet, kann jedes Gerät eines Benutzers einhergehend mit einer Bestätigung, dass die Nachricht ihrem beabsichtigten Empfänger zugestellt wurde, angewiesen werden, seine Benutzeroberfläche oder Nachrichtenrepositories zu aktualisieren. Das kann darin bestehen, die Elemente im Ausgangspostfach in den Ordner Gesendete Elemente zu bewegen, die Widgets auf der Benutzeroberfläche zu aktualisieren, Benachrichtigungen zu versenden, oder Ähnliches.
-
8 ist ein Flussdiagramm eines Verfahrens, das gemäß einer Ausführungsform von einem Proxy-Gerät mit SMS/MMS-Fähigkeiten zur Handhabung von SMS/MMS-Nachrichten im Auftrag von Proxied-Geräten durchgeführt wird, denen die SMS/MMS-Fähigkeiten fehlen. Die in 8 gezeigte Verarbeitung nach dem Verfahren 800 kann von einer Software (z.B. Anweisungen oder Code-Module) durchgeführt werden, wenn diese von einer zentralen Recheneinheit (CPU oder Prozessor) einer Logik-Maschine, wie zum Beispiel einem Computersystem, oder Informationsverarbeitungsgerät, von Hardware-Komponenten eines elektronischen Geräts, von anwendungsspezifischen integrierten Schaltkreisen oder von Kombinationen aus Software- und Hardwareelementen ausgeführt wird.
-
In Schritt 810 wird in einem Proxy-Gerät (z.B. Begleitgerät 120) eine Nachricht von einem Content Delivery Service oder Messaging Service empfangen. Die Nachricht kann über eine permanente Verbindung empfangen werden, die das Proxy-Gerät mit dem Dienst unterhält. In Schritt 820 bestimmt das Proxy-Gerät einen SMS/MMS-Empfänger. In verschiedenen Ausführungsformen kann der Messaging Service eine eigens erstellte Nachricht an das Proxy-Gerät schicken und das Proxy-Gerät anweisen, eine SMS/MMS-Nachricht an einen oder mehrere Empfänger zu senden. Die Nachricht kann ein spezielles Thema haben, mit dem sie gegenüber dem Proxy-Gerät als eine Nachricht identifiziert wird, die unter Einsatz seiner SMS/MMS-Fähigkeiten an einen oder mehrere Empfänger zu senden ist. In einigen Ausführungsformen kann der Messaging Service lediglich ein Übertragungsmechanismus zur Weiterleitung von Nachrichten sein, die in ihrem nativen Format erstellt sind. Das Proxied-Gerät und/oder das Proxy-Gerät kann/können bestimmen, wie es kenntlich gemacht werden soll, dass gegebenenfalls die Nutzdaten einer Nachricht als SMS/MMS-Nachrichten zu versenden sind.
-
In einigen Ausführungsformen kann Schritt 810 und/oder 820 einen oder mehrere Sicherheitsprüfungen umfassen. Zum Beispiel kann das Proxy-Gerät ermitteln, ob das Proxied-Gerät dazu autorisiert ist, die Fähigkeiten des Proxy-Geräts zu nutzen. Das Proxy-Gerät kann eine sichere Masterliste von autorisierten Geräten führen und als Reaktion auf eingehende Nachrichten diese Liste konsultieren. Das Proxy-Gerät kann außerdem feststellen, ob die Zustellung von Nachrichten an den beabsichtigten Empfänger eingeschränkt ist. Einschränkungen können auf der Identität des beabsichtigten Empfängers und/oder den Inhalten oder dem Betreff der Nachricht beruhen.
-
Wenn das Proxied-Gerät autorisiert und die Zustellung zum beabsichtigten Empfänger nicht eingeschränkt ist, sendet bspw. das Proxy-Gerät in Schritt 830 eine Übermittlungsbestätigung an den Dienst. Der Übermittlungsbefehl kann dem Service anzeigen, dass das Proxy-Gerät die Nachricht erhalten hat und dabei ist, einen Zustellversuch an den beabsichtigten SMS/MMS-Empfänger durchzuführen. Das System kann eine Benachrichtigung an das Proxied-Gerät (oder andere dem Benutzer zugeordnete Geräte) weiterleiten, so dass nun die Benutzeroberfläche die Nachrichtenstatus-Informationen anzeigen kann.
-
In Schritt 840 wird unter Verwendung des Proxy-Geräts eine SMS/MMS-Nachricht an einen Empfänger gesendet. Die SMS/MMS-Nachricht kann unter Verwendung der Verbindungen des Proxy-Geräts mit einem Mobilfunkbetreiber, Handy-Betreiber, Internet-SMS/MMS-Provider oder Ähnlichem an einen oder mehrere Empfänger gesendet werden. In Schritt 850 wird optional ermittelt, ob die SMS/MMS erfolgreich gesendet wurde. Das Proxy-Gerät kann bspw. beim Senden einer SMS/MMS-Nachricht einen Zustellbericht anfordern. Für die Zustellung nach bestem Bemühen kann der Vorgang des Sendens einer SMS/MMS-Nachricht als Erfolg gewertet werden.
-
Basierend auf der in Schritt 850 getroffenen Feststellung, dass die SMS/MMS erfolgreich gesendet wurde, wird in Schritt 860 eine Bestätigung erzeugt. Basierend auf der in Schritt 850 getroffenen Feststellung, dass die SMS/MMS nicht erfolgreich gesendet wurde, wird in Schritt 870 eine Fehlermeldung erzeugt. In Schritt 880 wird vom Begleitgerät eine Antwort an den Dienst gesendet. Die Antwort kann entweder die in Schritt 860 erzeugte Bestätigung oder die in Schritt 870 erzeugte Fehlermeldung beinhalten. In verschiedenen Ausführungsformen kann die Antwort auch über den Dienst an das Proxied-Gerät oder an weitere beteiligte oder autorisierte Geräte des Benutzers weitergeleitet werden.
-
C. Reply Push Senden von SMS/MMS-Nachrichten an Proxied-Geräte
-
9 ist ein Message Sequence Chart, in dem gemäß einer Ausführungsform das Weiterleiten von Antwort-SMS/MMS-Nachrichten, die an Proxy-Geräte zugestellt wurden, an Proxied-Geräte ohne SMS/MMS-Fähigkeiten dargestellt wird. In diesen Beispielen empfängt ein Proxy-Gerät (z.B. Begleitgerät 120) unter Einsatz seiner SMS/MMS-Fähigkeiten eine SMS/MMS-Nachricht bei 905. Bei 910 entscheidet das Proxy-Gerät, ob die SMS/MMS-Nachricht an andere Benutzergeräte weitergeleitet werden soll. Diese Entscheidung kann aufgrund dessen getroffen werden, dass das Proxy-Gerät bei früheren Nachrichten als Proxy fungiert hat, die von autorisierten, in einer Masterliste verzeichneten Geräten basierend auf den Präferenzen des Benutzers für die jeweiligen Geräte gesendet wurden. Wenn das Proxy-Gerät entscheidet, dass eine SMS/MMS-Nachricht an andere Benutzergeräte weitergeleitet werden soll, wird bei 910 eine Nachricht erzeugt. Bei 915 wird die Nachricht an einen Dienst, zum Beispiel an einen Content Delivery Service (z.B. PNS 220) oder einen Messaging Service gesendet.
-
Bei 920 empfängt der Dienst die Nachricht vom Proxy-Gerät und bestimmt das Ziel der Nachricht. In einigen Ausführungsformen bestimmt der Dienst ein Proxied-Gerät (z.B. Mobilgerät 115) als Ziel, zumindest für die Belange des Dienstes, basierend auf einem Geräte-Token, der mit dem Proxied-Gerät assoziiert ist und entsprechend dem Geräteprofil des Proxied-Geräts in der Nachricht des Proxy-Geräts integriert oder ihr beigefügt ist. Bei 925 sendet der Dienst die Nachricht an das Proxied-Gerät.
-
Bei 930 empfängt das Proxied-Gerät die Nachricht und entscheidet, ob es selbst das beabsichtigte Ziel und/oder der beabsichtigte Empfänger ist. Wenn dem so ist, verarbeitet das Proxied-Gerät die Nachricht. Zum Beispiel kann das Proxied-Gerät seine Benutzeroberfläche oder sein Nachrichtenrespository mit der SMS/MMS-Nachrichten aktualisieren.
-
III. KOMMUNIKATIONSSTAPEL AUF MOBILGERÄT
-
Die Kommunikation von Daten ausgehend von einem Gerät (z.B. Mobilgerät 115 oder Begleitgerät 120) kann über verschiedene Protokolle (z.B. 802.11 Protokolle, Bluetooth-Protokolle und Nahfeldkommunikationsprotokolle (NFC-Protokolle) erfolgen. Für die Entscheidung, welches Protokoll verwendet werden soll, kann ein Gerät einen Link Manager beinhalten, der festlegt, welches Protokoll für eine bestimmte Applikation zu verwenden ist und welche Treiberpfad-Daten gesendet werden sollten. Ein Link Layer einer unteren Ebene kann auch wählen, welches spezielle Protokoll verwendet werden soll. Außerdem kann ein User Tunnel (UTUN) Controller eine Vielzahl von virtuellen Verbindungen mit verschiedenen Client-Applikationen koordinieren und so eine Kommunikation über eine gemeinsame Socketverbindung mit einem anderen Gerät ermöglichen (z.B. Mobilgerät 115 kommuniziert mit Begleitgerät 120).
-
10 zeigt einen Protokollstapel 1000 für die Kommunikation von Daten gemäß Ausführungsformen der vorliegenden Erfindung. Verschiedene Module im Protokollstapel 1000 können wegfallen, andere Module können hinzugefügt werden. Die Softwaremodule können auf demselben Prozessor oder auf verschiedenen Prozessoren ausgeführt werden. Obwohl nur wenige Kommunikationsprotokolle gelistet sind, können zahlreiche drahtlose Protokolle verwendet werden. Bluetooth-Protokolle können bspw. Basic Rate (BR), Enhanced Data Rate (EDR) und Low Energy (LE) Optionen enthalten. Bluetooth BR/EDR wird auch als „Classic Bluetooth“ bezeichnet.
-
In einigen Ausführungsformen kann eine Client-Applikation 1005 auf dem Gerät (z.B. Mobilgerät 105) Daten abfragen, die an ein anderes Gerät zu senden sind (z.B. Begleitgerät 120). Bei der Abfrage kann das andere Gerät mit einer geeigneten Kennung angegeben werden, z.B. Account-Name, eine IP-Adresse, eine MAC-Adresse etc.). Die Abfrage kann erfolgen bevor oder nachdem das Gerät feststellt, dass das andere Gerät im Kommunikationsmodus ist; festzustellen ist dieses z.B. durch anfängliche Signalübertragung wie bei einem Handshake. Die Daten (z.B. in einer Nachricht oder einem Datenstrom) können an jedes geeignete Anwendungsschicht-Protokoll wie z.B. HTTP, RTP, SMTP, MGCP etc. gesendet werden. Das andere Gerät kann ein beliebiges Gerät, auch ein anderes Gerät des Benutzers sein. Die Abfrage kann als Reaktion auf eine vom Benutzer durchgeführte Aktion, ein internes Ereignis (z.B. basierend auf Zeit oder anderen Kriterien), das in derselben oder in einer anderen Applikation (z.B. Kalender-App) existieren kann, oder ein externes Ereignis (z.B. Reaktion auf eine Nachricht von einem anderen Gerät) erfolgen. Ein Beispiel für ein Ereignis ist ein Synchronisierungsereignis.
-
Vor dem Senden der Daten kann die Client-Applikation 1005 eine Open Socket-Anfrage (z.B. im Fall von Streaming) stellen. Die Socket-Anfrage kann Informationen von einem Identitätsdienste- (IDS-) Framework 1015 nutzen, die eine Adresse (oder eine andere Art von ID) für das andere Gerät liefern können. Zum Beispiel kann die Client-Applikation 1005 die Account-Informationen für das zweite Gerät (z.B. Account-Informationen eines anderen oder desselben Benutzers) „wissen“, und das IDS-Framework 1015 kann für einen bestimmten Account eine Liste von Geräte-IDs speichern. Um diese Liste zu erhalten, kann das IDS-Framework 1015 mit der Identitätsverwaltungs-Infrastruktur 105 in Kommunikation sein. Daher kann das IDS-Framework 1015 Geräte-IDs (z.B. Adressen) für alle Geräte, die der Benutzer bei der Identitätsverwaltungs-Infrastruktur 105 registriert hat, speichern oder auf andere Weise erlangen. Zum Beispiel kann das IDS-Framework 1015 die Identitätsverwaltungs-Infrastruktur 105 über einen IDS Daemon dazu auffordern, die Geräte-IDs zu übermitteln. In einer Implementierung kann die Socket-Anfrage an den Kernel 1010 gestellt werden.
-
In einem Messaging-Beispiel kann die Aufforderung zum Senden von Daten an das IDS-Framework 1015 gerichtet werden, um eine Geräte-ID zu erlangen, die an einen Nachrichtencontroller 1020 und einen User Tunnel (UTUN) Controller 1025 gesendet werden kann. Der UTUN Controller 1025 kann ein Mapping zwischen der Geräte-ID und einer IP-Adresse (z.B. einer virtuellen IP-Adresse) erstellen, wenn die Geräte-ID keine IP-Adresse ist. Zwischen dem Nachrichtencontroller 1020 (der dem Socket eine Geräte-ID zuweist) und dem Kernel 1010 (der dem Socket eine Adresse, z.B. eine virtuelle IP-Adresse zuweisen kann) kann ein Socket erzeugt werden. Der UTUN Controller 1025 kann dazu verwendet werden, zwischen dem Nachrichtencontroller 1020 und dem Kernel 1010 eine Socket-Verbindung herzustellen. Auf diese Weise braucht die „send date“ Anfrage von der Client-Applikation 1005 keine Geräte-ID zu beinhalten, vielmehr kann sie ein Account angeben, das dann vom IDS-Framework 1015 durch Cross Referencing mit bekannten Geräten des Accounts und deren Fähigkeiten (bspw. wenn die Anfrage bestimmte Fähigkeiten verlangt) verglichen wird. Da eine Geräte-ID durchaus ermittelt werden kann, braucht vor dem Erzeugen des Sockets keine Kopplung durchgeführt zu werden.
-
In verschiedenen Ausführungsformen kann das IDS-Framework 1015 von der Client-Applikation 1005 einen bestimmten Port/Dienst beim anderen Gerät angegeben bekommen, den Port/Dienst anhand der von der Identitätsverwaltungs-Infrastruktur 105 erhaltenen Informationen bestimmen oder den Port/Dienst aufgrund eines Token bestimmen, der in der Anforderung mitgeschickt wurde. Das IDS-Framework 1015 kann dann eine Geräte-ID und weitere Header-Informationen an den Nachrichtencontroller 1020 und/oder den UTUN Controller 1025 kommunizieren. Das IDS-Framework 1015 und der UTUN Controller 1025 können über Cross Process Communication (XPC) kommunizieren. Der UTUN Controller 1025 kann ein Teil eines IDS Daemons sein und eine Geräte-ID vom Identitätsverwaltungs-Server 215 erhalten.
-
Wie vorstehend erwähnt, kann der UTUN Controller 1025 eine virtuelle Adresse erzeugen, die der tatsächlichen Geräteadresse entspricht, wobei die virtuelle Adresse verwendet werden kann, um einen virtuellen Socket zu erzeugen. Ein virtueller Socket kann ebenfalls unter Verwendung einer beliebigen Geräte-ID (einer tatsächlichen Adresse eines Geräts oder einer andern ID) erzeugt werden. Beispielsweise kann ein Socket für die Kommunikation zwischen der Client-Applikation 1005 und dem Kernel 1010 (z.B. in einem Streaming-Kontext) erzeugt werden, wobei der Kernel 1010 verschiedene Sockets zu verschiedenen Client-Applikationen offen haben kann. Der Kernel 1010 kann eine einzelne Verbindung zum UTUN Controller 1025 für das andere Gerät haben und die Daten von verschiedenen Client-Applikationen in die einzelne Verbindung hinein multiplexen (muxen). Stattdessen bzw. außerdem kann der UTUN Controller 1025 auch das Muxen durchführen, wenn z.B. ein mehrfacher Socket zwischen dem Kernel 1010 und dem UTUN Controller 1025 für verschiedene Client-Applikationen zum anderen Gerät vorhanden ist. Eingehende Daten können gedemultiplext (gedemuxt) werden, so dass sie zur Ziel-Client-Applikation 1005 gesendet werden können.
-
Als weiteres Beispiel kann ein Socket zwischen dem Kernel 1010 und einem Nachrichtencontroller 1020 (z.B. in einem Messaging-Kontext) erzeugt werden, wobei der Socket für jedes Zielgerät erzeugt werden kann und verschiedene Sockets, die auf dasselbe Gerät bezogen sind, möglicherweise unterschiedliche Prioritäten haben. Daher kann ein bestimmter virtueller Socket mit einem bestimmten Gerät und einer bestimmten Priorität (z.B. hoch oder niedrig) assoziiert werden. Der Nachrichtencontroller 1020 kann verschiedene Verbindungen zu verschiedenen Client-Applikationen haben. Daher kann der Nachrichtencontroller 1020 die Fähigkeiten zum Muxen/Demuxen aufweisen.
-
Der UTUN Controller kann einen primären Socket zum anderen Gerät erzeugen. Wenn der UTUN Controller 1025 Daten über eine virtuelle Verbindung erhält, die mit dem zweiten Gerät assoziiert ist, kann er die virtuelle Verbindung zum primären Socket für die Kommunikation mit dem anderen Gerät durch Mapping abbilden. Alle Daten für das andere Geräte können dann durch den primären Socket gesendet werden. Die virtuelle Adresse für einen virtuellen Sockel kann an die Client-Applikation 1015 zurückgegeben werden, z.B. im Stream-Kontext. In einer Ausführungsform ist ein virtueller Socket, bei dem der Kernel 1010 involviert ist, ein TCP-Socket. Die virtuelle Adresse kann dasselbe Format wie eine reguläre Adresse, z.B. eine IPv6 Adresse haben. Ein Mux-Modul kann eine beliebige Kombination aus Kernel 1010, Nachrichtencontroller 1020 und UTUN Controller 1025 beinhalten.
-
Wenn die Client-Applikation 1005 Daten sendet, kann die Client-Applikation 1005 den virtuellen Socket nutzen, um Daten zum Kernel 1010 zu senden. Beispielsweise können die Daten unter Verwendung des TCP über den virtuellen Sockel gesendet werden. Der Kernel 1010 kann eine UTUN-Schnittstelle für die Kommunikation mit dem UTUN Controller 1025 implementieren. Der Kernel 1010 gibt dann die Daten (z.B. mit einem TCP-Header) weiter, und der virtuelle Socket identifiziert die virtuelle Adresse gegenüber dem UTUN Controller 1025, der dann die virtuelle Adresse nutzt um die Geräte-Adresse zwecks Bestimmung des Geräte-Sockets zu ermitteln.
-
Beim Senden der Daten über den Geräte-Socket kann der Link Manager 1030 bestimmen, welcher Link genutzt werden soll. Ein Link kann eine bestimmte Kombination aus einem drahtlosen Schnittstellenprotokoll (z.B. Bluetooth oder WLAN), einem Transportprotokoll (z.B. TCP, UDP etc.) und einem Zielgerät sein. Auf diese Weise braucht der UTUN Controller 1025 nicht zu „wissen“, wie die Daten gesendet werden, sondern kann die Daten einfach an den Link Manager 1030 senden.
-
In verschiedenen Ausführungsformen kann die Entscheidung des Link Managers pro Datenpaket, pro Satz Datenpakete oder pro Geräte-Socket getroffen werden und sich von einem Datenpaket zum nächsten ändern. Der Link Manager 1030 kann dann einen Link für das Senden der Daten wählen. Im dargestellten Beispiel liefert ein WLAN-Linki035 die Softwaretreiber für die Kommunikation über ein oder mehrere WLAN-Protokolle, und ein BLTE-Link 1040 liefert die Softwaretreiber für die Kommunikation über Bluetooth LE. Der WLAN-Link 1035 ist in Kommunikation mit der WLAN-Hardware 1070, und der BLTE-Link 1040 ist in Kommunikation mit der BTLE-Hardware 1065. Der WLAN-Link 1035 kann für verschiedene WLAN-Protokolle verwendet werden, wie zum Beispiel infra-WLAN (Infrastructure-WLAN). In einer Ausführungsform kann der Link Manager 1030 alle Links ausprobieren, um herauszufinden, ob einer von ihnen das andere Gerät kontaktieren kann, und dann kann er den verbunden Link mit dem höchsten vorgegebenen Rang oder mit einem dynamischen Rang wählen.
-
Die Hardware 1065-1170 kann in Kommunikation mit den Links sein, die verschiedenen Geräten zugewiesen sind. Zum Beispiel können die Links 1035, 1040 und 1045 für die Kommunikation mit einem zweiten Gerät zugewiesen sein. Und andere Links, die für die Kommunikation mit einem dritten Gerät zugewiesen sind, können ebenfalls in Kommunikation mit der Hardware 1065-1170 sein. Wenn eine bestimmte Hardware Daten empfängt, kann die Software ein bestimmtes, sendendes Gerät identifizieren und dann, z.B. unter Verwendung von Header-Informationen den entsprechenden Link bestimmen, der zum sendenden Gerät und zum Transportprotokoll gehört.
-
In einigen Ausführungsformen kann ein kombinierter Link 1045 eine Schnittstelle 1055 für die Kommunikation mit dem Link Manager 1030 und einen Selektor 1050 umfassen, der ein bestimmtes Protokoll zur Verwendung auswählt. Die Protokolle können die gleichen wie diejenigen sein, die dem Link Manager 1030 zur Verfügung stehen, es können aber auch andere sein. Der Selektor 1050 kann ähnliche Funktionen wie der Link Manager 1030 ausführen, indem ein bestimmter Link ausgewählt wird. Jedoch können der Link Manager 1030 und der Selektor 1050 bei der Entscheidung, welcher Link zu verwenden ist, unterschiedliche Kriterien anwenden. Beispielsweise kann der Link Manager 1030 entscheiden, den kombinierten Link 1045 zu verwenden, und der Selektor 1050 kann entscheiden, dass die BTLE Hardware 1065 verwendet werden soll. Die Hardware kann auf dem gleichen Chip oder auf separaten Chips untergebracht sein.
-
Eines oder mehrere Protokolle können nur über den kombinierten Link 1045 verfügbar sein, bspw. die klassische Bluetooth Hardware 1050. Der Link Manager 1030 und der Selektor können bei der Entscheidung, welcher Link zu verwenden ist, unterschiedliche Kriterien anwenden, wie zum Beispiel den Stromverbrauch eines Links, die Geschwindigkeit eines Links (z.B. Echtzeit-Datenrate), und die Signalstärke eines Links. Bei der Wahl des Links kann ein Optimierungsziel darin bestehen, eine minimale Datenrate mit dem möglichst geringsten Energieverbrauch vorzusehen.
-
IV. MOBILGERÄT
-
11 ist ein Blockdiagramm eines tragbaren elektronischen Geräts oder Mobilgeräts 1100 gemäß einer Ausführungsform. Das Mobilgerät 1100 umfasst im Allgemeinen ein computerlesbares Medium 1102, ein Verarbeitungssystem 1104, ein Input/Output (I/O) Subsystem 1106, drahtlose Schaltungen 1108, Audioschaltungen 1110 einschließlich Lautsprecher 1112 und Mikrofon 1114. Diese Komponenten können über einen oder mehrere Kommunikationsbusse oder Signalleitungen miteinander verkoppelt sein. Das Mobilgerät 1100 kann irgendein tragbares elektronisches Gerät sein, einschließlich Handheld-Computer, Tablet-Computer, Mobiltelefon, Laptop-Computer, Tablet-Gerät, Medienplayer, Personal Digital Assistant (PDA), Schlüsselanhänger, Autoschlüssel, Access Card, Multifunktionsgerät, Handy, tragbares Spielegerät o.Ä., einschließlich einer Kombination aus zwei oder mehreren dieser Gegenstände.
-
Es sollte offenkundig sein, dass die in 11 gezeigte Architektur nur ein Beispiel für eine Architektur des Mobilgeräts 1100 ist, und dass das Mobilgerät 1100 mehr oder weniger Komponenten oder eine andere Konfiguration von Komponenten besitzen kann als dort gezeigt wird. Die verschiedenen in 11 gezeigten Komponenten können in Hardware, Software oder einer Kombination aus Hard- und Software ausgebildet werden, einschließlich einer oder mehrerer Signalverarbeitungs- und/oder anwendungsspezifischer integrierter Schaltungen.
-
Die drahtlosen Schaltungen 1108 werden verwendet, um Informationen über einen drahtlosen Link oder ein drahtloses Netzwerk zu senden und empfangen und sie an die konventionellen Schaltungen anderer Geräte, bspw. eines Antennensystems, eines RF-Transceivers, eines oder mehrerer Verstärker, eines Tuners, eines oder mehrerer Oszillatoren, eines digitalen Signalprozessors, eines CODEC Chipsets, eines Speichers etc. zu senden und von dort zu empfangen. In einigen Ausführungsformen sind die drahtlosen Schaltungen 1108 in der Lage, Kommunikation mit anderen Geräten herzustellen und aufrechtzuerhalten, wofür sie eines oder mehrere Kommunikationsprotokolle verwenden, einschließlich Zeitmultiplexverfahren (TDMA), Codemultiplexverfahren (CDMA), das Globale Mobilkommunikationssystem (GSM), das erweiterte GSM-Datenumfeld (EDGE), Wideband Code Division Multiple Access (W-CDMA), Long Term Evolution (LTE), LTE-Advanced, WLAN (wie bspw. IEEE 802.11a, IEEE 802.11b, IEEE 802.11g und/oder IEEE 802.11n), Bluetooth, Wi-MAX, Internet-Telefonie (VoIP), Nahfeld-Kommunikationsprotokoll, Protokoll für eMail, Instant Messaging und/oder Kurznachrichtendienst (SMS) oder irgendein anderes geeignetes Kommunikationsprotokolls, auch Kommunikationsprotokolle, die zum Einreichungszeitpunkt dieses Dokumentes noch nicht entwickelt waren. Ein Mobilgerät 1100 kann drahtlose Schaltungen umfassen, die über mehrere unterschiedliche Arten von drahtlosen Netzwerken kommunizieren können, je nach der Reichweite, die für die Kommunikation erforderlich ist. Je nach Art bzw. Reichweite der Kommunikation kann z.B. ein drahtloser Transceiver für kurze Reichweiten (z.B. Bluetooth), für mittlere Reichweiten (z.B. WLAN) und/oder für große Reichweiten (z.B. GSM/GPRS, UMTS, CDMA2000 ix/EV-DO und LTE/LTE-Advanced) verwendet werden.
-
Die drahtlosen Schaltungen 1108 sind über die Peripherieschnittstelle 1116 mit dem Verarbeitungssystem 1104 gekoppelt. Die Schnittstelle 1116 kann konventionelle Komponenten für die Herstellung und Aufrechterhaltung von Kommunikation zwischen Peripheriegeräten und dem Verarbeitungssystem 1104 enthalten. Von den drahtlosen Schaltungen 1108 erhaltene Sprach- und Dateninformationen (z.B. in Spracherkennungs- oder Sprachbefehlsanwendungen) werden über die Peripherieschnittstelle 1116 an einen oder mehrere Prozessoren 1118 geleitet. Der eine oder die mehreren Prozessoren sind konfigurierbar, so dass verschiedene Datenformate verarbeitet werden können.
-
Die Peripherieschnittstelle 1116 koppelt die Eingangs- und Ausgangs-Peripherie des Geräts 1100 mit dem einen oder mehreren Prozessoren 1118 und dem computerlesbaren Medium 1102. Der eine oder die mehreren Prozessoren 1118 kommunizieren über einen Controller 1120 mit dem computerlesbaren Medium 1102. Das computerlesbare Medium 1102 kann irgendein Gerät oder Medium sein, das Code und/oder Daten zur Verwendung durch den einen oder die mehreren Prozessoren 1118 speichern kann. Das Medium 1102 kann eine Speicherhierarchie, einschließlich Cache, Hauptspeicher und Sekundärspeicher umfassen. Die Speicherhierarchie kann mit irgendeiner Kombination aus RAM (z.B. SRAM, DRAM, DDRAM), ROM, FLASH, magnetischen und/oder optischen Speichergeräten, wie bspw. Laufwerke, Magnetband, CDs (Compact Discs) und DVDs (Digital Video Discs) implementiert werden. In einigen Ausführungsformen können die Peripherieschnittstelle 116, der eine oder die mehreren Prozessoren 1118 und der Speichercontroller 1120 auf einem einzelnen Chip implementiert werden, z.B. Verarbeitungssystem 1104. In einigen anderen Ausführungsformen können sie auf separaten Chips implementiert werden.
-
Das Mobilgerät 1100 kann ebenfalls ein Stromversorgungssystem 1122 für die Versorgung der verschiedenen Hardware-Komponenten mit elektrischer Energie umfassen. Das Stromversorgungssystem 1122 kann ein Strommanagement-System, eine oder mehrere Stromquellen (z.B. Batterie, Wechselstrom (AC)), ein Ladesystem, eine Netzausfallerkennungsschaltung, einen Stromrichter oder Wechselrichter, eine Spannungsanzeige (z.B. eine Leuchtdiode, LED) und irgendwelche sonstigen Komponenten, die typischerweise mit der Erzeugung, der Verwaltung und der Verteilung von Strom in mobilen Geräten assoziiert werden, umfassen.
-
In einigen Ausführungsformen umfasst das Mobilgerät 1100 eine Kamera 1124. In einigen Ausführungsformen enthält das Mobilgerät 1100 Sensoren 1126. Die Sensoren können Beschleunigungsmesser, Kompass, Gyrometer, Drucksensoren, Audiosensoren, Lichtsensoren, Barometer und Ähnliches umfassen. Die Sensoren 1126 können verwendet werden um Standortfaktoren abzutasten, wie zum Beispiel die akustischen Verhältnisse und die Lichtverhältnisse eines Standorts. In einigen Ausführungsformen kann das Mobilgerät 1100 einen GPS-Empfänger, manchmal als GPS-Gerät 1128 bezeichnet, umfassen. Ein Mobilgerät kann ein Satelliten-Navigationssystem nutzen, wie zum Beispiel das Global Positioning System (GPS), um Standortinformationen, Zeitinformationen, Höhenlagen oder sonstige Navigations-Informationen zu ermitteln. In einigen Ausführungsformen kann das Mobilgerät 1100 einen externen Port 1130 umfassen (z.B. USB, FireWire, Lightning-Anschluss, 30-poliger Anschluss etc.). Der externe Port 1130 kann für die direkte Kopplung mit anderen Geräten oder für die indirekte Kopplung über ein Netzwerk (z.B. Internet, WLAN etc. ) angepasst werden.
-
Der eine oder die mehreren Prozessoren 1118 führen verschiedene Software-Komponenten aus, die im Medium 1102 gespeichert sind, um bestimmte Funktionen für das Gerät 1100 durchzuführen. In einigen Ausführungsformen umfassen die Software-Komponenten das Betriebssystem 1132, das Kommunikationsmodul (oder einen Befehlssatz) 1134 und weitere Anwendungen (oder Befehlssätze) 1136. Das Betriebssystem 1132 kann irgendein geeignetes Betriebssystem sein, einschließlich iOS, Mac OS, Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS oder ein eingebettetes Betriebssystem wie bspw. VxWorks. Das Betriebssystem kann verschiedene Prozeduren, Befehlssätze, Softwarekomponenten und/oder Treiber für die Steuerung und Verwaltung der allgemeinen Systemaufgaben (z.B. Speicherverwaltung, Speichergerätesteuerung, Energiemanagement etc.) umfassen und erleichtert die Kommunikation zwischen verschiedenen Hardware- und Softwarekomponenten.
-
Das Kommunikationsmodul 1134 erleichtert die Kommunikation mit anderen Geräten über einen oder mehrere externe Ports 1130 oder über die drahtlosen Schaltungen 1108 und enthält verschiedene Softwarekomponenten für die Handhabung von Daten, die von den drahtlosen Schaltungen 1108 und/oder dem externen Port 1130 empfangen wurden.
-
Die eine oder mehreren Applikationen 1136 auf dem Mobilgerät 1100 können alle Applikationen einschließen, die auf dem Gerät 1100 installiert sind, einschließlich, aber ohne Beschränkung auf einen Browser, ein Adressbuch, eine Kontaktliste, E-Mail, Instant Messaging, soziale Netze, Textverarbeitung, Tastatur-Emulation, Widgets, JAVA-fähige Applikationen, Verschlüsselung, digitale Rechteverwaltung, Spracherkennung, Stimmnachbildung, einen Musikspieler (der aufgenommene und in einer oder mehreren Dateien, z.B. MP3 oder AAC-Dateien gespeicherte Musik wiedergibt).
-
Es können auch andere Module oder Befehlssätze (nicht gezeigt) vorhanden sein, wie zum Beispiel ein Grafikmodul, ein Zeitmodul etc. Zum Beispiel kann das Grafikmodul verschiedene konventionelle Softwarekomponenten zum Rendern, Animieren und Anzeigen grafischer Objekte (einschließlich, aber ohne Beschränkung auf Text, Webseiten, Icons, digitale Bilder, Animationen u.Ä.) auf einer Display-Oberfläche umfassen. In einem anderen Beispiel kann ein Timer-Modul ein Software-Timer sein. Das Timer-Modul kann auch in Hardware implementiert werden. Das Timer-Modul kann verschiedene Timer für eine beliebige Anzahl von Ereignissen unterhalten.
-
Das I/O Subsystem 1106 kann mit einem Display-System (nicht gezeigt) gekoppelt werden, welches ein berührungsempfindliches Display sein kann. Das Display zeigt dem Benutzer die visuelle Ausgabe auf einer grafischen Benutzeroberfläche (GUI) an. Die visuellen Ausgaben können Text, Grafik, Video und irgendeine Kombination davon umfassen. Einige oder alle der visuellen Ausgaben können Benutzeroberflächen-Objekten entsprechen. Ein Display kann LEDs (Leuchtdioden), LCD-(Flüssigkristallanzeigen-)-Technologie oder LPD-(lichtemittierende Polymerdisplay-)-Technologie verwenden, obwohl in anderen Ausführungsformen andere Display-Technologien verwendet werden können.
-
In einigen Ausführungsformen kann das I/O-Subsystem 1106 ein Display und Benutzereingabevorrichtungen wie bspw. eine Tastatur, Maus und/oder ein Trackpad umfassen. In einigen Ausführungsformen kann das I/O-Subsystem 1106 ein berührungsempfindliches Display umfassen. Ein berührungsempfindliches Display kann auch Eingaben vom Benutzer basierend auf haptischem und/oder taktilem Kontakt annehmen. In einigen Ausführungsformen bildet ein berührungsempfindliches Display eine berührungsempfindliche Oberfläche, welche die Eingabe des Benutzers annimmt. Das berührungsempfindliche Display/Oberfläche detektiert (gemeinsam mit irgendwelchen assoziierten Modulen und/oder Befehlssätzen in Medium 1102) Kontakt (und irgendeine Bewegung oder ein Loslassen des Kontakts) auf dem berührungsempfindlichen Display und wandelt den detektierten Kontakt um in Interaktion mit Benutzeroberflächenobjekten, wie bspw. einen oder mehrere Softkeys, die auf dem Berührungsbildschirm angezeigt werden, wenn der Kontakt erfolgt. In einigen Ausführungsformen entspricht ein Kontaktpunkt zwischen dem berührungsempfindlichen Display und dem Benutzer einer oder mehrerer Fingerbreiten des Benutzers. Der Benutzer kann Kontakt herstellen mit dem berührungsempfindlichen Display unter Verwendung irgendeines geeigneten Objekts oder Zubehörs, wie z.B. eines Eingabestifts, Stifts, Fingers, usw. Ein berührungsempfindliches Display kann den Kontakt sowie jede Bewegung oder jedes Loslassen davon detektieren unter Verwendung irgendwelcher geeigneter Sensitivitätstechnologien, einschließlich kapazitive, Widerstands-, Infrarot-, und oberflächenakustische Wellentechnologien sowie Näherungssensoranordnungen oder andere Elemente zum Bestimmen eines oder mehrerer Kontaktpunkte auf dem berührungsempfindlichen Display.
-
Des Weiteren kann das I/O-Subsystem mit einer oder mehreren anderen physischen Steuervorrichtungen (nicht gezeigt) gekoppelt werden, wie bspw. Druckknöpfe, Tasten, Schalter, Wippschalter, Nummernschalter, Schiebeschalter, Sticks, LEDs etc. zum Steuern oder Ausführen verschiedener Funktionen, wie Energiesteuerung, Lautsprecherlautstärkeregelung, Klingeltonlautstärke, Tastatureingabe, Scrollen, Halten, Menü, Bildschirmsperre, Löschen und Beenden von Kommunikation und Ähnlichem. In einigen Ausführungsformen kann zusätzlich zum Berührungsbildschirm das Gerät 1100 ein Touchpad (nicht gezeigt) zur Aktivierung oder Deaktivierung bestimmter Funktionen umfassen. In einigen Ausführungsformen ist das Touchpad ein berührungsempfindlicher Bereich des Geräts, der, anders als der Berührungsbildschirm, keine visuelle Ausgabe anzeigt. Das Touchpad kann eine berührungsempfindliche Oberfläche sein, die vom berührungsempfindlichen Display getrennt oder eine Erweiterung der berührungsempfindlichen Oberfläche ist, welche vom berührungsempfindlichen Display gebildet wird.
-
Die vorstehende Beschreibung kann sich auf spezifische Beispiele eines Mobilgeräts (z.B. eines am Handgelenk tragbaren Geräts) und/oder eines Begleitgerät (z.B. eines Smartphones) beziehen. Es versteht sich, dass diese Beispiele veranschaulichend und nicht einschränkend sind; sie können durch andere Vorrichtungen ersetzt werden, die ähnliche Funktionsblöcke und/oder Algorithmen ausführen, um die hierin beschriebenen Vorgänge und/oder andere Vorgänge durchzuführen.
-
Ausführungsformen der vorliegenden Erfindung z.B. in Verfahren, Vorrichtungen, computerlesbaren Medien u.Ä. können unter Verwendung irgendeiner Kombination aus dedizierten Komponenten, programmierbaren Prozessoren und/oder programmierbaren Geräten realisiert werden. Die hierin beschriebenen verschiedenen Prozesse können auf demselben Prozessor oder auf verschiedenen Prozessoren in irgendeiner Kombination durchgeführt werden. Wo es beschrieben wird, dass die Komponenten dazu konfiguriert sind, bestimmte Aktionen durchzuführen, kann diese Konfiguration z.B. durch die Gestaltung elektronischer Schaltungen zur Durchführung dieser Aktionen oder durch die Programmierung programmierbarer elektronischer Schaltkreise (wie z.B. Mikroprozessoren) zur Durchführung dieser Aktionen oder durch irgendeine Kombination davon erfolgen. Während sich die vorstehend beschriebenen Ausführungsformen auf spezifische Hardware- und Softwarekomponenten beziehen können, wird der Fachmann erkennen, dass ebenfalls andere Kombinationen aus Hardware- und/oder Softwarekomponenten verwendet werden können, und dass bestimmte Aktionen, die als in Hardware implementiert beschrieben werden, auch in Software implementiert werden können und umgekehrt.
-
Computerprogramme, die verschiedene Merkmale der vorliegenden Erfindung umfassen, können codiert und auf verschiedenen computerlesbaren Speichermedien gespeichert werden; geeignete Medien umfassen Magnetplatte oder - band, optische Speichermedien wie Compact Disc (CD) oder DVD (Digital Versatile Disc), Flash-Speicher und sonstige nichtflüchtige Medien. Die mit dem Programmcode codierten computerlesbaren Medien können mit einem kompatiblen elektronischen Gerät gebündelt werden, oder der Programmcode kann getrennt von elektronischen Geräten bereitgestellt werden (z.B. über Internet-Download oder als separat verpacktes computerlesbares Speichermedium).
-
Obwohl die Erfindung im Hinblick auf spezifische Ausführungsformen beschrieben wurde, ist es daher anzuerkennen, dass mit der Erfindung beabsichtigt wird, alle Modifikationen und Äquivalente innerhalb des Schutzumfangs der nachfolgenden Ansprüche abzudecken.
-
In einigen Ausführungsformen eines Verfahrens für Proxied-Kommunikation kann das Verfahren umfassen: eine erste Vorrichtung, die einen oder mehrere Prozessoren hat, sowie eine Schnittstelle, die Fähigkeiten für den Kurznachrichtendienst (SMS) oder den Multimedia Messaging Service (MMS) hat: Registrieren von Profilinformationen der ersten Vorrichtung, die darauf hinweisen, dass die erste Vorrichtung Fähigkeiten für den Kurznachrichtendienst (SMS) oder den Multimedia Messaging Service (MMS) hat; Empfangen von Nutzdaten, die auf den Profilinformationen basieren und von einer zweiten Vorrichtung erzeugt wurden, welche mit dem Benutzer der ersten Vorrichtung assoziiert ist, wobei die Nutzdaten eine Nachricht, eine Adresse einer Empfängervorrichtung und eine Markierung enthalten, die darauf hinweist, dass die erste Vorrichtung die Nachricht an die Empfängervorrichtung zu senden hat; und Senden der Nachricht als SMS/MMS-Nachricht an die Empfängervorrichtung unter Verwendung der Schnittstelle.
-
In irgendeiner der vorstehenden Ausführungsformen umfasst das Empfangen der Nutzdaten von der zweiten Vorrichtung das Empfangen der Nutzdaten als eine Nicht-SMS/MMS-Nachricht.
-
In irgendeiner der vorstehenden Ausführungsformen umfasst das Registrieren der Profilinformationen der ersten Vorrichtung die Bereitstellung eines oder mehrerer Attribute der ersten Vorrichtung, die auf die Gerätefähigkeiten zum Senden von SMS/MMS-Nachrichten hinweisen.
-
In irgendeiner der vorstehenden Ausführungsformen umfasst die Nachricht Chat-Daten, die an einer Benutzeroberfläche der zweiten Vorrichtung erhalten wurden.
-
In irgendeiner der vorstehenden Ausführungsformen umfasst die Nachricht das Empfangen von Multimedia-Daten, die an einer Benutzeroberfläche der zweiten Vorrichtung gewählt wurden.
-
In irgendeiner der vorstehenden Ausführungsformen kann das Verfahren weiterhin umfassen: an der ersten Vorrichtung: Senden einer Benachrichtigung an die zweite Vorrichtung, die darauf hinweist, dass die erste Vorrichtung die SMS/MMS-Nachricht gesendet hat.
-
In irgendeiner der vorstehenden Ausführungsformen kann das Verfahren weiterhin umfassen: Senden von Informationen an eine oder mehre der einen oder mehreren Vorrichtungen, die mit dem Benutzer assoziiert, sind als Reaktion auf das Senden der SMS/MMS-Nachricht.
-
In einigen Ausführungsformen kann ein Verfahren der Proxied-Kommunikation umfassen: einen Server, der ein oder mehrere Computersysteme hat: Empfangen von Informationen zur Registrierung von Gerätefähigkeiten einer ersten Vorrichtung, wobei die Informationen darauf hinweisen, dass die erste Vorrichtung Fähigkeiten für den Kurznachrichtendienst (SMS) oder den Multimedia Messaging Service (MMS) hat; Senden der Gerätefähigkeiten der ersten Vorrichtung an eine zweite Vorrichtung, die mit dem Benutzer der ersten Vorrichtung assoziiert ist; Empfangen von Nutzdaten von der zweiten Vorrichtung, die an die erste Vorrichtung zu senden sind, wobei die Nutzdaten von der zweiten Vorrichtung erzeugt wurden, wobei die Nutzdaten eine Nachricht, eine Adresse einer Empfängervorrichtung und eine Markierung enthalten, welche darauf hinweist, dass die erste Vorrichtung die Nachricht an die Empfängervorrichtung zu senden hat; und Senden der Nutzdaten an die erste Vorrichtung unter Verwendung einer Nicht-SMS/MMS-Nachricht, wobei die Nutzdaten die ersten Vorrichtung anweisen, die Nachricht als SMS/MMS-Nachricht an die Empfängervorrichtung zu senden.
-
In irgendeiner der vorstehenden Ausführungsformen kann das Verfahren außerdem umfassen: am Server: Erhalten einer Anfrage von der zweiten Vorrichtung, welche die Gerätefähigkeiten der ersten Vorrichtung abfragt; und Identifizieren eines Geräteprofils, welches die Gerätefähigkeiten der ersten Vorrichtung angibt.
-
In irgendeiner der vorstehenden Ausführungsformen kann das Verfahren außerdem umfassen: am Server: Senden der Nutzdaten an andere, mit dem Benutzer assoziierte Vorrichtungen unter Verwendung von Nicht-SMS/MMS-Nachrichten, wobei die Nutzdaten die anderen Vorrichtungen anweisen, Nachrichtenrepositories zu aktualisieren.
-
In irgendeiner der vorstehenden Ausführungsformen kann das Verfahren außerdem umfassen: am Server: Deregistrieren der Gerätefähigkeiten der ersten Vorrichtung; und Senden einer Benachrichtigung an die zweite Vorrichtung.