Bearer independent protocol giao thức bip là gì năm 2024

Uploaded by

api-3826672

0% found this document useful (0 votes)

1K views

181 pages

Copyright

© Attribution Non-Commercial (BY-NC)

Available Formats

PDF, TXT or read online from Scribd

Share this document

Did you find this document useful?

Is this content inappropriate?

0% found this document useful (0 votes)

1K views181 pages

Thuat Ngu Chuyen Nganh Vien Thong 165 274

Uploaded by

api-3826672

Jump to Page

You are on page 1of 181

Search inside document

Reward Your Curiosity

Everything you want to read.

Anytime. Anywhere. Any device.

No Commitment. Cancel anytime.

Bearer independent protocol giao thức bip là gì năm 2024

BIP có nghĩa là gì? Trên đây là một trong những ý nghĩa của BIP. Bạn có thể tải xuống hình ảnh dưới đây để in hoặc chia sẻ nó với bạn bè của bạn thông qua Twitter, Facebook, Google hoặc Pinterest. Nếu bạn là một quản trị viên web hoặc blogger, vui lòng đăng hình ảnh trên trang web của bạn. BIP có thể có các định nghĩa khác. Vui lòng cuộn xuống để xem định nghĩa của nó bằng tiếng Anh và năm nghĩa khác trong ngôn ngữ của bạn.

Ý nghĩa của BIP

Hình ảnh sau đây trình bày một trong những định nghĩa về BIP trong ngôn ngữ tiếng Anh.Bạn có thể tải xuống tệp hình ảnh ở định dạng PNG để sử dụng ngoại tuyến hoặc gửi hình ảnh định nghĩa BIP cho bạn bè của bạn qua email.

Bearer independent protocol giao thức bip là gì năm 2024

Ý nghĩa khác của BIP

Như đã đề cập ở trên, BIP có ý nghĩa khác. Xin biết rằng năm ý nghĩa khác được liệt kê dưới đây.Bạn có thể nhấp vào liên kết ở bên trái để xem thông tin chi tiết của từng định nghĩa, bao gồm các định nghĩa bằng tiếng Anh và ngôn ngữ địa phương của bạn.

Protocol Conversion "Bearer Independent Protocol (Bip)" - Tcp/Ip for Communication Between Sim and Terminal Download PDF

Info

Publication number US20070239857A1US20070239857A1 US11/629,546 US62954605A US2007239857A1 US 20070239857 A1 US20070239857 A1 US 20070239857A1 US 62954605 A US62954605 A US 62954605A US 2007239857 A1 US2007239857 A1 US 2007239857A1 Authority US United States Prior art keywords electronic device http tcp smart card server Prior art date 2004-06-15 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.)Granted Application number US11/629,546 Other versionsUS8447836B2 (en Inventor Ilan Mahalal Nicolas Chaumartin Jorge 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 Axalto 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.) 2004-06-15 Filing date 2005-06-10 Publication date 2007-10-11 2005-06-10Application filed by Axalto SA filed Critical Axalto SA 2006-12-14Assigned to AXALTO SA reassignment AXALTO SA ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SEVILLA, JORGE ABELLAN, MAHALAL, ILAN 2007-10-11Publication of US20070239857A1 publication Critical patent/US20070239857A1/en 2011-11-11Assigned to GEMALTO SA reassignment GEMALTO SA CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: AXALTO SA 2013-05-21Application granted granted Critical 2013-05-21Publication of US8447836B2 publication Critical patent/US8447836B2/en StatusExpired - Fee Related legal-status Critical Current 2027-05-14Adjusted expiration legal-status Critical

Links

  • USPTO
  • USPTO PatentCenter
  • Espacenet
  • Discuss

Images

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

Definitions

  • the present invention generally relates to the exchange of data between a first electronic device and a second electronic device, and more specifically to the exchange of HTTP (Hypertext Transfer Protocol) messages between a web server being implemented by or running on the first electronic device and a web browser running on the second electronic device.
  • HTTP Hypertext Transfer Protocol
  • the first electronic device according to the invention a portable device
  • the second electronic device according to the invention is external to the portable device.
  • the first electronic or portable device will be an integrated circuit card or smart card, in particular the ones compatible with ISO 7816-4, comprising platforms such as (U)SIM ((U) Subscriber Identification Module), UICC, R-UIM (Removable—User Identification Module) and WIM (Wireless Identification Module), and the second electronic or external device will be a smart card terminal in the form of a mobile telephone.
  • the portable device is a Multi Media Memory card
  • the external device is a PDA (Personal Digital Assistant) or a PC (Personal Computer).
  • Web servers such as HTTP or HTTPS servers can be embedded in portable devices like smart cards. Resources residing on the smart card can then be accessed via HTTP by an application running on the terminal to which the smart card is connected. Furthermore, since HTTP is designed to transmit hypertext pages, a web browser can be used on the terminal, e.g. as a user interface for smart card applications.
  • the application layer Internet protocol HTTP is designed to be used over TCP/IP (Transmission Control Protocol/Internet Protocol) and standard browsers use TCP/IP to transmit HTTP messages.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • standard browsers use TCP/IP to transmit HTTP messages.
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • other protocols usually other protocols than TCP are used on transport layer level.
  • current smart card solutions hosting a web server use proprietary protocols for transmission of HTTP messages.
  • the object is achieved by a method of offering the services of an HTTP or HTTPS server, the server being implemented by or running on a first electronic device, to a second electronic device, where the first electronic device exchanges RTTP messages with the second electronic device over a communication channel between the first and the second electronic device according to the Bearer Independent Protocol.
  • the HTTP messages communicated by the first electronic device to the second electronic device over the communication channel are determined to be further communicated within the second electronic device over TCP/IP to an application running on the second electronic device, and the HTTP messages received by the first electronic device from the second electronic device have been communicated within the second electronic device over TCP/IP.
  • the application for exchanging the HTTP messages with the server can use TCP/IP, which is the standard protocol for exchanging HTTP messages.
  • the application running on the second electronic device is a web browser and the HTTP or HTTPS server serves HTML, xHTML, cHTML or WML pages to this web browser.
  • hypertext pages can be used, e.g., to form the user interface of an application running on the first electronic device.
  • the DECLARE SERVICE command is used to notify the second electronic device that the first electronic device offers the services of the HTTP or HTTPS server.
  • the user can be authenticated with a standard HTTP WW-Authenticate delivering PIN-Type and/or PIN-Value attributes.
  • the first electronic device is a smart card.
  • the first electronic device is a Multi Media Memory card.
  • One preferred embodiment of the inventions is a computer program element comprising computer program code means to make a first electronic device execute the previously described method.
  • Another preferred embodiment of the invention is an electronic device implementing or running an HTTP or HTTPS server and executing the previously described method.
  • a further embodiment of the invention is a method of enabling an application running on a second electronic device to use the TCP/IP protocol for exchanging HTTP messages with an HTTP or HTTPS server being implemented by or running on a first electronic device, a communication channel according to the Bearer Independent Protocol being used for exchanging the HTTP messages between the second electronic device and the first electronic device, on the second electronic device the communication channel being managed by a gateway which performs protocol conversion Bearer Independent Protocol—TCP/IP for messages being received from the HTTP or HTTPS server, and protocol conversion TCP/IP—Bearer Independent Protocol for messages being sent to HTTP or HTTPS server.
  • TCP/IP Bearer Independent Protocol
  • the application running the second electronic device can then establish a TCP/IP connection to the gateway just as if the connection was established to the HTTP server directly, which makes the use of the Bearer Independent Protocol transparent to the application.
  • an internal IP address and an internal domain name are allocated for the gateway and the internal domain name is mapped to the internal IP address, and the internal domain name is used in Uniform Resource Identifiers to indicate that the Uniform Resource Identifier identifies a resource on the first electronic device.
  • the first electronic device is a smart card and the Uniform Resource Identifier comprises information to access standardized smart card applications such as (U)SIM and WIM applications.
  • the application running on the second electronic device can serve for displaying a hypertext user interface of the smart card application.
  • a command is sent to the first electronic device in order to open a communication channel when the application running on the second electronic device opens a TCP/IP socket to the gateway.
  • the communication channel between the gateway and the HTTP server can then be used as a continuation of a TCP/IP connection between the application running on the second electronic device and the gateway.
  • the TCP/IP socket is mapped to the opened channel.
  • Each communication channel can then be used as a dedicated channel for one socket connection, simplifying the forwarding of HTTP messages in the gateway.
  • the second electronic device is a web browser.
  • a web browser is a standard application for displaying hypertext pages and accessing a web server using HTTP.
  • the second electronic device is a mobile telephone.
  • the second electronic device is a PDA.
  • the second electronic device is a PC.
  • One preferred embodiment of the inventions is a Computer program element comprising computer program code means to make a device execute the previously described method.
  • Another preferred embodiment of the invention is a device running an application and executing the previously described method.
  • FIG. 1 is a schematic diagram showing how data is transmitted between a smart card and a remote server using the Bearer Independent Protocol and TCP/IP.
  • FIG. 2 is a schematic diagram showing a preferred embodiment of the invention, in particular the components used for data transmission on the external device.
  • FIG. 3 is a schematic diagram illustrating how data is exchanged between a smart card web server and a terminal web client using a routing table.
  • FIG. 4 is a diagram showing the command sequence for the service declaration between smart card and terminal.
  • FIG. 5 is a diagram showing the command sequence for the opening of a communication channel between the smart card and the terminal.
  • FIG. 6 is a diagram showing the command sequence for sending data from the terminal web browser to the smart card.
  • proactive UICC commands according to the Bearer Independent Protocol as defined in ETSI TS 102 223 (e.g. section 4.11 and section 6), in the following called “BIP commands”, are used for communicating HTTP messages between the first electronic device and the external device.
  • the Bearer Independent Protocol is the set of commands (OPEN CHANNEL, CLOSE CHANNEL, SEND DATA, RECEIVE DATA, and GET CHANNEL STATUS) and events (Data available, Channel status) which allows a smart card to establish a communication channel with a terminal, and through the terminal to a remote server or a remote device in a network. Between the smart card and the terminal existing lower protocol layers are used to exchange data on the communication channel. Between the terminal and the remote server or remote device different protocols can be used, to make the use of the Bearer Independent Protocol transparent to the remote server or remote device.
  • FIG. 1 shows an example of a communication between a smart card 1 and remote server 13 through a terminal 2 , using TCP/IP between the terminal and the remote server.
  • step 100 the communication channel is established between the smart card 1 and the terminal 2 .
  • step 101 the terminal 2 receives data from the card 1 via the SEND command, which the terminal in step 102 inserts into TCP packets and sends them to the remote server 13 over a previously established TCP/IP connection.
  • step 103 the terminal 2 receives data from the remote server 13 over the TCP/IP connection, strips the data from the TCP packets and sends it to the card 1 in step 104 , where the card 1 is notified by the terminal 2 using a Data available event, whereupon the card 1 pulls the data from the terminal 2 sending a RECEIVE command.
  • FIG. 2 shows how HTTP messages according to the invention are communicated between a server running on a first electronic device 1 , like a web server running on a smart card, and an application 23 running on an external device 2 , like a web browser on a smart card terminal.
  • This browser can be, e.g., a browser for displaying HTML (Hypertext Modelling Language), xHTML (extensible HTML), cHTML (compact HTML) or WML (Wireless Markup Language) pages.
  • HTML Hypertext Modelling Language
  • xHTML extensible HTML
  • cHTML compact HTML
  • WML Wireless Markup Language
  • the messages are not transmitted directly via a TCP/IP connection between the server and the browser 23 , but via a gateway 24 residing on the terminal 2 .
  • HTTP messages between the server and the gateway 24 are communicated over communication channels using BIP commands.
  • HTTP messages between the gateway 24 and the browser 23 are communicated over TCP/IP sockets.
  • the browser 23 instead of establishing a TCP/IP connection to the server, the browser 23 establishes this connection to the gateway 24 .
  • the gateway 24 forwards the HTTP messages received via the TCP/IP connection from the browser 23 to the server via the communication channel, and in the other direction it forwards the HTTP messages received from the server via the communication channel to the browser 23 via the TCP/IP connection.
  • URI Uniforms Resource Identifiers
  • the domain name denoting the smart card in the example “localsmartcard”, is mapped to an internal IP address which is assigned to the gateway. This mapping will be fixed e.g. in a static routing and DNS table 25 residing on the smart card.
  • the web browser 23 wants to access a smart card resource identified by a URI, it is directed to the gateway 24 by the routing and DNS table 25 .
  • This configuration is illustrated in FIG. 3 , showing that a web browser 23 communicates with a smart card web server 4 by consulting a routing table 25 .
  • a smart card 1 running a web server 4 may indicate this service to the terminal using the “DECLARE SERVICE” command, e.g. with the command sequence proposed in ETSI TS 102 223 (annex M) and as shown in FIG. 4 .
  • the service declaration typically will be carried out at startup.
  • the gateway triggers the opening of a communication channel, e.g. by using the command sequence proposed in ETSI TS 102 223, annex M, and as shown in FIG. 5 .
  • the gateway sends an ENVELOPE (Local connection), to make the smart card 1 send an OPEN CHANNEL command to the terminal 2 .
  • ENVELOPE command is an APDU command used to transmit data to an application residing on the smart card 1 , see e.g. ETSI TS 102 221, section 7.4.2.2; the OPEN CHANNEL command is a BIP command as defined in ETSI TS 102 223, section 6.4.27.
  • the gateway opens a new communication channel each time the web browser opens a TCP/IP socket to the gateway.
  • a socket represents an endpoint of communication on which a connection can be established.
  • the gateway then preferably maps the opened socket to the opened channel, so that for each socket which the web browser intends to open to the web server 4 a dedicated communication channel is created between the web server 4 and the gateway 25 .
  • the gateway performs protocol conversion between the Bearer Independent Protocol and TCP/IP by sending the HTTP messages received via the TCP/IP socket from the web browser 23 to the web server 4 via the communication channel, and sending the HTTP messages received from the web server 4 via the communication channel to the web browser 23 via the TCP/IP socket.
  • FIG. 6 An example of the command sequence for sending data from the web browser 23 to the web server 4 is given in FIG. 6 , in accordance with annex M of ETSI TS 102 223.
  • the gateway after having received data from the web browser 23 , sends an ENVELOPE command to the smart card to inform it that data has arrived and to make it send a RECEIVE DATA command.
  • the RECEIVE DATA command is a BIP command as defined in ETSI TS 102 223, section 6.4.29. This command indicates to the gateway the maximum data length the smart card is willing to receive.
  • the gateway transmits the data using a TERMINAL RESPONSE command.
  • TERMINAL RESPONSE is an APDU command as defined in ETSI TS 102 221, section 10.1. Note that a channel identifier identifying the communication channel on which the communication takes place is transmitted as a parameter in both the ENVELOPE and RECEIVE DATA commands.
  • a similar mechanism is employed for transmission of HTTP messages in the other direction, i.e. from the web server 4 to the web browser 23 .
  • a SEND DATA command will be sent from the smart card 1 to the gateway 24 .
  • the SEND DATA command is a BIP command as defined in ETSI TS 102 223, section 6.4.30. It will be used for transmitting the HTTP message from the web server 4 to the gateway 24 , so that the latter can forward it via TCP/IP to the web browser 23 .
  • each of the components ⁇ authority>, ⁇ path> and ? ⁇ query> may be absent in a particular URI.
  • ⁇ authority> denotes a top hierarchical element for a naming authority.
  • the intended usage of a smart card URI generally is for local smart card content accessed by a terminal web browser 23 . Therefore, the authority component could be a domain name like “localsmartcard”.
  • the ⁇ path> component identifies the resource within the scope of the scheme and authority.
  • ⁇ ef> ⁇ df> 2*[ ⁇ BYTE]
  • ⁇ DIGIT> “1”
  • “df” stands for a smart card Dedicated File, which corresponds to a directory in the smart card file system
  • ef stands for a smart card Elememtary File, which corresponds to a smart card data file.
  • USIM and WIM refer to a USIM (Universal Subscriber Identity Module, see 3GPP TS 31.102) and WIM (Wireless Identity Module) Application Dedicated File (ADF) when a smart card contains such an application.
  • USIM Universal Subscriber Identity Module
  • WIM Wireless Identity Module
  • ADF Application Dedicated File
  • the ⁇ query> component is a string of information to be interpreted by the resource.
  • ⁇ state> ⁇ http_query> n*[BYTE]
  • the ⁇ state> component is a string that could be used as an indication to the smart card framework at which entry point to begin the execution of an application which creates dynamic content as response to an HTTP request.
  • the smart card server 4 can provide means to enable this security conditions as they are defined for local terminal-application APDU protocols. E.g., it may issue a request in order to ask the user a PIN (Personal Identity Number).
  • PIN Personal Identity Number
  • the authorization is performed between the client application 23 and the smart card server 4 , using the standard HTTP authorization exchange, which is briefly depicted in the following:
  • the smart card server 4 will respond to an HTTP request with an HTTP response message containing a Status-Line with a status code “401” (Unauthorized) and a WWW-Authenticate field consisting of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
  • the response will be sent to the client application 23 .
  • the client application 23 should then perform the corresponding dialog with the user (e.g. request PIN or password) and send back the request including an Authorization request header containing the Authorization credentials.
  • the PIN value is passed in the response data field.
  • the username if present, may be ignored by the smart card server 23 .
  • the access verification in this case is PIN verification.
  • the VERIFY PIN command must be sent with the following data: Byte(s) Description Length 1-8 PIN value 8
  • the browser sends the following HTTP GET request to the smart card:
  • the smart card gateway sends the request in BIP commands.
  • the command data is: Byte(s) Description Length 1-Lc GET http://localsmartcard/7F40/5F30 HTTP/1.1 Lc
  • the smart card server 4 may then retrieve the corresponding resource (e.g. content of a file) and send it back with the following HTTP Response sent in BIP commands: Byte(s) Description Length 1-Le HTTP/1.1 200 OK Le Content-type: text/plain Content-length: 3406 This is the content of the file
  • the gateway 24 When receiving the response, the gateway 24 will encapsulate it in a TCP/IP packet and send it as an HTTP response packet to the browser.
  • the URI field can be in absolute form. (e.g. http://localsmartcard/12A1) respecting the rules for smart card URIs as defined in this document.
  • HTTP version which should be implemented on the smart card web server 4 is HTTP/1.1.
  • HTTP 1.1 specification in RFC 2616, the value of the HTTP-Version field should be “HTTP/1.1”.
  • the smart card web server 4 will ignore the non-supported fields.
  • the “Host” field shall be omitted, since requested URI is always in absolute form.
  • Client Error Status-Code 401 Unauthorized
  • the smart card web server may support the following ENTITY header fields, for each of the HTTP request messages.
  • “Content-Type” HTTP header field should be included by the smart card server depending on the resource being transferred within the HTTP response.

Abstract

The services of an HTTP or HTTPS server, being implemented by or running on a first electronic device, are offered to a second electronic device by exchanging HTTP messages between the first electronic device and the second electronic device over a communication channel according to the Bearer Independent Protocol. An application running on the second electronic device can use the TCP/IP protocol for exchanging HTTP messages with the server A gateway is employed on the second electronic device, which manages the communication channel and which performs protocol conversion Bearer Independent Protocol—TCP/IP for messages received from the application running on the second electronic device, and protocol conversion TCP/IP—Bearer Independent Protocol for messages being sent to the server.

Description

BACKGROUND OF THE INVENTION

  • 1. Field of the Invention
  • The present invention generally relates to the exchange of data between a first electronic device and a second electronic device, and more specifically to the exchange of HTTP (Hypertext Transfer Protocol) messages between a web server being implemented by or running on the first electronic device and a web browser running on the second electronic device.
  • The first electronic device according to the invention a portable device, and the second electronic device according to the invention is external to the portable device. In the main application of the invention, the first electronic or portable device will be an integrated circuit card or smart card, in particular the ones compatible with ISO 7816-4, comprising platforms such as (U)SIM ((U) Subscriber Identification Module), UICC, R-UIM (Removable—User Identification Module) and WIM (Wireless Identification Module), and the second electronic or external device will be a smart card terminal in the form of a mobile telephone. We will use the example of a smart card and a terminal throughout this description. The invention nevertheless can be applied to other cases where e.g. the portable device is a Multi Media Memory card or the external device is a PDA (Personal Digital Assistant) or a PC (Personal Computer).
  • 2. Background Art
  • Web servers such as HTTP or HTTPS servers can be embedded in portable devices like smart cards. Resources residing on the smart card can then be accessed via HTTP by an application running on the terminal to which the smart card is connected. Furthermore, since HTTP is designed to transmit hypertext pages, a web browser can be used on the terminal, e.g. as a user interface for smart card applications.
  • The application layer Internet protocol HTTP is designed to be used over TCP/IP (Transmission Control Protocol/Internet Protocol) and standard browsers use TCP/IP to transmit HTTP messages. However, for data transmission between a smart card and a terminal, usually other protocols than TCP are used on transport layer level. In particular, current smart card solutions hosting a web server use proprietary protocols for transmission of HTTP messages. SUMMARY OF THE INVENTION
  • It is therefore an object of the invention to provide the mechanisms for exchanging HTTP messages between a web server embedded in a portable device, like a smart card, and an application running on an external device, like a web browser running on a smart card terminal, using existing transport layers on the smart card.
  • It is a further object of the invention to allow the application running on the external device to use TCP/IP for the exchange of HTTP messages, just as if there was a TCP/IP connection between this application and the web server embedded in the portable device.
  • This object is achieved by the methods and the devices as defined in independent claims 1, 8 and 9 and 10, 19 and 20. Further preferred embodiments are defined in the dependent claims.
  • According to a preferred embodiment of the invention, the object is achieved by a method of offering the services of an HTTP or HTTPS server, the server being implemented by or running on a first electronic device, to a second electronic device, where the first electronic device exchanges RTTP messages with the second electronic device over a communication channel between the first and the second electronic device according to the Bearer Independent Protocol.
  • This has the advantage that standard mechanisms and commands as defined by standardization bodies like 3GPP (3rd Generation Partnership Project) and ETSI (European Telecommunications Standards Institute) can be used to exchange HTTP messages between the first and the second electronic device.
  • According to a further preferred embodiment of the invention, the HTTP messages communicated by the first electronic device to the second electronic device over the communication channel are determined to be further communicated within the second electronic device over TCP/IP to an application running on the second electronic device, and the HTTP messages received by the first electronic device from the second electronic device have been communicated within the second electronic device over TCP/IP.
  • This has the advantage that the application for exchanging the HTTP messages with the server can use TCP/IP, which is the standard protocol for exchanging HTTP messages. According to a further preferred embodiment of the invention, the application running on the second electronic device is a web browser and the HTTP or HTTPS server serves HTML, xHTML, cHTML or WML pages to this web browser.
  • By doing so, hypertext pages can be used, e.g., to form the user interface of an application running on the first electronic device.
  • According to a further preferred embodiment of the invention, the DECLARE SERVICE command is used to notify the second electronic device that the first electronic device offers the services of the HTTP or HTTPS server.
  • This allows the first electronic device to download into the database of the second electronic device the information that the first electronic device provides the services of a web server.
  • According to a further preferred embodiment of the invention, the user can be authenticated with a standard HTTP WW-Authenticate delivering PIN-Type and/or PIN-Value attributes.
  • This allows user identification by solely using HTTP messages understood by a web browser, rendering the use of other commands like APDU (Application Protocol Data Unit) commands unnecessary.
  • In a preferred embodiment of the invention the first electronic device is a smart card.
  • In another preferred embodiment of the invention the first electronic device is a Multi Media Memory card.
  • One preferred embodiment of the inventions is a computer program element comprising computer program code means to make a first electronic device execute the previously described method.
  • Another preferred embodiment of the invention is an electronic device implementing or running an HTTP or HTTPS server and executing the previously described method.
  • A further embodiment of the invention is a method of enabling an application running on a second electronic device to use the TCP/IP protocol for exchanging HTTP messages with an HTTP or HTTPS server being implemented by or running on a first electronic device, a communication channel according to the Bearer Independent Protocol being used for exchanging the HTTP messages between the second electronic device and the first electronic device, on the second electronic device the communication channel being managed by a gateway which performs protocol conversion Bearer Independent Protocol—TCP/IP for messages being received from the HTTP or HTTPS server, and protocol conversion TCP/IP—Bearer Independent Protocol for messages being sent to HTTP or HTTPS server.
  • The application running the second electronic device can then establish a TCP/IP connection to the gateway just as if the connection was established to the HTTP server directly, which makes the use of the Bearer Independent Protocol transparent to the application.
  • According to a further preferred embodiment of the invention, an internal IP address and an internal domain name are allocated for the gateway and the internal domain name is mapped to the internal IP address, and the internal domain name is used in Uniform Resource Identifiers to indicate that the Uniform Resource Identifier identifies a resource on the first electronic device.
  • When the application running on the second electronic device wants to access the resource identified by the Uniform Resource Locator, its HTTP request via TCP/IP will be directed to the gateway, where it can be passed on to the smart card server.
  • According to a further preferred embodiment of the invention, the first electronic device is a smart card and the Uniform Resource Identifier comprises information to access standardized smart card applications such as (U)SIM and WIM applications.
  • By doing so, the application running on the second electronic device can serve for displaying a hypertext user interface of the smart card application.
  • According to a further preferred embodiment of the invention, a command is sent to the first electronic device in order to open a communication channel when the application running on the second electronic device opens a TCP/IP socket to the gateway.
  • The communication channel between the gateway and the HTTP server can then be used as a continuation of a TCP/IP connection between the application running on the second electronic device and the gateway.
  • According to a further preferred embodiment of the invention, the TCP/IP socket is mapped to the opened channel.
  • Each communication channel can then be used as a dedicated channel for one socket connection, simplifying the forwarding of HTTP messages in the gateway.
  • According to a further preferred embodiment of the invention, the second electronic device is a web browser.
  • A web browser is a standard application for displaying hypertext pages and accessing a web server using HTTP.
  • According to a further preferred embodiment of the invention the second electronic device is a mobile telephone.
  • According to a further preferred embodiment of the invention the second electronic device is a PDA.
  • According to a further preferred embodiment of the invention the second electronic device is a PC.
  • One preferred embodiment of the inventions is a Computer program element comprising computer program code means to make a device execute the previously described method.
  • Another preferred embodiment of the invention is a device running an application and executing the previously described method. BRIEF DESCRIPTION OF THE DRAWINGS
  • The foregoing and other objects, aspects and advantages of the invention will be better understood from the following detailed description of the preferred embodiments of the invention made with reference to the drawings, in which:
  • FIG. 1 is a schematic diagram showing how data is transmitted between a smart card and a remote server using the Bearer Independent Protocol and TCP/IP.
  • FIG. 2 is a schematic diagram showing a preferred embodiment of the invention, in particular the components used for data transmission on the external device.
  • FIG. 3 is a schematic diagram illustrating how data is exchanged between a smart card web server and a terminal web client using a routing table.
  • FIG. 4 is a diagram showing the command sequence for the service declaration between smart card and terminal.
  • FIG. 5 is a diagram showing the command sequence for the opening of a communication channel between the smart card and the terminal.
  • FIG. 6 is a diagram showing the command sequence for sending data from the terminal web browser to the smart card. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION
  • According to the invention, proactive UICC commands according to the Bearer Independent Protocol as defined in ETSI TS 102 223 (e.g. section 4.11 and section 6), in the following called “BIP commands”, are used for communicating HTTP messages between the first electronic device and the external device. The Bearer Independent Protocol is the set of commands (OPEN CHANNEL, CLOSE CHANNEL, SEND DATA, RECEIVE DATA, and GET CHANNEL STATUS) and events (Data available, Channel status) which allows a smart card to establish a communication channel with a terminal, and through the terminal to a remote server or a remote device in a network. Between the smart card and the terminal existing lower protocol layers are used to exchange data on the communication channel. Between the terminal and the remote server or remote device different protocols can be used, to make the use of the Bearer Independent Protocol transparent to the remote server or remote device.
  • FIG. 1 shows an example of a communication between a smart card 1 and remote server 13 through a terminal 2, using TCP/IP between the terminal and the remote server. In step 100 the communication channel is established between the smart card 1 and the terminal 2. In step 101 the terminal 2 receives data from the card 1 via the SEND command, which the terminal in step 102 inserts into TCP packets and sends them to the remote server 13 over a previously established TCP/IP connection. In step 103 the terminal 2 receives data from the remote server 13 over the TCP/IP connection, strips the data from the TCP packets and sends it to the card 1 in step 104, where the card 1 is notified by the terminal 2 using a Data available event, whereupon the card 1 pulls the data from the terminal 2 sending a RECEIVE command.
  • However, while the Bearer Independent Protocol is actually designed to facilitate communication between a smart card and a remote server or remote device outside the terminal, BIP commands can also be used for communication between the smart card and an application running locally on the terminal. FIG. 2 shows how HTTP messages according to the invention are communicated between a server running on a first electronic device 1, like a web server running on a smart card, and an application 23 running on an external device 2, like a web browser on a smart card terminal. This browser can be, e.g., a browser for displaying HTML (Hypertext Modelling Language), xHTML (extensible HTML), cHTML (compact HTML) or WML (Wireless Markup Language) pages.
  • The messages are not transmitted directly via a TCP/IP connection between the server and the browser 23, but via a gateway 24 residing on the terminal 2. HTTP messages between the server and the gateway 24 are communicated over communication channels using BIP commands. HTTP messages between the gateway 24 and the browser 23 are communicated over TCP/IP sockets.
  • In other words, instead of establishing a TCP/IP connection to the server, the browser 23 establishes this connection to the gateway 24. The gateway 24 forwards the HTTP messages received via the TCP/IP connection from the browser 23 to the server via the communication channel, and in the other direction it forwards the HTTP messages received from the server via the communication channel to the browser 23 via the TCP/IP connection.
  • In HTTP requests, Uniforms Resource Identifiers (URI) are used to identify a requested resource, see specification of the Hypertext Transfer Protocol version 1.1 in RFC 2616, section 5. To access the smart card, URIs like http://localsmartcard will be used. The domain name denoting the smart card, in the example “localsmartcard”, is mapped to an internal IP address which is assigned to the gateway. This mapping will be fixed e.g. in a static routing and DNS table 25 residing on the smart card. When the web browser 23 wants to access a smart card resource identified by a URI, it is directed to the gateway 24 by the routing and DNS table 25. This configuration is illustrated in FIG. 3 , showing that a web browser 23 communicates with a smart card web server 4 by consulting a routing table 25.
  • It is the task of the gateway to manage the communication channels and to perform protocol conversion between the Bearer Independent Protocol and TCP/IP, as will now be explained.
  • In an initial phase, a smart card 1 running a web server 4 according to a preferred embodiment of the invention may indicate this service to the terminal using the “DECLARE SERVICE” command, e.g. with the command sequence proposed in ETSI TS 102 223 (annex M) and as shown in FIG. 4 . The service declaration typically will be carried out at startup.
  • The first time the web browser connects to the gateway in order to access the HTTP server, the gateway triggers the opening of a communication channel, e.g. by using the command sequence proposed in ETSI TS 102 223, annex M, and as shown in FIG. 5 . The gateway sends an ENVELOPE (Local connection), to make the smart card 1 send an OPEN CHANNEL command to the terminal 2. The ENVELOPE command is an APDU command used to transmit data to an application residing on the smart card 1, see e.g. ETSI TS 102 221, section 7.4.2.2; the OPEN CHANNEL command is a BIP command as defined in ETSI TS 102 223, section 6.4.27.
  • In a preferred embodiment of the invention, the gateway opens a new communication channel each time the web browser opens a TCP/IP socket to the gateway. A socket represents an endpoint of communication on which a connection can be established. The gateway then preferably maps the opened socket to the opened channel, so that for each socket which the web browser intends to open to the web server 4 a dedicated communication channel is created between the web server 4 and the gateway 25.
  • Once the communication channel is established, data can be exchanged between the web browser 23 and the web server 4. The gateway performs protocol conversion between the Bearer Independent Protocol and TCP/IP by sending the HTTP messages received via the TCP/IP socket from the web browser 23 to the web server 4 via the communication channel, and sending the HTTP messages received from the web server 4 via the communication channel to the web browser 23 via the TCP/IP socket.
  • An example of the command sequence for sending data from the web browser 23 to the web server 4 is given in FIG. 6 , in accordance with annex M of ETSI TS 102 223. The gateway, after having received data from the web browser 23, sends an ENVELOPE command to the smart card to inform it that data has arrived and to make it send a RECEIVE DATA command. The RECEIVE DATA command is a BIP command as defined in ETSI TS 102 223, section 6.4.29. This command indicates to the gateway the maximum data length the smart card is willing to receive. The gateway then transmits the data using a TERMINAL RESPONSE command. TERMINAL RESPONSE is an APDU command as defined in ETSI TS 102 221, section 10.1. Note that a channel identifier identifying the communication channel on which the communication takes place is transmitted as a parameter in both the ENVELOPE and RECEIVE DATA commands.
  • For transmission of HTTP messages in the other direction, i.e. from the web server 4 to the web browser 23, a similar mechanism is employed. Instead of a RECEIVE DATA, a SEND DATA command will be sent from the smart card 1 to the gateway 24. The SEND DATA command is a BIP command as defined in ETSI TS 102 223, section 6.4.30. It will be used for transmitting the HTTP message from the web server 4 to the gateway 24, so that the latter can forward it via TCP/IP to the web browser 23.
  • In the following, the syntax of a smart card URI, whose use in HTTP requests was already mentioned above, will be explained in greater detail. The general URI syntax is defined in RFC 2396 as follows:
  • <scheme>:<scheme-specific-part>
  • In the context of the present invention, the scheme “http” is used.
  • In a great number of URIs, the general syntax of <scheme-specific-part> is
  • //<authority><path>?<query>
  • where each of the components <authority>, <path> and ?<query> may be absent in a particular URI.
  • <authority> denotes a top hierarchical element for a naming authority. In the context of the present invention, the intended usage of a smart card URI generally is for local smart card content accessed by a terminal web browser 23. Therefore, the authority component could be a domain name like “localsmartcard”.
  • The <path> component identifies the resource within the scope of the scheme and authority. A complete syntax of the path component for the local smart card can be depicted as follows: <path> = [“/”sc_resource]* <sc_resource> = <df> | <ef> <df> = 2*[<BYTE] | “USIM” | “WIM” | <aid> <ef> = 2*[<BYTE>] <aid> = “AID=”16*[BYTE] <BYTE> = 2*[HEX] <HEX> = “A” | “B” | “C” | “D” | “E” | “F”| “a” | “b” | “c” | “d” | “e” | “f” | <DIGIT> <DIGIT> = “1” | “2” | “3” | “4” | “5” | “6” | “7” | “8” | “9” | “0”
  • “df” stands for a smart card Dedicated File, which corresponds to a directory in the smart card file system, “ef” stands for a smart card Elememtary File, which corresponds to a smart card data file.
  • “USIM” and “WIM” refer to a USIM (Universal Subscriber Identity Module, see 3GPP TS 31.102) and WIM (Wireless Identity Module) Application Dedicated File (ADF) when a smart card contains such an application.
  • Examples for URIs with authority and path components as defined above are:
  • http://localsmartcardlUSIM/12A1
  • http://localsmartcardl3F00
  • The <query> component is a string of information to be interpreted by the resource. A proposed syntax is: <query> = <http_query> | <state> <http_query> = n*[BYTE]
  • The <state> component is a string that could be used as an indication to the smart card framework at which entry point to begin the execution of an application which creates dynamic content as response to an HTTP request.
  • Within a query component, the characters “;”, “/”, “?”, “:”, “@”, “&”, “=”, “+”, “,”, and “$” should be reserved.
  • Examples of URIs with query components according to the above definition are: http://localsmartsard/3F00/2F24?record=02 http://localsmartcard/12121215199764382564579867542734/?state=entry1
  • In the following, some security considerations for access through a web server to resources residing on the smart card will be outlined.
  • If the smart card resource requires an access condition which has not been fulfilled, the smart card server 4 can provide means to enable this security conditions as they are defined for local terminal-application APDU protocols. E.g., it may issue a request in order to ask the user a PIN (Personal Identity Number).
  • The authorization is performed between the client application 23 and the smart card server 4, using the standard HTTP authorization exchange, which is briefly depicted in the following:
  • The smart card server 4 will respond to an HTTP request with an HTTP response message containing a Status-Line with a status code “401” (Unauthorized) and a WWW-Authenticate field consisting of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
  • In a preferred embodiment of the invention, the smart card server 4 challenges with a PIN request using a WWW-Authenticate field as follows: WWW-Authenticate : Digest realm= <PINName> Note:
    
    
    <PINName> string can have different values depending on the type of PIN being asked (e.g. “PIN1”, “CHV1”)
  • The response will be sent to the client application 23. The client application 23 should then perform the corresponding dialog with the user (e.g. request PIN or password) and send back the request including an Authorization request header containing the Authorization credentials.
  • Note: for PIN usage, the PIN value is passed in the response data field. The username, if present, may be ignored by the smart card server 23.
  • In the following, an example of communicating HTTP messages between a terminal web browser 23 and a smart card web server 4 will be given.
  • The browser 23 displays the following HTML page: <HTML> <BODY> <A HREF=“http://localsmartcard/7F40/5F30”> Test the smartcard-URI </A>
  • The user clicks on the link.
  • The access verification in this case is PIN verification. The VERIFY PIN command must be sent with the following data: Byte(s) Description Length 1-8 PIN value 8
  • The browser sends the following HTTP GET request to the smart card:
  • GET http://localsmartcard/7F40/5F30 HTTP/1.1
  • The smart card gateway sends the request in BIP commands. The command data is: Byte(s) Description Length 1-Lc GET http://localsmartcard/7F40/5F30 HTTP/1.1 Lc
  • The smart card server 4 may then retrieve the corresponding resource (e.g. content of a file) and send it back with the following HTTP Response sent in BIP commands: Byte(s) Description Length 1-Le HTTP/1.1 200 OK Le Content-type: text/plain Content-length: 3406 This is the content of the file
  • When receiving the response, the gateway 24 will encapsulate it in a TCP/IP packet and send it as an HTTP response packet to the browser.
  • In the following, a definition of a minimal HTTP profile needed for accessing a web server 4 on a smart card 1 is given. The profile is defined as a subset of HTTP 1.1. The following restrictions apply:
  • The URI field can be in absolute form. (e.g. http://localsmartcard/12A1) respecting the rules for smart card URIs as defined in this document.
  • The HTTP version which should be implemented on the smart card web server 4 is HTTP/1.1. Thus, according to HTTP 1.1 specification in RFC 2616, the value of the HTTP-Version field should be “HTTP/1.1”.
  • The following table lists the HTTP methods that should be supported by the smart card web server 4 along with recommendations which one of these should be optional or mandatory: Method Supported OPTIONS Optional GET Mandatory HEAD Mandatory POST Mandatory PUT Mandatory DELETE Optional TRACE Optional CONNECT Optional
  • When receiving an incoming request that is not supported, the smart card server 4 shall respond with an HTTP response message with Status-Code=405 (Method not allowed).
  • The following table lists the GENERAL headers to be supported by the smart card web server along with recommendations which ones of these should be optional or mandatory. Field Supported Connection Mandatory Date Optional Pragma Optional Trailer Optional Transfer-Encoding Optional Upgrade Optional Via Optional Warning Optional
  • Specific actions on reception:
  • The smart card web server 4 will ignore the non-supported fields.
  • The following listed REQUEST header fields for each of the HTTP request messages should be supported by the smart card web server 4. Field Supported Additional comments Accept Optional Accept-Charset Optional Accept-Encoding Optional Accept-Language Optional Authorization Mandatory Expect Optional From Optional Host Optional Host field SHALL be empty. If-Match Optional If-Modified-Since Optional If-None-Match Optional If-Range Optional If-Unmodified-Since Optional Max-Forwards Optional Proxy-Authorization Optional Not applicable Range Optional Referer Optional TE Optional User-Agent Optional
  • Specific actions on reception:
  • The “Host” field shall be omitted, since requested URI is always in absolute form.
  • The “Authorization” field is described above 5
  • The smart card server 4 should support the following status codes: Successful Status-Code = 200 OK |201 Created |204 No Content |205 Reset Content
  • Client Error Status-Code = 401 Unauthorized |403 Forbidden |404 Not Found |405 Method Not Allowed |413 Request Entity Too Large |414 Request-URI Too Large
  • Server Error Status-Code = 500 Internal Server Error |505 HTTP Version not supported
  • The following table lists the RESPONSE header fields for each of the HTTP request messages that should be supported by the corresponding sending/receiving entities. Field Supported Additional comments Accept-Ranges Optional Age Optional ETag Optional Location Optional Proxy-Authenticate Optional N/A Retry-After Optional Server Optional Vary Optional WWW-Authenticate Mandatory c.f. above
  • Specific actions on reception:
  • None
  • The smart card web server may support the following ENTITY header fields, for each of the HTTP request messages. Field Supported Allow Optional Content-Encoding Optional Content-Language Optional Content-Length Mandatory Content-Location Optional Content-MD5 Mandatory Content-Range Optional Content-Type Mandatory Expires Optional Last-Modified Optional Extension-header Optional
  • Specific actions on sending entities:
  • “Content-Type” HTTP header field should be included by the smart card server depending on the resource being transferred within the HTTP response.

Claims (25)

1. Method of offering the services of an HTTP or HTTPS server, the server being implemented by or running on a first electronic device, to a second electronic device, characterized in that the first electronic device exchanges HTTP messages with the second electronic device over a communication channel between the first and the second electronic device according to the Bearer Independent Protocol.

2. Method according to

claim 1

, characterized in that the HTTP messages communicated by the first electronic device to the second electronic device over the communication channel are determined to be further communicated within the second electronic device over TCP/IP to an application running on the second electronic device, and in that the HTTP messages received by the first electronic device from the second electronic device have been communicated within the second electronic device over TCP/IP.

3. Method according to

claim 2

, characterized in that the application running on the second electronic device is a web browser and in that the HTTP or HTTPS server serves HTML, xHTML, cHTML or WML pages to this web browser.

4. Method according to one

claim 1

, characterized in that the DECLARE SERVICE command is used to notify the second electronic device that the first electronic device offers the services of the HTTP or HTTPS server.

5. Method according to

claim 1

, characterized in that the user can be authenticated with a standard HTTP WWW-Authenticate delivering PIN-Type and/or PIN-Value attributes.

6. Method according to

claim 1

, characterized in that the first electronic device is a smart card.

7. Method according to

claim 1

, characterized in that the first electronic device is a Multi Media Memory card.

8. Method according to

claim 1

, characterized in that the second electronic device is a mobile telephone.

9. Method according to

claim 1

, characterized in that the second electronic device is a PDA.

10. Method according to

claim 1

, characterized in that the second electronic device is a PC.

11. Computer program element comprising computer program code means to make an electronic device execute the method according to

claim 1

.

12. Electronic device implementing or running an HTTP or HTTPS server executing the method according to

claim 1

.

13. Method of enabling an application running on a second electronic device to use the TCP/IP protocol for exchanging HTTP messages with an HTTP or HTTPS server being implemented by or running on a first electronic device, a communication channel according to the Bearer Independent Protocol being used for exchanging the HTTP messages between the first and the second electronic device, characterized in that on the second electronic device the communication channel is managed by a gateway which performs protocol conversion Bearer Independent Protocol—TCP/IP for messages being received from the HTTP or HTTPS server, and protocol conversion TCP/IP—Bearer Independent Protocol for messages being sent to the HTTP or HTTPS server.

14. Method according to

claim 13

, characterized in that an internal IP address and an internal domain name are allocated for the gateway and the internal domain name is mapped to the internal IP address, and in that the internal domain name is used in Uniform Resource Identifiers to indicate that the Uniform Resource Identifier identifies a resource on the first electronic device.

15. Method according to

claim 13

, characterized in that the first electronic device is a Multi Media Memory card.

16. Method according to

claim 13

, characterized in that the first electronic device is a smart card.

17. Method according to

claim 14

, characterized in that first electronic device is a smart card and in that the Uniform Resource Identifier comprises information to access standardized smart card applications such as (U)SIM and WBVI.

18. Method according to

claim 13

, characterized in that a command is sent to the first electronic device in order to open a communication channel when the application running on the second electronic device opens a TCP/IP socket to the gateway.

19. Method according to

claim 18

, characterized in that the TCP/IP socket is mapped to the opened communication channel.

20. Method according to

claim 13

, characterized in that the application running on the second electronic device is a web browser.

21. Method according to

claim 13

, characterized in that the second electronic device is a mobile telephone.

22. Method according to

claim 13

, characterized in that the second electronic device is a PDA.

23. Method according to

claim 13

, characterized in that the second electronic device is a PC.

24. Computer program element comprising computer program code means to make an electronic device execute the method according to

claim 13

.

25. Electronic device running an application and executing the method according to

claim 13.

US11/629,546 2004-06-15 2005-06-10 Protocol conversion “Bearer Independent Protocol (BIP)”—TCP/IP for communication between SIM and terminal Expired - Fee Related US8447836B2 (en)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date TitleEP04291503 2004-06-15EP04291503 2004-06-15EP04291503.3 2004-06-15EP04292033A EP1608123A1 (en) 2004-06-15 2004-08-11 Method and device for communicating HTTP messages with portable devices EP04292033.0 2004-08-11EP04292033 2004-08-11PCT/IB2005/001621 WO2005125154A1 (en) 2004-06-15 2005-06-10 Protocol conversion “bearer independent protocol (bip)”- tcp/ip for communication between sim and terminal

Publications (2)

Publication Number Publication DateUS20070239857A1 true US20070239857A1 (en) 2007-10-11US8447836B2 US8447836B2 (en) 2013-05-21

Family

ID=34970683

Family Applications (1)

Application Number Title Priority Date Filing DateUS11/629,546 Expired - Fee Related US8447836B2 (en) 2004-06-15 2005-06-10 Protocol conversion “Bearer Independent Protocol (BIP)”—TCP/IP for communication between SIM and terminal

Country Status (6)

Country LinkUS (1)US8447836B2 (en)EP (2)EP1608123A1 (en)AT (1)ATE440436T1 (en)DE (1)DE602005016109D1 (en)ES (1)ES2334367T3 (en)WO (1)WO2005125154A1 (en)

Cited By (41)

* Cited by examiner, † Cited by third party Publication number Priority date Publication date Assignee TitleUS20090113025A1 (en)* 2007-10-31 2009-04-30George Sarosi System and method for remotely accessing cablecard US20090177848A1 (en)* 2008-01-07 2009-07-09Sandisk Il Ltd. Methods and systems for classifying storage systems using fixed static-ip addresses US20090177781A1 (en)* 2008-01-07 2009-07-09Sandisk Il Ltd. Methods and systems for communicating with storage systems using slim ip stacks US20090191917A1 (en)* 2005-11-21 2009-07-30Nec Corporation Method of communication between a (u)sim card in a server mode and a client US20100325269A1 (en)* 2008-07-10 2010-12-23Sk Telecom. Co., Ltd Personalized service system based on smart card and method thereof, and smart card applied to the same US20110111802A1 (en)* 2008-01-16 2011-05-12Oliver Richter Portable data carrier comprising a cat interpreter US20120064942A1 (en)* 2010-07-29 2012-03-15Myriad Group Ag Method for the connection between a MMSIM card and an application US20120142332A1 (en)* 2009-06-30 2012-06-07Zte Corporation Data download method and terminal US20120158940A1 (en)* 2009-09-02 2012-06-21Gemalto Sa Method for a secure device to resolve an ip address of a target server WO2012085624A1 (en)* 2010-12-23 2012-06-28Research In Motion Limited Card toolkit support for ip multimedia subsystem US20120168494A1 (en)* 2009-09-22 2012-07-05Sk Telecom Co., Ltd. Smart card-based browsing system and smart card-based browsing method and smart card for the same US20120204206A1 (en)* 2009-08-04 2012-08-09Telefonica, S.A. System and method for controlling access to contents US8532136B1 (en)* 2005-10-19 2013-09-10American Megatrends, Inc. Communication with a handset via a private network US20130290479A1 (en)* 2010-06-08 2013-10-31Gemalto Sa Method for connecting to a remote server from a browser enabled with a browser's extension on a host device US8606319B2 (en) 2010-10-20 2013-12-10Blackberry Limited Card application toolkit support for IP multimedia subsystem US20130329683A1 (en)* 2010-12-06 2013-12-12Gemalto Sa Method for remotely delivering a full subscription profile to a uicc over ip US20140003248A1 (en)* 2012-06-27 2014-01-02Qualcomm Incorporated Systems and methods for bearer independent protocol gateway optimization US8788670B2 (en) 2008-10-31 2014-07-22Gemalto Sa Method for establishing a link between the applications of an authentication card of a subscriber and an IMS network US8983541B2 (en) 2010-10-20 2015-03-17Blackberry Limited Card application toolkit support for IP multimedia subsystem US20150106456A1 (en)* 2013-10-10 2015-04-16Jvl Ventures, Llc Systems, methods, and computer program products for managing communications US20150119017A1 (en)* 2012-06-21 2015-04-30Huizhou Tcl Mobile Communication Co., Ltd. Method and system for implementing smart card remote operation based on smart card web server JP2015513729A (en)* 2012-02-22 2015-05-14中▲興▼通▲訊▼股▲フン▼有限公司 Data access method and apparatusUS9154929B2 (en) 2011-04-26 2015-10-06Blackberry Limited Transmission of the PDP context activation rejection cause codes to the UICC US20160065695A1 (en)* 2013-11-01 2016-03-03At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device US9408066B2 (en) 2010-12-06 2016-08-02Gemalto Inc. Method for transferring securely the subscription information and user data from a first terminal to a second terminal US9560025B2 (en) 2013-11-27 2017-01-31At&T Intellectual Property I, L.P. Apparatus and method for secure delivery of data from a communication device US20170063416A1 (en)* 2009-10-01 2017-03-02T-Mobile Usa, Inc. System and method for pairing a uicc card with a particular mobile communications device US20170237825A1 (en)* 2014-08-27 2017-08-17Huawei Technologies Co., Ltd. Resource Download Method, Electronic Device, and Apparatus US9813428B2 (en) 2013-10-28 2017-11-07At&T Intellectual Property I, L.P. Apparatus and method for securely managing the accessibility to content and applications US9882902B2 (en) 2013-11-01 2018-01-30At&T Intellectual Property I, L.P. Apparatus and method for secure provisioning of a communication device US9886690B2 (en) 2012-11-19 2018-02-06At&T Mobility Ii Llc Systems for provisioning universal integrated circuit cards US9967247B2 (en) 2014-05-01 2018-05-08At&T Intellectual Property I, L.P. Apparatus and method for managing security domains for a universal integrated circuit card US10015665B2 (en) 2012-11-16 2018-07-03At&T Intellectual Property I, L.P. Methods for provisioning universal integrated circuit cards KR101863677B1 (en)* 2010-10-27 2018-07-13에스케이플래닛 주식회사 System and method for interfacing between terminal and smart card US20180249397A1 (en)* 2015-03-31 2018-08-30Gemalto Sa Method and chip for detecting a corruption of at least one configuration parameter US10091655B2 (en) 2013-09-11 2018-10-02At&T Intellectual Property I, L.P. System and methods for UICC-based secure communication US10104062B2 (en) 2013-10-23 2018-10-16At&T Intellectual Property I, L.P. Apparatus and method for secure authentication of a communication device US10122534B2 (en) 2013-10-04 2018-11-06At&T Intellectual Property I, L.P. Apparatus and method for managing use of secure tokens US10356208B2 (en) 2013-11-27 2019-07-16At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions according to client device states CN111464550A (en)* 2020-04-10 2020-07-28南京铱迅信息技术股份有限公司 HTTPS transparent protection method for message processing equipment CN114430548A (en)* 2020-10-15 2022-05-03中移互联网有限公司 Service processing method, device and system

Families Citing this family (24)

* Cited by examiner, † Cited by third party Publication number Priority date Publication date Assignee TitleDE102005024122A1 (en)* 2005-05-25 2006-11-30Infineon Technologies Ag Radio-communication arrangement, has data processing device determining whether data is addressed to circuit card, and web-server-program receiving data from circuit card and transmitting to network according to Internet-protocol US8559987B1 (en)* 2005-12-31 2013-10-15Blaze Mobile, Inc. Wireless bidirectional communications between a mobile device and associated secure element DE102006024882A1 (en)* 2006-05-24 2007-11-29Sagem Orga Gmbh smart cardDE102006041526A1 (en)* 2006-09-05 2008-03-20Giesecke & Devrient Gmbh Portable data carrier for communication with a telecommunication terminalEP1903466A1 (en)* 2006-09-20 2008-03-26Axalto SA A method for communicating with a personal token, comprising encapsulating a request inside a response EP1903465A1 (en)* 2006-09-20 2008-03-26Axalto SA A SIP communication with a secure personal token for interacting with personal data EP1933528B9 (en)* 2006-12-12 2018-05-23Orange Secure service access from a communication apparatus with a personal device CN101325592B (en) 2007-06-14 2011-04-20华为技术有限公司 Method, apparatus and system for establishing load-bearing connection DE102007050836A1 (en)* 2007-10-24 2009-04-30Giesecke & Devrient Gmbh Internet smart cardDE102008004384A1 (en)* 2008-01-15 2009-07-16Giesecke & Devrient Gmbh Secure data communicationEP2107807A1 (en)* 2008-04-04 2009-10-07Irdeto Access B.V. Conditional access system and smartcard for use in conditional access system DE102009004181A1 (en)* 2008-04-11 2009-10-15Giesecke & Devrient Gmbh Processing client requestsCN101335758B (en)* 2008-07-24 2011-09-21中兴通讯股份有限公司 Method and system for access service in SIM card by dual-processor terminal GB0821236D0 (en)* 2008-11-20 2008-12-31Nec Corp Client-server communications in mobile radio communications device CN101600263B (en)* 2009-06-30 2011-05-11中兴通讯股份有限公司 Data transmission method and terminal EP2445170B1 (en)* 2010-10-19 2014-10-08Vodafone Holding GmbH Device and method for contactless short range communication WO2012094675A2 (en)* 2011-01-07 2012-07-12Seven Networks, Inc. System and method for reduction of mobile network traffic used for domain name system (dns) queries US8964973B2 (en) 2012-04-30 2015-02-24General Electric Company Systems and methods for controlling file execution for industrial control systems US8973124B2 (en) 2012-04-30 2015-03-03General Electric Company Systems and methods for secure operation of an industrial controller US9046886B2 (en) 2012-04-30 2015-06-02General Electric Company System and method for logging security events for an industrial control system US9172544B2 (en)* 2012-10-05 2015-10-27General Electric Company Systems and methods for authentication between networked devices KR102264992B1 (en) 2014-12-31 2021-06-15삼성전자 주식회사 Method and Device for allocating a server in wireless communication system US10135790B2 (en) 2015-08-25 2018-11-20Anchorfree Inc. Secure communications with internet-enabled devices CN107454058A (en)* 2017-06-29 2017-12-08广州视源电子科技股份有限公司 A kind of data transmission method for uplink, system, readable storage medium storing program for executing and computer equipment

Citations (7)

* Cited by examiner, † Cited by third party Publication number Priority date Publication date Assignee TitleUS20030067909A1 (en)* 2001-08-13 2003-04-10Belhassen Jerbi Method and apparatus for setting up a communications link US20040131083A1 (en)* 2001-04-09 2004-07-08Francois-Xavier Arques Method for data transmission by a mobile station comprising a datagram size (mds) determination US20040176134A1 (en)* 2002-07-26 2004-09-09Scott Goldthwaite System and method for mobile transactions using the bearer independent protocol US20050138004A1 (en)* 2003-12-17 2005-06-23Microsoft Corporation Link modification system and method US20050259673A1 (en)* 2004-05-18 2005-11-24Axalto 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 US20080010456A1 (en)* 2003-01-31 2008-01-10Jacques Seif Communication between a smart card and a server US20080133760A1 (en)* 2002-11-02 2008-06-05Berkvens Winfried Antonius Hen Method and Apparatus Allowing Remote Access in Data Networks

  • 2004
    • 2004-08-11 EP EP04292033A patent/EP1608123A1/en not_active Withdrawn
  • 2005
    • 2005-06-10 DE DE602005016109T patent/DE602005016109D1/en active Active
    • 2005-06-10 AT AT05750686T patent/ATE440436T1/en not_active IP Right Cessation
    • 2005-06-10 US US11/629,546 patent/US8447836B2/en not_active Expired - Fee Related
    • 2005-06-10 WO PCT/IB2005/001621 patent/WO2005125154A1/en active Application Filing
    • 2005-06-10 EP EP05750686A patent/EP1757070B1/en not_active Not-in-force
    • 2005-06-10 ES ES05750686T patent/ES2334367T3/en active Active

Patent Citations (7)

* Cited by examiner, † Cited by third party Publication number Priority date Publication date Assignee TitleUS20040131083A1 (en)* 2001-04-09 2004-07-08Francois-Xavier Arques Method for data transmission by a mobile station comprising a datagram size (mds) determination US20030067909A1 (en)* 2001-08-13 2003-04-10Belhassen Jerbi Method and apparatus for setting up a communications link US20040176134A1 (en)* 2002-07-26 2004-09-09Scott Goldthwaite System and method for mobile transactions using the bearer independent protocol US20080133760A1 (en)* 2002-11-02 2008-06-05Berkvens Winfried Antonius Hen Method and Apparatus Allowing Remote Access in Data Networks US20080010456A1 (en)* 2003-01-31 2008-01-10Jacques Seif Communication between a smart card and a server US20050138004A1 (en)* 2003-12-17 2005-06-23Microsoft Corporation Link modification system and method US20050259673A1 (en)* 2004-05-18 2005-11-24Axalto 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

Cited By (93)

* Cited by examiner, † Cited by third party Publication number Priority date Publication date Assignee TitleUS8532136B1 (en)* 2005-10-19 2013-09-10American Megatrends, Inc. Communication with a handset via a private network US20090191917A1 (en)* 2005-11-21 2009-07-30Nec Corporation Method of communication between a (u)sim card in a server mode and a client US8316150B2 (en)* 2007-10-31 2012-11-20Time Warner Cable Inc. System and method for remotely accessing cablecard US9178945B2 (en) 2007-10-31 2015-11-03Time Warner Cable Enterprises Llc System and method for remotely accessing cablecard module US20090113025A1 (en)* 2007-10-31 2009-04-30George Sarosi System and method for remotely accessing cablecard US20090177848A1 (en)* 2008-01-07 2009-07-09Sandisk Il Ltd. Methods and systems for classifying storage systems using fixed static-ip addresses US20090177781A1 (en)* 2008-01-07 2009-07-09Sandisk Il Ltd. Methods and systems for communicating with storage systems using slim ip stacks US7882249B2 (en) 2008-01-07 2011-02-01Sandisk Il Ltd. Methods and systems for communicating with storage systems using slim IP stacks US8028122B2 (en) 2008-01-07 2011-09-27Sandisk Il Ltd. Methods and systems for classifying storage systems using fixed static-IP addresses US20110111802A1 (en)* 2008-01-16 2011-05-12Oliver Richter Portable data carrier comprising a cat interpreter US8966108B2 (en)* 2008-01-16 2015-02-24Giesecke & Devrient Gmbh Portable data carrier comprising a CAT interpreter US20100325269A1 (en)* 2008-07-10 2010-12-23Sk Telecom. Co., Ltd Personalized service system based on smart card and method thereof, and smart card applied to the same US8504685B2 (en)* 2008-07-10 2013-08-06SK Planet Co., Ltd Personalized service system based on smart card and method thereof, and smart card applied to the same US8788670B2 (en) 2008-10-31 2014-07-22Gemalto Sa Method for establishing a link between the applications of an authentication card of a subscriber and an IMS network US8666385B2 (en)* 2009-06-30 2014-03-04Zte Corporation Data download method and terminal US20120142332A1 (en)* 2009-06-30 2012-06-07Zte Corporation Data download method and terminal US20120204206A1 (en)* 2009-08-04 2012-08-09Telefonica, S.A. System and method for controlling access to contents JP2013504235A (en)* 2009-09-02 2013-02-04ジエマルト・エス・アー How secure device resolves IP address of target serverUS20120158940A1 (en)* 2009-09-02 2012-06-21Gemalto Sa Method for a secure device to resolve an ip address of a target server JP2013505510A (en)* 2009-09-22 2013-02-14エスケー プラネット カンパニー、リミテッド Browsing system based on smart card, browsing method based on smart card and smart card thereforUS20120168494A1 (en)* 2009-09-22 2012-07-05Sk Telecom Co., Ltd. Smart card-based browsing system and smart card-based browsing method and smart card for the same US8579202B2 (en)* 2009-09-22 2013-11-12Sk Planet Co., Ltd. Smart card-based browsing system and smart card-based browsing method and smart card for the same US20170063416A1 (en)* 2009-10-01 2017-03-02T-Mobile Usa, Inc. System and method for pairing a uicc card with a particular mobile communications device US10050657B2 (en)* 2009-10-01 2018-08-14T-Mobile Usa, Inc. System and method for pairing a UICC card with a particular mobile communications device US20130290479A1 (en)* 2010-06-08 2013-10-31Gemalto Sa Method for connecting to a remote server from a browser enabled with a browser's extension on a host device US20120064942A1 (en)* 2010-07-29 2012-03-15Myriad Group Ag Method for the connection between a MMSIM card and an application US8606319B2 (en) 2010-10-20 2013-12-10Blackberry Limited Card application toolkit support for IP multimedia subsystem US8983541B2 (en) 2010-10-20 2015-03-17Blackberry Limited Card application toolkit support for IP multimedia subsystem KR101863677B1 (en)* 2010-10-27 2018-07-13에스케이플래닛 주식회사 System and method for interfacing between terminal and smart card US9817993B2 (en) 2010-12-06 2017-11-14Gemalto Sa UICCs embedded in terminals or removable therefrom US9294919B2 (en) 2010-12-06 2016-03-22Gemalto Sa Method for exporting on a secure server data comprised on a UICC comprised in a terminal US10242210B2 (en) 2010-12-06 2019-03-26Gemalto Sa Method for managing content on a secure element connected to an equipment US20130329683A1 (en)* 2010-12-06 2013-12-12Gemalto Sa Method for remotely delivering a full subscription profile to a uicc over ip US9532223B2 (en) 2010-12-06 2016-12-27Gemalto Sa Method for downloading a subscription from an operator to a UICC embedded in a terminal US9037193B2 (en) 2010-12-06 2015-05-19Gemalto Sa Method for switching between a first and a second logical UICCS comprised in a same physical UICC US9946888B2 (en) 2010-12-06 2018-04-17Gemalto Sa System for managing multiple subscriptions in a UICC US9690950B2 (en) 2010-12-06 2017-06-27Gemalto Sa Method for exporting data of a Javacard application stored in a UICC to a host US9462475B2 (en) 2010-12-06 2016-10-04Gemalto Sa UICCs embedded in terminals or removable therefrom US9408066B2 (en) 2010-12-06 2016-08-02Gemalto Inc. Method for transferring securely the subscription information and user data from a first terminal to a second terminal US9760726B2 (en)* 2010-12-06 2017-09-12Gemalto Sa Method for remotely delivering a full subscription profile to a UICC over IP US9326146B2 (en) 2010-12-06 2016-04-26Gemalto Inc. Method for downloading a subscription in an UICC embedded in a terminal US9301145B2 (en) 2010-12-06 2016-03-29Gemalto Sa UICCs embedded in terminals or removable therefrom US20140010148A1 (en)* 2010-12-23 2014-01-09Research In Motion Limited Card Toolkit Support for IP Multimedia Subsystem CN103270807A (en)* 2010-12-23 2013-08-28捷讯研究有限公司 Card toolkit support for ip multimedia subsystem US20120166654A1 (en)* 2010-12-23 2012-06-28Research In Motion Limited Card Toolkit Support for IP Multimedia Subsystem US9717063B2 (en)* 2010-12-23 2017-07-25Blackberry Limited Card toolkit support for IP multimedia subsystem WO2012085624A1 (en)* 2010-12-23 2012-06-28Research In Motion Limited Card toolkit support for ip multimedia subsystem US9619442B2 (en)* 2010-12-23 2017-04-11Blackberry Limited Card toolkit support for IP multimedia subsystem US9154929B2 (en) 2011-04-26 2015-10-06Blackberry Limited Transmission of the PDP context activation rejection cause codes to the UICC JP2015513729A (en)* 2012-02-22 2015-05-14中▲興▼通▲訊▼股▲フン▼有限公司 Data access method and apparatusUS9497620B2 (en)* 2012-06-21 2016-11-15Huizhou Tcl Mobile Communication Co., Ltd. Method and system for implementing smart card remote operation based on smart card web server EP2866418B1 (en)* 2012-06-21 2019-02-27Huizhou TCL Mobile Communication Co., Ltd. Method and system for implementing smart card remote operation based on smart card web server US20150119017A1 (en)* 2012-06-21 2015-04-30Huizhou Tcl Mobile Communication Co., Ltd. Method and system for implementing smart card remote operation based on smart card web server US20140003248A1 (en)* 2012-06-27 2014-01-02Qualcomm Incorporated Systems and methods for bearer independent protocol gateway optimization JP2015524586A (en)* 2012-06-27 2015-08-24クアルコム,インコーポレイテッド Socket management method with bearer independent protocolUS9094433B2 (en)* 2012-06-27 2015-07-28Qualcomm Incorporated Systems and methods for bearer independent protocol gateway optimization US10015665B2 (en) 2012-11-16 2018-07-03At&T Intellectual Property I, L.P. Methods for provisioning universal integrated circuit cards US10834576B2 (en) 2012-11-16 2020-11-10At&T Intellectual Property I, L.P. Methods for provisioning universal integrated circuit cards US10681534B2 (en) 2012-11-16 2020-06-09At&T Intellectual Property I, L.P. Methods for provisioning universal integrated circuit cards US9886690B2 (en) 2012-11-19 2018-02-06At&T Mobility Ii Llc Systems for provisioning universal integrated circuit cards US11368844B2 (en) 2013-09-11 2022-06-21At&T Intellectual Property I, L.P. System and methods for UICC-based secure communication US10735958B2 (en) 2013-09-11 2020-08-04At&T Intellectual Property I, L.P. System and methods for UICC-based secure communication US10091655B2 (en) 2013-09-11 2018-10-02At&T Intellectual Property I, L.P. System and methods for UICC-based secure communication US10122534B2 (en) 2013-10-04 2018-11-06At&T Intellectual Property I, L.P. Apparatus and method for managing use of secure tokens US20150106456A1 (en)* 2013-10-10 2015-04-16Jvl Ventures, Llc Systems, methods, and computer program products for managing communications KR101842666B1 (en)* 2013-10-10 2018-05-14구글 엘엘씨 Systems, methods, and computer program products for managing communications US10778670B2 (en) 2013-10-23 2020-09-15At&T Intellectual Property I, L.P. Apparatus and method for secure authentication of a communication device US10104062B2 (en) 2013-10-23 2018-10-16At&T Intellectual Property I, L.P. Apparatus and method for secure authentication of a communication device US9813428B2 (en) 2013-10-28 2017-11-07At&T Intellectual Property I, L.P. Apparatus and method for securely managing the accessibility to content and applications US11477211B2 (en) 2013-10-28 2022-10-18At&T Intellectual Property I, L.P. Apparatus and method for securely managing the accessibility to content and applications US11005855B2 (en) 2013-10-28 2021-05-11At&T Intellectual Property I, L.P. Apparatus and method for securely managing the accessibility to content and applications US10104093B2 (en) 2013-10-28 2018-10-16At&T Intellectual Property I, L.P. Apparatus and method for securely managing the accessibility to content and applications US10375085B2 (en) 2013-10-28 2019-08-06At&T Intellectual Property I, L.P. Apparatus and method for securely managing the accessibility to content and applications US9628587B2 (en)* 2013-11-01 2017-04-18At&T Intellectual Property I, L.P. Apparatus and method for secure over the air programming of a communication device US9942227B2 (en) 2013-11-01 2018-04-10At&T Intellectual Property I, L.P. Apparatus and method for secure over the air programming of a communication device US10200367B2 (en) 2013-11-01 2019-02-05At&T Intellectual Property I, L.P. Apparatus and method for secure provisioning of a communication device US9882902B2 (en) 2013-11-01 2018-01-30At&T Intellectual Property I, L.P. Apparatus and method for secure provisioning of a communication device US10567553B2 (en) 2013-11-01 2020-02-18At&T Intellectual Property I, L.P. Apparatus and method for secure over the air programming of a communication device US20160065695A1 (en)* 2013-11-01 2016-03-03At&T Intellectual Property I, Lp Apparatus and method for secure over the air programming of a communication device US10701072B2 (en) 2013-11-01 2020-06-30At&T Intellectual Property I, L.P. Apparatus and method for secure provisioning of a communication device US10356208B2 (en) 2013-11-27 2019-07-16At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions according to client device states US9560025B2 (en) 2013-11-27 2017-01-31At&T Intellectual Property I, L.P. Apparatus and method for secure delivery of data from a communication device US9729526B2 (en) 2013-11-27 2017-08-08At&T Intellectual Property I, L.P. Apparatus and method for secure delivery of data from a communication device US10827032B2 (en) 2013-11-27 2020-11-03At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions according to client device states US10476859B2 (en) 2014-05-01 2019-11-12At&T Intellectual Property I, L.P. Apparatus and method for managing security domains for a universal integrated circuit card US9967247B2 (en) 2014-05-01 2018-05-08At&T Intellectual Property I, L.P. Apparatus and method for managing security domains for a universal integrated circuit card US20170237825A1 (en)* 2014-08-27 2017-08-17Huawei Technologies Co., Ltd. Resource Download Method, Electronic Device, and Apparatus US10979532B2 (en) 2014-08-27 2021-04-13Huawei Technologies, Co., Ltd. Resource download method, electronic device, and apparatus US10462258B2 (en)* 2014-08-27 2019-10-29Huawei Technologies Co., Ltd. Resource download method, electronic device, and apparatus US10779220B2 (en)* 2015-03-31 2020-09-15Thales Dis France Sa Method and chip for detecting a corruption of at least one configuration parameter US20180249397A1 (en)* 2015-03-31 2018-08-30Gemalto Sa Method and chip for detecting a corruption of at least one configuration parameter CN111464550A (en)* 2020-04-10 2020-07-28南京铱迅信息技术股份有限公司 HTTPS transparent protection method for message processing equipment CN114430548A (en)* 2020-10-15 2022-05-03中移互联网有限公司 Service processing method, device and system

Also Published As

Publication number Publication dateEP1757070A1 (en) 2007-02-28EP1608123A1 (en) 2005-12-21US8447836B2 (en) 2013-05-21WO2005125154A1 (en) 2005-12-29ES2334367T3 (en) 2010-03-09DE602005016109D1 (en) 2009-10-01ATE440436T1 (en) 2009-09-15EP1757070B1 (en) 2009-08-19

Similar Documents

Publication Publication Date TitleUS8447836B2 (en) 2013-05-21 Protocol conversion “Bearer Independent Protocol (BIP)”—TCP/IP for communication between SIM and terminal KR100644616B1 (en) 2006-11-10 Method for single-sign-on based on markup language, and system for the same CN102333110B (en) 2014-10-15 VPN network client for mobile device having fast reconnect CN101010927A (en) 2007-08-01 Protocol conversion &

39;bearer independent protocol (bip)&

39;-TCP/IP for communication between SIM and terminal CN102333075B (en) 2014-10-15 VPN network client for mobile device having fast reconnect CN102316092B (en) 2014-03-26 VPN network client for mobile device having fast reconnect CN102333306B (en) 2015-06-24 Multi-service vpn network client for mobile device having integrated acceleration CN102316094B (en) 2015-06-24 Multi-service VPN network client for mobile device having integrated acceleration CN102316153B (en) 2014-11-05 VPN network client for mobile device having dynamically constructed display for native access to web mail CN102316093B (en) 2014-11-12 Dual-Mode Multi-Service VPN Network Client for Mobile Device US7197125B1 (en) 2007-03-27 Method and apparatus for selecting and managing wireless network services using a directory FI109756B (en) 2002-09-30 A method of utilizing local resources in a communication system, a communication system and wireless communicationUS7644163B2 (en) 2010-01-05 Plug and play mobile services US9641495B2 (en) 2017-05-02 Method for user identification US20050014489A1 (en) 2005-01-20 System, apparatus, and method for providing a mobile server US20040152446A1 (en) 2004-08-05 Method for providing network access to a mobile terminal and corresponding network US20090158402A1 (en) 2009-06-18 System and method for authorizing access request for home network US7752322B2 (en) 2010-07-06 System for ubiquitous network presence and access without cookies CA2468667A1 (en) 2003-06-05 System and method for identifying and accessing network services JP2003523033A (en) 2003-07-29 Method of registering a user on a directory server of an Internet type network and / or searching for a user on said network, and a smart card for implementing said methodCA2361726A1 (en) 2000-08-10 A telecommunications gateway EP1251671B1 (en) 2005-11-23 A method of providing a proxy server based service to a communications device on a network US7743405B2 (en) 2010-06-22 Method of authentication via a secure wireless communication system US20100223462A1 (en) 2010-09-02 Method and device for accessing services and files RU2537275C2 (en) 2014-12-27 Smart card security feature profile in home subscriber server

Date Code Title Description 2006-12-14 AS Assignment

Owner name:AXALTO SA, FRANCE

Free format text:ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MAHALAL, ILAN;SEVILLA, JORGE ABELLAN;REEL/FRAME:018712/0802;SIGNING DATES FROM 20050630 TO 20050708

Owner name:AXALTO SA, FRANCE

Free format text:ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MAHALAL, ILAN;SEVILLA, JORGE ABELLAN;SIGNING DATES FROM 20050630 TO 20050708;REEL/FRAME:018712/0802

2011-11-11 AS Assignment

Owner name:GEMALTO SA, FRANCE

Free format text:CHANGE OF NAME;ASSIGNOR:AXALTO SA;REEL/FRAME:027216/0331

Effective date:20081001

2013-05-01 STCF Information on status: patent grant

Free format text:PATENTED CASE

2016-10-27 FPAY Fee payment

Year of fee payment:4

2021-01-11 FEPP Fee payment procedure

Free format text:MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

2021-06-28 LAPS Lapse for failure to pay maintenance fees

Free format text:PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY