-
Hintergrund der Erfindung
-
1. Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht sich auf ein Verfahren, das in einem Dienst- bzw. Servicesystem verwendet wird, und insbesondere auf ein verfahren zum Vorsehen des Prozessbetriebs in einem Verwaltungsgegenstand bzw. Management-Objekt der Software- und Applikationssteuerung bzw. SACMO (SACMO = Software and Application Control Management Object) für ein Servicesystem.
-
2. Beschreibung des Standes der Technik
-
Die Open Mobile Alliance (OMA) wurde gegründet, um OMA-Spezifikationen für mobile Dienste zu entwickeln, die die Bedürfnisse der Nutzer erfüllen. Darüber hinaus zielen die OMA-Spezifikationen darauf ab, mobile Dienste vorzusehen, die kompatibel bzw. interoperabel über geographische Gebiete (z. B. Länder), Betreiber, Service-Provider, Netzwerke, Betriebssysteme und mobile Vorrichtungen hinweg sind. Im Detail können mobile Dienste, die den OMA-Spezifikationen entsprechen, durch die Nutzer verwendet werden, ohne Beschränkung auf bestimmte Betreiber und Service-Provider. Die mobilen Dienste, die den OMA-Spezifikationen entsprechen, sind ebenfalls trägerdienstunabhängig, d. h. die Träger, die die mobilen Dienste tragen, können mobile System der zweiten Generation (2G), wie beispielsweise GSM, EDGE oder GPRS, oder einer dritten Generation (3G) und spätere mobile Systeme, wie beispielsweise UMTS, LTE oder LTE-Advanced sein. Ferner können die mobilen Dienste auf einem Betriebssystem, wie beispielsweise Windows, Android oder Linux, die auf verschiedenen mobilen Vorrichtungen betrieben werden, ausgeführt werden. Daher können Branchen die Vorrichtungen liefern oder die mobilen Dienste, die die OMA-Spezifikationen unterstützen, von einem stark wachsenden Markt profitieren, der durch die Interoperabilität bzw. vollständige Kompatibilität der mobilen Dienste ermöglicht wird. Darüber hinaus können die Benutzer, die Vorrichtungen nutzen oder die mobilen Dienste verwenden, die die OMA-Spezifikationen unterstützen, bessere Erfahrungen aufgrund der Interoperabilität der mobilen Dienste sammeln.
-
Ein Vorrichtungsverwaltungs- bzw. DM-Protokoll (DM = Device Management), das den OMA-Spezifikationen entspricht, ist für die Verwaltung von Vorrichtungen, wie beispielsweise Mobiltelefone, PDAs und Palmtop-Computer ausgelegt. Die Vorrichtungsverwaltung soll die folgenden typischen Verwendungen unterstützen: die Konfiguration der Vorrichtung zum Ermöglichen von Veränderungen an den Einstellungen und Parametern der Vorrichtung, Software-Upgrades zum Vorsehen neuer Software (z. B. Applikationen und System-Software) und/oder Fehlerbehebungen, die auf die Vorrichtung geladen werden können, und Störungsmanagement zum Melden von Fehlern von der Vorrichtung und/oder Abfragen über den Status der Vorrichtung. Zusätzlich definiert das DM-Protokoll einen Weg, gemäß dem ein DM-klient (z. B. eine mobile Vorrichtung) mit einem DM-Server (z. B. Netzwerk) kommuniziert, und dadurch kann der DM-Klient einen Befehl, einen Status oder eine Meldung an den DM-Server rückkoppeln. Ferner verwaltet der DM-Server den DM-Klient durch einen Satz von Verwaltungsgegenständen bzw. Management-Objekten in dem DM-Klient. Das Management-Objekt entspricht einer Software- und Applikationssteuerungs-Verwaltungsgegenstands-Spezifikation bzw. SACMO-Spezifikation (SACMO = Software and Application Control Management Object), die darauf abzielt, Fernbetätigungen für die Software- und Applikationssteuerung in der Vorrichtung zu ermöglichen. SACMO-Spezifikationen werden Fähigkeiten des Ausführens von Verwaltungsaktivitäten, wie beispielsweise Arbeitsablauf, Verarbeitung und Verwaltung auf dem Gerät bzw. On-Device-Management der Software und Applikationen vorsehen, die die bestehenden Verwaltungsgegenstände bzw. Management-Objekte nutzen.
-
Das Ziel von SACMO ist es zu ermöglichen, dass DM-Betriebe gemäß den Arbeitsablaufskripten in der Vorrichtung angewendet werden, wodurch jegliche Kombinationen von Betrieben auf bestehenden Management-Objekten angewendet werden und bedingt ausgeführt werden können, wobei lediglich die kombinierten Ergebnisse zurück an den DM-Server berichtet werden. Dies verhindert eine Reihe von einzelnen Klient-Server-Interaktionen, wodurch der Netzwerkverkehr optimiert und die Abeitsablaufausführungszeit verringert wird.
-
Es sei auf 1 Bezug genommen, die ein schematisches Schaubild eines SACMO-Management-Objekt-Verzeichnisbaums in dem Stand der Technik ist. Der SACMO-Management-Objekt-Verzeichnisbaum wird verwendet um Parameter und die Betriebsfunktionalität einzustellen, die für das Verwalten eines Arbeitsablaufgegenstands notwendig ist. Ein Arbeitsablauf ist eine Sequenz von Schritten, die bedingt ausgeführt wird. Jeder Schritt kann ein Betrieb, Prozess, Befehl oder eine andere Art von Ressource sein. Zwischen den Schritten wird eine Bedingung verwendet, um den nächsten Schritt zu bestimmen. Ein Prozess ist eine Grundeinheit für eine spezifische Betriebsausführung. Ein Prozess besteht aus einem einheitlichen Ressourcenkennungs- bzw. URI-Pfad (URI = Uniform Resource Identifier), der den Knoten des Ziel-Management-Objekts anzeigt, der auszuführen ist. Der Prozess wird durch eine eindeutige Prozess-Kennung bzw. -ID angezeigt und diese kann in den Arbeitsabläufen wiederverwendet werden. Ein Schritt ist eine Grundeinheit eines Arbeitsablaufs, die aus einem Prozess und einer Information für den/die nächsten Schritt(e) besteht. Ein Schritt MUSS eine Prozess-ID besitzen, um anzuzeigen, dass ein entsprechender Prozess auszuführen ist. Wenn ein Schritt von einem anderen Schritt gefolgt wird, wird ein nächster Subverzeichnisbaum erzeugt. Der Subverzeichnisbaum des nächsten Schritts kann mehrere nächste Schritte enthalten. Jeder nächste Schritt besitzt eine ID des nächsten Schritts bzw. NextStepID, um den nachfolgenden Schritt und eine Bedingung für den nächsten Schritt, die angewendet werden soll (optional), anzuzeigen.
-
Im gegenwärtigen Aufbau des SACMO ist der Prozess ausgelegt, um einen Ausführungsbetrieb, Exec, auf einem Knoten eines Management-Objekts oder auf einem Knoten für eine Anwendung bzw. Applikation laufen zu lassen, d. h. einem Process/<X>/TargetApp/ExecAppURI, wobei die Zielapplikation bzw. TargetApp ein interner Knoten ist, der die Informationen gruppiert, die für das Ausführen der einen Applikation verwendet wird, und die ExecAppURI ist ein Blattknoten, der eine URI für eine Applikation, die ausgeführt werden soll, spezifiziert. Die SACMO-Spezifikation definiert jedoch nicht, wie ein Wert von einem Knoten des Management-Objekts zu erhalten ist, und dadurch ist es nur erlaubt, dass der Betrieb eines Knoten des Management-Objekts einen Exec-Betrieb ausführt, aber kann nicht verwendet werden, um einen Wert von einem Knoten zu erhalten. Es sei bemerkt, dass der Wert, der von dem Knoten erhalten wird, mit einem vorbestimmten Wert in einer „Bedingung” verglichen werden kann, die in 1 gezeigt ist. Darüber hinaus definiert die SACMO-Spezifikation nicht, wie ein Knoten in einem Management-Objekt, welches der Grundbetrieb des DM-Protokolls ist, hinzuzufügen oder zu löschen ist.
-
Zusammenfassung der Erfindung
-
Die Offenbarung sieht daher ein Verfahren zum Vorsehen eines Prozesbetriebs in einem Management-Objekt der Software- und Applikationssteuerung bzw. SACMO (SACMO = Software and Application Control Management Object) vor, um die oben erwähnten Probleme zu lösen.
-
Ein Verfahren zum Vorsehen eines Prozessbetriebs in einer Management-Objekt- bzw. MO-Spezifikation, die der Vorrichtungsverwaltung bzw. DM (DM = Device Management) der Open Mobile Alliance (OMA) für einen Klient entspricht, ist offenbart. Das Verfahren weist das Erzeugen eines ersten Knoten und eines zweiten Knoten in einem Prozess-Subverzeichnisbaum eines Management-Objekts auf, wobei der erste Knoten einen Betrieb für den zweiten Knoten anzeigt und der zweite Knoten einen Bestimmungsort anzeigt, auf dem der Betrieb ausgeführt wird.
-
Ein Verfahren zum Vorsehen eines Prozessbetriebs in einer Management-Objekt- bzw. MO-Spezifikation, die der Vorrichtungsverwaltung bzw. DM (DM = Device Management) der Open Mobile Alliance (OMA) für einen Klient entspricht, ist offenbart. Das Verfahren weist das Erzeugen eines Knoten in einem Prozess-Subverzeichnisbaum eines Management-Objekts auf, wobei der Knoten einen Betrieb und einen Bestimmungsort anzeigt, auf dem der Betrieb ausgeführt wird, wobei der Klient den Betrieb des Knotens auf dem Bestimmungsort des Knotens ausführt.
-
Diese und andere Ziele der vorliegenden Erfindung werden ohne Zweifel Fachleuten des Gebiets nach dem Lesen der nachfolgenden, detaillierten Beschreibung des bevorzugten Ausführungsbeispiels offensichtlich sein, das in den verschiedenen Figuren und Zeichnungen dargestellt ist.
-
Kurze Beschreibung der Zeichnungen
-
1 ist ein schematisches Schaubild eines SACMO-Management-Objekt-Verzeichnisbaums des Standes der Technik.
-
2 ist ein schematisches Schaubild eines beispielhaften Servicesystems.
-
3 ist ein schematisches Schaubild einer beispielhaften Kommunikationsvorrichtung.
-
4 ist ein Flussdiagramm eines beispielhaften Prozesses.
-
5 ist ein schematisches Schaubild eines SACMO-Management-Objekt-Verzeichnisbaums der vorliegenden Erfindung.
-
6 ist ein Flussdiagramm eines beispielhaften Prozesses.
-
Detaillierte Beschreibung
-
Es sei auf 2 Bezug genommen, die ein schematisches Schaubild eines Dienst- bzw. Servicesystems 20 gemäß einem Beispiel der vorliegenden Offenbarung ist. Das Servicesystem 20 entspricht einem DM-Protokoll (DM = Device Management) der Open Mobile Alliance (OMA) und besteht kurz gesagt aus einem Server und einem Klient. Der Server und der Klient entsprechen einer MO-Spezifikation (MO = Management Object), z. B. dem SACMO (SACMO = Software and Application Control Management Object). SACMO wurde vorgeschlagen, um zu ermöglichen, dass der DM-Betrieb gemäß Arbeitsablaufskripten in einer Vorrichtung angewendet wird, wodurch jegliche Kombinationen von Betrieben auf bestehenden Management-Objekten anwendet und bedingt ausgeführt werden können, wobei lediglich die Kombinationsergebnisse zurück an den Server berichtet werden. Es sei bemerkt, das Komponenten des SACMO Prozesse, Schritte, Arbeitsabläufe und Transaktionen umfassen, die Fachleuten des Gebiets gut bekannt sein sollte, so dass hierin keine detaillierte Beschreibung erfolgt.
-
Es sei auf 3 Bezug genommen, die ein schematisches Schaubild einer Kommunikationsvorrichtung 30 gemäß einem Beispiel der vorliegenden Offenbarung ist. Die Kommunikationsvorrichtung 30 kann der Server oder der Klient sein, die in 2 gezeigt sind, ist aber nicht hierauf beschränkt. Die Kommunikationsvorrichtung 30 kann einen Prozessor 300, wie beispielsweise einen Mikroprozessor oder eine anwendungsspezifische, integrierte Schaltung bzw. ASIC (ASIC = Application Specific Integrated Circuit), eine Speichereinheit 310 und eine Kommunikationsschnittstelleneinheit 320 umfassen. Die Speichereinheit 310 kann irgendeine Datenspeichervorrichtung sein, die einen Programmcode 314 speichern kann, auf den durch den Prozessor 300 zugegriffen werden kann. Beispiele der Speichereinheit 310 umfassen, sind aber nicht hierauf beschränkt, eine SIM-Karte (SIM = Subscriber Identity Module), einen ROM-Speicher (ROM = Read-Only Memory), einen Flash-Speicher, einen RAM-Speicher (RAM = Random-Access Memory), CD-ROM/DVD-ROM, Magnetbänder, Festplatten und optische Speichervorrichtungen. Die Kommunikationsschnittstelleneinheit 320 ist vorzugsweise ein Sendeempfänger bzw. Transceiver und kann Signale mit dem Server gemäß den Verarbeitungsergebnissen des Prozessors 300 austauschen.
-
Es sei auf 4 Bezug genommen, die ein Flussdiagramm eines Prozesses 40 gemäß einem Beispiel der vorliegenden Offenbarung ist. Der Prozess 40 wird verwendet, um einen Prozessbetrieb in einer MO-Spezifikation vorzusehen, z. B. SACMO für den Klient, der in 2 gezeigt ist. Der Prozess 40 kann in den Programmcode 314 kompiliert werden und umfasst die folgenden Schritte:
Schritt 400: Start.
Schritt 402: Erzeugen eines ersten Knotens und eines zweiten Knotens in einem Prozess-Subverzeichnisbaum eines Management-Objekts, wobei der erste Knoten einen Betrieb für den zweiten Knoten anzeigt, und der zweite Knoten einen Bestimmungsort anzeigt, auf dem der Betrieb ausgeführt wird.
Schritt 404: Ende.
-
Gemäß dem Prozess 40 werden zwei Knoten in dem Prozess-Subverzeichnisbaum eines Management-Objekts erzeugt. Der erste Knoten spezifiziert einen Betrieb für einen zweiten Knoten, und der zweite Knoten weist auf einen Bestimmungsort hin, auf dem der erste Knoten arbeitet. Daher führt der Klient den Betrieb des ersten Knoten auf dem Bestimmungsort des zweiten Knoten aus, während der Prozess ausgelöst wird. Basierend auf der gegenwärtigen Entwicklung aufgrund von OMA-Spezifikationen ist das Management-Objekt in dem Prozess 40 vorzugsweise ein Management-Objekt, das dem SACMO entspricht. Das Management-Objekt in dem Prozess 40 kann einer anderen Art von MO-Spezifikation entsprechen, die vorschlägt, dass ein DM-Betrieb ausgeführt wird, und ist nicht auf SACMO beschränkt. Es hängt davon ab, ob irgendeine andere MO-Spezifikation durch OMA in der Zukunft vorgeschlagen wird und ob der Prozess 40 basierend auf der neuen MO-Spezifikation ausgeführt werden kann.
-
Es sei bemerkt, dass der Betrieb des ersten Knoten ein DM-Befehl ist, der „Erhalten”, „Hinzugefügen”, „Ersetzen”, „Löschen”, „Ausführen” oder ein anderer Befehl sein kann, der in dem DM-Protokoll definiert ist. Oder der Betrieb des ersten Knoten ist ein vorbestimmter Befehl. Beispielsweise kann der vorbestimmte Befehl „Erhalten”, „Ausführen”, „Schreiben” etc. sein. Darüber hinaus ist der Bestimmungsort des zweiten Code eine einheitliche Ressourcenkennung bzw. URI (URI = Uniform Resource Identifier), wodurch die URI auf einen Knoten des Management-Objekts bzw. MO des Klienten oder einen Ort einer Applikation hinweist. Auf diese Weise wird die Funktion des Prozesses ausgedehnt, um es zu ermöglichen, dass mehrere DM-Befehle auf dem Knoten des MO ablaufen oder mehrere vordefinierte Befehle auf der Applikation ablaufen.
-
Im Detail sei auf 5 Bezug genommen, die ein SACMO-Management-Objekt-Verzeichnisbaum der vorliegenden Erfindung ist. Wie gesehen werden kann, werden die Blatt-Knoten „Befehl” (d. h. Process/<X>/MOOperation/Command) und „URI” (d. h. Process/<X>/MOOperation/URI) unter einem inneren Knoten „MOOperation” (d. h. Process/<X>/MOOperation) in dem Prozess-Subverzeichnisbaum eines Management-Objekts hinzugefügt, der dem SACMO entspricht. Der „Befehl” ist ein DM-Befehl (z. B. ein Erhalten-, Hinzufügen-, Ersetzen-, Löschen- oder Ausführen-Befehl) oder ein vorbestimmter Befehl. Die „URI” spezifiziert eine Adresse, wie beispielsweise einen Knoten eines MO des Klienten, oder einen Bestimmungsort einer Applikation. Auf diese Art und Weise kann ein Wert von einem Knoten des SACMO zum Vergleich mit einem Wert in der „Bedingung” erhalten werden. Beispielsweise ist ein „Befehl”-Knoten ein Erhalten-Knoten, und der „URI”-Knoten weist auf einen Knoten des MO des Klienten, wobei der Knoten einen Wert speichert. Der Klient führt einen Erhalten-Betrieb aus, um den Wert des Knoten zu erhalten. Andererseits, wenn der „Befehl”-Knoten ein Ausführen-Befehl ist und der „URI”-Knoten auf einen Bestimmungsort einer Applikation weist, führt der Klient den Ausführen-Betrieb aus, um die Applikation auszuführen.
-
Es sei auf 6 Bezug genommen, die ein Flussdiagramm eines Prozesses 60 gemäß einem Beispiel der vorliegenden Offenbarung ist. Der Prozess 60 wird verwendet, um einen Prozessbetrieb in einer MO-Spezifikation für den Klienten auszuführen, der in 2 gezeigt ist. Der Prozess 60 kann in den Programmcode 314 kompiliert werden und umfasst die folgenden Schritte:
Schritt 600: Start.
Schritt 602: Erzeugen eines Knoten in einem Prozess-Subverzeichnisbaum eines Management-Objekts, wobei der Knoten eine Betrieb anzeigt und einen Bestimmungsort, auf dem der Betrieb ausgeführt wird, wodurch der Klient den Betrieb auf dem Bestimmungsort ausführt.
Schritt 604: Ende.
-
Gemäß dem Prozess 60 werden ein Betrieb und ein Bestimmungsort in einen Knoten eines Prozess-Subverzeichnisbaums eines Management-Objekts eingegeben. Daher führt der Klient den Betrieb auf dem Bestimmungsort aus, während der Prozess ausgelöst wird. Basierend auf der gegenwärtigen Entwicklung aufgrund der OMA-Spezifikationen ist das Management-Objekt in dem Prozess 60 vorzugsweise ein Management-Objekt, das dem SACMO entspricht. Das Management-Objekt in dem Prozess 60 kann einer anderen Art von MO-Spezifikation entsprechen, die vorgeschlagen wurde, um zu ermöglichen, dass ein DM-Betrieb angewendet wird, der nicht auf SACMO beschränkt ist. Es hängt davon ab, ob irgendeine andere MO-Spezifikation durch OMA in der Zukunft vorgeschlagen wird und ob der Prozess 60 basierend auf der neuen MO-Spezifikation ausgeführt werden kann.
-
Es sei bemerkt, dass der Betrieb des Knotens ein DM-Befehl ist, der einen „Erhalten”, „Hinzufügen”, „Ersetzen”, „Löschen”, „Ausführen” oder ein anderer Befehl sein kann, der in dem DM-Protokoll definiert ist. Oder der Betrieb des Knotens ist ein vorbestimmter Befehl. Beispielsweise kann der vorbestimmte Befehl „Erhalten”, „Ausführen”, „Schreiben” etc. sein. Darüber hinaus ist der Bestimmungsort des Codes eine einheitliche Ressourcenkennung bzw. URI (URI = Uniform Resource Identifier), durch welche die URI zu einem Knoten eines MO oder einem Bestimmungsort einer Applikation weist. Auf diese Weise wird die Funktion des Prozesses in der SACMO erweitert, um es zu ermöglichen, dass mehrere DM-Befehle auf dem Knoten des MO oder vordefinierte Befehle auf der Applikation ablaufen.
-
Anders als bei Prozess 40 wird nur ein Knoten in den Prozess-Subverzeichnisbaum des Management-Objekts hinzugefügt, der einen Befehl und einen Bestimmungsort, der ein Knoten in einem MO des Klienten oder ein Ort einer Applikation ist, spezifiziert. Die detaillierte Beschreibung für den Befehl kann aus dem obigen entnommen werden und wird daher hierin weggelassen.
-
Es sei bemerkt, dass die oben erwähnten Schritt des Prozesses vorgeschlagene Schritte umfassen, die durch Mittel realisiert werden könnten, die eine Hardware, eine Firmware, die als eine Kombination von einer Hardwarevorrichtung und von Computeranweisungen und Daten bekannt ist, die sich als schreibgeschützte Software auf der Hardware-Vorrichtung befinden, oder ein elektronisches System realisiert werden könnte. Beispiele der Hardware können analoge, digitale und gemischte Schaltungen, die als Mikroschaltung, Mikrochip oder Siliziumchip bekannt sind. Beispiele des elektronischen Systems können ein System-on-Chip bzw. SOC, ein System-in-Package bzw. SiP, einen Computer-on-Module bzw. COM und die Kommunikationsvorrichtung 30 umfassen.
-
Zusammenfassend wird die Funktion des Prozesses des SACMO durch Erzeugen von/eines Knoten in dem Prozess-Subverzeichnisbaum eines Verwaltungsgegenstands bzw. Management-Objekts verbessert, um mehr Betriebe auszuführen (z. B. Erhalten eines Werts von einem Knoten eines MO).
-
Fachleute werden in einfacher Weise erkennen, dass zahlreiche Modifikationen und Veränderungen der Vorrichtung und des Verfahrens vorgenommen werden können, während die Lehren der Erfindung beibehalten werden. Demgemäß sollte die obige Beschreibung so ausgelegt werden, dass sie lediglich durch den Rahmen und Umfang der beigefügten Ansprüche begrenzt wird.
