DE60126421T2

DE60126421T2 - Verfahren und terminal zum sicheren bezug von programmen

Info

Publication number: DE60126421T2
Application number: DE60126421T
Authority: DE
Inventors: Kazuhiro Yokohama YAMADA; Masaaki Yokohama Yamamoto; Yoshiaki Yokosuka HIRAMATSU; Kyoko Shibuya INOUE; Dai Ichikawa KAMIYA; Eriko Chiyoda OOSEKI; Motoki Yokosuka TOKUDA; Tatsuro Yokohama OOI; Yutaka Minato SUMI
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2000-11-24
Filing date: 2001-11-21
Publication date: 2007-10-25
Anticipated expiration: 2021-11-22
Also published as: WO2002042918A1; BR0107377A; US7174333B2; AU2406202A; EP1338971A1; JP2002163111A; KR20020079798A; CN1198432C; PL356885A1; JP3692290B2; NO324486B1; ES2280433T3; AU2002224062B2; EP1338971B1; US20030097373A1; HK1056024A1; EP1338971A4; NZ519408A; CA2394294C; DE60126421D1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft ein Verfahren zum Erhalten von Anwendungen über ein Netzwerk, und ein Endgerät zum Erhalten von Anwendungen mittels dieses Verfahrens.
Stand der Technik
Aufgrund der jüngsten Entwicklung von Kommunikationsnetzwerken findet das Erhalten von Daten über Netzwerke, so wie dem Internet, (Herunterladen) eine weite Verwendung. Die über Netzwerke, so wie das Internet, erhaltenen Daten werden üblicherweise in einem Festspeicher, so wie einer Festplatte, gespeichert. Auf die im Festspeicher gespeicherten Daten kann erneut durch Auslesen der Daten aus dem Festspeicher zugegriffen werden, in dem Daten gespeichert sind, selbst nachdem eine CPU (Central Processing Unit bzw. Zentralverarbeitungseinheit) und ein RAM (Random Access Memory bzw. Direktzugriffsspeicher) durch erneutes Starten des Endgerätes durch einmaliges Abschalten der Leistung des Endgerätes und dann erneutes Anschalten davon initialisiert sind.
Wenn Daten über Netzwerke, so wie das Internet, erhalten sind, können die erhaltenen Daten außerdem sogar in einem temporären Speicher gespeichert werden, so wie einem RAM. Ein Beispiel der Daten dieser Art ist ein Java-Applet. Ein Java-Applet ist ein Programm, das durch Nutzen von Java (Java-Anwendung) produziert ist. Ein Java-Applet wird über Netzwerke, so wie das Internet, erhalten und im temporären Speicher des Endgerätes gespeichert. Ein in dem Endgerät erhaltenes Java-Applet wird über den Browser zum Ansehen von in HTML (Hyper Text Markup Language) geschriebenen Web-Seiten und über eine Java Virtual Machine verwendet. Wie oben beschrieben, wenn das Endgerät erneut gestartet wird, wird der temporäre Speicher des RAM initialisiert, und die in dem temporären Speicher gespeicherten Daten werden eliminiert. Wenn über Netzwerke, so wie das Internet, erhaltene Daten im temporären Speicher gespeichert sind, können sie nicht erneut verwendet werden, es sei denn die Daten werden erneut über Netzwerke, so wie das Internet, erhalten, nachdem das Endgerät erneut gestartet wird.
Es gibt eine Anzahl von Java-Anwendungen, die, anders als ein Java-Applet, im Festspeicher gespeichert werden, nachdem sie von Netzwerken, so wie dem Internet, erhalten werden, und die nicht erneut von Netzwerken, so wie dem Internet, erhalten werden müssen, selbst nachdem das Endgerät erneut gestartet wird. Es gibt außerdem Java-Anwendungen, die im Festspeicher des Endgerätes gespeichert werden, und die nicht von einem Netzwerk erhalten werden müssen. Für den Zweck der Beschreibung der vorliegenden Erfindung wird eine „Java-Anwendung" jedoch auf eine Java-Anwendung verweisen, die von einem Netzwerk erhalten ist, da das Erhalten von Daten von einem Netzwerk die Voraussetzung ist.
Es sollte beachtet werden, dass, egal ob die von Netzwerken, so wie dem Internet, erhaltenen Daten im Festspeicher oder im temporären Speicher gespeichert werden, sie üblicherweise von einem Netzwerk, so wie dem Internet, als eine Datei empfangen werden. Wenn zum Beispiel eine aus einer einzelnen Datei bestehende Java-Anwendung von einem Web-Server durch HTTP (Hyper Text Transfer Protocol) erhalten wird, findet es in einer Aufeinanderfolge statt, mit anderen Worten mit Verbinden mit dem Web-Server, Anfordern einer Information, Empfangen der Antwort und Trennen von dem Web-Server. In diesem Fall, da der Benutzer eine Java-Anwendung durch Bedienen des Endgerätes anfordert, startet das Herunterladen unmittelbar und die Verbindung zwischen dem Web-Server und dem Endgerät bleibt aufrecht erhalten, bis der Download vollständig ist. Eine Nachricht wird in dem Endgerät angezeigt, die angibt, dass eine Datei heruntergeladen wird.
In diesem Verfahren zum Erhalten von Daten kann der Endgerätbenutzer nicht eine Eigenschaftsinformation, so wie die Dateigröße der Java-Anwendung, vor dem Beginnen des Herunterladens davon kennen; und somit kann der Endgerätbenutzer nicht die zum Herunterladen der Java-Anwendung erforderliche Zeitmenge vorhersagen. Deshalb gibt es ein Problem, dass, wenn eine Java-Anwendung aus einer Vielzahl von Dateien besteht, eine Verwendung des Endgerätes aufgrund einer länger als erwarteten Herunterladezeit eingeschränkt sein kann. Dies ist extrem gravierend, besonders für Endgeräte, so wie Zellulartelefone, in denen ein Browser installiert ist, der eine beschränkte Kommunikationsreichweite oder Prozessfähigkeit hat. Eine erforderliche Eigenschaftsinformation, so wie der Dateiname der Java-Anwendung und die Dateigröße, kann selbstverständlich auf der Web-Seite in dem Endgerät des Benutzers angezeigt werden, aber es gibt Bedenken, dass eine inkorrekte Eigenschaftsinformation dem Benutzer aufgrund fehlerhafter Beschreibungen oder eines betrügerischen Inhaltes gemeldet werden könnte.
Zum Vermeiden der oben erwähnten Probleme wird ein Aufteilen einer Java-Anwendung in zwei Dateien, eine ADF (Application Descriptor File bzw. Anwendungsdeskriptordatei), die eine Eigenschaftsinformation enthält, und ein JAR (Java Archive bzw. Java-Archiv), das das Grundelement bzw. die Entität der Daten enthält, und ein Empfangen dieser in Aufeinanderfolge bei dem Endgerät vorgeschlagen. JAR ist ein Dateityp, in dem eine oder eine Vielzahl von Dateien in Einer organisiert sind. JAR ist fähig zum Herunterladen einer Vielzahl von Dateien in einer Operation, wodurch die zum Herunterladen jeder Datei in einer separaten Operation erforderliche Zeit gespart wird. Wenn eine Datei in zwei Dateien, ADF und JAR, aufgeteilt ist, wird das Problem des Sicherstellens der Sicherheit überhaupt nicht berücksichtigt.
Von Jörg Heuer et al.: „Adaptive Multimedia Messaging based on MPEG-7-The M3-Box", Proceedings 2nd INT'L Symposium on Mobile Multimedia Systems and Applications, 10. November 2000, XP002001575 Delft, Niederlande, ist ein Datenerhaltungsverfahren zum Erhalten von Mediendaten von einer Multimedianachrichtenzentrale bekannt, mit einem ersten Empfangsschritt in einem Endgerät, das eine Kommunikation über ein Netzwerk zum Empfangen über das Netzwerk einer ersten Dateneinheit kann, in der eine Beschreibung von Medien, die auf dem Endgerät, d.h. der Ausgabevorrichtung, angezeigt werden können, gespeichert ist.
In Czerwinski Steven et al.: „An Architecture for a Secure Service Discovery Service", Proceedings of the 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking, 15. August 1999, XP000896069, New York, USA, wird ein sicherer Service Discovery Service (SDS) beschrieben, der einen zweiteiligen Mechanismus verwendet, in dem Client-Abfragen und eine Dienstbeschreibung zwischen dem Provider und dem Client mit Verwenden von XML in dem ersten Schritt gesendet werden. Zum Vermeiden einer betrügerischen Verwendung wird die gesamte zwischen dem Client und dem Server gesendete Information verschlüsselt und zusätzlich wird eine starke Authentifizierung von Endpunkten verwendet.
Gemäß diesen Beschreibungen wird eine Inhaltdarstellung des geprüften Accounts erzeugt und an den Empfänger übertragen, der die Ausgabevorrichtung zum Browsen durch die Darstellung verwenden kann.
Offenbarung der Erfindung
Die Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zum Erhalten einer Anwendung und ein Endgerät bereitzustellen, das eine ausreichend hohe Sicherheit sicherstellen kann.
Diese Aufgabe wird gemäß der vorliegenden Erfindung durch ein Verfahren zum Erhalten einer Anwendung wie in Anspruch 1 definiert gelöst. Vorteilhafte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen gegeben.
Gemäß diesem Verfahren zum Erhalten einer Anwendung wird bestimmt, ob die zweite Dateneinheit empfangen werden kann, durch Vergleich des Kommunikationsmodus, der verwendet wurde, wenn die erste Dateneinheit empfangen wurde, mit dem Kommunikationsmodus, der zum Empfangen der zweiten Dateneinheit verwendet wird. Das heißt, dass eine Datenakquisition verboten werden kann, wenn der Kommunikationsmodus unpassend von der Zeit, wenn die erste Dateneinheit empfangen wird, zu der Zeit umgeschaltet wird, wenn die zweite Dateneinheit empfangen wird. Es kann, mit anderen Worten, eine ausreichend hohe Sicherheit sichergestellt werden, wenn geteilte Daten erhalten werden.
Außerdem stellt die vorliegende Erfindung ein Verfahren zum Erhalten einer Anwendung bereit, worin eine Akquisition der Daten nicht ermöglicht wird, wenn eine Sicherheit eines Kommunikationsmodus, der zum Empfangen der zweiten Dateneinheit verwendet wird, niedriger als eine Sicherheit eines Kommunikationsmodus ist, der in dem ersten Empfangsschritt in dem Bestimmungsschritt verwendet wurde.
Außerdem stellt die vorliegende Erfindung ein Verfahren zum Erhalten einer Anwendung bereit, worin ein Kommunikationsmodus zum Empfangen der Dateneinheit ein eine Verschlüsselungskommunikation verwendender Modus ist, und eine Datenakquisition nicht ermöglicht wird, wenn ein Kommunikationsmodus zum Empfangen der zweiten Dateneinheit ein Modus ist, der in dem Bestimmungsschritt nicht eine Verschlüsselung verwendet.
Außerdem stellt die vorliegende Erfindung ein Verfahren zum Erhalten einer Anwendung bereit, worin eine Datenakquisition nicht ermöglicht wird, wenn ein Kommunikationsmodus, der in dem ersten Empfangsschritt verwendet wurde, und ein zum Empfangen der zweiten Dateneinheit verwendeter Kommunikationsmodus in dem Bestimmungsschritt nicht übereinstimmen.
Außerdem stellt die vorliegende Erfindung ein Verfahren zum Erhalten einer Anwendung bereit, worin die Daten ein Computerprogramm sind, das bei dem Endgerät ausgeführt werden kann.
Außerdem stellt die vorliegende Erfindung, in irgendeinem der oben beschriebenen Verfahren, ein Verfahren zum Erhalten einer Anwendung bereit, worin das Computerprogramm ein Computerprogramm ist, das eine Kommunikation durchführt.
Außerdem stellt die vorliegende Erfindung, in irgendeinem der oben beschriebenen Verfahren, ein Verfahren zum Erhalten einer Anwendung bereit, worin das Endgerät ein Zellulartelefon ist.
Die Aufgabe der vorliegenden Erfindung wird ferner durch ein wie in Anspruch 7 definiertes Endgerät gelöst.
Kurze Beschreibung der Zeichnungen
1 ist ein Diagramm, das den Grundprozess zum Erhalten einer Java-Anwendung in dem Endgerät in der Ausführungsform der vorliegenden Erfindung zeigt.
2 ist ein Diagramm, das die Kommunikationsmuster dieses Endgeräts zeigt.
3 ist ein Diagramm, das die angezeigten Nachrichten in diesem Endgerät zeigt.
4 ist ein Blockdiagramm, das die Konfiguration des das Endgerät verwendenden Datenzustellungssystems zeigt.
5 ist ein Blockdiagramm, das die Konfiguration der Schlüsseleinheiten dieses Endgerätes zeigt.
6 ist ein Konzeptdiagramm, das die Konfiguration von Prozesstabellen PT1 und PT2 innerhalb dieses Endgerätes zeigt.
7 ist ein Flussdiagramm, das den von diesem Endgerät während der Akquisition einer Java-Anwendung durchgeführten Prozess zeigt.
Bester Modus zum Ausführen der Erfindung
Hier werden im Nachfolgenden die bevorzugten Ausführungsformen der vorliegenden Erfindung mit Verweis auf die Diagramme erläutert werden. Die vorliegende Erfindung ist nicht auf die folgenden Ausführungsformen beschränkt und vielfältige Änderungen sind möglich, ohne von dem Bereich der Erfindung, wie durch die angefügten Ansprüche offenbart, abzuweichen.
[Grundsätzliche Idee]
Zuerst wird die grundsätzliche Idee des Datenerhaltungsverfahrens der vorliegenden Erfindung erläutert werden.
1 zeigt den Grundprozess, wenn das Endgerät in der vorliegenden Ausführungsform eine Java-Anwendung erhält. Wie in 1 gezeigt, wird, während der Akquisition und der Ausführung einer Java-Anwendung, der Prozess in dem Endgerät in der Reihenfolgen A, B, C, D durchgeführt. Das Endgerät sendet, mit anderen Worten, zuerst eine Akquisitionsanforderung an das Netzwerk für die Seite aus, um eine Java-Anwendung zu erhalten, und greift auf die relevante Seite zu (Schritt A). Bei diesem Zustand gibt der Endgerätbenutzer dann einen Auftrag zum Erhalten der in dieser Seite beschriebenen Java-Anwendung durch Bedienen des Endgerätes ein, das Endgerät sendet die Akquisitionsanforderung in Ansprechen auf diesen Auftrag aus, erhält eine ADF der relevanten Java-Anwendung und speichert sie im Festspeicher (Schritt B). Dann sendet das Endgerät an das Netzwerk die Akquisitionsanforderung für das JAR aus, das dieser ADF entspricht, erhält das relevante JAR und speichert es im Festspeicher (Schritt C). Dann, wenn der Endgerätbenutzer die Ausführung der erhaltenen Java-Anwendung (das im JAR enthaltene Programm) durch Bedienen des Endgerätes beauftragt, wird die relevante Java-Anwendung bei dem Endgerät ausgeführt (Schritt D).
Der Grundprozess ist genau wie oben beschrieben, aber die Bedingungen ändern sich gemäß dem zum Erreichen jedes Schrittes verwendeten Kommunikationsmodus. Zum Beispiel ist eine Operation, in der derselbe Kommunikationsmodus in Schritten A bis C verwendet wird, unterschiedlich von einer Operation, in der ein gewöhnlicher Kommunikationsmodus, in dem es keine Verschlüsselung gibt, im Schritt A verwendet wird, aber danach eine Kommunikation durch SSL (Secure Sockets Layer), was das Protokoll zum Senden und Empfangen einer Information durch Verschlüsseln ist, bis Schritt C verwendet wird. Die Operation des Endgerätes, was solchen Bedingungen entspricht, ist wie folgt.
2 ist ein Diagramm, das die Kommunikationsmuster des Endgerätes der vorliegenden Erfindung zeigt, und, wie in diesem Diagramm gezeigt, sind die Kommunikationsmuster P1 bis P8 mögliche Kommunikationsmuster des Endgerätes. Die Kommunikationsmuster P1 bis P8 sind sämtliche der möglichen Variationen der Ordnung jedes Kommunikationsmodus (gewöhnlich/SSL) der Schritte A bis C.
3 ist ein Diagramm, das die angezeigten Nachrichten in dem Endgerät der vorliegenden Ausführungsform zeigt. In diesem Diagramm sind die angezeigte Nachricht von der Zeit, wenn ein Umschalten vom Schritt A zum Schritt B beginnt, und die angezeigte Nachricht von der Zeit, wenn ein Umschalten vom Schritt B zum Schritt C beginnt, die Kommunikationsmustern P1 bis P8 entsprechen, angegeben, und die Operation des Endgerätes kann von diesen angezeigten Nachrichten identifiziert werden. Außerdem sind in diesem Diagramm die beim Umschalten vom Schritt A zum Schritt B verwendeten Verbindungsmodi und die beim Umschalten vom Schritt B zum Schritt C verwendeten Verbindungsmodi jedem Kommunikationsmuster zugeordnet, und die angezeigten Nachrichten sind den Kommunikationsmustern und jedem Verbindungsmodus zugeordnet. Jedoch sind in manchen Fällen die angezeigten Nachrichten bestimmt, ohne sich auf die Verbindungsmodi zu stützen, und „–" ist in der Spalte solch eines Verbindungsmodus angegeben. Die Typen der Verbindungsmodi sind ein Lebendighaltemodus, in dem eine Vielzahl von Daten durch Aufrechterhalten der Verbindung weitergeleitet werden, und ein Nicht-Lebendighaltemodus, in dem die Verbindung aufgehoben wird, immer wenn ein Datenaustausch terminiert. Der Nicht-Lebendighaltemodus ist der gewöhnliche Datenaustauschmodus von HTTP, und der Lebendighaltemodus ist der gewöhnliche Datenaustauschmodus von HTTPS (Hyper Text Transfer Protocol Security), das SSL entspricht.
In der vorliegenden Ausführungsform werden die in Diagramm 3 gezeigten Operationen erreicht. Diese Operationen werden später im Detail beschrieben werden. Ein Beispiel einer Operation wird nun für den Zweck zum Erläutern des Diagramms erläutert werden. Gemäß Kommunikationsmuster P6 (das Kommunikationsmuster, in dem sämtliche Kommunikationsmodi von Schritt A bis C SSL sind), während eines Umschaltens vom Schritt A zum Schritt B, wenn der Kommunikationsmodus der Nicht-Lebendighaltemodus ist, ist zum Beispiel die angezeigte Nachricht bei dem Beginnen des Umschaltens vom Schritt A zum Schritt B „SSL-Kommunikation beginnt". Während des Umschaltens vom Schritt B zum Schritt C, wenn der Verbindungsmodus Lebendighalten ist, gibt es außerdem keine Anzeige bei dem Beginnen.
Die auffälligste Stelle in diesem Diagramm ist, dass in Kommunikationsmustern P3 und P4 ein Umschalten vom Schritt B zum Schritt C nicht ermöglicht ist. Wie in 2 gezeigt, ist in Kommunikationsmustern P3 und P4 der Kommunikationsmodus im Schritt B SSL, und der Kommunikationsmodus im Schritt C ist gewöhnlich. In der vorliegenden Ausführungsform wird, mit anderen Worten, das Akquisitionsmuster zum Erhalten einer ADF durch eine Kommunikation mit Verwenden des Verschlüsselungskommunikationsmodus, und nachfolgenden Erhalten des JAR durch eine Kommunikation mit Verwenden des gewöhnlichen Kommunikationsmodus nicht ermöglicht. Der Grund für dieses wird nachher erläutert werden.
Wenn eine von dem Netzwerk erhaltene Java-Anwendung ausgeführt wird und die ausgeführte Java-Anwendung eine Kommunikation über ein Netzwerk durchführt, ist der Modus, der verwendet wird, wenn diese Java-Anwendung eine Kommunikation über ein Netzwerk durchführt, üblicherweise der Kommunikationsmodus, der verwendet wurde, wenn das Endgerät die Java-Anwendung erhielt. Wenn zum Beispiel eine durch eine SSL-Kommunikation erhaltene Java-Anwendung ausgeführt wird und diese Java-Anwendung eine Kommunikation über ein Netzwerk durchführt, wird dieser Kommunikationsmodus auf SSL beschränkt sein. Deshalb kann, bei der Endgerätseite, solange wie der Kommunikationsmodus SSL war, wenn die Java-Anwendung erhalten wurde, bestimmt werden, dass eine persönliche Information über den Endgerätbenutzer nicht in der klaren Sprache übertragen werden wird, selbst wenn diese Java-Anwendung eine persönliche Information über den Endgerätbenutzer mit Verwenden des Netzwerks danach überträgt.
Es sollte beachtet werden, dass, wie in der vorliegenden Ausführungsform, wenn eine Java-Anwendung von einem Netzwerk mit Verwenden von ADF und JAR erhalten ist, diese Java-Anwendung eine Kommunikation in demselben Kommunikationsmodus durchführt, wie wenn JAR erhalten wurde. Mit anderen Worten, wie in Kommunikationsmustern P3 und P4 gesehen werden kann, wenn der Kommunikationsmodus während der Akquisition von ADF SSL ist und der Kommunikationsmodus während der Akquisition von JAR gewöhnlich ist, wird die in diesem JAR enthaltene Java-Anwendung eine Kommunikation in dem gewöhnlichen Kommunikationsmodus durchführen, wenn sie eine Kommunikation mit Verwenden eines Netzwerks durchführt.
Jedoch tendiert ein Benutzer dazu, anzunehmen, dass ein Kommunikationsmodus zum Erhalten von JAR SSL ist, wenn der Kommunikationsmodus zum Erhalten der ADF SSL ist. Wenn ein Unterschied zwischen dem Kommunikationsmodus zum Erhalten der ADF und dem Kommunikationsmodus zum Erhalten des JAR ermöglicht bzw. erlaubt wird, gibt es das Risiko, dass eine persönliche Information über den Endgerätbenutzer in der klaren Sprache übertragen wird, entgegengesetzt zu dem Willen des Benutzers. Sobald eine persönliche Information in der klaren Sprache übertragen wird, entgegengesetzt zu dem Willen des Endgerätbenutzers, gibt es außerdem das Risiko, dass eine dritte Person mit einer betrügerischen Absicht usw. sich heimlich einen Zugriff auf eine persönliche Information über den Endgerätbenutzer verschafft. Zum Vermeiden solcher Probleme wird ein Umschalten vom Schritt B zum Schritt C in Kommunikationsmustern P3 und P4, wie in 3 gezeigt, nicht ermöglicht bzw. erlaubt. In 2 sind der Kommunikationsmodus des Schrittes B und der Kommunikationsmodus des Schrittes C sogar in Kommunikationsmustern P1 und P2 unterschiedlich, aber diese Kommunikationsmuster sind in der vorliegenden Ausführungsform ermöglicht bzw. erlaubt, da die durch eine bei dem Endgerät ausgeführte Java-Anwendung übertragenen Daten um einiges sicherer sind, als es ein Benutzer wahrscheinlicherweise fordert.
[Konfiguration]
Als nächstes wird das Datenzustellungssystem durch Verwenden des Endgerätes T in der vorliegenden Ausführungsform erläutert werden.
4 ist ein Blockdiagramm, das die Konfiguration des Datenzustellungssystems durch Verwenden des Endgerätes T zeigt, und, wie in diesem Diagramm gezeigt, ist dieses Datenzustellungssystem das System, das dem Endgerät T ermöglicht bzw. erlaubt, das WWW (World Wide Web) zu nutzen.
In diesem Diagramm ist Endgerät T ein Endgerät, in diesem Fall ein Zellulartelefon, zum Empfangen des Paketkommunikationsdienstes eines Mobilpaket-Kommunikationsnetzwerks MPN, das mit dem Mobilpaket-Kommunikationsnetzwerk MPN und dem Mobiltelefonnetzwerk (nicht gezeigt) fern zu verbinden ist. Das Mobiltelefonnetzwerk ist das Netzwerk zum Bereitstellen eines Anrufdienstes für Standardmobiltelefone, und Endgerät T kann diesen Anrufdienst empfangen. Die detaillierten Funktionen und Konfigurationen des Endgerätes T werden später beschrieben werden.
Mobilpaket-Kommunikationsnetzwerk MPN besteht aus einer Vielzahl von Basisstationen BS, einer Vielzahl von Paketteilnehmer-Verarbeitungsvorrichtungen PS, einem Gateway-Server GWS und Kommunikationsleitungen zum Verbinden dieser.
Basisstationen BS sind zum Beispiel bei konstanten Intervallen platziert und jede Basisstation deckt ein Gebiet mit einem Radius von 500 Metern ab und führt eine Funkkommunikation mit Endgerät T innerhalb ihrer Funkzone durch.
Paketteilnehmer-Verarbeitungsvorrichtung PS ist das Computersystem, das in der Paketteilnehmer-Vermittlungsstation zum Bedienen einer Vielzahl von Basisstationen BS installiert ist, und sie empfängt Paketaustauschanforderungen vom Endgerät T und überträgt die empfangenen Pakete an das adressierte Endgerät T über andere Paketteilnehmer-Verarbeitungsvorrichtungen PS und Basisstationen BS weiter.
Gateway-Server GWS ist das Computersystem, das in der Mobilpaket-Gateway-Weiterübertragungs-Vermittlungsstellenstation zum gegenseitigen Verbinden von unterschiedlichen Netzwerken, so wie Mobilpaket-Kommunikationsnetzwerk MPN und Internet INET installiert ist, und das Austauschungen von Kommunikationsprotokollen, die unterschiedlich sind, zwischen den Netzwerken durchführt. Die Austauschungen bzw. Vermittlungen von Kommunikationsprotokollen in diesem Fall sind im Speziellen gegenseitige Austauschungen von Übertragungsprotokollen für das Mobilpaket-Kommunikationsnetzwerk, dem Mobilpaket-Kommunikationsnetzwerk MPN entspricht, und dem Übertragungsprotokoll-Internet INET entspricht.
Das Übertragungsprotokoll, dem Internet INET entspricht, enthält TCP-IP (Transmission Control Protocol/Internet Protocol) der Netzwerkschicht und der Transportschicht, was das OSI Reference Model ist, und das Protokoll von HTTP, HTTPS usw., die auf diesem TCP/IP erreicht werden. Das Protokoll, das Mobilpaket-Kommunikationsnetzwerk MPN entspricht, enthält das Protokoll, in dem TCP/IP vereinfacht ist (hier im Nachfolgenden als TL bezeichnet), und das Protokoll, das äquivalent zu HTTP und HTTPS ist (hier im Nachfolgenden als AL bezeichnet). Endgerät T verwendet, mit anderen Worten, WWW auf AL.
Außerdem empfängt Gateway-Server GWS eine HTTP- (oder HTTPS-) Nachricht, die ein GET-Verfahren verwendet, vom Endgerät T, er prüft sie auf einen URL (Uniform Resource Locator), der in HTTP (oder HTTPS) enthalten ist, was dieses GET-Verfahren verwendet. Wenn dieser URL der allgemeine URL auf Internet INET ist, wird die HTTP- (oder HTTPS) Nachricht, die dieses GET-Verfahren verwendet, an Internet INET weitergeleitet, und die vom Internet INET übertragene Antwort, die der HTTP- (oder HTTPS) Nachricht entspricht, die dieses GET-Verfahren verwendet, wird an dieses Endgerät T zurückgesendet. Wenn der URL, der in HTTP (oder HTTPS) enthalten ist, was das GET-Verfahren verwendet, einer ist, der den Ressourcenort von sich selbst angibt, sendet der Gateway-Server GWS diese Ressource, die mit der HTTP- (oder HTTPS) Nachricht korreliert ist, die dieses GET-Verfahren verwendet, zurück an das Endgerät T.
IP-Server W ist der Server, der mit Internet INET verbunden ist, und stellt vielfältige Dienste für Clients bereit, die das WWW verwenden. Wenn IP-Server W eine Anforderung für eine HTTP- (oder HTTPS-) Nachricht empfängt, die das GET-Verfahren verwendet, über Internet INET, sendet er, genauer genommen, die Ressource (die Datei in Bearbeitung in der vorliegenden Ausführungsform) zurück, die durch den URL identifiziert ist, der in der HTTP- (oder HTTPS-) Nachricht enthalten ist, die dieses GET-Verfahren verwendet. In der vorliegenden Ausführungsform ist der Zweck des IP-Servers W ein Übertragen einer Java-Anwendung, und jede Kommunikation zwischen IP-Server W und Endgerät T wird durch HTTP (und HTTPS) und AL durchgeführt. Außerdem unterstützen sowohl der IP-Server W als auch Endgerät T den Datenaustauschmodus von Lebendighalten/Nicht-Lebendighalten von HTTP (und HTTPS) und SSL von HTTPS.
Als nächstes wird die Konfiguration von Endgerät T erläutert werden. In diesem Abschnitt wird jedoch die Konfiguration von Schlüsseleinheiten, die direkten Bezug zu der vorliegenden Erfindung haben, erläutert werden.
5 ist ein Blockdiagramm, das die Konfiguration von Schlüsseleinheiten des Endgerätes T zeigt, und, wie in diesem Diagramm gezeigt, hat Endgerät T eine eingebaute Sende-Empfangseinheit 11 (zum Beispiel mit einer Antenne, einer Funkeinheit, einem Sender, einem Empfänger usw. ausgerüstet) zum Durchführen einer Funkkommunikation mit Basisstation BS, eine Geräuschproduziereinheit 12 (zum Beispiel bestehend aus einer Geräuschquelle, einem Lautsprecher usw.) zum Produzieren eines Geräusches, eine Eingabeeinheit 13, die mit Tastaturblöcken ausgerüstet ist, durch welche Eingabeoperationen, so wie eine Zahleneingabe und eine Buchstabeneingabe, durchgeführt werden, eine Flüssigkristallanzeige 14, die die Anzeigedomäne einer spezifischen Größe enthält, und eine Steuereinheit 15, die jede dieser Einheiten steuert.
Steuereinheit 15 hat eine eingebaute CPU 151, die jede Steueroperation durchführt, den Browser, der durch CPU 151 ausgeführt wird, die Software zum Ausführen der Java Virtual Machine, solche Software wie das Steuerprogramm für Endgerät T, eine zum Verbinden mit Gateway-Server GWS erforderliche Information, Prozesstabelle PT1, die später beschrieben werden wird, ROM (Read Only Memory bzw. Nurlesespeicher) 152, in dem PT2 usw. gespeichert sind, Flash-Speicher 153, in dem empfangene Daten, der eingerichtete Inhalt des Benutzers (zum Beispiel die Fähigkeit zur automatischen Akquisition von JAR) usw. gespeichert sind, um zu ermöglichen, dass sie erneut verwendet werden können, selbst nachdem das Endgerät erneut gestartet wird, und RAM 154, der verhindert, dass gespeicherte Daten erneut verwendet werden, nachdem das Endgerät erneut gestartet ist, und der als der Arbeitsspeicher der CPU 151 zu verwenden ist.
Wenn der Netzschalter (nicht gezeigt) angeschaltet wird, liest CPU 151 das im ROM 152 gespeicherte Steuerprogramm aus und führt es aus, steuert dann ROM 152, Flash-Speicher 153, RAM 154, jede der Einheiten 11 bis 13 und Flüssigkristallanzeige 14 in Übereinstimmung mit Befehlen des Benutzers, die von dem Steuerprogramm und Eingabeeinheit 13 eingegeben sind. Außerdem aktiviert CPU 151, in Übereinstimmung mit dem von der Eingabeeinheit 13 eingegebenen Befehl, den Browser, und ist fähig zum Durchführen einer Kommunikation auf diesem Browser in Übereinstimmung mit dem Befehl von Eingabeeinheit 13. Weiterhin ist CPU 151 fähig zum Steuern des Kommunikationsprozesses basierend auf Prozesstabellen PT1 und PT2 (Verweis auf 6), die im ROM 152 gespeichert sind. Spezifische Operationen durch diese Funktion werden später beschrieben werden.
Außerdem aktiviert CPU 151 eine Java Virtual Machine, wenn sie eine im Flash-Speicher 153 gespeicherte Java-Anwendung ausführt, und führt diese Java-Anwendung auf dieser Java Virtual Machine aus. Weiterhin aktiviert CPU 151 die Java Virtual Machine und den Browser, wenn sie auf eine im RAM 154 gespeicherte Java-Anwendung (Java-Applet) zugreift und führt diese Java-Anwendung auf der Java Virtual Machine und dem Browser aus.
Eine Datenakquisition durch Endgerät T wird zuerst durchgeführt durch Erhalten von HTML-Daten von dem Heimat-URL (dem Ressourcenort von Gateway GWS, auf das zuerst zugegriffen werden soll), im ROM 152 gespeichert, durch CPU 151, die auf den im ROM 152 gespeicherten Browser zugreift und diesen Browser ausführt. Basierend auf diesen Daten zeigt die Flüssigkristallanzeige 15 dann die Anzeige des Dialogschirms an und Daten werden erhalten, wenn der Benutzer Eingabeeinheit 13 bedient, nach der Anzeige dieses Dialogschirms.
[Operation zum Erhalten einer Java-Anwendung]
7 ist ein Flussdiagramm, das den Fluss des Prozesses zeigt, den Endgerät T durchführt, wenn eine Java-Anwendung erhalten wird, und danach werden, vorwiegend durch Verweis auf 2, 3, 6 und 7, die Operationen des Endgerätes T zum Erhalten einer Java-Anwendung von IP-Server W gemäß jedem Kommunikationsmuster erläutert werden. In den Erläuterungen unten sind die Operationen, die überlappen, jedoch soweit wie möglich weggelassen. Beim Endgerät T wird angenommen, dass der Browser bereits aktiviert worden ist. Bezüglich der Akquisitionsausführungsform der Java-Anwendung, die der Gegenstand der Akquisition ist, kann sie außerdem entweder im Festspeicher oder im temporären Speicher gespeichert werden, aber nur der Fall, in dem eine Java-Anwendung im Festspeicher gespeichert wird, nach ihrer Akquisition, wird erläutert werden, um eine Verkomplizierung der Erläuterung zu vermeiden.
(1) Fall des Kommunikationsmusters P1
Wie in 2 gezeigt, sind die Kommunikationsmodi des Kommunikationsmusters P1 im gewöhnlichen Modus im Schritt A und Schritt B und in SSL im Schritt C.
Zuerst erhält Endgerät T die Seite (hier im Nachfolgenden als Herunterladeseite bezeichnet) zum Erhalten der Java-Anwendung, die ihr Gegenstand ist (Schritt S1). Genauer genommen steuert CPU 151 von Endgerät T (Verweis auf 5) die Sende-Empfangseinheit 11 basierend auf dem Befehl des Benutzers, der von Eingabeeinheit 13 eingegeben ist, und sendet IP-Server W eine HTTP-Nachricht durch das GET-Verfahren, was die Erfüllung bzw. Befolgung der Sende-Empfangseinheit 11 auf diesen Befehl ist (Verweis auf 4). In Ansprechen darauf werden HTML-Daten der Herunterladeseite, die der Gegenstand ist, vom IP-Server W zurückgesendet. Diese HTML-Daten werden durch Sende-Empfangseinheit 11 empfangen und werden an CPU 151 von Sende-Empfangseinheit 11 transferiert. CPU 151 speichert diese HTML-Daten in RAM 154 und stellt die Benutzerschnittstelle bereit durch weiteres Interpretieren und Ausführen dieser Daten. Als ein Ergebnis erscheint die Anzeige dieser Benutzerschnittstelle in Flüssigkristallanzeige 14.
Dann wartet Endgerät T auf eine Eingabe eines Befehls durch den Benutzer (Schritt S2), und der Akquisitionsprozess terminiert, wenn der eingegebene Befehl nicht der Befehl zum Erhalten der Ziel-Java-Anwendung ist (Schritt S3). Genauer genommen, identifiziert CPU 151 von Endgerät T den Inhalt des Befehls durch den Benutzer basierend auf dem Befehl, der von Eingabeeinheit 13 und der aktuellen Benutzerschnittstelle eingegeben ist, und der Akquisitionsprozess terminiert, wenn Befehle, die unterschiedlich von dem Inhalt zum Erhalten der Java-Anwendung, so wie Erhalten einer unterschiedlichen Seite, sind, eingegeben werden, oder der Netzschalter (nicht gezeigt) abgeschaltet wird.
Wenn andererseits der im Schritt S2 eingegebene Befehl die Anforderung zum Erhalten der Ziel-Java-Anwendung ist (Schritt S3), durch HTML-Daten, die im Schritt S1 erhalten sind, werden das Umschaltmuster vom Schritt A zum Schritt B und der Verbindungsmodus identifiziert (Schritt S4). Dann wird der Prozess, der dem identifizierten Ergebnis entspricht, ausgeführt, und die ADF, die der Gegenstand bzw. das Ziel ist, wird erhalten (Schritt S5). In diesem Fall sind die Kommunikationsmodi sowohl von Schritt A als auch von B gewöhnlich; deshalb, in Übereinstimmung mit der in 6 gezeigten Prozesstabelle PT1, wird der Prozess zum Erhalten der ADF durch eine gewöhnliche Kommunikation durchgeführt. Während dieses Prozesses wird „wird erhalten" auf Flüssigkristallanzeige 14 angezeigt. Wie in Prozesstabelle PT1 in 6 gezeigt, wird der Verarbeitungsinhalt bestimmt, was auch immer der Verbindungsmodus in diesem Fall ist. Außerdem wird der Kommunikationsmodus im Schritt B nicht durch den Benutzer bestimmt, sondern wird im Schritt S4 durch Referenzieren der URL preisgegeben, der in HTML-Daten enthalten ist, die im Schritt S1 zum Erhalten der ADF erhalten sind. Genauer genommen zeigt der Beginn der URL den Kommunikationsmodus zum Zugreifen auf den WWW-Server an, und wenn der URL mit „http" beginnt, wird der Kommunikationsmodus „gewöhnlich" sein, da HTTP angezeigt wird. Wenn der URL mit „https" beginnt, wird der Kommunikationsmodus „SSL" sein, da HTTPS angezeigt wird.
Wenn die Akquisition der ADF vollendet ist, und wenn die automatische Akquisition des JAR nicht ermöglicht bzw. erlaubt wird (Schritt S6), schreitet Endgerät T fort, um den Benutzer zu fragen, ob JAR erhalten werden sollte (Schritt S7). Wenn der Befehl zum Fortsetzen der Akquisition von JAR als die Antwort auf diese Anfrage eingegeben wird (Schritt S8), schreitet es zu dem Prozess von Schritt S9 voran. Wenn jedoch der Befehl zum Unterbrechen der Akquisition von JAR eingegeben wird, wird der Unterbrechungsprozess durchgeführt (Schritt S12) und der Prozess kehrt zum Schritt S1 zurück. Wenn die automatische Akquisition des JAR ermöglicht bzw. erlaubt wird (Schritt S6), schreitet der Prozess unmittelbar zum Schritt S9 voran.
Endgerät T ist mit der Funktion ausgerüstet zum Setzen eines Erlaubens/Nicht-Erlaubens der automatischen Akquisition des JAR. CPU 151 setzt/setzt zurück das bezeichnete Bit des Flash-Speichers 153, das das Bit zum Setzen des Erlaubens/Nicht-Erlaubens der automatischen Akquisition des JAR ist, in Ansprechen auf den von Eingabeeinheit 13 eingegebenen Befehl. Durch Referenzieren dieses Bits kann CPU 151 deshalb die Erlauben-/Nicht-Erlauben-Einstellung für die automatische Akquisition des JAR identifizieren. Außerdem unterbricht CPU 151, in dem Unterbrechungsprozess im Schritt 512, den Prozess zum Erhalten der Java-Anwendung, verwirft die ADF, die der Gegenstand bzw. das Ziel ist, und im Flash-Speicher 153 gespeichert wird, und zieht den maximalen Vorteil aus dem Speichervolumen des Flash-Speichers 153.
Als nächstes wird das Umschaltmuster vom Schritt B zum Schritt C und der Verbindungsmodus identifiziert, und der Akquisitionsprozess des JAR wird basierend auf dem identifizierten Ergebnis durchgeführt (Schritt 510, S11). In diesem Fall ist der Kommunikationsmodus von Schritt B gewöhnlich und der Kommunikationsmodus von Schritt C ist SSL; deshalb, wie in Prozesstabelle PT2 gezeigt, wird der Prozess der sein, in welchem JAR durch neues Starten einer SSL-Kommunikation erhalten wird. Während dieses Prozesses wird „SSL-Kommunikation beginnt (wird authentifiziert)" in Flüssigkristallanzeige 14 als die Anzeigenachricht angezeigt. Somit wird der Prozess, der dem Umschaltmuster P1 in 3 entspricht, passend durchgeführt. Wie in Prozesstabelle PT2 in 6 gezeigt, wird der Prozessinhalt bestimmt, was auch immer der Verbindungsmodus in diesem Fall ist. Außerdem wird der Kommunikationsmodus von Schritt C im Schritt S9 preisgegeben durch Referenzieren des URL, der in der ADF-Datei enthalten ist, die im Schritt S5 zum Erhalten des JAR erhalten ist. Wenn die ADF erhalten ist, wenn der URL mit „http" beginnt, wird der Kommunikationsmodus „gewöhnlich" sein. Wenn der URL mit „https" beginnt, wird der Kommunikationsmodus „SSL" sein.
(2) Fall des Kommunikationsmusters P2
Wie in 2 gezeigt, sind die Kommunikationsmodi des Kommunikationsmusters P2 gewöhnlich im Schritt B und SSL im Schritt A und C.
Zuerst wird, in Schritten 1 bis 5, derselbe Prozess wie in Kommunikationsmuster P1 durchgeführt. Da der Kommunikationsmodus im Schritt A jedoch SSL ist, wird HTTPS des GET-Verfahrens an IP-Server W im Schritt S1 übertragen. Außerdem ist der Kommunikationsmodus SSL im Schritt A und der Kommunikationsmodus ist gewöhnlich im Schritt B während dieses Prozesses; deshalb, wie in der in 6 gezeigten Prozesstabelle PT1 gezeigt, wird die SSL-Kommunikation gestoppt werden, und der Prozess zum Erhalten der ADF durch eine gewöhnliche Kommunikation wird durchgeführt werden. Während dieses Prozesses wird „SSL-Seite terminiert" in Flüssigkristallanzeige 14 als die Anzeigenachricht angezeigt werden.
Nach Schritt S9 ist auch der Kommunikationsmodus im Schritt B gewöhnlich und der Kommunikationsmodus im Schritt C ist SSL; deshalb wird derselbe Prozess wie Kommunikationsmuster P1 durchgeführt werden. Somit wird der Prozess, der Kommunikationsmuster P2 in 3 entspricht, passend durchgeführt.
(3) Fall des Kommunikationsmusters P3
Wie in 2 gezeigt, sind die Kommunikationsmodi des Kommunikationsmusters P3 gewöhnlich in Schritten A und C und SSL in Schritt B.
In Schritten S1 bis S5 wird zuerst derselbe Prozess wie Kommunikationsmuster P1 durchgeführt. Während dieses Prozesses ist jedoch der Kommunikationsmodus des Schrittes A gewöhnlich und der Kommunikationsmodus des Schrittes B ist SSL; deshalb, wie in der in 6 gezeigten Prozesstabelle PT1 gezeigt, wird der Prozess der Eine zum Erhalten der ADF durch neues Starten einer SSL-Kommunikation sein. Während dieses Prozesses wird „SSL-Kommunikation beginnt (wird authentifiziert)" in Flüssigkristallanzeige 14 als die Anzeigenachricht angezeigt. Selbst wenn der Verbindungsmodus Lebendighalten ist, startet eine SSL-Kommunikation in diesem Prozess neu, trotz des Verbindungsmodus, da ein Umschalten zum SSL-Kommunikationsmodus von dem gewöhnlichen Kommunikationsmodus ohne Terminieren des Prozesses unmöglich ist.
Als nächstes werden das Umschaltmuster vom Schritt B zum Schritt C und der Verbindungsmodus identifiziert (Schritt S9). Während dieses Prozesses ist der Kommunikationsmodus im Schritt B SSL und der Kommunikationsmodus im Schritt C ist gewöhnlich; deshalb wird das bestimmte Ergebnis im Schritt S10 „ja" sein und der Prozess kehrt zum Schritt S1 über den Unterbrechungsprozess im Schritt S12 zurück. Die Ziel-Java-Anwendung wird, mit anderen Worten, nicht erhalten und der Prozess, der Kommunikationsmuster P3 in 3 entspricht, wird passend durchgeführt.
(4) Fall des Kommunikationsmusters P4
Wie in 2 gezeigt, sind die Kommunikationsmodi des Kommunikationsmusters P4 gewöhnlich im Schritt C und SSL in Schritten A und B.
Zuerst wird in Schritten S1 bis S5 derselbe Prozess wie Kommunikationsmuster P1 durchgeführt. Da jedoch der Kommunikationsmodus im Schritt A SSL ist, wird eine HTTPS-Nachricht des GET-Verfahrens an IP-Server W im Schritt S1 übertragen. Außerdem ist in diesem Prozess der Kommunikationsmodus in Schritten A und B SSL; deshalb wird der Prozess in Übereinstimmung mit dem Verbindungsmodus von Schritt A bis Schritt B durchgeführt. Wenn der Verbindungsmodus Nicht-Lebendighalten ist, wird, mit anderen Worten, der Prozess zum Erhalten der ADF durch Starten einer SSL-Kommunikation durchgeführt. Wenn der Verbindungsmodus Lebendighalten ist, wird der Prozess zum Erhalten einer ADF durch Fortsetzen einer SSL-Kommunikation durchgeführt. In dem ersteren Fall wird „SSL-Kommunikation beginnt" in Flüssigkristallanzeige 14 angezeigt, und in dem letzteren Fall wird keine Anzeige in Flüssigkristallanzeige 14 angezeigt. Eine Nachricht wird nicht angezeigt, wenn der Verbindungsmodus Lebendighalten ist, weil ein neuer Prozess einer SSL-Kommunikation nicht startet.
Außerdem ist der Kommunikationsmodus des Schrittes B SSL, und der Kommunikationsmodus des Schrittes C ist gewöhnlich, deshalb wird derselbe Prozess wie Kommunikationsmuster P3 durchgeführt. Somit wird der Prozess, der Kommunikationsmuster P4 in 3 entspricht, passend durchgeführt.
(5) Fall des Kommunikationsmusters P5
Wie in 2 gezeigt, sind die Kommunikationsmodi des Kommunikationsmusters P5 gewöhnlich im Schritt A und SSL im Schritt B und C.
Zuerst wird, in Schritten S1 bis S5, derselbe Prozess wie Kommunikationsmuster P3 durchgeführt. Dann, in dem Prozess nach Schritt S9, da der Kommunikationsmodus SSL im Schritt B und C ist, wird der Prozess in Übereinstimmung mit dem Verbindungsmodus vom Schritt B zum Schritt C basierend auf der in 6 gezeigten Prozesstabelle PT2 durchgeführt. Der Prozess zum Erhalten des JAR wird, mit anderen Worten, durchgeführt durch Starten einer SSL-Kommunikation, wenn der Verbindungsmodus Nicht-Lebendighalten ist, und der Prozess zum Erhalten des JAR durch Fortsetzen einer SSL-Kommunikation wird durchgeführt, wenn der Verbindungsmodus Lebendighalten ist. In dem ersteren Fall wird „SSL-Kommunikation beginnt" in Flüssigkristallanzeige 14 angezeigt, und in dem letzteren Fall wird keine Nachricht in Flüssigkristallanzeige 14 angezeigt. Somit wird der Prozess, der Kommunikationsmuster P5 in 3 entspricht, passend durchgeführt.
(6) Fall des Kommunikationsmusters P6
Wie in 2 gezeigt, ist der Kommunikationsmodus des Kommunikationsmusters P6 SSL in Schritten A, B und C.
Zuerst wird, in Schritten S1 bis S5, derselbe Prozess wie Kommunikationsmuster P4 durchgeführt. Dann wird in dem Prozess nach Schritt S9 derselbe Prozess wie Kommunikationsmuster P5 durchgeführt. Somit wird der Prozess, der Kommunikationsmuster P6 in 3 entspricht, passend durchgeführt.
(7) Fall des Kommunikationsmusters P7
Wie in 2 gezeigt, ist der Kommunikationsmodus des Kommunikationsmusters P7 gewöhnlich im Schritt A, B und C.
Zuerst wird, in Schritten S1 bis S5, derselbe Prozess wie Kommunikationsmuster P1 durchgeführt. Dann wird in dem Prozess des Schrittes S9 und danach der Prozess zum Erhalten des JAR durch Fortsetzen einer gewöhnlichen Kommunikation gemäß der in 6 gezeigten Prozesstabelle PT2 durchgeführt, da der Kommunikationsmodus der Schritte B und C gewöhnlich ist. Während dieses Prozesses wird „wird erhalten" in Flüssigkristallanzeige 14 als die angezeigte Nachricht angezeigt. Somit wird der Prozess, der Kommunikationsmuster P7 in 3 entspricht, passend durchgeführt.
(8) Fall des Kommunikationsmusters P8
Wie in 2 gezeigt, sind die Kommunikationsmodi für Kommunikationsmuster P8 SSL im Schritt A und gewöhnlich in Schritten B und C.
Zuerst wird, in Schritten S1 bis S5, dasselbe Kommunikationsmuster wie P2 durchgeführt. Dann wird in dem Prozess des Schrittes S9 und danach dasselbe Kommunikationsmuster wie P7 durchgeführt. Somit wird der Prozess, der Kommunikationsmuster P8 in 3 entspricht, passend durchgeführt.
[Ergänzung]
Wie oben erläutert, gemäß der vorliegenden Erfindung, wird der Prozess, der jedem in 2 und 3 gezeigten Kommunikationsmuster entspricht, passend durchgeführt, und eine ADF wird durch Kommunikation in dem Verschlüsselungskommunikationsmodus erhalten. Dann kann das Muster zum Akquirieren einer Java-Anwendung durch Erhalten des JAR durch eine Kommunikation im gewöhnlichen Kommunikationsmuster eliminiert werden.
Wenn der Endgerätbenutzer die erhaltene Java-Anwendung ausführt und die erhaltene Java-Anwendung eine Kommunikation mittels Verwenden des Netzwerks durchführt, kann daher eine Übertragung einer persönlichen Information in der klaren Sprache durch die Java-Anwendung, gegen den Willen des Endgerätbenutzers, verhindert werden.
Außerdem, wie in der oben erwähnten Ausführungsform, ist ein Zellulartelefon als ein Endgerät wirksam. Die Datenverarbeitungsfähigkeit eines Zellulartelefons ist niedriger im Vergleich zu einem Endgerät, so wie einem Notebook-Computer und die Bandbreite des Kommunikationspfades ist schmaler im Vergleich zu einer Kabelkommunikation; deshalb ist die Möglichkeit, dass die Bedienung des Endgerätes für eine längere Zeitperiode eingeschränkt ist, als es der Benutzer erwartet, im Stand der Technik höher. Aber in der vorliegenden Ausführungsform wird solch eine Einschränkung durch Ermöglichen vermieden, dass eine Java-Anwendung erhalten wird, durch Aufteilen davon in eine ADF und ein JAR, und durch Ermöglichen, dass der Benutzer, der eine Eigenschaftsinformation über die ADF referenzierte, über das Erhalten des JAR bestimmt.
In der oben erwähnten Ausführungsform wurde das Beispiel gezeigt, dass eine Java-Anwendung ermöglicht wird, die ohne erneutes Erhalten der Java-Anwendung zu verwenden ist, selbst nachdem das Endgerät erneut gestartet wurde, durch Speichern der erhaltenen Java-Anwendung in den Festspeicher; jedoch ist auch das erneute Erhalten der Java-Anwendung machbar, nachdem das Endgerät erneut angeschaltet ist, durch Speichern der erhaltenen Java-Anwendung in einen temporären Speicher.
Außerdem ist, in der oben erwähnten Ausführungsform, eine Java-Anwendung nur ein Beispiel von Daten, die erhalten werden können, aber andere Programme oder Daten können auch erhalten werden. Die vorliegende Erfindung kann, mit anderen Worten, angewendet werden, wenn eine Art von Daten, die in zwei Einheiten aufgeteilt sind, von dem Internet erhalten wird.
Außerdem sind, in der oben erwähnten Ausführungsform, Kommunikationsmuster P1 und P2 in 2 erlaubt, aber diese können verboten werden. Es ist, mit anderen Worten, möglich ein Akquisitionsmuster zu verbieten, in dem das Kommunikationssystem des Schrittes B und das Kommunikationssystem des Schrittes C nicht übereinstimmen.
Außerdem ist, in der oben erwähnten Ausführungsform, ein Zellulartelefon ein Beispiel eines Endgerätes, aber in der vorliegenden Erfindung können andere Endgeräte, die eine Kommunikation über ein Netzwerk durch ein Kabel oder durch die Luft durchführen können, verwendet werden.
Außerdem sind, in der oben erwähnten Ausführungsform, Kommunikationsmuster P3 und P4 in 2, ohne Ausnahme, nicht erlaubt, aber solche Einschränkungen treffen nicht auf die vorliegende Erfindung zu. Beispielsweise kann durch Befragung des Benutzers, ob eine Akquisition möglich ist, wenn die Kommunikationsmuster P3 und P4 in 2 sind, JAR empfangen und gespeichert werden, wenn der Benutzer zustimmt. Anderenfalls kann, durch Erlauben, dass ein Typ einer Java-Anwendung in der ADF gespeichert wird, ein JAR empfangen und gespeichert werden, selbst wenn die Kommunikationsmuster P3 und P4 in 2 sind, wenn die Java-Anwendung von dem Typ ist, der keine Kommunikation durchführt.
Außerdem sind, in der oben erwähnten Ausführungsform, Beispiele zum Weiterleiten von Daten durch Verwenden von HTTP (und HTTPS) und AL gezeigt, aber in der vorliegenden Erfindung kann irgendein Protokoll, das eine Verschlüsselungskommunikation erreichen kann, übernommen werden. Es kann selbstverständlich irgendein Kommunikationsprotokoll sein, das Lebendighalten und Nicht-Lebendighalten entspricht. Es kann auch ein Kommunikationsprotokoll sein, das nicht diesen entspricht.
Außerdem ist, in der oben erwähnten Ausführungsform, ein Beispiel eines Umwandelns eines Kommunikationsprotokolls bei Gateway-Server GWS gezeigt, aber dieses ist nur ein Beispiel. Beispielsweise kann, durch Ermöglichen, dass HTTP (und HTTPS) und SSL bei dem Endgerät verarbeitet werden, eine Kommunikation direkt zwischen dem Endgerät und IP-Server ausgeführt werden, oder sie kann ausgeführt werden, nachdem sie eine Vielzahl von Umwandlungen durchlaufen hat.

Claims

Verfahren zum Erhalten einer Anwendung in einem Endgerät, mit: einem ersten Empfangsschritt (S5) in einem Endgerät (T), das über ein Netzwerk (MPN) kommunizieren kann, zum Empfangen einer ersten Dateneinheit (ADF), in der eine Eigenschaftsinformation über eine Anwendung gespeichert ist, in einem gewöhnlichen oder sicheren Kommunikationsmodus über das Netzwerk; einem Schritt (S9) zum Identifizieren des Kommunikationsmodus zum Empfangen einer zweiten Dateneinheit (JAR), in der ein Grundelement der Anwendung gespeichert ist, als gewöhnlich oder sicher; einem Bestimmungsschritt (S10) zum Bestimmen, ob die Sicherheit des identifizierten, zum Empfangen der zweiten Dateneinheit verwendeten Kommunikationsmodus niedriger ist als die Sicherheit des in dem ersten Empfangsschritt (S5) verwendeten Kommunikationsmodus; und einem weiteren Schritt, in dem die zweite Dateneinheit (JAR) von der Netzwerkseite (S11) empfangen wird, wenn ein bestimmtes Resultat in dem Bestimmungsschritt „nein" ist, und die zweite Dateneinheit nicht von der Netzwerkseite empfangen wird, wenn es „ja" ist (S12).
verfahren gemäß Anspruch 1, wobei ein sicherer Kommunikationsmodus zum Empfangen der ersten Dateneinheit (ADF) ein eine Verschlüsselungskommunikation verwendender Modus ist, und eine Akquisition der Daten als „nein" bestimmt wird, wenn ein Kommunikationsmodus zum Empfangen der zweiten Dateneinheit ein Modus ist, der nicht eine Verschlüsselung in dem Bestimmungsschritt (S10) verwendet.
Verfahren gemäß Anspruch 1, wobei eine Akquisition der Daten als „nein" bestimmt wird, wenn ein Kommunikationsmodus, der in dem ersten Empfangsschritt verwendet wurde, und ein zum Empfangen der zweiten Dateneinheit verwendeter Kommunikationsmodus in dem Bestimmungsschritt (S10) nicht übereinstimmen.
Verfahren gemäß Anspruch 1, wobei die Daten ein Computerprogramm sind, das bei dem Endgerät (T) ausgeführt werden kann.
Verfahren gemäß Anspruch 4, wobei das Computerprogramm ein Computerprogramm ist, das eine Kommunikation durchführt.
Verfahren gemäß Anspruch 1, wobei das Endgerät (T) ein Mobiltelefon ist.
Endgerät (T), mit: einer ersten Empfangseinrichtung zum Empfangen in einem gewöhnlichen oder sicheren Kommunikationsmodus einer ersten Dateneinheit (ADF), in der eine Eigenschaftsinformation über eine Anwendung gespeichert ist, von einer Netzwerkseite; einer Einrichtung zum Identifizieren des Kommunikationsmodus zum Empfangen einer zweiten Dateneinheit (JAR), in der ein Grundelement der Anwendung gespeichert ist, als gewöhnlich oder sicher; einer Bestimmungseinrichtung zum Bestimmen, ob die Akquisition der Daten durchführbar ist, basierend darauf, ob die Sicherheit des identifizierten Kommunikationsmodus zum Empfangen der zweiten Dateneinheit (JAR) niedriger ist als die Sicherheit des Kommunikationsmodus, der zum Empfangen der ersten Dateneinheit (ADF) von der Netzwerkseite verwendet wird; und einer weiteren Empfangseinrichtung, die die zweite Dateneinheit von der Netzwerkseite empfängt, wenn ein bestimmtes Resultat durch die Bestimmungseinrichtung „nein" ist, und die zweite Dateneinheit nicht von der Netzwerkseite empfängt, wenn es „ja" ist.