FR2893803A1 - Methode de communication entre une cartre (u)sim en mode serveur et un client - Google Patents

Methode de communication entre une cartre (u)sim en mode serveur et un client Download PDF

Info

Publication number
FR2893803A1
FR2893803A1 FR0553531A FR0553531A FR2893803A1 FR 2893803 A1 FR2893803 A1 FR 2893803A1 FR 0553531 A FR0553531 A FR 0553531A FR 0553531 A FR0553531 A FR 0553531A FR 2893803 A1 FR2893803 A1 FR 2893803A1
Authority
FR
France
Prior art keywords
channel
server
command
terminal
bip
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.)
Pending
Application number
FR0553531A
Other languages
English (en)
Inventor
Fabrice Zappulla
Olivier Dong
Hubert Helaine
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.)
NEC Technologies UK Ltd
Original Assignee
NEC Technologies UK Ltd
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 NEC Technologies UK Ltd filed Critical NEC Technologies UK Ltd
Priority to FR0553531A priority Critical patent/FR2893803A1/fr
Priority to PCT/JP2006/322828 priority patent/WO2007058241A1/fr
Priority to CN2006800435933A priority patent/CN101313622B/zh
Priority to EP06832717.0A priority patent/EP1954086B1/fr
Priority to US12/094,224 priority patent/US20090191917A1/en
Priority to JP2007545281A priority patent/JP4930377B2/ja
Publication of FR2893803A1 publication Critical patent/FR2893803A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/169—Special adaptations of TCP, UDP or IP for interworking of IP based networks with other networks 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/60—Types of network addresses
    • H04L2101/618—Details of network addresses
    • H04L2101/663—Transport layer addresses, e.g. aspects of transmission control protocol [TCP] or user datagram protocol [UDP] ports

Abstract

L'invention concerne une méthode de communication entre une carte à puce ((U)SIM), équipée d'un serveur (SCWS), et un ou plusieurs clients, ladite carte étant comprise dans un terminal radiomobile et communiquant avec ce dernier au moyen d'au moins un canal BIP, ledit terminal assurant une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients.

Description

METHODE DE COMMUNICATION ENTRE UNE CARTE (U)SIM EN MODE SERVEUR ET UN
CLIENT
DESCRIPTION 5 DOMAINE TECHNIQUE L'invention concerne le domaine des télécommunications mobiles et plus particulièrement celles mettant en oeuvre une carte à puce dans un terminal mobile. 10 ÉTAT DE LA TECHNIQUE ANTÉRIEURE On sait que dans un réseau GSM, par exemple, un abonné dispose dans son terminal mobile d'une carte à puce, dite carte SIM, pour Subscriber Identity Module, comprenant une mémoire et un 15 microcontrôleur. La mémoire stocke des répertoires et fichiers qui contiennent classiquement l'identifiant de l'opérateur, les données liées au réseau, les numéros d'appel d'urgence, le répertoire téléphonique etc. Plus récemment, la carte SIM a été dotée de 20 nouvelles fonctionnalités, lui permettant de sauvegarder le contenu de certains fichiers comme le répertoire sur un serveur distant, en utilisant le canal SMS (Short Message Service). Les derniers développements concernent entre autres le rôle qu'est 25 appelée à jouer la carte SIM dans le réseau GPRS (pour General Packet Radio Service), dit aussi 2,5G , et le réseau UMTS (pour Universal Mobile Telecommunication System), dit aussi 3G. Dans ce dernier cas, la carte SIM est appelée UICC pour Universal Integrated 30 Circuit Card . Par la suite on utilisera le terme générique (U)SIM pour désigner une carte comportant une fonction SIM, quelle que soit la génération concernée. Il a été proposé dans ce cadre un mécanisme permettant à la carte (U)SIM d'accéder au terminal et au réseau, quel que soit mode de connexion du terminal mobile, à savoir en mode de circuit commuté (typiquement GSM) ou en mode paquet (typiquement GPRS). Ce mécanisme est connu sous l'acronyme de BIP pour Bearer Independent Protocol , le canal logique permettant à la carte (U)SIM de communiquer avec le terminal mobile étant pour cette raison appelée canal BIP. Il convient de noter qu'en général un ou plusieurs canaux BIP peuvent être établis entre la carte et le terminal. Ce dernier dispose d'un logiciel médiateur (middleware) permettant aux applications de la carte (U)SIM d'interagir avec celles du terminal, logiciel dénommé CAT pour Card Application Toolkit . On trouvera une description détaillée du protocole BIP dans le document de l'ETSI intitulé TS 102223, notamment dans sa version 7 d'Octobre 2005, V7.1.0, disponible sous le site wca_.etsi.org. Au moyen du protocole BIP, la carte (U)SIM peut notamment agir comme client et envoyer des requêtes à un serveur distant. Dernièrement, il a été proposé d'héberger un serveur sur la carte (U)SIM. Dans ce cas des clients distants ou bien locaux (c'est-à-dire dans le terminal mobile, comme un browser local ou un applet, peuvent transmettre des requêtes http au serveur hébergé sur la carte et récupérer notamment des pages web stockées dans sa mémoire. Que la carte (U)SIM opère en mode client ou en mode serveur, le terminal mobile assure au moyen du logiciel médiateur CAT la conversion du protocole BIP en protocole TCP/IP et réciproquement. La Figure 1 illustre schématiquement une 5 communication entre une carte (U)SIM opérant en mode serveur et un client. On y distingue la carte (U)SIM (ici une carte UICC) comportant un serveur SCWS pour (SmartCard Web Server), 110, le module du logiciel CAT, 120, 10 dénommé ici SATS (pour SIM Application Toolkit Server) remplissant la fonction de passerelle entre les protocoles BIP et TCP/IP, les piles TCP/IP client et serveur représentées respectivement en 130 et 140, et le client 150. Ce client peut être local, par exemple 15 le browser du terminal ou une mobilette (application midlet), ou bien distant. Selon les spécifications actuelles du protocole BIP, une seule connexion client peut être acceptée par canal BIP. Si le serveur de la carte veut 20 accepter une autre connexion client, il lui faut alors créer un nouveau canal. Etant donné que les canaux BIP sont en nombre limité (au maximum 7 d'après la norme TS 102223 mais le terminal mobile peut en supporter moins), les contraintes de fonctionnement sont 25 importantes. Par exemple, si la carte veut ouvrir un canal BIP en mode client alors que le nombre maximal de canaux BIP a été atteint, la carte devra préalablement fermer un canal BIP, par exemple un canal BIP en mode serveur. 30 En outre, lorsque plusieurs canaux BIP ont été établis, des données ne peuvent être échangées simultanément sur les différents canaux. En d'autres termes, la communication entre le terminal mobile et la carte a lieu en mode série, un canal BIP après l'autre.
La Figure 2 illustre schématiquement un chronogramme communication en mode serveur entre la carte et un client, par exemple le browser local. Les piles TCP/IP n'ont pas été représentées par souci de simplification.
On remarque que le serveur ne supporte les connexions avec le client que de manière séquentielle. Ainsi deux requêtes de connexions du même client (dues par exemple à deux requêtes HTTP GET) seront satisfaites successivement.
Il convient de noter que les messages d'évènement transmis par la passerelle 120 au serveur 110 pour l'avertir de la connexion/ deconnexion avec le client ne comportent pas d'identifiant de la connexion concernée.
Dans la version de protocole HTTP 1.0 et les versions précédentes, les connexions TCP sont, par défaut, fermées après un échange de requête et réponse ( connection :Close dans l'en-tête de la requête). Il est néanmoins possible en incluant un en-tête connection : Keep-Alive dans la requête de demander à ce que la connexion soit maintenue ouverte. Dans ce cas, si le client envoie une autre requête, celle-ci utilise la connexion précédemment crée. Dans la version de protocole HTTP 1.1, les connexions sont maintenues ouvertes par défaut.
Si le client envoie plusieurs requêtes HTTP 1.1 en rafale, par exemple parce que le client après avoir téléchargé un première page HTML doit télécharger d'autres objets (images, sons), les requêtes autres que la première échoueront. La Figure 3 illustre la situation évoquée plus haut, à savoir une rafale 210 de requêtes du client (browser) 150 au serveur 110. Une telle rafale est susceptible d'être traitée par le serveur s'il travaille en mode dit automatic reconnection tel que défini au point 6.4.27.1 de la norme susmentionnée. La connexion demandée par la première requête est confirmée au client en 211. Une seule connexion TCP pouvant être acceptée, la seconde requête est rejetée et le client en est averti en 212. Après que le client et le serveur ont échangé des données via la connexion TCP et le canal BIP, le client transmet une requête de déconnexion 213 qui est confirmée en 214. Le browser relance la seconde requête et demande à nouveau une connexion en 216, après l'arrivée à échéance d'un timer 215 (du browser ou de la pile TCP/IP du client), armé lors du premier échec en 212. En pratique la temporisation peut atteindre 10 s ce qui freine considérablement le téléchargement et peut même conduire au non téléchargement de certains objets.
La Figure 4 illustre une tentative de communication entre la carte 110 opérant en mode serveur et deux clients, ici deux clients locaux, le browser du terminal mobile 150 et un midlet 160 d'une application Java (par exemple un jeu sur le terminal mobile). Comme on peut le constater, après que le browser a fait une tentative fructueuse de connexion en 220, la requête de connexion issue du midlet échoue en 221, car le port TCP associé au canal BIP n'est pas disponible. De manière plus critique, si la requête HTTP du browser est du type Keep-Alive (par ex. requête HTTP 1.1) et que celui-ci ne demande plus de nouvelles données, le port TCP du serveur reste mobilisé alors que le serveur est inactif. Par exemple si l'usager, après avoir téléchargé une page du serveur décide de lancer une nouvelle application requérant d'accéder au serveur, cette dernière ne pourra se dérouler qu'après l'arrivée à échéance du timer (du browser) pour la première connexion. En définitive, le protocole BIP actuel impose au serveur de la carte d'être monoclient (à tout le moins lorsqu'un seul canal BIP peut être ouvert).
La Figure 5 illustre une communication entre la carte 110 opérant en mode serveur et un client, le serveur étant lui-même en mode dit automatic reconnection au sens du point 6.4.27.1 de la norme susmentionnée. Brièvement, si le serveur est dans ce mode, le canal BIP n'est pas fermé (par une commande Close channel) lorsque la connexion TCP avec le client est coupée et la passerelle est mise en attente d'une nouvelle connexion. Le serveur peut alors accepter un seconde requête du client et une nouvelle connexion TCP peut être établie. Dans cette Figure on a explicité les piles TCP/IP. Dans une première phase 230, un canal BIP est ouvert sur une commande Open Channel du protocole BIP. Le terminal mobile le confirme par une réponse Terminal Response positive. Le browser transmet alors une première requête en 231, la liaison TCP est établie après l'échange 232. Le browser 150 peut alors échanger des données avec la carte 110, comme indiqué en 233. Si une seconde requête est transmise par le browser en 234 avant que l'échange 233 soit terminé, la passerelle 120 rejettera la demande de connexion en 235 et se remettra en attente d'une nouvelle requête de connexion, 236.
Le but de la présente invention est de remédier aux inconvénients mentionnés ci-dessus, notamment de permettre le traitement par la carte (U)SIM opérant en mode serveur de plusieurs requêtes simultanées issues du même client ou de clients distincts. EXPOSÉ DE L'INVENTION A cette fin l'invention est définie par une méthode de communication entre une carte à puce, équipée d'un serveur, et un ou plusieurs clients, ladite carte étant comprise dans un terminal radiomobile et communiquant avec ce dernier au moyen d' au moins un canal BIP, caractérisée en ce que ledit terminal assure une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients.
Ainsi un canal BIP pourra supporter plusieurs connexions TCP avec ce ou ces clients pour satisfaire des requêtes simultanées.
La méthode de communication entre le serveur et la passerelle pourra avantageusement comprendre une première commande (Open Channel), ladite commande comprenant un paramètre indiquant audit terminal le nombre maximal de connexions TCP à ouvrir pour ledit canal BIP.
La méthode de communication pourra encore avantageusement comprendre, l'émission d'une seconde commande (Receive Data) par le serveur demandant au dit terminal de lui transmettre les données issues d'une des connexions TCP associées au dit canal BIP (lorsque le serveur aura été averti que de telles données étaient disponibles), ladite commande comprenant un paramètre identifiant ladite connexion TCP.
La méthode de communication pourra avantageusement prévoir que ledit serveur envoie des données au dit terminal via le canal BIP et demande à ce dernier de les transmettre vers le ou l'un desdits clients, au moyen d'une troisième commande (Send Data), ladite commande comprenant un paramètre identifiant la connexion TCP à utiliser par le terminal pour la transmission.
La méthode de communication pourra avantageusement prévoir que ledit serveur demande au dit terminal de fermer une ou plusieurs des connexions TCP associées au dit canal BIP, au moyen d'une quatrième commande (Close Channel), ladite commande comprenant un paramètre identifiant la ou les connexions TCP à fermer.
La méthode de communication pourra avantageusement prévoir que ledit terminal transmet au dit serveur un message d'évènement (Data available event), ledit message indiquant que des données du ou d'un desdits clients sont disponibles pour ledit canal BIP et identifiant la connexion TCP associée au dit canal sur laquelle elles ont été reçues.
La méthode de communication pourra enfin avantageusement prévoir que ledit terminal transmet au dit serveur un message d'évènement (Channel status event) indiquant qu'une connexion TCP associée au canal BIP a été établie ou a été fermée et identifiant cette connexion. Ainsi le protocole BIP entre la carte à puce et la passerelle pourra supporter la gestion de plusieurs connexions TCP associées à un même canal. L'invention prévoit également le format des messages pour ce protocole. L'invention vise enfin une carte à puce comportant des moyens logiciels adaptés à générer des messages de commande et un terminal mobile comportant des moyens logiciels adaptés à générer des messages d'évènement, leur permettant de mettre en oeuvre la méthode susmentionnée.
BRÈVE DESCRIPTION DES DESSINS L'invention sera mieux comprise par la description de modes de réalisation à l'aide des figures suivantes : la Fig. 1 illustre schématiquement une communication entre une carte (U)SIM opérant en mode serveur et un client. la Fig. 2 illustre schématiquement un chronogramme de la communication entre la carte et un client, - la Fig. 3 illustre schématiquement la situation où une rafale de requêtes est transmise par le client à la carte (U) SIM ; - la Fig. 4 illustre schématiquement une tentative de communication entre la carte (U)SIM et deux clients ; - la Fig. 5 illustre schématiquement le chronogramme d'une communication entre un client et le serveur de la carte (U)SIM, celui-ci étant en mode automatic reconnection ; - la Fig. 6 illustre schématiquement le chronogramme d'une communication entre la carte (U)SIM et un client, selon un mode de réalisation de l'invention ; - la Fig. 7 illustre schématiquement le mécanisme de rupture de la communication entre la carte (U)SIM et un client, selon un mode de réalisation de l'invention; - la Fig. 8 illustre schématiquement une tentative de communication entre la carte (U)SIM et deux clients, dans le cadre de la mise en oeuvre de l'invention ; - la Fig. 9 illustre schématiquement le chronogramme d'une communication entre la carte (U)SIM et un client, selon un mode de réalisation de l'invention, lorsque le serveur de la carte (U)SIM est en mode automatic reconnection . EXPOSÉ DÉTAILLÉ DE MODES DE RÉALISATION PARTICULIERS L'idée à la base de l'invention est de permettre l'association de plusieurs connexions TCP à un canal BIP. Pour ce faire le protocole BIP entre le serveur hébergé par la carte et la passerelle est enrichi de manière à spécifier, pour un canal BIP donné, à quelle connexion TCP s'applique la commande. En particulier, comme nous le verrons en détail plus loin, l'invention prévoit que les commandes Receive data , Send data , Close channel du serveur et les messages d'évènement Data available et Status channel du terminal mobile, tels que définies dans la norme ETSI TS 102223, doivent désormais comporter un identifiant de la connexion TCP à laquelle ils s'appliquent.
La Figure 6 illustre un chronogramme de communication entre une carte (U)SIM opérant en mode serveur et un client, par exemple le browser du terminal mobile, lorsque la présente invention est mise en oeuvre.
Comme précédemment, l'échange 240 entre la carte et la passerelle assure l'établissement du canal BIP. Une rafale de requêtes est transmise par le browser en 241. En réponse deux connexions TCP sont établies par la passerelle 120, c'est-à-dire deux ports TCP sont ouverts pour ces connexions. L'établissement des connexions est confirmé au browser en 243 et le serveur de la carte en est averti en 244 au moyen de messages d'évènement Channel status . Des données sont ensuite transmises par le browser à destination du serveur sur lesdites connexions TCP. La passerelle 120 du terminal mobile avertit le serveur en 246 et en 250 que des données sont disponibles sur les deux ports TCP respectifs au moyen de messages d'évènement Data available . Chaque message Data available indique la connexion TCP dont il d'agit. En réponse, le serveur demande à la passerelle de lui transmettre les données, au moyen de commandes Receive data , en précisant à chaque fois de quelle connexion TCP (id-1, id-2) il s'agit. On remarque, que contrairement au chronogramme représenté en Figure 6, la seconde requête de connexion n'est pas rejetée et est servie sans délai.
Lorsque les données en provenance d'un port ont toutes été transmises, la connexion TCP correspondante peut être rompue à l'initiative du serveur selon un mécanisme illustré en Figure 7. Ainsi des ressources de communication sont libérées et pourront être utilisées pour une autre requête. Ceci est particulièrement avantageux lorsque le nombre de connexions TCP pour le canal BIP a été atteint. Dans le cas présent, toutes les données du port id-1 ayant été transmises au serveur, ce dernier décide de le fermer. Pour ce faire, il transmet en 258 une commande Close channel , identifiant la connexion TCP à fermer. La Figure 8 illustre la situation où deux clients, par exemple le browser du terminal mobile et un midlet tentent de se connecter au serveur de la carte (U)SIM. Les deux requêtes 260 et 262 peuvent être satisfaites sans délai grâce à l'établissement de deux connexions TCP. La passerelle 120 du terminal mobile en avertit le serveur au moyen de messages d'évènement Status channel , 261,263, identifiant les connexions TCP concernées. De manière similaire les requêtes de déconnexions sont servies sans délai et le serveur en est averti en 265, 267 par des messages d'évènement Status channel identifiant les connexions TCP rompues.
La Figure 9 illustre le chronogramme d'une communication entre la carte (U)SIM et un client, par exemple un browser, lorsque le serveur de la carte (U)SIM est en mode automatic reconnection . Dans ce mode, le serveur de la carte requiert du terminal mobile l'ouverture d'un canal BIP grâce à une commande Open Channel et précise dans celle-ci le nombre maximal de connexions TCP que le canal BIP peut simultanément supporter (2 dans le cas illustré). Lorsqu'une première requête est émise par le browser, une connexion TCP est établie au terme de l'échange 280. Si une seconde requête est alors émise par le browser, une seconde connexion TCP est établie au terme de l'échange 282. Le browser et le serveur de la carte (U)SIM peuvent alors échanger des données sur les deux connexions. Le nombre maximal de connexions TCP étant atteint, le terminal mobile (la passerelle) n'a pas à retourner en mode écoute et attendre une nouvelle demande de connexion du serveur. Ce n'est que lorsque la passerelle est avertie de la rupture d'une des connexions par le browser, en 284, que la passerelle retourne en mode écoute, en 286. Afin de permettre la mise en oeuvre de l'invention telle que décrite, il est prévu de modifier certaines commandes du protocole BIP défini dans la norme ETSI TS 10223 V7.1.0. Plus précisément il est proposé de paramétrer la commande Open Channel par le nombre maximal de connexions TCP. Ce nombre sera indiqué dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.27 de la norme susmentionnée.
La commande Close channel sera, quant à elle, paramétrée par : - un premier paramètre indiquant si (a) une ou (b) toutes les connexions TCP sont à fermer et dans le cas (b) si le canal logique BIP est lui-même aussi à fermer un second paramètre identifiant la connexion à fermer dans le cas (a).
Ces deux paramètres seront placés dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.28 de la norme susmentionnée.
La réponse du terminal (TR) à une telle commande comportera le cas échéant l'identifiant de connexion.
La commande Receive data sera paramétrée par la connexion TCP (c'est-à-dire le port TCP) dont le serveur veut récupérer les données. L'identifiant de la connexion sera indiqué dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.29 de la norme susmentionnée. La réponse du terminal (TR) à une telle commande comportera le cas échéant l'identifiant de connexion.
La commande Send data sera paramétrée par la connexion TCP sur laquelle le terminal doit transmettre les données. L'identifiant de la connexion sera indiqué dans le champ Command Qualifier de l'élément de données TLV Command details de la commande définie au point 6.6.30 de la norme susmentionnée. La réponse du terminal (TR) à une telle commande comportera le cas échéant l'identifiant de connexion.30 Le message d'évènement (message aussi appelé ENVELOPE command dans la norme concernée) Data available sera paramétrée par la connexion TCP, i.e. le port TCP sur lequel des données sont disponibles. On rappelle que ce message est transmis du terminal mobile au serveur de la carte (U)SIM. Il contiendra à cet effet un identifiant de la connexion en question dans le champ Channel status de l'élément de données TLV Channel status du message défini au point 7.5.10 de la norme susmentionnée.
Le message d'évènement Channel status transmis par le terminal au serveur de la carte (U)SIM donnera le statut de la connexion TCP. Il contiendra à cet effet un identifiant de ladite connexion dans le champ Channel status de l'élément de données TLV Channel status du message défini au point 7.5.11 de la norme susmentionnée.

Claims (10)

REVENDICATIONS
1. Méthode de communication entre une carte à puce ( (U) SIM) , équipée d'un serveur (SCWS), et un ou plusieurs clients, ladite carte étant comprise dans un terminal radiomobile et communiquant avec ce dernier au moyen d'au moins un canal BIP, caractérisée en ce que ledit terminal assure une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients.
2. Méthode de communication selon la revendication 1, caractérisée en ce que ledit canal BIP est ouvert au moyen d'une première commande (Open Channel) dudit serveur, ladite commande comprenant un paramètre indiquant audit terminal le nombre maximal de connexions TCP à ouvrir pour ledit canal BIP.
3. Méthode de communication selon la revendication 2, caractérisée en ce que ledit serveur ayant été averti par le terminal que des données issues d'une des connexions TCP associées au dit canal BIP étaient disponibles, transmet une seconde commande (Receive Data) demandant au dit terminal de les lui transmettre, ladite commande comprenant un paramètre identifiant ladite connexion TCP.
4. Méthode de communication selon la revendication 2 ou 3, caractérisée en ce que ledit serveur envoie des données au dit terminal via le canalBIP et demande à ce dernier de les transmettre vers le ou l'un desdits clients, au moyen d'une troisième commande (Send Data), ladite commande comprenant un paramètre identifiant la connexion TCP à utiliser par le terminal pour la transmission.
5. Méthode selon l'une des revendications précédentes, caractérisée en ce que ledit serveur demande au dit terminal de fermer une ou plusieurs des connexions TCP associées au dit canal BIP, au moyen d'une quatrième commande (Close Channel), ladite commande comprenant un paramètre identifiant la ou les connexions TCP à fermer.
6. Méthode selon l'une des revendications 1 à 4, caractérisée en ce que ledit serveur demande au dit terminal de fermer une ou toutes les connexions TCP associées au canal BIP, au moyen d'une quatrième commande (Close Channel), ladite commande comprenant un paramètre indiquant au terminal si : (a) l'une seulement des connexions TCP associées au canal BIP est à fermer ; ou bien (b) toutes les connexions TCP associées au canal TCP est à fermer ; ledit paramètre identifiant, dans le cas (a), la connexion TCP à fermer.
7. Méthode selon la revendication 6 caractérisée en ce que le paramètre de la quatrième commande indique en outre dans le cas (b) si le canal BIP est également à fermer.
8. Méthode selon l'une des revendications précédentes caractérisée en ce que ledit terminal transmet au dit serveur un message d'évènement (Data available event), ledit message indiquant que des données du ou d'un desdits clients sont disponibles pour ledit canal BIP et identifiant la connexion TCP associée au dit canal sur laquelle elles ont été reçues.
9. Méthode selon l'une des revendications précédentes caractérisée en ce que ledit terminal transmet au dit serveur un message d'évènement (Channel status event) indiquant qu'une connexion TCP associée au canal BIP a été établie ou a été fermée et identifiant cette connexion.
10. Méthode de communication entre un dispositif possédant une fonction SIM ((U)SIM), équipée d'un serveur (SCWS), et un ou plusieurs clients, ledit dispositif étant connecté à un terminal radiomobile et communiquant avec ce dernier au moyen d'au moins un canal BIP, caractérisée en ce que ledit terminal assure une fonction de passerelle entre ledit canal BIP et une pluralité de connexions TCP avec le ou lesdits clients.
FR0553531A 2005-11-21 2005-11-21 Methode de communication entre une cartre (u)sim en mode serveur et un client Pending FR2893803A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
FR0553531A FR2893803A1 (fr) 2005-11-21 2005-11-21 Methode de communication entre une cartre (u)sim en mode serveur et un client
PCT/JP2006/322828 WO2007058241A1 (fr) 2005-11-21 2006-11-16 Carte (u)sim en mode serveur et méthode de communication avec client
CN2006800435933A CN101313622B (zh) 2005-11-21 2006-11-16 服务器模式下的(u)sim卡与客户端之间的通信方法
EP06832717.0A EP1954086B1 (fr) 2005-11-21 2006-11-16 Carte (U)SIM en mode serveur et méthode de communication avec client
US12/094,224 US20090191917A1 (en) 2005-11-21 2006-11-16 Method of communication between a (u)sim card in a server mode and a client
JP2007545281A JP4930377B2 (ja) 2005-11-21 2006-11-16 サーバモードにおける（ｕ）ｓｉｍカードとクライアントとの通信方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0553531A FR2893803A1 (fr) 2005-11-21 2005-11-21 Methode de communication entre une cartre (u)sim en mode serveur et un client

Publications (1)

Publication Number Publication Date
FR2893803A1 true FR2893803A1 (fr) 2007-05-25

Family

ID=38016592

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0553531A Pending FR2893803A1 (fr) 2005-11-21 2005-11-21 Methode de communication entre une cartre (u)sim en mode serveur et un client

Country Status (6)

Country Link
US (1) US20090191917A1 (fr)
EP (1) EP1954086B1 (fr)
JP (1) JP4930377B2 (fr)
CN (1) CN101313622B (fr)
FR (1) FR2893803A1 (fr)
WO (1) WO2007058241A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2923633A1 (fr) * 2007-11-13 2009-05-15 Oberthur Card Syst Sa Carte a microprocesseur, telephone comprenant une telle carte et procede d'execution d'une commande dans une telle carte.
FR2923634A1 (fr) * 2007-11-13 2009-05-15 Oberthur Card Syst Sa Carte a microprocesseur, telephone comprenant une telle carte et procede d'execution d'une commande dans une telle carte.
FR2923632A1 (fr) * 2007-11-13 2009-05-15 Oberthur Card Syst Sa Carte a microprocesseur, telephone comprenant une telle carte et procede de traitement dans une telle carte.
DE102008004693A1 (de) * 2008-01-16 2009-08-13 Giesecke & Devrient Gmbh Portabler Datenträger mit CAT-Interpreter
EP2019533A3 (fr) * 2007-07-26 2009-09-30 Giesecke & Devrient GmbH Support de données doté d'un MIDlet

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007013339A1 (de) * 2007-03-20 2008-09-25 Giesecke & Devrient Gmbh Portabler Datenträger als Web-Server
EP2009605A1 (fr) * 2007-06-28 2008-12-31 Gemplus Procédé d'interaction avec les éléments physiques formant le contenu d'une machine
GB2457645B (en) * 2007-10-17 2012-05-16 Vodafone Plc Access control
WO2009060263A1 (fr) 2007-11-08 2009-05-14 Nokia Corporation Architecture de connectivité pour une découverte de services
CA2695677C (fr) 2007-11-13 2013-08-20 Nokia Corporation Procede et appareil comprenant un navigateur
KR100974469B1 (ko) * 2008-07-07 2010-08-10 주식회사 솔라시아 통합 메시지 관리 프로그램이 내장된 스마트카드를 구비한이동통신 단말기와, 이를 이용한 통합 메시지 관리 장치 및방법
JP5406289B2 (ja) * 2008-07-10 2014-02-05 エスケープラネット株式会社 スマートカード基盤の個人化サービスシステム及びその方法、そしてこれに適用されるスマートカード
CN101335758B (zh) * 2008-07-24 2011-09-21 中兴通讯股份有限公司 双处理器终端访问sim卡中服务的方法及系统
KR100957637B1 (ko) 2008-07-25 2010-05-13 주식회사 케이티 스마트 카드에 구현된 웹 서버로 컨텐츠를 제공하는 방법,이를 위한 컨텐츠 제공 서버 및 스마트 카드
KR100968961B1 (ko) * 2008-07-28 2010-07-14 주식회사 케이티 스마트 카드 웹 서버를 이용한 광고 정보 제공 방법, 이를 위한 스마트 카드 및 광고 제공 서버
KR100968963B1 (ko) * 2008-07-31 2010-07-14 주식회사 케이티 스마트카드 및 통신 단말에서 정보를 갱신하는 방법
KR100986840B1 (ko) * 2008-08-01 2010-10-12 주식회사 케이티 단말 관리 장치 및 방법
KR100968964B1 (ko) * 2008-08-06 2010-07-14 주식회사 케이티 단말 설정 방법 및 장치
KR100931736B1 (ko) 2008-09-29 2009-12-29 주식회사 케이티 스마트 카드 웹 서버를 이용하여 스마트 카드에 저장된 폰북 정보를 관리하는 방법 및 이를 위한 폰북 정보 관리 서버
KR100967361B1 (ko) 2008-10-14 2010-07-05 에스케이씨앤씨 주식회사 네트워크 개시 서비스를 이용하여 스마트 카드 웹서버의 관리 에이전트를 호출하는 방법
KR101164294B1 (ko) 2008-11-17 2012-07-09 에스케이플래닛 주식회사 스마트 카드 기반 메시징 서비스 시스템 및 그 방법
GB0821236D0 (en) * 2008-11-20 2008-12-31 Nec Corp Client-server communications in mobile radio communications device
CN101739247A (zh) * 2008-11-26 2010-06-16 爱思开电讯投资（中国）有限公司 一种集成平台
CN101754442A (zh) * 2008-11-28 2010-06-23 爱思开电讯投资（中国）有限公司 智能卡及提供一致性Web服务的方法和系统
CN102246212B (zh) 2008-12-16 2015-02-04 诺基亚公司 用于客户机的共享访问
CN101600265B (zh) * 2009-06-30 2012-07-04 中兴通讯股份有限公司 通用集成电路卡的确定方法及装置
CN101600263B (zh) * 2009-06-30 2011-05-11 中兴通讯股份有限公司 数据传输方法及终端
CN101594614B (zh) * 2009-06-30 2011-07-13 中兴通讯股份有限公司 数据下载方法以及终端
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
KR101025108B1 (ko) 2009-11-16 2011-03-25 에스케이씨앤씨 주식회사 이동 단말에게 균일한 응답시간을 제공하는 스마트카드 웹서버의 ｈｔｔｐ서비스 처리방법
GB2478971A (en) * 2010-03-25 2011-09-28 Nec Corp Generating a user interface on a mobile phone for an application on a UICC using metadata
CN101841925B (zh) * 2010-04-21 2012-10-17 华为终端有限公司 一种双中央微处理器间的通信方法、装置及系统
EP2458900A1 (fr) 2010-11-30 2012-05-30 Gemalto SA Procédé d'information sur la présence du support de dispositif distant
EP2461613A1 (fr) * 2010-12-06 2012-06-06 Gemalto SA Procédés et système pour la manipulation de données d'une UICC
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
CN102594892B (zh) * 2012-02-22 2018-08-24 南京中兴新软件有限责任公司 数据访问方法及装置
CN102724315B (zh) * 2012-06-21 2016-06-08 惠州Tcl云创科技有限公司 基于智能卡网页服务器实现智能卡远程操作的方法及系统
CN102752375B (zh) * 2012-06-21 2015-10-28 惠州Tcl移动通信有限公司 实现智能卡远程操作的方法及系统
US9094433B2 (en) * 2012-06-27 2015-07-28 Qualcomm Incorporated Systems and methods for bearer independent protocol gateway optimization
CN103888546B (zh) * 2014-04-15 2018-04-13 北京握奇数据系统有限公司 移动终端App与移动终端智能卡数据交互的方法及系统
CN106550351B (zh) * 2015-09-22 2020-07-07 联芯科技有限公司 传输bip协议数据的方法及所适用的移动设备
US10614133B2 (en) * 2018-02-08 2020-04-07 Timothy J Pollock Distributed web browser software architecture
EP3544252A1 (fr) * 2018-03-19 2019-09-25 Virtual Solution AG Procédés et appareil de commande d'accès spécifique d'une application à un réseau sécurisé

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10233606A1 (de) * 2002-07-24 2004-02-12 Siemens Ag Verfahren und Datensystem zum Anbinden eines drahtlosen lokalen Netzwerks an eine UMTS-Endstation
KR20050096930A (ko) * 2003-01-31 2005-10-06 악살토 에스.에이. 스마트카드와 서버 사이의 통신
US7702817B2 (en) * 2003-10-28 2010-04-20 Microsoft Corporation Wireless network access technologies for retrieving a virtual resource via a plurality of wireless network interfaces
US7421707B2 (en) * 2003-12-22 2008-09-02 Sun Microsystems, Inc. System and method for inducing asynchronous behavioral changes in a managed application process
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
EP1608123A1 (fr) * 2004-06-15 2005-12-21 Axalto SA Procédé et dispositif pour communiquer de messages HTTP avec des dispositifs portables
US7454233B2 (en) * 2004-09-23 2008-11-18 Gemalto Inc Communications of UICC in mobile devices using internet protocols
US20060168274A1 (en) * 2004-11-08 2006-07-27 Eliezer Aloni Method and system for high availability when utilizing a multi-stream tunneled marker-based protocol data unit aligned protocol
US8250214B2 (en) * 2004-12-20 2012-08-21 Vmware, Inc. System, method and computer program product for communicating with a private network
US20060198300A1 (en) * 2005-03-03 2006-09-07 Chia-Hsin Li Multi-channel TCP connections with congestion feedback for video/audio data transmission

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Smart Cards", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. SCP-WG1, no. V610, December 2004 (2004-12-01), XP014027288, ISSN: 0000-0001 *
"Smart cards", ETSI STANDARDS, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, SOPHIA-ANTIPO, FR, vol. SCP-WG3, no. V710, October 2005 (2005-10-01), XP014031813, ISSN: 0000-0001 *
REES J ET AL: "WEBCARD: A JAVA CARD WEB SERVER", SMART CARD RESEARCH AND ADVANCED APPLICATIONS. IFIP WORKING CONFERENCE ON SMART CARD RESEARCH AND ADVANCED APPLICATIONS, 20 September 2000 (2000-09-20), pages 197 - 207, XP001013569 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2019533A3 (fr) * 2007-07-26 2009-09-30 Giesecke & Devrient GmbH Support de données doté d'un MIDlet
FR2923633A1 (fr) * 2007-11-13 2009-05-15 Oberthur Card Syst Sa Carte a microprocesseur, telephone comprenant une telle carte et procede d'execution d'une commande dans une telle carte.
FR2923634A1 (fr) * 2007-11-13 2009-05-15 Oberthur Card Syst Sa Carte a microprocesseur, telephone comprenant une telle carte et procede d'execution d'une commande dans une telle carte.
FR2923632A1 (fr) * 2007-11-13 2009-05-15 Oberthur Card Syst Sa Carte a microprocesseur, telephone comprenant une telle carte et procede de traitement dans une telle carte.
EP2065858A3 (fr) * 2007-11-13 2009-12-02 Oberthur Technologies Carte à microprocesseur, téléphone comprenant une telle carte et procédé d'exécution d'une commande dans une telle carte
EP2065859A3 (fr) * 2007-11-13 2009-12-02 Oberthur Technologies Carte à microprocesseur, téléphone comprenant une telle carte et procédé de traitement dans une telle carte
EP2065857A3 (fr) * 2007-11-13 2009-12-02 Oberthur Technologies Carte à microprocesseur, téléphone comprenant une telle carte et procédé d'exécution d'une commande dans une telle carte
US8016203B2 (en) 2007-11-13 2011-09-13 Oberthur Technologies Smartcard, telephone comprising such a card and method for executing a command in such a card
US8066193B2 (en) 2007-11-13 2011-11-29 Oberthur Technologies Smartcard, telephone comprising such a card and method for executing a command in such a card
US8261996B2 (en) 2007-11-13 2012-09-11 Oberthur Technologies Smart card, telephone comprising such a card and method for executing a command in such a card
DE102008004693A1 (de) * 2008-01-16 2009-08-13 Giesecke & Devrient Gmbh Portabler Datenträger mit CAT-Interpreter
US8966108B2 (en) 2008-01-16 2015-02-24 Giesecke & Devrient Gmbh Portable data carrier comprising a CAT interpreter

Also Published As

Publication number Publication date
US20090191917A1 (en) 2009-07-30
JPWO2007058241A1 (ja) 2009-05-07
EP1954086B1 (fr) 2014-01-08
WO2007058241A1 (fr) 2007-05-24
EP1954086A4 (fr) 2011-04-13
CN101313622A (zh) 2008-11-26
EP1954086A1 (fr) 2008-08-06
CN101313622B (zh) 2011-09-07
JP4930377B2 (ja) 2012-05-16

Similar Documents

Publication Publication Date Title
FR2893803A1 (fr) Methode de communication entre une cartre (u)sim en mode serveur et un client
EP3632087B1 (fr) Sélection d'une tranche de réseau relative à une application
CA2393089C (fr) Procede d'adressage d'un terminal mobile
EP0996299B1 (fr) Procédé de lancement d'une application par un terminal, sous commande d'un module d'identification d'abonné
EP1678899B1 (fr) Procede et dispositif d acces a un terminal serveur mobile d un premier reseau de communication au moyen d un termi nal client d un autre reseau de communication
EP1726124A1 (fr) Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
WO2008012273A1 (fr) Procede de synchronisation entre un equipement mobile et une carte a puce
EP2692113B1 (fr) Procédé de mise a jour d'éléments sécurisés compris dans des terminaux d'un réseau de télécommunication et serveur de mise à jour correspondant
CA2804562A1 (fr) Procede d'etablissement d'une communication sur internet entre terminaux mobiles, programme d'ordinateur et support d'enregistrement
FR2847406A1 (fr) Procede et dispositif modulaire de tracage d'un message multimedia a travers un reseau de telecommunications
EP0996300B1 (fr) Procédé d'accès à un serveur de services à partir d'une station mobile, module d'identification d'abonné et terminal correspondants
EP1371251A1 (fr) Module de radiocommunication hebergeant et executant un logiciel client, et procede correspondant de mise en oeuvre d'un logiciel client de pilotage
EP2494801A1 (fr) Procédé d'établissement d'une session applicative, dispositif et notification correspondante
EP1850602B1 (fr) Procédé et système pour accélérer l'accès à un contenu à partir d'un terminal mobile
EP1494419B1 (fr) Système de transmission de paramètres caractéristiques d'une session de communication d'un terminal vers un serveur distant
EP2124413A1 (fr) Système et procédé pour effectuer une communication entre un serveur et équipement d'utilisateur
WO2020201321A1 (fr) Transmission de messages dans un contexte multi-terminaux
FR2819072A1 (fr) Procede de synchronisation de donnees sur une liaison serie
EP1239647A1 (fr) Procédé et dispositifs de sécurisation d'une session de communication
EP2553993A1 (fr) Procede et systeme de communication entre un equipement et un serveur
FR2850225A1 (fr) Procede perfectionne de generation d'une requete d'activation de contexte entre un equipement de communication et un reseau de communications
FR2908251A1 (fr) Procede et systeme de synchronisation de repertoires
WO2017060624A1 (fr) Moyens de gestion d'accès à des données
FR2785133A1 (fr) Procede d'acces a un serveur de service a partir d'une station mobile, module d'identification d'abonne et terminal correspondants
WO2002089447A2 (fr) Systeme et procede de communication entre stations traitant des dossiers communs