US2010070649A1PendingUtilityA1

Process for communication between a device running java me and a server over the air, as well as related system

Assignee: NG CHEE WEIPriority: Nov 30, 2006Filed: Nov 30, 2007Published: Mar 18, 2010
Est. expiryNov 30, 2026(~0.3 yrs left)· nominal 20-yr term from priority
Inventors:Chee Wei Ng
H04L 67/02
41
PatentIndex Score
0
Cited by
0
References
0
Claims

Abstract

Process of communication via HTTP or HTTPS between a device running Java ME® and a server over the air, said server receiving and transmitting SOAP (Simple Object Access Protocol) messages from/to an operator on a host over a network and being capable of exchanging SOAP messages under Application Protocol Data Unit (APDU) data form/with the device, characterized in that the SOAP messages are translated from/to binary messages according to a protocol in the server, said binary messages being exchanged with the device, the binary messages being binary request messages or binary response messages.

Claims

exact text as granted — not AI-modified
1 . A process of communication between a secure element and a host server, comprising:
 a. generating a batch of APDU commands (SOAP) by said host server;   b. sending said batch of APDU commands from said host server to said secure element;   c. transforming said batch of APDU commands (SOAP) to a binary message by a download gateway for optimization of a network;   d. fragmenting said batch of APDU commands to support limitations of said network and the secure element;   e. managing a retry mechanism and save failure point during the binary message exchange to support an auto recovery function;   f. managing the communication to said download gateway by a Java ME (J2ME) application on the secure element;   g. assembling fragmented binary message by said J2ME application on the secure element;   h. forwarding said APDU commands to said secure element one by one by said J2ME application on the secure element;   i. collecting all APDU responses by said J2ME application on the secure element; and   j. building a response binary message by batch by said J2ME application on the secure element.   
   
   
       2 . A process according to  claim 1 , in which the binary messages include one or more binary request messages and binary response messages,
 the binary request message comprising:
 a header segment of seven bytes; 
 a body segment part of N bytes; and 
 an information segment part of five bytes, 
   the binary response message including:
 a header segment part of seven bytes; 
 a body segment part of N bytes; and 
 an information segment part of three bytes, 
   where N is a variable number.   
   
   
       3 . A process according to  claim 2 , in which the header segment comprises:
 a response code of one byte;   a session ID length of variable length;   an error code of one byte;   a batch sequence of one byte;   a fragmented packet sequence of one byte; and   an information segment index of one byte.   
   
   
       4 . A process according to  claim 2 , in which the body segment comprises:
 an APDU data length of one byte;   an APDU data value of variable length;   N set of APDU length of one byte; and   N set of APDU data of variable length,   
     where N is a variable number. 
   
   
       5 . A process according to  claim 2 , in which the information segment comprises:
 an information code of one byte;   an application ID length of one byte;   an application ID value of variable length;   
   
   
       6 . A process according to  claim 5 , in which the information segment comprises:
 an information data length of one byte; and   an information data value of variable length.   
   
   
       7 . A process according to  claim 2 , in which the header segment comprises:
 a response code of one byte;   a session ID length of one byte;   a session ID value of variable length;   an error code of one byte;   a batch sequence of one byte;   a fragmented packet sequence of one byte; an   an information segment index.   
   
   
       8 . A process according to  claim 2 , in which the information segment comprises:
 an information code of one byte.   
   
   
       9 . A process according to  claim 2 , in which more segments are requested by the secure element, wherein:
 the binary request message for one or more fragments, comprising:
 a first header segment part of two bytes and 
 a first body segment part of one byte, 
   the response of the request for more fragment from the server being a binary response message for more fragment, including:
 a second header segment part of two bytes and 
 a second body segment part of one byte. 
   
   
   
       10 . A process according to  claim 9 , in which the one or more of said first and second header segments comprise:
 a command code of one byte and   a fragmented packet sequence of one byte.   
   
   
       11 . A process according to  claim 9 , in which the body segments comprise:
 fragmented APDU data of variable length.   
   
   
       12 . A process according to  claim 1 , further comprising:
 implementing recovery and auto-retry means;   saving messages before sending said messages at predefined saving points of the process, the saving points being:
 in the server, each time the server sends to the secure element a binary message including APDU commands, and, 
 in the secure element, each time the secure element sends to the server a binary message including an execution result of APDU commands. 
   
   
   
       13 . A process according to  claim 12 , further comprising:
 starting a counter of time in the secure element each time the secure element sends an execution result of APDU commands message;   executing, by the secure element, if the server is not reacting after a predetermined count of time, a retry by resending the message from the related saving point; and   authorizing a predetermined number of retries for each saving point and aborting the process after said authorized number of retries is executed.   
   
   
       14 . A process according to  claim 1  wherein said secure element is a smart card device. 
   
   
       15 . A system for communication between a secure element and a host server, wherein the system comprises:
 a secure element of any type, including any form factor of smart card such as SIM or embedded secure element or detachable secure element;   a host server adapted to generate APDU commands to be sent to said secure element;   a download gateway adapted to transform APDU commands to binary message for the optimization of a network;   said download gateway adapted to fragment a group of APDU commands by batch to support the limitations of said network and the secure element;   said download gateway adapted to support an auto recovery function by managing a retry mechanism and save failure point during the binary message exchange;   a Java ME (J2ME) application on the secure element adapted to manage the communication to said download gateway;   said Java ME (J2ME) application on the secure element adapted to assemble the fragmented binary message;   said Java ME (J2ME) application on the secure element adapted to forward APDU commands to a secure element one by one;   said Java ME (J2ME) application on the secure element adapted to collect APDU responses and build a response binary by batch;   
   
   
       16 . A system according to  claim 15 , wherein said binary messages include one or more binary request messages and binary response messages,
 the said binary request message comprising:
 a header segment of seven bytes; 
 a body segment part of N bytes; and 
 an information segment part of five bytes, 
   said binary response message including:
 a header segment part of seven bytes; 
 a body segment part of N bytes; and 
 an information segment part of three bytes, 
   where N a variable number.   
   
   
       17 . A system according to  claim 16 , wherein the header segment comprises:
 a response code of one byte;   a session ID length of variable length;   an error code of one byte;   a batch sequence of one byte;   a fragmented packet sequence of one byte; and   an information segment index of one byte.   
   
   
       18 . A system according to  claim 16 , wherein the body segment comprises:
 an APDU data length of one byte;   an APDU data value of variable length;   N set of APDU length of one byte; and   N set of APDU data of variable length,   
     where N is a variable number. 
   
   
       19 . A system according to  claim 16 , wherein the information segment comprises:
 an information code of one byte;   an application ID length of one byte; and   an application ID value of variable length.   
   
   
       20 . A system according to  claim 19 , wherein the information segment comprises:
 an information data length of one byte; and   an information data value of variable length.   
   
   
       21 . A system according to  claim 16 , wherein the header segment comprises:
 a response code of one byte;   a session ID length of one byte;   a session ID value of variable length;   an error code of one byte;   a batch sequence of one byte;   a fragmented packet sequence of one byte; and   an information segment index of one byte.   
   
   
       22 . A system according to  claim 16 , wherein the information segment comprises:
 an information code of one byte;   
   
   
       23 . A system according to  claim 16 , wherein more segments are requested by said secure element wherein:
 the binary request message for one or more fragment comprising:
 a first header segment part of two bytes and 
 a first body segment part of one byte; 
   the response of the request for one or more fragment from the server being a binary response message for one or more fragment including:
 a second header segment part of two bytes and 
 a second body segment part of one byte. 
   
   
   
       24 . A system according to  claim 23 , wherein one or more of said first and second header segments comprise:
 a command code of one byte and   a fragmented packet sequence of one byte.   
   
   
       25 . A system according to  claim 23 , wherein one or more of said first and second body segments comprise fragmented APDU data of variable length. 
   
   
       26 . A system according to  claim 15 , further comprising:
 recovery and auto-retry means,   
     said server adapted to save messages before sending said messages each time said server sends said secure element a binary message including APDU commands; said secure element adapted to save messages before sending said messages each time said secure element sends said server a binary message including an execution result of APDU commands. 
   
   
       27 . A system according to  claim 26 , further comprising:
 a counter of time adapted to start in said secure element each time said secure element sends an execution result of APDU commands message, said secure element adapted to execute a retry, if the server is not reacting after a predetermined count of time, by resending the message from the related saving point,   
     said secure element adapted to authorize a predetermined number of retries for each said saving point, 
     said secure element adapted to abort the process, after said authorized number of retries is executed. 
   
   
       28 . A system for communication between a secure element and a host server, comprising:
 a. means for generating a batch of APDU commands (SOAP) by said host server;   b. means for sending said batch of APDU commands from said host server to said secure element;   c. means for transforming said batch of APDU commands (SOAP) to a binary message by a download gateway for optimization of a network;   d. means for fragmenting said batch of APDU commands to support limitations of said network and the secure element;   e. means for managing a retry mechanism and save failure point during the binary message exchange to support an auto recovery function;   f. means for managing the communication to said download gateway by a Java ME (J2ME) application on the secure element;   g. means for assembling fragmented binary message by said J2ME application on the secure element;   h. means for forwarding APDU commands to said secure element one by one by said J2ME application on the secure element;   i. means for collecting all APDU responses by said J2ME application on the secure element; and   j. means for building a response binary message by batch by said J2ME application on the secure element.

Join the waitlist — get patent alerts

Track US2010070649A1 — get alerts on status changes and closely related new filings.

We store only your email — no account needed. See our privacy policy.