ES2334367T3 - Conversion de protocolo "protocolo independiente de soporte" (bip) - tcp/ip para la comunicacion entre un modulo sim y un terminal. - Google Patents

Conversion de protocolo "protocolo independiente de soporte" (bip) - tcp/ip para la comunicacion entre un modulo sim y un terminal. Download PDF

Info

Publication number
ES2334367T3
ES2334367T3 ES05750686T ES05750686T ES2334367T3 ES 2334367 T3 ES2334367 T3 ES 2334367T3 ES 05750686 T ES05750686 T ES 05750686T ES 05750686 T ES05750686 T ES 05750686T ES 2334367 T3 ES2334367 T3 ES 2334367T3
Authority
ES
Spain
Prior art keywords
electronic device
http
tcp
server
protocol
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.)
Active
Application number
ES05750686T
Other languages
English (en)
Inventor
Ilan Mahalal
Nicolas Chaumartin
Jorge Abellan Sevilla
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemalto SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Gemalto SA filed Critical Gemalto SA
Application granted granted Critical
Publication of ES2334367T3 publication Critical patent/ES2334367T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion
    • H04L69/085—Protocols for interworking; Protocol conversion specially adapted for interworking of IP-based networks with other networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

Método de ofrecer los servicios de un servidor HTTP o HTTPS, el servidor siendo implementado por o ejecutado en un primer dispositivo electrónico portátil (1), a una aplicación (23) ejecutada en un segundo dispositivo electrónico, en dónde el primer dispositivo electrónico intercambia mensajes HTTP con el segundo dispositivo electrónico a través de un canal de comunicación entre el primer y segundo dispositivo electrónico según el Protocolo Independiente del Portador, caracterizado en que el segundo dispositivo electrónico (2) es un terminal lector que aloja el dispositivo portátil (1).

Description

Conversión de protocolo "protocolo independiente de soporte" (BIP) - TCP/Ip para la comunicación entre un módulo SIM y un terminal.
En términos generales, el presente invento trata del intercambio de datos entre un primer dispositivo electrónico y un segundo dispositivo electrónico, y especialmente del intercambio de mensajes HTTP (Protocolo de Transferencia de Hipertexto) entre un servidor web implementado por o ejecutado en el primer dispositivo electrónico y un navegador web que opera en el segundo dispositivo electrónico.
De conformidad con el invento, el primer dispositivo electrónico es portátil y el segundo dispositivo electrónico es externo al dispositivo portátil.
En la aplicación principal del invento, el primer dispositivo electrónico o dispositivo portátil será una tarjeta de circuito integrado o tarjeta inteligente, en concreto la compatible con ISO 7816-4, que incluye plataformas (U) SIM ((U) Módulo de Identificación del Suscriptor), UICC, R-UIM (Módulo de Identidad de Usuario Desmontable) y WIM (Módulo de Identidad Inalámbrica); el segundo dispositivo electrónico será un terminal lector de tarjeta inteligente en forma de teléfono móvil. A lo largo de esta descripción, utilizaremos el ejemplo de una tarjeta inteligente y un terminal. No obstante, el invento puede aplicarse a otros casos en los que el dispositivo portátil sea una tarjeta de memoria
Multimedia Card o el dispositivo externo sea un PDA (Asistente Personal Digital) o un PC (Ordenador Personal).
Los servidores web como HTTP o HHTPS pueden estar integrados en dispositivos portátiles al igual que las tarjetas inteligentes. Los recursos incluidos en las tarjetas inteligentes pueden ser accedidos por el HHTP a través de una aplicación ejecutada en el terminal donde está conectada la tarjeta inteligente. Además, debido a que el HTTP está diseñado para transmitir páginas de hipertexto, para aplicaciones de la tarjeta inteligente, puede ser utilizado un navegador web en el terminal como una interfaz de usuario.
El nivel de aplicación del protocolo de Internet HTTP está diseñado para ser utilizado sobre TCP/IP (Protocolo de Control de Transmisión/Protocolo de Internet) y los navegadores estándares utilizan TCP/IP para transmitir mensajes HTTP. Sin embargo, para la transmisión de datos entre una tarjeta inteligente y un terminal, se utilizan otros protocolos diferentes al TCP en el nivel de capa transporte. Específicamente, las actuales soluciones de tarjeta inteligente que alojan un servidor web utilizan protocolos patentados para la transmisión de mensajes HHTP.
Documento:
BADRA M ET AL: "Toward SSL integration in SIM smartcards" CONFERENCIA SOBRE CONEXIÓN DE REDES Y COMUNICACIONES INALÁMBRICAS, 2004. WCNC. 2004 IEEE ATLANTA, GA, USA 21-25 MARZO 2004, PISCATAWAY, NJ, USA, IEEE, vol. 2, 21 marzo 2004, páginas 889-894, ISBN: 0-7803-8344-3, revela el uso de un canal BIP para la comunicación entre una tarjeta inteligente y un servidor remoto.
Por lo tanto, el objetivo del invento es proporcionar mecanismos para el intercambio de mensajes HTTP entre un servidor web integrado en un dispositivo portátil, como una tarjeta inteligente, y una aplicación ejecutada en un dispositivo externo, como un navegador web ejecutado en un terminal lector de tarjeta inteligente, por medio de la utilización de capas transporte existentes en la tarjeta inteligente.
Además, el invento tiene como objeto permitir que la aplicación ejecutada en el dispositivo externo utilice TCP/IP para el intercambio de menajes HTTP como si hubiera una conexión TCP/IP entre esta aplicación y el servidor web integrado en el dispositivo portátil.
El objetivo se consigue a través de los métodos y dispositivos definidos en las afirmaciones independientes 1 y 17. Las nuevas formas de realización preferentes están definidas en las afirmaciones dependientes.
De conformidad con la realización preferente del invento, se consigue el objetivo mediante un método consistente en ofrecer los servicios de los servidores HTTP o HTPPS, siendo el servidor implementado por o ejecutado en el primer dispositivo electrónico, a un segundo dispositivo electrónico en dónde el primer dispositivo electrónico intercambia mensajes HTTP con el segundo dispositivo electrónico a través de un canal de comunicación entre el primer y segundo dispositivo electrónico, según el Protocolo Independiente del Portador.
La ventaja consiste en que los mecanismos y comandos estándar definidos por entidades de estandarización como el 3GPP (Proyecto de Asociación para la Tercera Generación) y el ETSI (Instituto Europeo de Normas de Telecomunicaciones), pueden utilizarse para intercambiar mensajes HTTP entre el primer y el segundo dispositivo electrónico.
Según una realización preferente adicional del invento, los mensajes HTTP transmitidos desde el primer dispositivo electrónico al segundo a través del canal de comunicación, serán asimismo transmitidos dentro del segundo dispositivo electrónico a una aplicación ejecutada en el segundo dispositivo electrónico a través de TCP/IP, y los mensajes HTTP recibidos por el primer dispositivo electrónico desde el segundo dispositivo electrónico han sido comunicados dentro del segundo dispositivo electrónico a través de TCP/IP.
Esto tiene la ventaja de que la aplicación de intercambio de mensajes HTTP con el servidor puede utilizar TCP/IP, lo cual es un protocolo estándar para el intercambio de mensajes HTTP.
Según una realización preferente adicional del invento, la aplicación ejecutada en el segundo dispositivo electrónico es un navegador web y el servidor HTPP o HTTPS transfiere páginas HTML, xHTML, cHTML o WML a este navegador web.
Por lo tanto, las páginas de hipertexto se pueden utilizar para crear la interfaz de usuario de una aplicación ejecutada en el primer dispositivo electrónico.
Según una realización preferente adicional del invento, se utiliza la orden de DECLARE SERVICE (declaración de servicio) para notificar al segundo dispositivo electrónico acerca de los servicios del servidor HTTP o HTTPS ofrecidos por el primer dispositivo electrónico.
Esto permite al primer dispositivo electrónico descargar en la base de datos del segundo dispositivo electrónico la información proporcionada por el primer dispositivo electrónico a los servicio del servidor web.
Según una realización preferente adicional del invento, el usuario puede ser autenticado con un encabezado HTTP estándar de WWW-Authenticate enviando atributos de PIN-Type y/o PIN-Value.
Esto permite identificar al usuario únicamente usando mensajes HTTP descifrables por un navegador web, convirtiendo en totalmente innecesario el uso de otras unidades como APDU (Unidad de Datos del Protocolo de Aplicación).
En una realización preferente del invento, el primer dispositivo electrónico es una tarjeta inteligente.
En otra realización preferente del invento, el primer dispositivo electrónico es una tarjeta de memoria Multimedia Card.
Una realización preferente del invento es un programa informático que incluye elementos de programas informáticos de codificación para hacer que el primer dispositivo electrónico ejecute el método descrito anteriormente.
Otra realización preferente del invento es un dispositivo electrónico el cual implementa o ejecuta un servidor HTTP o HTTPS y efectúa el método descrito anteriormente.
Una realización preferente adicional del invento consiste en método por el cual se permite que una aplicación ejecutada en un segundo dispositivo electrónico utilice el protocolo TCP/IP para intercambiar mensajes con un servidor HTTP o HTTPS implementado o ejecutado en un primer dispositivo electrónico, a través de un canal de comunicación según el Protocolo Independiente del Portador para el intercambio de mensajes entre el segundo y primer dispositivo electrónico. En el segundo dispositivo electrónico (2), el canal de comunicación está gestionado por un gateway (pasarela) que convierte los protocolos del Protocolo Independiente del Portador -TCP/IP en mensajes recibidos por el servidor HTTP o HTTPS, así como la conversión de TCP/IP-Protocolo Independiente del Portador en mensajes enviados al servidor HTTP o HTTPS.
La aplicación ejecutada en el segundo dispositivo electrónico podrá establecer una conexión TCP/IP con el gateway como si la conexión estuviera establecida directamente con el servidor HTTP, lo que hace el uso del Protocolo Independiente del Portador transparente a la aplicación.
Según una realización preferente adicional del invento, se asignan una dirección IP interna y un nombre de dominio interno al gateway y el nombre de dominio interno es mapeado a la dirección IP interna, y el nombre de dominio interno es utilizado en Identificadores de Recursos Uniformes para indicar que el identificador de Recurso Uniforme identifica un recurso en el primer dispositivo electrónico.
Cuando la aplicación ejecutada en el segundo dispositivo electrónico intenta acceder al recurso identificado por el Localizador de Recurso Uniforme, su solicitud HTTP a través del TCP/IP será dirigido al gateway donde podrá ser remitido al servidor de tarjeta inteligente.
Según una realización preferente adicional del invento, el primer dispositivo electrónico es una tarjeta inteligente y el identificador de Recurso Uniforme constituye información para acceder a las aplicaciones estándar de la tarjeta inteligente como las aplicaciones (U) SIM y WIM.
De esta manera, la aplicación ejecutada en el segundo dispositivo electrónico puede ser utilizada para visualizar una interfaz de usuario de hipertexto de la aplicación de tarjeta inteligente.
Según una realización preferente adicional del invento, se envía una orden al primer dispositivo electrónico para abrir un canal de comunicación cuando la aplicación ejecutada en el segundo dispositivo electrónico abre un socket TCP/IP al gateway.
\newpage
El canal de comunicación entre el gateway y el servidor HTTP puede ser utilizado como una continuación de una conexión TCP/IP entre la aplicación ejecutada en el segundo dispositivo electrónico y el gateway.
Según una realización preferente adicional del invento, el socket TCP/IP es mapeado al canal abierto.
Cada canal de comunicación puede ser utilizado como un canal dedicado para cada conexión de socket, simplificando el reenvío de mensajes HTTP en el gateway.
Según una realización preferente adicional del invento, el segundo dispositivo electrónico es el navegador web.
Un navegador web es una aplicación estándar para visualizar páginas de hipertexto y acceder a un servidor web mediante HTTP.
Según una realización preferente adicional del invento, el segundo dispositivo electrónico es un teléfono móvil.
Según una realización preferente adicional del invento, el segundo dispositivo electrónico es un PDA.
Según una realización preferente adicional del invento, el segundo dispositivo electrónico es un PC.
Una realización preferente del invento es un programa informático que incluye elementos de programas informáticos de codificación para hacer que el primer dispositivo electrónico ejecute el método descrito anteriormente.
Otra realización preferente del invento es un dispositivo que ejecuta una aplicación y realiza el método descrito anteriormente.
Todo lo anteriormente descrito y demás objetos, aspectos y ventajas del invento pueden entenderse mejor a partir de las siguientes descripciones detalladas de las realizaciones preferentes del invento efectuadas en relación con los dibujos, en los que:
La Figura 1 es un diagrama esquemático que muestra cómo se transmite la información entre una tarjeta inteligente y un servidor remoto utilizando el Protocolo Independiente del Portador y el TCP/IP.
La Figura 2 es un diagrama esquemático que muestra una realización preferente del invento, particularmente los componentes utilizados para la transmisión de datos en el dispositivo externo.
La Figura 3 es una diagrama esquemático que ilustra la forma en que se intercambia la información entre un servidor web de tarjeta inteligente y un cliente web utilizando una tabla de enrutamiento.
La Figura 4 es un diagrama que muestra la secuencia de comandos para la declaración de servicio entre la tarjeta inteligente y el terminal.
La Figura 5 es un diagrama que muestra la secuencia de comandos para abrir un canal de comunicación entre la tarjeta inteligente y el terminal.
La figura 6 es un diagrama que muestra la secuencia de comandos para enviar información desde el navegador web a la tarjeta inteligente.
Según el invento, los comandos proactivos de la tarjeta UICC según el Protocolo Independiente del Portador de la forma definida en ETSI TS 102 233 (e.g. sección 4.11 y sección 6), los siguientes llamados "comandos BIP" son utilizados para transmitir mensajes HTTP entre el primer dispositivo electrónico y el dispositivo externo. El Protocolo Independiente del Portador consiste en la serie de comandos (ABRIR CANAL, CERRAR CANAL, ENVIAR DATOS, RECIBIR DATOS, y OBTENER ESTADO DEL CANAL) y eventos (Datos disponibles, Estado del canal) lo cual permite que una tarjeta inteligente establezca un canal de comunicación con un terminal, y a través de dicho terminal con un servidor remoto o dispositivo remoto en la red. Se utilizan niveles de protocolo más bajos para intercambiar información entre la tarjeta inteligente y el terminal en el canal de comunicación. Para hacer el uso de Protocolo Independiente del Portador transparente al servidor remoto o dispositivo remoto, es posible utilizar diferentes protocolos entre estos y el terminal.
La figura 1 muestra un ejemplo de una comunicación establecida entre la tarjeta inteligente 1 y el servidor remoto 13 a través de un terminal 2, utilizando TCP/IP entre el terminal y el servidor remoto. En el paso 100, el canal de comunicación se establece entre la tarjeta inteligente 1 y el terminal 2. En el paso 101, el terminal 2 recibe información de la tarjeta inteligente 1 a través del comando de ENVIAR, el cual el terminal introduce en paquetes TCP en el paso 102 y los envía al servidor remoto 13 a través de una conexión TCP/IP previamente establecida. En el paso 103, el terminal 2 recibe información del servidor remoto 13 a través de la conexión TCP/IP, separa la información de los paquetes TCP y la envía a la tarjeta 1 en el paso 104, donde la tarjeta 1 es avisada por el terminal 2 utilizando un evento disponible de Datos, con lo cual la tarjeta 1 obtiene la información del terminal 2 enviando un comando de RECIBIR.
Sin embargo, mientras que el Protocolo Independiente del Portador ha sido diseñado para facilitar la comunicación entre una tarjeta inteligente y un servidor remoto o dispositivo remoto externo al terminal, los comandos BIP también pueden ser utilizados para la comunicación entre una tarjeta inteligente y una aplicación ejecutada localmente en el terminal lector. La Figura 2 muestra cómo se transmiten, según el invento, los mensajes HTTP entre un servidor operativo, a un primer dispositivo electrónico 1, como un servidor web operativo en una tarjeta inteligente, y una aplicación 23 ejecutada por un dispositivo externo 2, como un navegador web en un terminal lector de tarjeta inteligente. Este navegador puede ser, por ejemplo, un navegador de visualización de páginas HTML (Lenguaje de Marcas de Hipertexto), cHTML (HTML extensible), cHTML (HTML compacto) o WML (Lenguaje de Marcas
Inalámbrico).
Los mensajes no se transmiten entre el servidor y el navegador 23 directamente a través de la conexión TCP/IP, en cambio se transmiten a través del gateway 24 localizado en el terminal 2. Los mensajes HTTP son transmitidos entre el servidor y el gateway 24 a través de canales de comunicación utilizando comandos BIP. Los mensajes entre el gateway 24 y el navegador 23 son transmitidos a través de los sockets TCP/IP.
En otras palabras, en lugar de establecer una conexión TCP/IP con el servidor, el navegador establece esta conexión con el gateway 24. El gateway 24 reenvía los mensajes HTTP recibidos a través de la conexión TCP/IP desde el navegador 23 hasta el servidor a través del canal de comunicación. En otra dirección, reenvía los mensajes HTTP recibidos del servidor a través del canal de comunicación al navegador 23 a través de la conexión TCP/IP.
En las solicitudes HTTP, los Identificadores de Recursos Uniformes (URI) se usan para identificar un recurso solicitado. Véase especificación del Protocolo de Transmisión de Hipertexto versión 1.1 en RFC 2616, sección 5. Para acceder a la tarjeta inteligente, se utilizarán URIs como http://localsmartcard. El nombre de dominio referente a la tarjeta inteligente en el ejemplo "localsmartcard", es mapeado a una dirección interna de IP la cual es asignada al gateway. Este mapeo se fijará en una ruta estática y tabla DNS 25 localizada dentro de la tarjeta inteligente. Cuando el navegador web 23 quiere acceder a un recurso de tarjeta inteligente identificado por un URI, se dirige al gateway 24 por la ruta asignada y la tabla DNS 25. Esta configuración se ilustra en la Figura 3, mostrando la comunicación entre un navegador web 23 y un servidor web de tarjeta inteligente 4 consultando una tabla de ruta 25.
El gateway debe encargarse de gestionar los canales de comunicación y realizar conversiones de protocolo entre el Protocolo Independiente del Portador y el TCP/IP, como se explica a continuación.
Como fase inicial, una tarjeta inteligente 1 que ejecuta un servidor web de tarjeta inteligente 4 de conformidad con una realización preferente del invento, puede asignar este servicio al terminal utilizando el comando "DECLARE SERVICE", por ejemplo con la secuencia de comandos propuesta en el ETSI TS 102 223 (anexo M) y de la forma ilustrada en la Figura 4. Normalmente, la declaración de servicio se realizará al iniciar.
La primera vez que se conecte el navegador web al gateway a fin de acceder el servidor HTTP, el gateway acciona la apertura de un canal de comunicación, por ejemplo utilizando la secuencia de comandos propuesta en el ETSI TS 102 223, anexo M, y como muestra la Figura 5. El gateway envía un ENVELOPE (conexión local) para hacer que la tarjeta inteligente 1 envíe un comando de CANAL ABIERTO al terminal 2. El comando ENVELOPE es un comando APDU utilizado para transmitir información a una aplicación operativa en una tarjeta inteligente 1. Ver ejemplo ETSI 102 221, sección 7.4.2.2. El comando de CANAL ABIERTO es un comando BIP según definido en el ETSI 102 223, sección 6.4.27.
En una realización preferente del invento, el gateway abre un nuevo canal de comunicación cada vez que el navegador web abre un socket TCP/IP al gateway. El socket representa un extremo de la comunicación donde se puede establecer una conexión. Entonces, el gateway mapea preferentemente el socket abierto al canal abierto, de manera que para cada socket que el navegador web pretende abrir al servidor web de tarjeta inteligente 4, se pueda crear un canal de comunicación entre el servidor web 4 y el gateway 25.
Una vez se establezca el canal de comunicación, se puede intercambiar información entre el navegador web 23 y el servidor web 4. El gateway realiza conversiones de protocolo entre el Protocolo Independiente del Portador y el TCP/IP enviando los mensajes HTTP recibidos a través del socket TCP/IP del navegador web 23, al servidor web 4 a través del canal de comunicación; y enviando los mensajes HTTP recibidos del servidor web 4 a través del canal de comunicación, al navegador web 23 a través del socket TCP/IP.
La figura 6 muestra un ejemplo de la secuencia de comandos para el envío de información desde el navegador web 23 al servidor web 4, de conformidad con el anexo M del ETSI TS 102.223.
El gateway, después de haber recibido la información del navegador web 23, envía un comando ENVELOPE a la tarjeta inteligente para informar de si los datos han sido recibidos y hacer que se envíe un comando de RECIBIR DATOS.
El comando de RECIBIR DATOS es un comando BIP según la definición del ETSI TS 102 223, sección 6.4.29. El comando ordena al gateway la longitud máxima de información que la tarjeta inteligente puede recibir. A continuación, el gateway transmite la información utilizando un comando de RESPUESTA DEL TERMINAL. Este comando es un comando APDU según la definición del ETSI TS 102 221, sección 10.1. Destacar que un canal identificador que identifica un canal de comunicación en el que se realiza una comunicación, es transmitido como parámetro en los comandos ENVELOPE y RECIBIR DATOS.
\global\parskip0.970000\baselineskip
Para transmitir mensajes HTTP en la otra dirección, por ejemplo desde el servidor web 4 al navegador web 23, se emplea un mecanismo similar. En vez del comando RECIBIR DATOS, la tarjeta inteligente 1 envía el comando ENVIAR DATOS al gateway 24. El comando ENVIAR DATOS es un comando BIP según la definición del ETSI TS 102 223, sección 6.4.30. Se utilizará para transmitir el mensaje HTTP desde el servidor web 4 al gateway 24 de forma que este último pueda reenviarlo al navegador web 23 a través del TCP/IP.
A continuación, se explica con mayor detenimiento la sintaxis de una tarjeta inteligente URI cuyo uso en las solicitudes HTTP ha sido mencionado anteriormente. La sintaxis general del URI se define en el RFC 2396 de la siguiente manera:
<scheme>:<scheme-specific-part>
En el contexto del presente invento, se utiliza el esquema de codificación "http".
En un gran número de URIs, la sintaxis general de <scheme>:<scheme-specific-part> es
//<authority><path>?<query>
en donde cada uno de los componentes <authority>, <path> y ?<query> pueden no aparecer en un URI en particular.
<authority>, denota un elemento jerárquico principal para un naming authority (autoridad de asignación de nombres). En el contexto del presente invento, el uso previsto de la tarjeta inteligente URI generalmente corresponde al contenido local de la tarjeta inteligente accedido por un terminal navegador web 23. Por lo tanto, el componente <authority> puede ser un nombre de dominio como "locasmartcard".
El componente <path> identifica el recurso dentro del marco del esquema de configuración y el <authority>. Una sintaxis completa del componente <path> para la tarjeta inteligente local se puede representar de la manera:
1
"df" se refiere a un Archivo Dedicado (Dedicated File) de la tarjeta inteligente el cual corresponde a un directorio en el sistema de archivos de la tarjeta inteligente; "ef" se refiere a un Archivo Elemental (Elementary File) el cual corresponde a un archivo de datos de la tarjeta inteligente.
"USIM" y "WM" se refieren a USIM (Módulo Universal de Identificación del Suscriptor, véase 3GPP TS 31.102) y WIM (Módulo de Identidad Inalámbrica), Aplicación de Archivo Dedicado (ADF) cuando una tarjeta inteligente contiene dicha aplicación.
Ejemplos de URIs con los componentes de <authority> y <path> descritos arriba son:
http://localsmartcard/USIM/12A1
http://localsmartcard/3F00
El componente <query> es una cadena de información que debe ser interpretada por el recurso. Una sintaxis propuesta es:
\quad
<query> \hskip1,7cm =<htpp_query>|<state>
\quad
<htpp_query> \hskip1cm = n*[BYTE]
\global\parskip1.000000\baselineskip
El componente <state> es un una cadena de caracteres que puede ser usada como indicación para el marco de trabajo de la tarjeta inteligente en cuyo punto de entrada se inicia la ejecución de una aplicación que crea un contenido dinámico como respuesta a una solicitud HTTP.
Dentro de un componente <query>, los caracteres ";","/","?",":","@","&","=","+",",", y "\textdollar" deben estar reservados.
Ejemplos de URIs con componentes de consulta (query) de acuerdo a la definición anterior son:
http://localsmartcard/3F00/2F24?record=02
http://localsmartcard/12121215199764382564579867542734/?state=entryl
\vskip1.000000\baselineskip
A continuación, se desarrolla de forma general algunas consideraciones para acceder a recursos en la tarjeta inteligente a través de un servidor web.
Si la tarjeta inteligente requiere una condición de acceso que no ha sido cumplida, el servidor de tarjeta inteligente 4 podrá proporcionar medios para permitir estas condiciones de seguridad de la forma definidas por los protocolos APDU referente a terminales-aplicaciones. Por ejemplo, podrá emitir una solicitud para preguntar al usuario un número PIN (Número de Identificación Personal).
La autorización se realiza entre la aplicación 23 del cliente y el servidor de tarjeta inteligente 4, utilizando la autorización estándar de intercambio de HTTP, descrito brevemente a continuación:
El servidor de tarjeta inteligente 4 responderá a una solicitud HTTP con un mensaje de respuesta HTTP que incluye una Línea de Estado con un código de estado "401" (No autorizado) y un encabezado WWW-Authenticate que consiste de al menos un desafío que indica el(los) esquema(s) de autenticación y los parámetros aplicables para la Solicitud-URI.
En una realización preferente del invento, el servidor de tarjeta inteligente 4 desafía con la solicitud de un número PIN utilizando un encabezado WWW-Authenticate como se muestra a continuación:
WWW-Authenticate: Digest realm=<PINName>
Nota: la cadena <PINName> puede tener diferentes valores dependiendo del tipo de PIN que se solicite (e.g. "PIN1", "CHV1").
La respuesta se enviará a la aplicación 23 del cliente. La aplicación 23 del cliente desarrollará el diálogo correspondiente con el usuario (e.g. solicitud de PIN o contraseña) y devolverá la solicitud incluyendo un encabezado de solicitud de Autorización que incluye los credenciales de Autorización.
Nota: para el uso del PIN, el valor del PIN es pasado al campo de datos de respuesta. El nombre de usuario, si es de aplicación, puede ser ignorado por el carserver 23.
A continuación, se muestra un ejemplo de un mensaje HTTP entre un navegador web 23 y un carserver.
El navegador 23 muestra la siguiente página HTML:
<HTML><BODY>
<A HREF="http://localsmartcard/7F40/5F30"> Test the smartcard-URI </A>
<BODY><HTML>
El usuario hace click en el enlace.
En este caso, la verificación de acceso es verificación de PIN. El comando VERIFICAR PIN debe ser enviado junto con la siguiente información:
3 
\newpage
El navegador envía la siguiente solicitud HTTO GET a la tarjeta inteligente:
GET http://localsmartcard/7F40/5F30 HTTP/1.1
El gateway de la tarjeta inteligente envía la solicitud en forma de comandos BIP. La información del comando corresponde a:
4 
\vskip1.000000\baselineskip
Por lo tanto, el servidor de tarjeta inteligente 4 podrá recuperar el recurso correspondiente (e.g. contenido de un archivo) y enviarlo de vuelta con la siguiente Respuesta HTTP a través de comandos BIP:
\vskip1.000000\baselineskip
5 
\vskip1.000000\baselineskip
Al recibir la respuesta, el gateway 24 encapsulará el paquete TCP/IP y lo enviará al navegador como un paquete de respuesta HTTP.
A continuación, se proporciona la definición del mínimo perfil HTTP necesitado para acceder a un servidor web 4 de una tarjeta inteligente 1. El perfil se define como un subconjunto de HTTP 1.1. Aplican las siguientes restricciones:
El campo URI puede ser de forma absoluta (e.g. http://localsmartcard/12A1) respetando las reglas para las tarjetas inteligentes de URIs según la forma definida en este documento.
La versión HTTP que debe ser implementada en un navegador web 4 es HTTP/1.1. Por lo tanto, según la especificación HTTP 1.1. en el RFC 2616, el valor del campo Versión-HTTP debe ser "HTTP/1.1".
La siguiente tabla indica los métodos HTTP que deben ser respaldados por un servidor web de tarjeta inteligente 4 junto con las recomendaciones indicando si el respaldo es obligatorio u opcional:
6
Al recibir una respuesta entrante no respaldada, el servidor de tarjeta inteligente 4 deberá responder con un mensaje de respuesta HTTP con el Código de Estado = 405 (Método no permitido).
La siguiente tabla muestra los encabezados GENERALES que deben ser respaldadas por un servidor web de tarjeta inteligente junto con las recomendaciones indicando si el respaldo es obligatorio u opcional:
\vskip1.000000\baselineskip
7 
\vskip1.000000\baselineskip
Acciones específicas durante la recepción:
El servidor web de la tarjeta inteligente ignorará los campos sin respaldo.
Los siguientes campos de encabezados de REQUEST para cada mensaje de solicitud HTTP deberá ser respaldado por el servidor web de la tarjeta inteligente 4.
\vskip1.000000\baselineskip
9 
\vskip1.000000\baselineskip
Acciones específicas durante la recepción:
- Se deberá omitir el campo de "Host" ya que el URI solicitado siempre se encuentra en forma absoluta.
- El campo de "Authorization" se describe arriba.
\vskip1.000000\baselineskip
El servidor web de tarjeta inteligente 4 respalda lo siguientes códigos de estado:
Código de Estado exitoso:
200 OK
| 201 Creado
| 204 Sin Contenido
| 205 Restaurar Contenido
\vskip1.000000\baselineskip
Errores de Código de Estado del Cliente =
401 Sin autorización
| 403 Prohibido
| 404 No se encuentra
| 405 Método no permitido
| 413 Entidad de Solicitud Demasiado Grande
| 414 URI de Solicitud Demasiado Grande
\vskip1.000000\baselineskip
Errores de Código de Estado del Servidor =
500 Error Interno del Servidor
| 500 HTTP Versión no respaldada
\vskip1.000000\baselineskip
La siguiente tabla muestra los campos de encabezados RESPONSE para cada mensaje de solicitud HTTP que debe ser respaldado por las correspondientes entidades remitentes/receptoras.
10
Acciones específicas durante la recepción:
Ninguna.
El servidor de tarjeta inteligente respalda los siguientes campos de encabezado ENTITY para cada mensaje de solicitud HTTP.
11
Acciones especificas de las entidades remitentes:
El campo de encabezado HTTP de "Content-Type" deberá ser incluido por el servidor de tarjeta inteligente dependiendo del recurso que está siendo transferido dentro de la respuesta HTTP.

Claims (17)

1. Método de ofrecer los servicios de un servidor HTTP o HTTPS, el servidor siendo implementado por o ejecutado en un primer dispositivo electrónico portátil (1), a una aplicación (23) ejecutada en un segundo dispositivo electrónico, en dónde el primer dispositivo electrónico intercambia mensajes HTTP con el segundo dispositivo electrónico a través de un canal de comunicación entre el primer y segundo dispositivo electrónico según el Protocolo Independiente del Portador, caracterizado en que el segundo dispositivo electrónico (2) es un terminal lector que aloja el dispositivo portátil (1).
2. Método según la reivindicación 1, caracterizado en que los mensajes HTTP transmitidos desde el primer dispositivo electrónico (1) al segundo dispositivo electrónico (2) a través del canal de comunicación, serán además transmitidos dentro del segundo dispositivo electrónico a una aplicación ejecutada en el segundo dispositivo electrónico a través de TCP/IP, y en que los mensajes HTTP recibidos por el primer dispositivo electrónico desde el segundo dispositivo electrónico han sido comunicados dentro del segundo dispositivo electrónico a través de
TCP/IP.
3. Método según la reivindicación 2, caracterizado en que la aplicación ejecutada en el segundo dispositivo electrónico es un navegador web y en que el servidor HTPP o HTTPS transfiere páginas HTML, xHTML, cHTML o WML a este navegador web (23).
4. Método según alguna de las reivindicaciones previas, caracterizado en que se utiliza la orden de DECLARE SERVICE para notificar al segundo dispositivo electrónico (2) acerca de los servicios del servidor HTTP o HTTPS ofrecidos por el primer dispositivo electrónico (1).
5. Método según alguna de las reivindicaciones previas, caracterizado en que el usuario puede ser autenticado con un encabezado HTTP estándar de WWW-Authenticate enviando atributos de PIN-Type y/o PIN-Value.
6. Método según alguna de las reivindicaciones previas, caracterizado en que el primer dispositivo electrónico es una tarjeta inteligente (1).
7. Método según alguna de las reivindicaciones 1 a 5, caracterizado en que el primer dispositivo electrónico (1) es una tarjeta de memoria Multimedia Card.
8. Método según alguna de las reivindicaciones previas, caracterizado en que el segundo dispositivo electrónico (2) es un teléfono móvil.
9. Método según alguna de las reivindicaciones 1 a 7, caracterizado en que el segundo dispositivo electrónico (2) es un PDA (Asistente Personal Digital).
10. Método según alguna de las reivindicaciones 1 a 7, caracterizado en que el segundo dispositivo electrónico (2) es un PC.
11. Método según cualquiera de las reivindicaciones previas caracterizado en que en el segundo dispositivo electrónico (2), el canal de comunicación está gestionado por un gateway (24) el cual convierte los protocolos del Protocolo Independiente del Portador -TCP/IP a mensajes recibidos por el servidor HTTP o HTTPS, así como la conversión de TCP/IP- Protocolo Independiente del Portador a mensajes enviado al servidor HTTP o HTTPS.
12. Método según la reivindicación 11, caracterizado en que una dirección IP interna y un nombre de dominio interno son asignados al gateway (24) y en que el nombre de dominio interno es mapeado a la dirección IP interna, y en que el nombre de dominio interno es utilizado en Identificadores de Recursos Uniformes para indicar que el identificador de Recurso Uniforme identifica un recurso en el primer dispositivo electrónico.
13. Método según la reivindicación 11 cuando depende de la reivindicación 6, caracterizado en que el primer dispositivo electrónico (1) es una tarjeta inteligente, y en que el Identificador de Recurso Uniforme incluye información para acceder a las aplicaciones estándares de la tarjeta inteligente como (U)SIM y WIM.
14. Método según alguna de las reivindicaciones 11 a 13, caracterizado en que se envía una orden al primer dispositivo electrónico para abrir un canal de comunicación cuando la aplicación ejecutada en el segundo dispositivo electrónico (2) abre un socket TCP/IP al gateway.
15. Método según la reivindicación 14, caracterizado en que el socket TCP/IP es mapeado al canal de comunicación abierto.
16. Método según alguna de las reivindicaciones 11 a 15, caracterizado en que la aplicación ejecutada en el segundo dispositivo electrónico es un navegador web.
\newpage
17. Un sistema incluyendo un primer dispositivo electrónico el cual corresponde a un dispositivo portátil (1) y un segundo dispositivo electrónico (2), el primer dispositivo electrónico ofreciendo los servicios de servidores HTTP o HTPPS, siendo el servidor implementado por o ejecutado en el primer dispositivo electrónico, el primer dispositivo electrónico intercambiando mensajes HTTP con el segundo dispositivo electrónico a través de un canal de comunicación entre el primer y segundo dispositivo electrónico según el Protocolo Independiente del Portador, caracterizado en que el segundo dispositivo electrónico es un terminal lector que aloja un dispositivo portátil.
ES05750686T 2004-06-15 2005-06-10 Conversion de protocolo "protocolo independiente de soporte" (bip) - tcp/ip para la comunicacion entre un modulo sim y un terminal. Active ES2334367T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP04291503 2004-06-15
EP04291503 2004-06-15
EP04292033A EP1608123A1 (en) 2004-06-15 2004-08-11 Method and device for communicating HTTP messages with portable devices
EP04292033 2004-08-11

Publications (1)

Publication Number Publication Date
ES2334367T3 true ES2334367T3 (es) 2010-03-09

Family

ID=34970683

Family Applications (1)

Application Number Title Priority Date Filing Date
ES05750686T Active ES2334367T3 (es) 2004-06-15 2005-06-10 Conversion de protocolo "protocolo independiente de soporte" (bip) - tcp/ip para la comunicacion entre un modulo sim y un terminal.

Country Status (6)

Country Link
US (1) US8447836B2 (es)
EP (2) EP1608123A1 (es)
AT (1) ATE440436T1 (es)
DE (1) DE602005016109D1 (es)
ES (1) ES2334367T3 (es)
WO (1) WO2005125154A1 (es)

Families Citing this family (65)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102005024122A1 (de) * 2005-05-25 2006-11-30 Infineon Technologies Ag Funk-Kommunikationseinrichtung, funkbasiertes Kommunikationsendgerät und Chipkarte
US8532136B1 (en) * 2005-10-19 2013-09-10 American Megatrends, Inc. Communication with a handset via a private network
FR2893803A1 (fr) * 2005-11-21 2007-05-25 Nec Technologies Uk Ltd Methode de communication entre une cartre (u)sim en mode serveur et un client
US8559987B1 (en) * 2005-12-31 2013-10-15 Blaze Mobile, Inc. Wireless bidirectional communications between a mobile device and associated secure element
DE102006024882A1 (de) * 2006-05-24 2007-11-29 Sagem Orga Gmbh Chipkarte
DE102006041526A1 (de) * 2006-09-05 2008-03-20 Giesecke & Devrient Gmbh Portabler Datenträger zur Kommunikation mit einem Telekommunikationsendgerät
EP1903465A1 (en) * 2006-09-20 2008-03-26 Axalto SA A SIP communication with a secure personal token for interacting with personal data
EP1903466A1 (en) * 2006-09-20 2008-03-26 Axalto SA A method for communicating with a personal token, comprising encapsulating a request inside a response
EP1933528B9 (fr) * 2006-12-12 2018-05-23 Orange Sécurisation d'accès à des services depuis un équipement communicant avec une entité personnelle
CN101325592B (zh) 2007-06-14 2011-04-20 华为技术有限公司 一种建立承载连接的方法、装置及系统
DE102007050836A1 (de) * 2007-10-24 2009-04-30 Giesecke & Devrient Gmbh Internet-Smart-Card
US8316150B2 (en) 2007-10-31 2012-11-20 Time Warner Cable Inc. System and method for remotely accessing cablecard
US7882249B2 (en) * 2008-01-07 2011-02-01 Sandisk Il Ltd. Methods and systems for communicating with storage systems using slim IP stacks
US8028122B2 (en) * 2008-01-07 2011-09-27 Sandisk Il Ltd. Methods and systems for classifying storage systems using fixed static-IP addresses
DE102008004384A1 (de) * 2008-01-15 2009-07-16 Giesecke & Devrient Gmbh Sichere Datenkommunikation
DE102008004693A1 (de) 2008-01-16 2009-08-13 Giesecke & Devrient Gmbh Portabler Datenträger mit CAT-Interpreter
EP2107807A1 (en) 2008-04-04 2009-10-07 Irdeto Access B.V. Conditional access system and smartcard for use in conditional access system
DE102009004181A1 (de) * 2008-04-11 2009-10-15 Giesecke & Devrient Gmbh Verarbeiten von Client-Anfragen
EP2299747A4 (en) * 2008-07-10 2014-06-25 Sk Planet Co Ltd PERSONALIZED SERVICE SYSTEM BASED ON USE OF INTELLIGENT CARD, METHOD AND INTELLIGENT CARD THEREFOR
CN101335758B (zh) * 2008-07-24 2011-09-21 中兴通讯股份有限公司 双处理器终端访问sim卡中服务的方法及系统
EP2182696A1 (fr) 2008-10-31 2010-05-05 Gemalto SA Procédé d'établissement d'une liaison entre les applications d'une carte d'authentification d'un abonné et un réseau IMS
GB0821236D0 (en) * 2008-11-20 2008-12-31 Nec Corp Client-server communications in mobile radio communications device
CN101600263B (zh) * 2009-06-30 2011-05-11 中兴通讯股份有限公司 数据传输方法及终端
CN101594614B (zh) * 2009-06-30 2011-07-13 中兴通讯股份有限公司 数据下载方法以及终端
UY32806A (es) * 2009-08-04 2010-09-30 Telefonica Sa Sistema y procedimiento para control de acceso a contenidos
EP2293525A1 (en) * 2009-09-02 2011-03-09 Gemalto SA Method for a secure device to resolve an IP address of a target server
KR101166797B1 (ko) * 2009-09-22 2012-07-26 에스케이플래닛 주식회사 스마트카드 기반 브라우징 시스템 및 그 방법, 그리고 이에 적용되는 스마트카드
US9497632B2 (en) * 2009-10-01 2016-11-15 T-Mobile Usa, Inc. System and method for pairing a UICC card with a particular mobile communications device
EP2395427A1 (en) * 2010-06-08 2011-12-14 Gemalto SA Method for connecting to a remote server from a browser enabled with a browser's extension on a host device
FR2963518B1 (fr) * 2010-07-29 2012-09-07 Myriad France Procede de connexion entre une carte mmsim et une application
EP2445170B1 (en) * 2010-10-19 2014-10-08 Vodafone Holding GmbH Device and method for contactless short range communication
US8983541B2 (en) 2010-10-20 2015-03-17 Blackberry Limited Card application toolkit support for IP multimedia subsystem
JP5722452B2 (ja) 2010-10-20 2015-05-20 ブラックベリー リミテッド Ｉｐマルチメディアシステム用のカードアプリケーションツールキットサポート
KR101863677B1 (ko) * 2010-10-27 2018-07-13 에스케이플래닛 주식회사 단말기와 스마트카드 간 인터페이스 시스템 및 그 방법
EP2461613A1 (en) 2010-12-06 2012-06-06 Gemalto SA Methods and system for handling UICC data
US9408066B2 (en) 2010-12-06 2016-08-02 Gemalto Inc. Method for transferring securely the subscription information and user data from a first terminal to a second terminal
JP5719452B2 (ja) * 2010-12-23 2015-05-20 ブラックベリー リミテッド Ｉｐマルチメディアサブシステムのためのカードツールキットサポート
EP2661697B1 (en) * 2011-01-07 2018-11-21 Seven Networks, LLC System and method for reduction of mobile network traffic used for domain name system (dns) queries
WO2012145817A1 (en) 2011-04-26 2012-11-01 Research In Motion Limited Transmission of the pdp content activation rejection cause codes to the uicc
CN102594892B (zh) * 2012-02-22 2018-08-24 南京中兴新软件有限责任公司 数据访问方法及装置
US8964973B2 (en) 2012-04-30 2015-02-24 General Electric Company Systems and methods for controlling file execution for industrial control systems
US9046886B2 (en) 2012-04-30 2015-06-02 General Electric Company System and method for logging security events for an industrial control system
US8973124B2 (en) 2012-04-30 2015-03-03 General Electric Company Systems and methods for secure operation of an industrial controller
CN102724315B (zh) * 2012-06-21 2016-06-08 惠州Tcl云创科技有限公司 基于智能卡网页服务器实现智能卡远程操作的方法及系统
US9094433B2 (en) * 2012-06-27 2015-07-28 Qualcomm Incorporated Systems and methods for bearer independent protocol gateway optimization
US9172544B2 (en) * 2012-10-05 2015-10-27 General Electric Company Systems and methods for authentication between networked devices
US8898769B2 (en) 2012-11-16 2014-11-25 At&T Intellectual Property I, Lp Methods for provisioning universal integrated circuit cards
US8959331B2 (en) 2012-11-19 2015-02-17 At&T Intellectual Property I, Lp Systems for provisioning universal integrated circuit cards
US9036820B2 (en) 2013-09-11 2015-05-19 At&T Intellectual Property I, Lp System and methods for UICC-based secure communication
US9124573B2 (en) 2013-10-04 2015-09-01 At&T Intellectual Property I, Lp Apparatus and method for managing use of secure tokens
EP3055978B1 (en) * 2013-10-10 2019-02-27 Google LLC Systems, methods, and computer program products for managing communications
US9208300B2 (en) 2013-10-23 2015-12-08 At&T Intellectual Property I, Lp Apparatus and method for secure authentication of a communication device
US9240994B2 (en) 2013-10-28 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for securely managing the accessibility to content and applications
US9313660B2 (en) 2013-11-01 2016-04-12 At&T Intellectual Property I, Lp Apparatus and method for secure provisioning of a communication device
US9240989B2 (en) 2013-11-01 2016-01-19 At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device
US9413759B2 (en) 2013-11-27 2016-08-09 At&T Intellectual Property I, Lp Apparatus and method for secure delivery of data from a communication device
US9197717B2 (en) 2013-11-27 2015-11-24 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions according to client device states
US9713006B2 (en) 2014-05-01 2017-07-18 At&T Intellectual Property I, Lp Apparatus and method for managing security domains for a universal integrated circuit card
WO2016029384A1 (zh) 2014-08-27 2016-03-03 华为技术有限公司 一种资源下载方法、电子设备及装置
KR102264992B1 (ko) 2014-12-31 2021-06-15 삼성전자 주식회사 무선 통신 시스템에서 서버 할당 방법 및 장치
EP3076701A1 (en) * 2015-03-31 2016-10-05 Gemalto Sa Method and chip for detecting a corruption of at least one configuration parameter
US10135790B2 (en) 2015-08-25 2018-11-20 Anchorfree Inc. Secure communications with internet-enabled devices
CN107454058A (zh) * 2017-06-29 2017-12-08 广州视源电子科技股份有限公司 一种数据发送方法、系统、可读存储介质及计算机设备
CN111464550B (zh) * 2020-04-10 2021-12-28 南京铱迅信息技术股份有限公司 一种用于报文处理设备的https透明防护方法
CN114430548B (zh) * 2020-10-15 2023-07-21 中移互联网有限公司 业务处理方法、装置及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2823408B1 (fr) * 2001-04-09 2003-05-30 Gemplus Card Int Procede de transmission de donnees par une station mobile comportant une etape de determination de la mds
DE10139745A1 (de) * 2001-08-13 2003-02-27 Siemens Ag Verfahren und Vorrichtung zum Herstellen einer Kommunikationsverbindung
JP2006505992A (ja) * 2002-11-08 2006-02-16 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ データネットワークにおいてリモートアクセスを許可する方法及び装置
JP2006518140A (ja) * 2003-01-31 2006-08-03 アクサルト・エス・アー スマートカードとサーバとの間の通信
WO2004086676A1 (en) * 2003-03-19 2004-10-07 Way Systems, Inc. System and method for mobile transactions using the bearer independent protocol
US20050138004A1 (en) * 2003-12-17 2005-06-23 Microsoft Corporation Link modification system and method
US20050259673A1 (en) * 2004-05-18 2005-11-24 Axalto Inc. Method and system for end-to-end communication between a universal integrated circuit card and a remote entity over an IP-based wireless wide area network and the internet

Also Published As

Publication number Publication date
EP1757070A1 (en) 2007-02-28
EP1757070B1 (en) 2009-08-19
ATE440436T1 (de) 2009-09-15
WO2005125154A1 (en) 2005-12-29
US8447836B2 (en) 2013-05-21
US20070239857A1 (en) 2007-10-11
EP1608123A1 (en) 2005-12-21
DE602005016109D1 (de) 2009-10-01

Similar Documents

Publication Publication Date Title
ES2334367T3 (es) Conversion de protocolo &#34;protocolo independiente de soporte&#34; (bip) - tcp/ip para la comunicacion entre un modulo sim y un terminal.
US6937588B2 (en) System and method for providing wireless application protocol service through internet
CN102333306B (zh) 一种蜂窝移动设备以及一种用于蜂窝移动设备的系统和方法
KR100723006B1 (ko) 인터넷형 네트워크 서버 디렉토리상에 유저를 등록하고상기 네트워크 상에 유저를 위치 설정하기 위한 방법 및이를 위한 스마트 카드
CN102333110B (zh) 用于移动设备的具有动态翻译用户主页的vpn网络客户端
CN102333075B (zh) 用于移动设备的具有动态故障转移的多服务vpn网络客户端
CN102316094B (zh) 用于移动设备的具有集成加速的多服务vpn网络客户端
CN102316153B (zh) 对网页邮件本地接入动态构造显示的vpn网络客户端
US8676260B2 (en) Method of managing information by a large capacity UICC
US8745187B2 (en) System and method for installing smart card applet
US8370461B2 (en) Mobile broadband device and method for managing mobile broadband device
US20040152446A1 (en) Method for providing network access to a mobile terminal and corresponding network
CN102316092A (zh) 用于移动设备的具有快速重新连接的vpn网络客户端
CN102316093A (zh) 用于移动设备的双模式多服务vpn网络客户端
CN101010927A (zh) 用于sim和终端之间的通信的协议转换“载体无关协议”－tcp/ip
US20090119364A1 (en) Method and system for exchange of data between remote servers
ES2551301T3 (es) Método y aparato para comunicar datos entre dispositivos de ordenador
CN1437811A (zh) 一种信息交换平台
JP2003110596A (ja) データ通信サービス提供方法
US7698747B2 (en) Applet download in a communication system
EP2377293A1 (en) Method and system for authentication of network nodes of a peer-to-peer network
US20030214970A1 (en) Method and apparatus for ensuring capability to send information to a wireless device using hybrid network capability
US20140280853A1 (en) Mobile Broadband Device and Method for Processing Mobile Broadband Service of the Mobile Broadband Device
US20100223462A1 (en) Method and device for accessing services and files
US20130052994A1 (en) Pairing of subscriber identity module and domain management functions in a secure environment