ES2280433T3 - Procedimiento y terminal para la adquisicion segura de aplicaciones. - Google Patents
Procedimiento y terminal para la adquisicion segura de aplicaciones. Download PDFInfo
- Publication number
- ES2280433T3 ES2280433T3 ES01997742T ES01997742T ES2280433T3 ES 2280433 T3 ES2280433 T3 ES 2280433T3 ES 01997742 T ES01997742 T ES 01997742T ES 01997742 T ES01997742 T ES 01997742T ES 2280433 T3 ES2280433 T3 ES 2280433T3
- Authority
- ES
- Spain
- Prior art keywords
- communication
- data
- terminal
- stage
- mode
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/166—Implementing security features at a particular protocol layer at the transport layer
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99939—Privileged access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99941—Database schema or data structure
- Y10S707/99944—Object-oriented database structure
- Y10S707/99945—Object-oriented database structure processing
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Computer Hardware Design (AREA)
- Mobile Radio Communication Systems (AREA)
- Credit Cards Or The Like (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
- Stored Programmes (AREA)
- Communication Control (AREA)
- Traffic Control Systems (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Heterocyclic Carbon Compounds Containing A Hetero Ring Having Oxygen Or Sulfur (AREA)
- Diaphragms For Electromechanical Transducers (AREA)
- Air Bags (AREA)
- Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
Abstract
Un procedimiento para obtener una aplicación en un terminal, que comprende: una primera etapa de recepción (S5) en un terminal (T) que puede comunicarse a través de una red (MPN) para recibir en un modo de comunicación normal o seguro, a través de dicha red, una primera unidad de datos (ADF) en la que está almacenada información sobre propiedades acerca de una aplicación; una etapa (S9) de identificación del modo de comunicación para recibir una segunda unidad de datos (JAR), en la que está almacenada una entidad de dicha aplicación, como normal o seguro; una etapa de determinación (S10) destinada a determinar si la seguridad del modo de comunicación identificado usado para recibir dicha segunda unidad de datos es inferior a la seguridad del modo de comunicación usado en dicha primera etapa de recepción (S5); y una etapa adicional en la que dicha segunda unidad de datos (JAR) se recibe desde dicho lado de la red (S11) cuando un resultado determinado en dicha etapa de determinación es ¿no¿,y dicha segunda unidad de datos no se recibe desde dicho lado de la red cuando es ¿sí¿ (S12).
Description
Procedimiento y terminal para la adquisición
segura de aplicaciones.
La presente invención se refiere a un
procedimiento para obtener aplicaciones a través de una red, y un
terminal para obtener aplicaciones por medio de este
procedimiento.
Debido al reciente desarrollo de las redes de
comunicaciones, la obtención de datos a través de redes tal como
Internet (descarga) se realiza de forma generalizada. Los datos
obtenidos a través de redes tales como Internet normalmente se
almacenan en una memoria fija tal como un disco duro. Incluso
después de inicializar la UCP (Unidad Central de Procesamiento) y
la RAM (memoria de acceso directo) mediante reinicio del terminal
apagando la alimentación eléctrica del terminal una vez y
encendiéndola después de nuevo, o mediante reinicialización del
terminal, se puede acceder de nuevo a los datos almacenados en
memoria fija mediante extracción por lectura de los datos desde la
memoria fija en la que se almacenan los datos.
Igualmente, cuando se obtienen datos a través de
redes tales como Internet, los datos obtenidos se pueden almacenar
incluso en memoria temporal tal como una RAM. Un ejemplo de datos de
este modo es una miniaplicación (applet) Java. La miniaplicación
Java es un programa que se produce utilizando Java (aplicación
Java). La miniaplicación Java se obtiene a través de redes tales
como Internet y se almacena en memoria temporal del terminal. La
miniaplicación Java obtenida en el terminal se usa a través del
navegador para ver páginas Web escritas en HTML (lenguaje de
composición de hipertexto) y máquina virtual Java. Como se ha
descrito anteriormente, cuando se reinicia el terminal, la memoria
temporal de RAM se inicializa y los datos almacenados en la memoria
temporal se suprimen. Cuando se almacenan en memoria temporal datos
obtenidos a través de redes tales como Internet, estos no se pueden
usar de nuevo, después de reiniciar el terminal, a menos que se
obtengan de nuevo los datos a través de redes tales como
Internet.
Existe una serie de aplicaciones Java que, a
diferencia de la miniaplicación Java, se almacenan en memoria fija
tras su obtención desde redes tales como Internet y no necesitan
obtenerse de nuevo desde redes tales como Internet incluso después
de reiniciar el terminal. También existen aplicaciones Java que se
almacenan en memoria fija del terminal y no necesitan obtenerse
desde una red. Sin embargo, a efectos de la descripción de la
presente invención, "aplicación Java" hará referencia en lo
sucesivo a una aplicación Java que se obtiene desde una red, puesto
que se presupone que los datos se obtienen desde una red.
Conviene advertir que, tanto si se almacenan en
memoria fija como en memoria temporal los datos obtenidos desde
redes tales como Internet, estos se reciben normalmente desde la red
tal como Internet en forma de archivo. Por ejemplo, cuando se
obtiene una aplicación Java compuesta de un único archivo desde un
servidor Web mediante HTTP (protocolo de transferencia de
hipertexto), esto tiene lugar en una secuencia, en otras palabras,
conectándose con el servidor Web, solicitando información,
recibiendo la respuesta y desconectándose del servidor Web. En este
caso, cuando el usuario solicita una aplicación Java manejando el
terminal, la descarga se inicia inmediatamente y la conexión entre
el servidor Web y el terminal se mantiene hasta que se complete la
descarga. En el terminal se visualiza un mensaje que indica que se
está descargando un archivo.
En este procedimiento de obtención de datos, el
usuario del terminal no puede conocer información sobre propiedades
tal como el tamaño de archivo de la aplicación Java antes de empezar
a descargarlo; por lo tanto, el usuario del terminal no puede
prever la cantidad de tiempo necesario para descargar la aplicación
Java. Por consiguiente, existe el problema de que, cuando una
aplicación Java se compone de una pluralidad archivos, el uso del
terminal puede verse restringido debido a un tiempo de descarga más
largo del previsto. Esto es extremadamente serio, especialmente
para terminales tales como teléfonos celulares, en los que está
instalado un navegador, que tienen un intervalo de comunicación o
potencia de procesamiento limitados. Evidentemente, sobre la página
Web en el terminal del usuario se puede visualizar información
necesaria sobre propiedades tal como el nombre de archivo de la
aplicación Java y el tamaño de archivo, pero existe la preocupación
de que se podría notificar al usuario alguna información sobre
propiedades incorrecta, debido a descripciones erróneas o una
intención fraudulenta.
A fin de evitar los problemas mencionados
anteriormente, se sugiere dividir una aplicación Java en dos
archivos, ADF (archivo descriptor de aplicación), que contiene
información sobre propiedades, y JAR (archivo Java), que contiene
la entidad de datos, y recibir estos en secuencia en el terminal.
JAR es un tipo de archivo en el que uno o una pluralidad de
archivos están organizados en uno. JAR es capaz de descargar una
pluralidad de archivos en una operación, ahorrando con ello el
tiempo requerido para descargar cada archivo en una operación
separada. Sin embargo, cuando se divide un archivo en dos archivos,
ADF y JAR, no se tiene en cuenta en absoluto el problema de
garantizar la seguridad.
Se conoce de Jörg Heuer y col.: "Adaptive
Multimedia Messaging based on
MPEG-7-The
M3-Box", Proceedings 2nd INT'L Symposium on
Mobile Multimedia Systems and Applications, 10 de noviembre de 2000,
XP002001575 Delft, Países Bajos, un procedimiento de obtención de
datos para obtener datos de contenido multimedia a partir de un
centro de mensajes multimedia, que comprende una primera etapa de
recepción en un terminal que puede ponerse en comunicación a través
de una red para recibir a través de la red una primera unidad de
datos en la que está almacenada una descripción de contenido
multimedia que se puede visualizar sobre el terminal, es decir, el
dispositivo de salida. En Czerwinski Steven y col.: "An
Architecture for a Secure Service Discovery Service",
Proceedings of the 5th Annual ACM/IEEE International Conference on
Mobile Computing and Networking, 15 de agosto de 1999, XP000896069,
Nueva York, Estados Unidos, se describe un Servicio de
Descubrimiento de Servicios (SDS) seguro que usa un mecanismo en
dos partes en el que las consultas del cliente y la descripción del
servicio se envían entre el proveedor y el cliente usando XML en la
primera etapa. Para prevenir el uso fraudulento, se cifra toda la
información enviada entre cliente y servidor y se usa adicionalmente
autenticación fuerte de los puntos extremos. De acuerdo con estas
descripciones, se genera una presentación de contenidos de la
cuenta comprobada y se transmite al destinatario que puede usar
entonces el dispositivo de salida para explorar la
presentación.
La presente invención tiene por objeto
proporcionar un procedimiento para obtener una aplicación y un
terminal que pueda garantizar una seguridad suficientemente
alta.
Este objeto queda resuelto según la presente
invención por un procedimiento para obtener una aplicación según se
define en la reivindicación 1. En las reivindicaciones subordinadas
se dan formas de realización ventajosas de la invención.
Mediante este procedimiento para obtener una
aplicación, el hecho de que pueda recibirse la segunda unidad de
datos se determina comparando el modo de comunicación que se usó
cuando se recibió la primera unidad de datos con el modo de
comunicación que se usa para recibir la segunda unidad de datos. Es
decir, la adquisición de datos se puede prohibir cuando se conmuta
de forma inadecuada el modo de comunicación desde el momento en que
se recibe la primera unidad de datos hasta el momento en que se
recibe la segunda unidad de datos. En otras palabras, se puede
garantizar una seguridad suficientemente alta cuando se obtienen
datos divididos.
Igualmente, la presente invención proporciona un
procedimiento para obtener una aplicación en el que no se autoriza
la adquisición de los datos cuando la seguridad de un modo de
comunicación que se usa para recibir la segunda unidad de datos es
inferior a la seguridad del modo de comunicación que se usó en la
primera etapa de recepción en la etapa de determinación.
Igualmente, la presente invención proporciona un
procedimiento para obtener una aplicación en el que un modo de
comunicación destinado a recibir la primera unidad de datos es un
modo que usa comunicación cifrada y no se autoriza la adquisición
de los datos cuando un modo de comunicación para recibir la segunda
unidad de datos es un modo que no usa cifrado en la etapa de
determinación.
Igualmente, la presente invención proporciona un
procedimiento para obtener una aplicación en el que no se autoriza
la adquisición de los datos cuando un modo de comunicación que se
usó en la primera etapa de recepción y un modo de comunicación
usado para recibir la segunda unidad de datos difieren en la etapa
de determinación.
Igualmente, la presente invención proporciona un
procedimiento para obtener una aplicación en el que los datos son
un programa informático que se puede ejecutar en el terminal.
Igualmente, la presente invención, en cualquiera
de los procedimientos descritos anteriormente, proporciona un
procedimiento para obtener una aplicación en el que el programa
informático es un programa informático que realiza una
comunicación.
Igualmente, la presente invención, en cualquiera
de los procedimientos descritos anteriormente, proporciona un
procedimiento para obtener una aplicación en el que el terminal es
un teléfono móvil.
El objeto de la presente invención queda
asimismo resuelto por un terminal según se define en la
reivindicación 7.
La Fig. 1 es un diagrama que muestra el
procedimiento básico de obtención de una aplicación Java en el
terminal en la forma de realización de la presente invención.
La Fig. 2 es un diagrama que muestra los
patrones de comunicaciones de este terminal.
La Fig. 3 es un diagrama que muestra los
mensajes visualizados en este terminal.
La Fig. 4 es un diagrama de bloques que muestra
la configuración del sistema de entrega de datos que usa este
terminal.
La Fig. 5 es un diagrama de bloques que muestra
la configuración de las unidades esenciales de este terminal.
La Fig. 6 es un diagrama conceptual que muestra
la configuración de las tablas de procesos PT1 y PT2 en el seno de
este terminal.
La Fig. 7 es un diagrama de flujo que muestra el
procedimiento realizado por este terminal durante la adquisición de
una aplicación Java.
En lo sucesivo, se explicarán las formas de
realización preferidas de la presente invención haciendo referencia
a los diagramas. La presente invención no queda limitada a las
siguientes formas de realización y son posibles varios cambios sin
salir del alcance de la invención según está desvelada por las
reivindicaciones que se adjuntan.
En primer lugar se explicará la idea fundamental
del procedimiento de obtención de datos de la presente
invención.
La Fig. 1 muestra el procedimiento básico en el
momento en que el terminal de la presente invención obtiene una
aplicación Java. Como se muestra en la Fig. 1, durante la
adquisición y la ejecución de una aplicación Java, el procedimiento
en el terminal se realiza en el orden A, B, C, D. En otras palabras,
en primer lugar el terminal emite a la red una petición de
adquisición de la página para obtener una aplicación Java y accede
a la página pertinente (etapa A). En este estado, el usuario del
terminal introduce entonces una orden de obtención de la aplicación
Java descrita en esta página manejando el terminal, el terminal
emite la petición de adquisición en respuesta a esta orden, obtiene
el ADF de la aplicación Java pertinente y lo almacena en memoria
fija (Etapa B). El terminal emite entonces a la red la petición de
adquisición del JAR que corresponde a este ADF, obtiene el JAR
pertinente y lo almacena en memoria fija (Etapa C). Luego, cuando el
usuario del terminal ordena la ejecución de la aplicación Java
obtenida (el programa contenido en el JAR) manejando el terminal,
la aplicación Java pertinente se ejecuta en el terminal (Etapa
D).
El procedimiento básico es tal y como se ha
descrito anteriormente, pero las condiciones cambian según el modo
de comunicación que se use para alcanzar cada etapa. Por ejemplo,
una operación en la que se usa el mismo modo de comunicación en las
Etapas A a C es diferente de una operación en la que en la Etapa A
se usa un modo de comunicación normal en el que no hay cifrado
pero, después de ello, se usa hasta la Etapa C comunicación por SSL
(nivel de conectores seguros), que es el protocolo para enviar y
recibir información mediante cifrado. El funcionamiento del
terminal que corresponde a tales condiciones es del siguiente
modo.
La Fig. 2 es un diagrama que muestra los
patrones de comunicación del terminal de la presente forma de
realización y, como se muestra en este diagrama, los patrones de
comunicación P1 a P8 son posibles patrones de comunicación del
terminal. Los patrones de comunicación P1 a P8 son todas las
variaciones posibles del orden de cada modo de comunicación
(normal/SSL) de las Etapas A a C.
La Fig. 3 es un diagrama que muestra los
mensajes visualizados en el terminal de la presente forma de
realización. En este diagrama, se indica el mensaje visualizado del
momento en el que comienza el desplazamiento de la Etapa A a la
Etapa B y el mensaje visualizado del momento en el que comienza el
desplazamiento de la Etapa B a la Etapa C, que corresponden a los
patrones de comunicación P1 a P8, y se puede identificar la
operación del terminal a partir de estos mensajes visualizados.
Igualmente, en este diagrama, los modos de conexión usados al
desplazarse de la Etapa A a la Etapa B y los modos de conexión
usados al desplazarse de la Etapa B a la Etapa C corresponden a
cada patrón de comunicación, y los mensajes visualizados
corresponden a los patrones de comunicación y a cada modo de
conexión. Sin embargo, en algunos casos, los mensajes visualizados
vienen determinados sin depender de los modos de conexión y se
indica "-" en la columna de un modo de conexión tal. Los tipos
de modo de conexión son modo de conexión persistente entre
peticiones ("keep-alive", que se denominará
modo de conexión persistente), en el que se puede reenviar una
pluralidad de datos manteniendo la conexión, y modo de conexión no
persistente entre peticiones
("non-keep-alive", que se
denominará modo de conexión no persistente), en el que la conexión
se cancela cada vez que finaliza un intercambio de datos. El modo
de conexión no persistente es el modo normal de intercambio de datos
de HTTP y el modo de conexión persistente es el modo normal de
intercambio de datos de HTTPS (protocolo de transferencia de
hipertexto seguro) que corresponde a SSL.
En la presente forma de realización, se logran
las operaciones mostradas en el diagrama 3. Estas operaciones se
describirán en detalle más tarde. A continuación se explicará, con
el propósito de explicar el diagrama, un ejemplo de una operación.
Por ejemplo, de acuerdo con el patrón de comunicación P6 (el patrón
de comunicación en el que todos los modos de comunicación desde la
Etapa A hasta C son SSL), mientras tiene lugar el desplazamiento de
la Etapa A a la Etapa B cuando el modo de conexión es conexión no
persistente, el mensaje visualizado al principio del desplazamiento
de la Etapa A a la Etapa B es "Comienza la comunicación SSL".
Igualmente, mientras tiene lugar el desplazamiento de la Etapa B a
la Etapa C cuando el modo de conexión es conexión persistente, no
hay visualización al principio.
El punto más distintivo en este diagrama es que,
en los patrones de comunicación P3 y P4, no se autoriza el
desplazamiento de la Etapa B a la Etapa C. Como se muestra en la
Fig. 2, en los patrones de comunicación P3 y P4, el modo de
comunicación en la Etapa B es SSL y el modo de comunicación en la
Etapa C es normal. En otras palabras, en la presente forma de
realización no está autorizado el patrón de adquisición de obtención
del ADF mediante comunicación usando el modo de comunicación
cifrada, obteniendo entonces posteriormente el JAR mediante
comunicación que usa el modo de comunicación normal. El motivo de
esto se explicará en lo sucesivo.
Cuando se ejecuta una aplicación Java obtenida
desde la red y la aplicación Java ejecutada realiza una comunicación
a través de una red, el modo usado cuando esta aplicación Java
realiza la comunicación a través de una red normalmente es el modo
de comunicación que se usó cuando el terminal obtuvo la aplicación
Java. Por ejemplo, cuando se ejecuta una aplicación Java obtenida
mediante comunicación SSL y esta aplicación Java realiza una
comunicación a través de una red, este modo de comunicación quedará
limitado a SSL. Por consiguiente, en el lado del terminal, siempre
que el modo de comunicación fuera SSL cuando se obtuvo la aplicación
Java, se puede determinar que no se transmitirá información
personal acerca del usuario del terminal en lenguaje claro incluso
cuando esta aplicación Java transmite información personal acerca
del usuario del terminal usando la red a partir de entonces.
Conviene advertir que, como en la presente forma
de realización, cuando se obtiene de una red una aplicación Java
usando ADF y JAR, esta aplicación Java realiza la comunicación en el
mismo modo de comunicación que cuando se obtuvo el JAR. En otras
palabras, como puede verse en los patrones de comunicación P3 y P4,
cuando el modo de comunicación durante la adquisición del ADF es
SSL y el modo de comunicación durante la adquisición del JAR es
normal, la aplicación Java contenida en este JAR realizará la
comunicación en el modo de comunicación normal cuando realice una
comunicación usando una red.
Sin embargo, un usuario tiende a suponer que el
modo de comunicación para obtener el JAR es SSL si el modo de
comunicación para obtener el ADF es SSL. Si se autoriza una
diferencia entre el modo de comunicación para obtener el ADF y el
modo de comunicación para obtener el JAR, existe el riesgo de que se
transmita información personal acerca del usuario del terminal en
lenguaje claro contra la voluntad del usuario. Igualmente, una vez
transmitida información personal en lenguaje claro contra la
voluntad del usuario del terminal, existe el riesgo de que una
tercera persona con intención fraudulenta, etcétera, pueda conseguir
subrepticiamente acceso a información personal sobre el usuario del
terminal. Para evitar tales problemas, el desplazamiento de la
Etapa B a la Etapa C no está autorizado en los patrones de
comunicación P3 y P4, como se muestra en la Fig. 3. En la Fig. 2,
el modo de comunicación de la Etapa B y el modo de comunicación de
la Etapa C son diferentes incluso en los patrones de comunicación
P1 y P2, pero estos patrones de comunicación están autorizados en
la presente forma de realización, puesto que los datos transmitidos
por una aplicación Java ejecutada en el terminal son mucho más
seguros de lo que un usuario puede requerir.
A continuación se explicará el sistema de
entrega de datos usando el terminal T en la presente forma de
realización.
La Fig. 4 es un diagrama de bloques que muestra
la configuración del sistema de entrega de datos usando el terminal
T y, como se muestra en este diagrama, este sistema de entrega de
datos es el sistema que autoriza al terminal T a utilizar la red
WWW (World Wide Web o red mundial).
En este diagrama, el terminal T es un terminal,
en este caso un teléfono móvil, destinado a recibir el servicio de
comunicación por paquetes de una red de comunicación móvil de
paquetes MPN, que ha de conectarse a distancia a la red de
comunicación móvil de paquetes MPN y la red de telefonía móvil (no
mostrada). La red de telefonía móvil es la red destinada a
proporcionar a teléfonos móviles estándares un servicio de llamadas
y el terminal T puede recibir este servicio de llamadas. Más tarde
se describirán las funciones y configuraciones detalladas del
terminal T.
La red de comunicación móvil de paquetes MPN se
compone de una pluralidad de estaciones base BS, una pluralidad de
dispositivos de tratamiento de abonado a paquetes PS, servidor de
pasarela GWS y líneas de comunicación para conectar estos.
Las estaciones base BS van situadas, por
ejemplo, a intervalos constantes, y cada estación base cubre un área
con un radio de 500 metros y realiza una radiocomunicación con el
terminal T dentro de su zona de radiodifusión.
El dispositivo de tratamiento de abonado a
paquetes PS es el sistema informático que está instalado en la
estación de conmutación de abonado a paquetes para servir a una
pluralidad de estaciones base BS y recibe del terminal T peticiones
de intercambio de paquetes y retransmite los paquetes recibidos al
terminal consignado T a través de otros dispositivos de tratamiento
de abonado a paquetes PS y estaciones base BS.
El servidor de pasarela GWS es el sistema
informático que está instalado en la estación de intercambio
retransmisora de la pasarela móvil de paquetes para conectar
mutuamente diferentes redes tales como la red de comunicación móvil
de paquetes MPN e Internet INET, y que realiza intercambios de
protocolos de comunicación que son diferentes entre las redes. Los
intercambios de protocolos de comunicación en este caso son
específicamente intercambios mutuos de protocolos de transmisión
para la red de comunicación móvil de paquetes que cumple la red de
comunicación móvil de paquetes MPN y protocolos de transmisión que
cumple Internet INET.
El protocolo de transmisión que cumple Internet
contiene TCP/IP (protocolo de control de transmisión/protocolo
Internet) del nivel de red y el nivel de transporte que es el modelo
de referencia OSI, y el protocolo de HTTP, HTTPS, etcétera que se
consiguen sobre este TCP/IP. El protocolo que cumple la red de
comunicación móvil de paquetes MPN contiene el protocolo en el que
se simplifica el TCP/IP (denominado en lo sucesivo TL) y el
protocolo que es el equivalente de HTTP y HTTPS (denominado en lo
sucesivo AL). En otras palabras, el terminal T usa la red WWW sobre
AL.
Igualmente, cuando el servidor de pasarela GWS
recibe desde el terminal T un mensaje HTTP (o HTTPS) que usa el
procedimiento GET, éste comprueba el URL (localizador uniforme de
recursos) contenido en el HTTP (o HTTPS) que usa este procedimiento
GET. Si este URL es el URL general sobre Internet INET, se reenvía a
Internet INET un mensaje HTTP (o HTTPS) que usa este procedimiento
GET y la respuesta transmitida desde Internet INET que corresponde
al mensaje HTTP (o HTTPS) que usa este procedimiento GET se devuelve
a este terminal T. Si el URL contenido en el HTTP (o HTTPS) que usa
el procedimiento GET es uno que indica su propia ubicación del
recurso, el servidor de pasarela GWS devuelve al terminal T este
recurso puesto en correlación con el mensaje HTTP (o HTTPS) que usa
este procedimiento GET.
El servidor IP W es el servidor que está
conectado a Internet INET y proporciona varios servicios a clientes
que usan la red WWW. Específicamente, cuando el servidor IP W recibe
una petición de mensaje HTTP (o HTTPS) que usa el procedimiento GET
a través de Internet INET, aquél devuelve el recurso (el archivo de
explotación en la presente forma de realización) que se identifica
por el URL contenido en el mensaje HTTP (o HTTPS) que usa este
procedimiento GET. En la presente forma de realización, el propósito
del servidor IP W es el de transmitir una aplicación Java y cada
comunicación entre el servidor IP W y el terminal T se realiza
mediante HTTP (y HTTPS) y AL. Igualmente, tanto el servidor IP W
como el terminal T soportan el modo de intercambio de datos de
conexión persistente/conexión no persistente de HTTP (y HTTPS) y SSL
de HTTPS.
A continuación se explicará la configuración del
terminal T. Sin embargo, en esta sección se explicará la
configuración de las unidades esenciales que se relacionan
directamente con la presente invención.
La Fig. 5 es un diagrama de bloques que muestra
la configuración de las unidades esenciales del terminal T y, como
se muestra en este diagrama, el terminal T tiene integradas una
unidad de transmisión-recepción 11 (por ejemplo,
equipada con una antena, una unidad de radio, un transmisor, un
receptor, etcétera) para realizar la radiocomunicación con la
estación base BS, una unidad de producción de sonido 12 (compuesta
de, por ejemplo, una fuente sonora, un altavoz, etcétera) para
producir sonido, una unidad de entrada 13 que va equipada con
teclados mediante los que se realizan operaciones de entrada tales
como entrada de números y entrada de letras, un visualizador por
cristal líquido 14 que contiene el campo de visualización de un
tamaño específico, y una unidad de control 15 que controla cada una
de estas unidades.
La unidad de control 15 tiene incorporadas una
UCP 151 que realiza cada operación de control, el navegador que es
ejecutado por la UCP 151, el soporte lógico para llevar a cabo la
máquina virtual Java, soporte lógico como el programa de control
del terminal T, información necesaria para la conexión al servidor
de pasarela GWS, una tabla de procesos PT1 que se describirá más
tarde, una ROM (memoria sólo de lectura) 152 en la que se almacena
una PT2, etcétera, una memoria flash 153 en la que se almacenan
datos recibidos, el contenido de instalación del usuario (por
ejemplo, la capacidad de adquisición automática del JAR), etcétera
para permitir que se usen de nuevo incluso después de reiniciar el
terminal, y una RAM 154 que está almacenada para prohibir que se
usen de nuevo datos recibidos después de reiniciar el terminal y que
ha de usarse como memoria de trabajo de la UCP 151.
Cuando se enciende el interruptor de
alimentación (no mostrado), la UCP 151 extrae por lectura y ejecuta
el programa de control almacenado en la ROM 152, después controla
la ROM 152, la memoria flash 153, la RAM 154, cada una de las
unidades 11 a 13 y el visualizador por cristal líquido 14 de
conformidad con los comandos del usuario introducidos desde el
programa de control y la unidad de entrada 13. Igualmente, la UCP
151, de conformidad con el comando introducido desde la unidad de
entrada 13, activa el navegador y es capaz de realizar la
comunicación sobre este navegador de conformidad con el comando
procedente de la unidad de entrada 13. Asimismo, la UCP 151 es
capaz de controlar el proceso de comunicación basándose en las
tablas de procesos PT1 y PT2 (remítase a la Fig. 6) almacenadas en
la ROM 152. Las operaciones específicas mediante esta función se
describirán más tarde.
Igualmente, la UCP 151 activa la máquina virtual
Java cuando ejecuta una aplicación Java almacenada en la memoria
flash 153 y ejecuta esta aplicación Java sobre esta máquina virtual
Java. Asimismo, la UCP 151 activa la máquina virtual Java y el
navegador cuando accede a una aplicación Java (miniaplicación Java)
almacenada en la RAM 154, y ejecuta esta aplicación Java sobre la
máquina virtual Java y el navegador.
La adquisición de datos por el terminal T se
realiza obteniendo, en primer lugar, datos HTML desde el URL
principal (la ubicación del recurso sobre la pasarela GWS a la que
debería acceder en primer lugar) almacenado en la ROM 152 mediante
la UCP 151, que accede al navegador almacenado en la ROM 152 y
ejecuta este navegador. Entonces, sobre la base de estos datos, el
visualizador por cristal líquido 15 solicita la orden de
visualización de la pantalla de diálogo y se obtienen datos cuando
el usuario maneja la unidad de entrada 13 tras la visualización de
esta pantalla de diálogo.
La Fig. 7 es un diagrama de flujo que muestra el
flujo del procedimiento que realiza el terminal T cuando se obtiene
una aplicación Java y, en lo sucesivo, haciendo referencia
principalmente a la Fig. 2, Fig. 3, Fig. 6 y Fig. 7, se explicarán
las operaciones del terminal T para obtener una aplicación Java
desde el servidor IP W de acuerdo con cada patrón de comunicación.
Sin embargo, en las explicaciones de más abajo, se omitirán en la
medida de lo posible las operaciones que se solapen. En el terminal
T, se supone que ya se ha activado el navegador. Igualmente, con
respecto a la forma de realización de adquisición de la aplicación
Java que es objeto de adquisición, ésta se puede almacenar tanto en
memoria fija como en memoria temporal, pero sólo se explicará el
caso en el que se almacena una aplicación Java en memoria fija tras
su adquisición, a fin de evitar la complicación de la
explicación.
Como se muestra en la Fig. 2, los modos de
comunicación del patrón de comunicación P1 son en modo normal en la
Etapa A y la Etapa B, y en SSL en la Etapa C.
En primer lugar, el terminal T obtiene la página
(denominada en lo sucesivo página de descarga) para obtener la
aplicación Java que es su objeto (Etapa S1). Específicamente, la UCP
151 del terminal T (remítase a la Fig. 5) controla la unidad de
transmisión-recepción 11 sobre la base del comando
del usuario introducido desde la unidad de entrada 13, y envía el
mensaje HTTP del servidor IP W por el procedimiento GET que es el
cumplimiento por la unidad de transmisión-recepción
11 de este comando (remítase a la Fig. 4). En respuesta, se
devuelven desde el servidor IP W datos HTML de la página de
descarga que es el objeto. Estos datos HTML son recibidos por la
unidad de transmisión-recepción 11 y transferidos a
la UCP 151 desde la unidad de transmisión-recepción
11. La UCP 151 almacena estos datos HTML en la RAM 154 y
proporciona la interfaz de usuario mediante la ulterior
interpretación y ejecución de estos datos. Como resultado, la
visualización mediante esta interfaz de usuario se muestra en el
visualizador por cristal líquido 14.
Entonces, el terminal T espera una entrada de un
comando por parte del usuario (Etapa S2) y el procedimiento de
adquisición finaliza si el comando introducido no es el comando para
obtener la aplicación Java objeto (Etapa S3). Específicamente, la
UCP 151 del terminal T identifica el contenido del comando por parte
del usuario basándose en el comando introducido desde la unidad de
entrada 13 y la interfaz de usuario actual, y el procedimiento de
adquisición finaliza si se introducen comandos que son diferentes
del contenido de obtención de la aplicación Java, tales como
obtener una página diferente, o se apaga el interruptor de
alimentación (no mostrado).
Por el contrario, si el comando introducido en
la Etapa S2 es la petición de obtención de la aplicación Java
objeto (Etapa S3), mediante datos HTML obtenidos en la Etapa S1, se
identifica el patrón de desplazamiento de la Etapa A a la Etapa B y
el modo de conexión (Etapa S4). Entonces se ejecuta el procedimiento
que corresponde al resultado identificado y se obtiene el ADF que
es el objeto (Etapa S5). En este caso, los modos de comunicación de
ambas Etapas A y B son normales; por consiguiente, de conformidad
con la tabla de procesos PT1 mostrada en la Fig. 6, se realiza el
procedimiento de obtención del ADF mediante comunicación normal.
Durante este procedimiento se visualiza, en el visualizador por
cristal líquido 14, "En curso de obtención". Como se muestra
en la tabla de procesos PT1 en la Fig. 6, el contenido del
procesamiento se determina sea cual sea en este caso el modo de
conexión. Igualmente, el modo de comunicación en la Etapa B no lo
determina el usuario, sino que se revela, en la Etapa S4, mediante
referencia al URL que está contenido en los datos HTML obtenidos en
la Etapa S1 para obtener el ADF. Específicamente, el principio del
URL visualiza el modo de comunicación para acceder al servidor Web
y, cuando el URL comienza por "http", el modo de comunicación
será "normal", puesto que se visualiza HTTP. Si el URL
comienza por "https", el modo de comunicación será "SSL",
puesto que se visualiza HTTPS.
Cuando se ha completado la adquisición del ADF y
si no está autorizada la adquisición automática del JAR (Etapa S6),
el terminal T procede a preguntar al usuario si debería obtenerse el
JAR (Etapa S7). Cuando se introduce el comando para continuar la
adquisición del JAR como respuesta a esta indagación (Etapa S8),
éste avanza hasta el procedimiento de la Etapa S9. Sin embargo,
cuando se introduce el comando para interrumpir la adquisición del
JAR, se realiza el procedimiento de interrupción (Etapa S12) y el
procedimiento retrocede a la Etapa S1. Igualmente, si está
autorizada la adquisición automática del JAR (Etapa S6), el
procedimiento avanza inmediatamente a la Etapa S9.
El terminal T está equipado con la función para
ajustar autorizar/denegar la adquisición automática del JAR. La UCP
151 establece/restablece el bit designado de la memoria flash 153
que es el bit destinado al ajuste de autorizar/denegar la
adquisición automática del JAR en respuesta al comando introducido
desde la unidad de entrada 13. Por consiguiente, mediante
referencia a este bit, la UCP 151 puede identificar el ajuste de
autorizar/denegar para la adquisición automática del JAR.
Igualmente, en el procedimiento de interrupción en la Etapa S12, la
UCP 151 interrumpe el procedimiento de obtención de la aplicación
Java, desecha el ADF que es el objeto y está almacenado en la
memoria flash 153 y aprovecha al máximo el volumen de memoria de la
memoria flash 153.
A continuación, se identifica el patrón de
desplazamiento de la Etapa B a la Etapa C y el modo de conexión, y
se realiza el procedimiento de adquisición del JAR sobre la base del
resultado identificado (Etapa S10, S11). En este caso, el modo de
comunicación de la Etapa B es normal y el modo de comunicación de
la Etapa C es SSL; por consiguiente, como se muestra en la tabla de
procesos PT2, el procedimiento será aquel en el que se obtiene el
JAR iniciando nuevamente la comunicación SSL. Durante este
procedimiento, se visualiza en el visualizador por cristal líquido
14, como mensaje de visualización, "Comienza comunicación SSL (en
curso de autenticación)". De este modo, se realiza
convenientemente el procedimiento que corresponde al patrón de
desplazamiento P1 en la Fig. 3. Como se muestra en la tabla de
procesos PT2 en la Fig. 6, el contenido del procedimiento se
determina sea cual sea en este caso el modo de conexión. Igualmente,
el modo de comunicación de la Etapa C se revelará en la Etapa S9
mediante referencia al URL que está contenido en el archivo ADF
contenido en la Etapa S5 para obtener el JAR. Cuando se obtiene el
ADF, si el URL comienza por "http", el modo de comunicación
será "normal". Si el URL comienza por "https", el modo de
comunicación será "SSL".
Como se muestra en la Fig. 2, los modos de
comunicación del patrón de comunicación P2 son normal en la Etapa
B y SSL en la Etapa A y C.
En primer lugar, en las Etapas 1 a 5, se realiza
el mismo procedimiento que en el patrón de comunicación P1. Sin
embargo, puesto que en la Etapa A, el modo de comunicación es SSL,
en la Etapa S1 se transmite al servidor IP W el HTTPS del
procedimiento GET. Igualmente, durante este procedimiento, el modo
de comunicación en la Etapa A es SSL y el modo de comunicación en
la Etapa B es normal; por consiguiente, como se muestra en la tabla
de procesos PT1 mostrada en la Fig. 6, la comunicación SSL se
detendrá y se realizará el procedimiento de obtención del ADF
mediante comunicación normal. Durante este procedimiento, en el
visualizador por cristal líquido 14 se visualiza, como mensaje de
visualización, "Finaliza página en SSL".
Igualmente, tras la Etapa S9, el modo de
comunicación en la Etapa B es normal y el modo de comunicación en
la Etapa C es SSL; por consiguiente, se realizará el mismo
procedimiento que en el patrón de comunicación P1. De este modo, se
realiza convenientemente el procedimiento que corresponde al patrón
de comunicación P2 en la Fig. 3.
Como se muestra en la Fig. 2, los modos de
comunicación del patrón de comunicación P3 son normal en las Etapa
A y C y SSL en la Etapa B.
En primer lugar, en las Etapas S1 a S5, se
realiza el mismo procedimiento que en el patrón de comunicación P1.
Sin embargo, durante este procedimiento, el modo de comunicación de
la Etapa A es normal y el modo de comunicación de la Etapa B es
SSL; por consiguiente, como se muestra en la tabla de procesos PT1
mostrada en la Fig. 6, el procedimiento será aquel destinado a
obtener el ADF iniciando nuevamente la comunicación SSL. Durante
este procedimiento, se visualiza en el visualizador por cristal
líquido 14, como mensaje de visualización, "Comienza comunicación
SSL (en curso de autenticación)". Incluso si el modo de conexión
es conexión persistente, en este procedimiento se inicia nuevamente
la comunicación SSL a pesar del modo de conexión, puesto que es
imposible conmutar al modo de comunicación SSL desde el modo de
comunicación normal sin finalizar el procedimiento.
A continuación, se identifica el patrón de
desplazamiento de la Etapa B a la Etapa C y el modo de conexión
(Etapa S9). Durante este procedimiento, el modo de comunicación en
la Etapa B es SSL y el modo de comunicación en la Etapa C es
normal; por consiguiente, el resultado determinado en la Etapa S10
será "sí" y el procedimiento retrocede a la Etapa S1 a través
del procedimiento de interrupción en la Etapa S12. En otras
palabras, la aplicación Java objeto no se obtiene y el
procedimiento que corresponde al patrón de comunicación P3 en la
Fig. 3 se realiza convenientemente.
Como se muestra en la Fig. 2, los modos de
comunicación del patrón de comunicación P4 son normal en la Etapa
C y SSL en las Etapas A y B.
En primer lugar, en las Etapas S1 a S5, se
realiza el mismo procedimiento que en el patrón de comunicación P1.
Sin embargo, puesto que en la Etapa A, el modo de comunicación es
SSL, en la Etapa S1 se transmite al servidor IP W el mensaje HTTPS
del procedimiento GET. Igualmente, en este procedimiento el modo de
comunicación en las Etapas A y B es SSL; por consiguiente, se
realiza el procedimiento de conformidad con el modo de conexión
desde la Etapa A a la Etapa B. En otras palabras, si el modo de
conexión es conexión no persistente, se realiza el procedimiento de
obtención del ADF iniciando una comunicación SSL. Si el modo de
conexión es conexión persistente, se realiza el procedimiento de
obtención del ADF continuando la comunicación SSL. En el primer
caso, se visualiza en el visualizador por cristal líquido 14
"Comienza comunicación SSL" y, en el último caso, no se
visualiza ningún mensaje en el visualizador por cristal líquido 14.
No se visualiza mensaje cuando el modo de conexión es conexión
persistente, dado que no se inicia un nuevo procedimiento de
comunicación SSL.
Igualmente, el modo de comunicación de la Etapa
B es SSL y el modo de comunicación de la Etapa C es normal, por lo
que se realiza el mismo procedimiento que en el patrón de
comunicación P3. De este modo, se realiza convenientemente el
procedimiento que corresponde al patrón de comunicación P4 en la
Fig. 3.
Como se muestra en la Fig. 2, los modos de
comunicación del patrón de comunicación P5 son normal en la Etapa
A y SSL en la Etapa B y C.
En primer lugar, en las Etapas S1 a S5, se
realiza el mismo procedimiento que en el patrón de comunicación P3.
Entonces, en el procedimiento ulterior a la etapa S9, puesto que el
modo de comunicación en la Etapa B y C es SSL, se realiza el
procedimiento de conformidad con el modo de conexión desde la Etapa
B a la Etapa C sobre la base del procedimiento de la tabla PT2
mostrada en la Fig. 6. En otras palabras, el procedimiento de
obtención del JAR se realiza iniciando una comunicación SSL cuando
el modo de conexión es conexión no persistente y el procedimiento
de obtención del JAR continuando la comunicación SSL se realiza
cuando el modo de conexión es conexión persistente. En el primer
caso, se visualiza en el visualizador por cristal líquido 14
"Comienza comunicación SSL" y, en el último caso, no se
visualiza ningún mensaje en el visualizador por cristal líquido 14.
De este modo, se realiza convenientemente el procedimiento que
corresponde al patrón de comunicación P5 en la Fig.
3.
3.
Como se muestra en la Fig. 2, el modo de
comunicación del patrón de comunicación P6 es SSL en las Etapas A,
B y C.
En primer lugar, en las Etapas S1 a S5, se
realiza el mismo procedimiento que en el patrón de comunicación P4.
Entonces, en el procedimiento ulterior a la Etapa S9, se realiza el
mismo procedimiento que en el patrón de comunicación P5. De este
modo, se realiza convenientemente el procedimiento que corresponde
al patrón de comunicación P6 en la Fig. 3.
Como se muestra en la Fig. 2, el modo de
comunicación del patrón de comunicación P7 es normal en las Etapas
A, B y C.
En primer lugar, en las Etapas S1 a S5, se
realiza el mismo procedimiento que en el patrón de comunicación P1.
Entonces, en el procedimiento de la Etapa S9 y a partir de la misma,
se realiza el procedimiento de obtención del JAR continuando la
comunicación normal de conformidad con la tabla de procesos PT2
mostrada en la Fig. 6, puesto que el modo de comunicación de las
Etapas B y C es normal. Durante este procedimiento, en el
visualizador por cristal líquido 14 se visualiza, como mensaje
visualizado, "En curso de obtención". De este modo, se realiza
convenientemente el procedimiento que corresponde al patrón de
comunicación P7 en la Fig. 3.
Como se muestra en la Fig. 2, los modos de
comunicación del patrón de comunicación P8 son SSL en la Etapa A y
normal en las Etapas B y C.
En primer lugar, en las Etapas S1 a S5, se
realiza el mismo patrón de comunicación que en P2. Entonces, en el
procedimiento de la Etapa S9 y a partir de la misma, se realiza el
mismo patrón de comunicación que en P7. De este modo, se realiza
convenientemente el procedimiento que corresponde al patrón de
comunicación P8 en la Fig. 3.
Como se ha explicado anteriormente, de acuerdo
con la presente forma de realización, el procedimiento que
corresponde a cada patrón de comunicación mostrado en la Fig. 2 y
la Fig. 3 se realiza convenientemente, y el ADF se obtiene
mediante comunicación en el modo de comunicación cifrada. Luego se
puede suprimir el patrón de adquirir una aplicación Java obteniendo
el JAR mediante comunicación en el patrón de comunicación
normal.
Por lo tanto, cuando el usuario de terminal
ejecuta la aplicación Java obtenida y la aplicación Java obtenida
realiza una comunicación usando la red, se puede impedir la
transmisión de información personal en lenguaje claro por la
aplicación Java contra la voluntad del usuario del terminal.
Igualmente, como en la forma de realización
mencionada anteriormente, un teléfono móvil es efectivo como
terminal. La aptitud para el tratamiento de datos de un teléfono
móvil es inferior comparado con un terminal tal como un
miniportátil, y el ancho de banda de la vía de comunicación es
estrecho en comparación con la comunicación por cable; por
consiguiente, la posibilidad de que el funcionamiento del terminal
se vea restringido durante un período de tiempo más prolongado de
lo que el usuario prevé es superior en las técnicas anteriores.
Todavía en la presente forma de realización, tal restricción se
evita autorizando que se obtenga una aplicación Java dividiéndola
en ADF y JAR y autorizando al usuario que consultó la información
sobre propiedades acerca del ADF a determinar si obtener o no el
JAR.
En la forma de realización mencionada
anteriormente, se mostró el ejemplo de autorizar que se use una
aplicación Java sin obtener de nuevo la aplicación Java incluso
después de haber reiniciado el terminal, almacenando la aplicación
Java obtenida en memoria fija; sin embargo, es factible también
obtener de nuevo la aplicación Java después encender el terminal,
almacenando la aplicación Java obtenida en memoria temporal.
Igualmente, en la forma de realización
mencionada anteriormente, una aplicación Java es sólo un ejemplo de
datos que se pueden obtener, pero también se pueden obtener otros
programas o datos. En otras palabras, la presente invención se
puede aplicar cuando se obtiene de Internet un tipo de datos que se
dividen en dos unidades.
Igualmente, en la forma de realización
mencionada anteriormente, se autorizan los patrones de comunicación
P1 y P2 de la Fig. 2, pero estos pueden prohibirse. En otras
palabras, es posible prohibir un patrón de adquisición en el que el
sistema de comunicación de la Etapa B y el sistema de comunicación
de la Etapa C difieren.
Igualmente, en la forma de realización
mencionada anteriormente, un teléfono móvil es un ejemplo de
terminal, pero en la presente invención se pueden usar otros
terminales que puedan realizar una comunicación a través de una red
mediante cable o el aire.
Igualmente, en la forma de realización
mencionada anteriormente, los patrones de comunicación P3 y P4 en la
Fig. 2 no están autorizados sin excepción, pero tales limitaciones
no se aplican a la presente invención. Por ejemplo, preguntando al
usuario si la adquisición es posible cuando los patrones de
comunicación son P3 y P4 en la Fig. 2, se puede recibir y almacenar
el JAR cuando el usuario lo apruebe. O en caso contrario,
autorizando que se almacene en ADF un tipo de aplicación Java, se
puede recibir y almacenar el JAR incluso si los patrones de
comunicación son P3 y P4 en la Fig. 2 si la aplicación Java es del
tipo que no realiza comunicación.
Igualmente, en la forma de realización
mencionada anteriormente, se muestran ejemplos de reenvío de datos
usando HTTP (y HTTPS) y AL, pero en la presente invención se puede
adoptar cualquier protocolo que pueda lograr una comunicación
cifrada. Éste puede ser evidentemente cualquier protocolo de
comunicación que corresponda a conexión persistente y conexión no
persistente. Éste también puede ser un protocolo de comunicación que
no corresponda a estos.
Igualmente, en la forma de realización
mencionada anteriormente, se muestra un ejemplo de conversión de un
protocolo de comunicación a nivel de un servidor de pasarela GWS,
pero esto sólo es un ejemplo. Por ejemplo, autorizando que se
procesen HTTP (y HTTPS) y SSL a nivel del terminal, la comunicación
se puede llevar a cabo directamente entre el terminal y el servidor
IP, o se puede llevar a cabo después de pasar por una pluralidad de
conversiones.
Claims (7)
1. Un procedimiento para obtener una
aplicación en un terminal, que comprende:
una primera etapa de recepción (S5) en un
terminal (T) que puede comunicarse a través de una red (MPN) para
recibir en un modo de comunicación normal o seguro, a través de
dicha red, una primera unidad de datos (ADF) en la que está
almacenada información sobre propiedades acerca de una
aplicación;
una etapa (S9) de identificación del modo de
comunicación para recibir una segunda unidad de datos (JAR), en la
que está almacenada una entidad de dicha aplicación, como normal o
seguro;
una etapa de determinación (S10) destinada a
determinar si la seguridad del modo de comunicación identificado
usado para recibir dicha segunda unidad de datos es inferior a la
seguridad del modo de comunicación usado en dicha primera etapa de
recepción (S5); y
una etapa adicional en la que dicha segunda
unidad de datos (JAR) se recibe desde dicho lado de la red (S11)
cuando un resultado determinado en dicha etapa de determinación es
"no", y dicha segunda unidad de datos no se recibe desde dicho
lado de la red cuando es "sí" (S12).
2. Un procedimiento según la reivindicación
1,
en el que un modo de comunicación seguro para
recibir dicha primera unidad de datos (ADF) es un modo que usa
comunicación cifrada, y la adquisición de dichos datos se determina
como "no" cuando un modo de comunicación para recibir dicha
segunda unidad de datos es un modo que no usa cifrado en dicha etapa
de determinación (S10).
3. Un procedimiento según la reivindicación
1,
en el que la adquisición de dichos datos se
determina como "no" cuando un modo de comunicación que se usó
en dicha primera etapa de recepción y un modo de comunicación usado
para recibir dicha segunda unidad de datos difieren en dicha etapa
de determinación (S10).
4. Un procedimiento según la reivindicación
1,
en el que dichos datos son un programa
informático que se puede ejecutar en dicho terminal (T).
5. Un procedimiento según la reivindicación
4,
en el que dicho programa informático es un
programa informático que realiza una comunicación.
6. Un procedimiento según la reivindicación
1,
en el que dicho terminal (T) es un teléfono
móvil.
7. Un terminal (T) que comprende:
un primer medio de recepción para recibir en
modo de comunicación normal o seguro una primera unidad de datos
(ADF) en la que está almacenada información sobre propiedades acerca
de una aplicación, desde un lado de la red;
medios para identificar el modo de comunicación
a fin de recibir una segunda unidad de datos (JAR), en la que está
almacenada una entidad de dicha aplicación, como normal o
seguro;
un medio de determinación para determinar si la
adquisición de dichos datos es factible basándose en el hecho de
que la seguridad del modo de comunicación identificado para recibir
dicha segunda unidad de datos (JAR) sea inferior a la seguridad del
modo de comunicación usado para recibir dicha primera unidad de
datos (ADF) desde dicho lado de la red; y
un medio de recepción adicional que recibe dicha
segunda unidad de datos desde dicho lado de la red cuando un
resultado determinado por dicho medio de determinación es "no",
y no recibe dicha segunda unidad de datos desde dicho lado de la
red cuando es "sí".
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000358046A JP3692290B2 (ja) | 2000-11-24 | 2000-11-24 | データ取得方法および端末 |
| JP2000-358046 | 2000-11-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2280433T3 true ES2280433T3 (es) | 2007-09-16 |
Family
ID=18830014
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES01997742T Expired - Lifetime ES2280433T3 (es) | 2000-11-24 | 2001-11-21 | Procedimiento y terminal para la adquisicion segura de aplicaciones. |
Country Status (17)
| Country | Link |
|---|---|
| US (1) | US7174333B2 (es) |
| EP (1) | EP1338971B1 (es) |
| JP (1) | JP3692290B2 (es) |
| KR (1) | KR100436687B1 (es) |
| CN (1) | CN1198432C (es) |
| AT (1) | ATE353150T1 (es) |
| AU (2) | AU2002224062B8 (es) |
| BR (1) | BR0107377A (es) |
| CA (1) | CA2394294C (es) |
| DE (1) | DE60126421T2 (es) |
| ES (1) | ES2280433T3 (es) |
| HK (1) | HK1056024A1 (es) |
| NO (1) | NO324486B1 (es) |
| NZ (1) | NZ519408A (es) |
| PL (1) | PL356885A1 (es) |
| TW (1) | TWI222817B (es) |
| WO (1) | WO2002042918A1 (es) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7694297B2 (en) * | 2001-12-28 | 2010-04-06 | Cisco Technology, Inc. | System and method for applet caching |
| JP4222774B2 (ja) * | 2002-05-20 | 2009-02-12 | 株式会社エヌ・ティ・ティ・ドコモ | 携帯端末およびプログラムの起動方法 |
| JP4323190B2 (ja) * | 2003-03-07 | 2009-09-02 | 株式会社エヌ・ティ・ティ・ドコモ | 通信端末 |
| JP4423259B2 (ja) * | 2003-05-15 | 2010-03-03 | ソフトバンクモバイル株式会社 | 連係動作方法及び移動通信端末装置 |
| US7694022B2 (en) * | 2004-02-24 | 2010-04-06 | Microsoft Corporation | Method and system for filtering communications to prevent exploitation of a software vulnerability |
| FR2887097A1 (fr) * | 2005-06-14 | 2006-12-15 | France Telecom | Procede de protection d'un code-source en langage semi-interprete |
| JP4754922B2 (ja) | 2005-09-30 | 2011-08-24 | 富士通株式会社 | ワーム感染装置の検出装置 |
| JP4916825B2 (ja) * | 2006-09-08 | 2012-04-18 | 株式会社エヌ・ティ・ティ・ドコモ | 通信端末装置及びそれを用いたデータ取得方法 |
| US8127020B2 (en) * | 2008-08-28 | 2012-02-28 | Red Hat, Inc. | HTTP standby connection |
| US8762876B2 (en) * | 2012-06-21 | 2014-06-24 | Google Inc. | Secure data entry via a virtual keyboard |
| CN106257879B (zh) * | 2015-06-16 | 2020-02-14 | 阿里巴巴集团控股有限公司 | 一种下载应用的方法和装置 |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH06284148A (ja) | 1993-03-30 | 1994-10-07 | Hitachi Ltd | 動画通信制御方法及び通信制御装置 |
| JPH09102857A (ja) | 1995-10-04 | 1997-04-15 | Canon Inc | ファクシミリ装置 |
| US9197599B1 (en) * | 1997-09-26 | 2015-11-24 | Verizon Patent And Licensing Inc. | Integrated business system for web based telecommunications management |
| US6810405B1 (en) * | 1998-08-18 | 2004-10-26 | Starfish Software, Inc. | System and methods for synchronizing data between multiple datasets |
| US6418472B1 (en) * | 1999-01-19 | 2002-07-09 | Intel Corporation | System and method for using internet based caller ID for controlling access to an object stored in a computer |
| JP2000285048A (ja) | 1999-03-31 | 2000-10-13 | Toshiba Corp | 情報ダウンロード機能付きサーバ及び端末並びに記録媒体 |
| JP4130272B2 (ja) | 1999-04-21 | 2008-08-06 | 大日本印刷株式会社 | 送信装置とその方法、受信装置とその方法および通信システム |
| US6772159B1 (en) * | 2000-02-24 | 2004-08-03 | International Business Machines Corporation | System and method for disconnected database access by heterogeneous clients |
| US6766353B1 (en) * | 2000-07-11 | 2004-07-20 | Motorola, Inc. | Method for authenticating a JAVA archive (JAR) for portable devices |
| US6823461B2 (en) * | 2002-06-27 | 2004-11-23 | Nokia Corporation | Method and system for securely transferring context updates towards a mobile node in a wireless network |
-
2000
- 2000-11-24 JP JP2000358046A patent/JP3692290B2/ja not_active Expired - Fee Related
-
2001
- 2001-11-21 DE DE60126421T patent/DE60126421T2/de not_active Expired - Lifetime
- 2001-11-21 NZ NZ519408A patent/NZ519408A/en not_active IP Right Cessation
- 2001-11-21 CN CNB01804056XA patent/CN1198432C/zh not_active Expired - Fee Related
- 2001-11-21 BR BR0107377-0A patent/BR0107377A/pt not_active Application Discontinuation
- 2001-11-21 AT AT01997742T patent/ATE353150T1/de not_active IP Right Cessation
- 2001-11-21 EP EP01997742A patent/EP1338971B1/en not_active Expired - Lifetime
- 2001-11-21 AU AU2002224062A patent/AU2002224062B8/en not_active Ceased
- 2001-11-21 AU AU2406202A patent/AU2406202A/xx active Pending
- 2001-11-21 ES ES01997742T patent/ES2280433T3/es not_active Expired - Lifetime
- 2001-11-21 US US10/204,363 patent/US7174333B2/en not_active Expired - Lifetime
- 2001-11-21 PL PL01356885A patent/PL356885A1/xx not_active Application Discontinuation
- 2001-11-21 CA CA002394294A patent/CA2394294C/en not_active Expired - Lifetime
- 2001-11-21 WO PCT/JP2001/010170 patent/WO2002042918A1/ja active IP Right Grant
- 2001-11-21 KR KR10-2002-7009453A patent/KR100436687B1/ko active IP Right Grant
- 2001-11-23 TW TW090129077A patent/TWI222817B/zh not_active IP Right Cessation
-
2002
- 2002-07-22 NO NO20023491A patent/NO324486B1/no not_active IP Right Cessation
-
2003
- 2003-11-06 HK HK03108031A patent/HK1056024A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| AU2002224062B2 (en) | 2005-06-23 |
| HK1056024A1 (en) | 2004-01-30 |
| AU2002224062B8 (en) | 2005-07-21 |
| ATE353150T1 (de) | 2007-02-15 |
| DE60126421D1 (de) | 2007-03-22 |
| KR100436687B1 (ko) | 2004-06-18 |
| BR0107377A (pt) | 2002-09-24 |
| PL356885A1 (en) | 2004-07-12 |
| EP1338971A4 (en) | 2005-09-28 |
| US20030097373A1 (en) | 2003-05-22 |
| NO20023491D0 (no) | 2002-07-22 |
| JP3692290B2 (ja) | 2005-09-07 |
| WO2002042918A1 (fr) | 2002-05-30 |
| CN1395704A (zh) | 2003-02-05 |
| EP1338971A1 (en) | 2003-08-27 |
| AU2406202A (en) | 2002-06-03 |
| NZ519408A (en) | 2004-05-28 |
| CN1198432C (zh) | 2005-04-20 |
| CA2394294A1 (en) | 2002-05-30 |
| US7174333B2 (en) | 2007-02-06 |
| TWI222817B (en) | 2004-10-21 |
| NO324486B1 (no) | 2007-10-29 |
| CA2394294C (en) | 2009-10-13 |
| NO20023491L (no) | 2002-09-19 |
| EP1338971B1 (en) | 2007-01-31 |
| JP2002163111A (ja) | 2002-06-07 |
| KR20020079798A (ko) | 2002-10-19 |
| DE60126421T2 (de) | 2007-10-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11736968B2 (en) | Capillary device charging | |
| US7454233B2 (en) | Communications of UICC in mobile devices using internet protocols | |
| EP2661864B1 (en) | System and method for communicating data between an application server and an m2m device | |
| KR101514647B1 (ko) | 이종 무선 네트워크간의 데이터 트래픽을 분산하는 장치 | |
| EP0973350A2 (en) | Method and apparatus for providing access control to local services of mobile devices | |
| JP5321708B2 (ja) | 移動式無線通信装置及びその接続状態の管理方法 | |
| ES2280433T3 (es) | Procedimiento y terminal para la adquisicion segura de aplicaciones. | |
| KR20010035348A (ko) | Ｓｍｓ와 무선 인터넷을 이용한 데이터 수신 방법 및시스템 | |
| US8948101B2 (en) | Client-server communications in mobile radio communications device | |
| US7698747B2 (en) | Applet download in a communication system | |
| WO2001099360A1 (en) | A method of communication | |
| KR101809317B1 (ko) | 데이터 액세스 방법 및 장치 | |
| CN108966319B (zh) | 数据包传输控制方法、移动终端以及装置 | |
| JP3929969B2 (ja) | 通信システム、サーバ、端末装置、通信方法、プログラムおよび記憶媒体 | |
| ES2247268T3 (es) | Metodo para asegurar la descarga de datos activos a un terminal. | |
| US8675539B1 (en) | Management-packet communication of GPS satellite positions | |
| US20100070635A1 (en) | Methods for setting up an ip connection using a shared key and related electronic devices and computer program products | |
| CN110913381A (zh) | 一种单向信息通知的安全传输系统及安全传输方法 | |
| CN115442784A (zh) | 蓝牙设备的通信方法、装置及设备 |